speckit.companion.living-adopt

Adopt a Code Area into a Living Spec

Bring an existing code area under living specs. You point at an area. The assistant reads its surface, proposes a small tree of capabilities for just that area, drafts a living spec for each, and on your confirmation registers them so the rest of the Living Specs pipeline picks them up.

This is opt-in and incremental. It never scans or rewrites the whole repository on its own, and it changes no other command's behavior.

Reading only the surface limits what you may claim, not what you may write about. Drafts are marked [DRAFT] and low-confidence items are flagged. A requirement that restates a function signature is still not a specification. See step 2.

Input

$ARGUMENTS

The argument is the code area (or areas) to adopt: a directory (e.g. src/billing/), a small set of related files, or several directories.

If the argument is empty, do not scan the whole repo. List the plausible top-level areas, describe each in a line, and ask which to adopt. Offer adopting several at once. "All of them" is a legitimate answer.

If the argument names several areas, adopt them in one run. Propose the full tree across all of them and bring it to the single review gate in step 1. Do not expand beyond what was named.

If the argument is ., the developer asked for the whole project. Read the conventions as always, then propose the tree for the whole source tree. Say at the gate how many capabilities and how many spec files that comes to, and offer a coarser cut (one spec per area) and a finer one (a spec per concern within an area) with the count each gives. Nothing is written until they pick.

The smallest thing that works

Before building anything, stop at the first rung that holds: does it need to exist at all; does this codebase already have it; does the standard library, the platform, or an installed dependency do it; can it be one line; only then, the minimum code that works. Fix the cause where every caller passes through, not the symptom one caller reported. Delete rather than add, boring rather than clever: no interface with one implementation, no factory for one product, no scaffolding for later. Lean governs what you build and write, not how the work is split: sending work to a worker where a step says to is not extra.