to-spec
Synthesize the current conversation and codebase understanding into a spec. Reuse settled requirements, implementation choices, and testing decisions; do not reopen them for confirmation. Treat proposals and rejected approaches as context unless the user adopted them.
Resolve routine uncertainty from repository evidence. Surface unresolved facts or decisions when they materially affect behavior, scope, contracts, or acceptance criteria. Ask a focused question only when the missing answer prevents an accurate spec; otherwise record the open decision and what it blocks. Complete the rest of the draft while waiting. Do not reopen the interview or invent a decision to make the spec appear complete.
Resolve the publication target from explicit user context, existing repository conventions, or the Git remote. If the target remains ambiguous, ask before publishing. Use the repository's existing triage label vocabulary; do not create or rename labels implicitly.
Process
-
Reuse relevant repository findings already established in the conversation. Inspect additional code only where needed to ground the spec or resolve a material unknown. Use the project's domain glossary vocabulary throughout the spec, and respect applicable ADRs and the user's latest decisions.
-
Reuse settled testing decisions. Where checks still need to be chosen, use existing interfaces or user workflows that demonstrate the required behavior and catch realistic regressions. Choose where and how many checks to run based on what they must prove; do not force every check through one interface or the full application. Treat a proposed new test interface as a suggestion unless already agreed. Ask only when the choice would change scope or a contract; ordinary test mechanics can remain implementation choices.
-
Write the spec using the relevant sections below, then publish it to the resolved project issue tracker. Preserve material open questions explicitly rather than presenting them as settled requirements, and assess readiness before applying labels.
Readiness
Apply ready-for-agent or a documented equivalent only when the label exists, its repository meaning is established, and all of the following hold: