Groundwork

View saved version →

---
name: settle
description: Turn a rough idea or underspecified repository change into a decision-complete implementation by inspecting the codebase, discovering intent, resolving material decisions through evidence-backed rounds, then implementing and verifying. Use when the user invokes /groundwork:settle, /settle, or $settle with or without a task, or asks to be brainstormed, grilled, or questioned before coding. Do not use for explanation-only work or pure research.
---

# Settle

Turn an underspecified coding request into a decision-complete implementation,
without making the user answer anything the repository can answer.

## Bare invocation

When the skill is invoked without a task, treat that as a request to begin
discovery, not as an activation check. Never answer that the skill is loaded,
and never ask in prose what the user wants to change or build.

Perform a bounded repository pass over project instructions, README and
manifests, decision records or memory, and the newest relevant tests, outputs,
or history. Then open the host-native question tool:

- put two to four verified facts with source anchors in the assistant text
  immediately before the call, together with the labelled inference and the
  dependency map;
- ask one root only when every other material decision genuinely depends on it;
  otherwise ask as much of the current frontier as the host's per-call cap
  holds;
- when there is no honest root or frontier, offer two or three
  repository-grounded observable outcomes and let the client's free-form Other
  choice carry the user's direction.

A bare invocation must reach the native question tool, not stop after reading
this skill or inspecting the repository.

## Ground yourself first

Read the project instructions, README, manifests, the code that owns the
behavior, and its tests. Search by domain concept, not by the words in the
request: something already built under another name turns a question into a
statement.

Read the newest decision record under `docs/decisions/` that covers the same
flow, when one exists. A decision it settles is a repository closure anchored
by the record's path, and is not asked again unless the code it describes has
changed since; then say what changed and ask it once more.

Finding the cause of the reported symptom ends your reading of *that* bug. It
does not end the inquiry. Keep going until you can see what else the same code
decides, because the second material decision is rarely mentioned in the request
and is usually visible in the same file as the first.

Separate what the repository states from what you concluded. Facts carry a path,
test name, or constant. Conclusions are labelled as yours.

## Size the work

Before the first question, place the request on one of three paths and say
which in the text before the first call. This is a statement the user can
overturn through the free-form choice, not a question.

- **Bounded:** the flow being changed already exists in the repository. A new
  flag or option, a changed default or exit code, a bug fix, or a behavior
  change inside that flow is bounded, however many ways there are to build
  it. Run the rest of this skill as written, and never open an approach
  comparison here: a choice of mechanism inside a bounded change is an
  ordinary single-axis question.
- **Architectural:** only when you can point at a structural marker: a new
  subsystem or service, a new public API or schema, a changed format of
  persistent state, a data migration, a trust boundary, or work spanning
  several repositories or seams. Where no flow exists yet — a new project,
  an empty directory — the work is architectural by definition. That several
  designs are conceivable is not a marker; name the marker when declaring
  this path. Compare approaches first, then run the rest of this skill on
  the approach chosen.
- **Spike:** the requested output is an answer, not code that stays: "can
  we", "is it possible", "how expensive would". State

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 1 — file references are metadata, not package contents.