intent-to-spec

intent-to-spec Skill

Core Mission

• Success Criteria:
  • Reads current functionality within the user-specified scope (source scope: Intent subtree / packet group / steering constraints / cross-cutting requirements) read-only, binding the three layers with related downstream designs and existing verification results while preserving provenance and confirmation status (R1.1 / R1.2). Follow rules/source-scope.md for source selection.
  • When the source scope is ambiguous, or the corresponding artifact is absent, generates no natural-language Spec and stops, showing the user what is ambiguous (the available scope) or which artifact is missing (the relevant skill to prepare it) (R1.3)
  • Treats the projection sources (intent-tree / compass / packets / steering) read-only, and does not create, modify, or delete them (R1.4)
  • Composes the natural-language Spec per the specified target format (the why-fronted upstream layout / the requirements-crossing integrated spec / their middle), and when no format is specified, uses the default and states explicitly in the output which format it was generated in (R2.1 / R2.4)
  • Satisfies trace assignment, inferred marking, invariant preservation, and the supplemented-places list (done in Step 4; R3.1 / R3.2 / R3.3 / R3.4)
  • Outputs the artifact as derived (regenerable) under .intent/nl-spec/ by full replacement, and never creates, modifies, or deletes any canonical artifact (intent-tree / compass / packets). Does not put operational boilerplate about derivation, source-of-truth status, Git tracking, or internal paths into the generated document (R4.1 / R4.2 / R4.3)
  • Does not modify application code in the intent-planning phase (R4.4). Follows the intent-* naming convention, does not modify external spec tools or the kiro-* development environment, does not call map-cc-sdd.md, and does not change the behavior of /intent-export-cc-sdd (R5.5)

Execution Steps

Step 1: Source interpretation (confirm scope and depth; do not generate if ambiguous/absent)

• Important-decision entry check: Read the target Intent Tree, Intent Compass, packets, and related Open Questions, and use CONTRACT.md to classify important decisions that change this generation's scope or authority. Where human judgment is needed, present a provisional answer, rationale, and conditions that would change the recommendation; pause only the affected scope until a decision, exclusion from scope, or scope-limited explicit continuation is obtained. However, documenting an undecided design in the sources as “unresolved” is not a design decision: do not stop generation or request approval merely to report it. This skill neither updates source materials nor approves designs.
• When the user runs /intent-to-spec, first interpret the argument's scope hint, format specification, and output-depth specification per rules/source-scope.md. For any axis the arguments alone do not uniquely determine, ask the user via AskUserQuestion and wait for the answer before confirming (do not fill in by guessing).
• Document-suite selection: When explicitly asked for “document suite,” “詳細文書群,” or an overall index with designs organized by category, read rules/format-document-suite.md and use its route instead of the subsequent single-document depth, mapping, and destination rules. Share scope confirmation, output-form selection, common reading, and fabrication checks. “Detailed” alone remains a single document. When depth is unspecified, offer “document suite (overall index and designs by category)” alongside the existing three levels in the same question; do not reask an explicit selection. Only when a thickness-fixed layout and a suite are both requested, clarify the intended structure.
• Output-depth confirmation (per the "output-depth axis" in rules/source-scope.md): confirm how deeply to write (brief / standard / detailed), riding the same dialogue completion as the range axes. When depth is made explicit in the arguments (e.g. "detailed," "in brief"), do not ask (do not add unnecessary questions). When it is not explicit, ask once, before generating, via AskUserQuestion (present the three levels as peers, without putting a "reasonable default" up front = anchoring avoidance). This is deliberately asymmetric to how format is treated when unspecified (silently use the default): missing thickness is invisible to the reader, so it is confirmed before generating (details in the corresponding section of source-scope).
• Output-form confirmation (DR189, multiple choice): confirm which form to output (Markdown / self-contained HTML / Marp slide Markdown), riding the same position as the depth confirmation. When the form is made explicit in the arguments (e.g. "in HTML," "and Marp"), do not ask (do not add unnecessary questions). When it is not explicit, ask once, before generating, via AskUserQuestion (multiple choice; present the three forms as peers). When unspecified / unanswered / dialogue is not possible, output only the default Markdown (backward-compatible; the default form is provisional). Write only the chosen forms in Step 5.
• Screen-material handling confirmation (DR190, fires only for a case with no screen-sketch record): only when the layout being generated deals with screens / touchpoints (an integrated design document, etc.) and the intent-tree's ## 画面ラフ参照 (screen-sketch reference) is "none" (not out of scope, and no path/link either), ask the user once before generating, via AskUserQuestion, to choose between "derive a screen-transition diagram with an inferred mark" and "only state 'no screen material'." Do not fire for a case where the screen sketch exists as a "path/link" or a case that is "out of scope" (if it exists, project it; if out of scope, do not raise a screen section). Do not ask when the handling is made explicit in the arguments. The body of the convention follows "Material for the screens / touchpoints section" in rules/format-integrated.md (a derived diagram must have an inferred mark; do not fabricate).
• No-generation gate (fail-fast. R1.3): when the source scope is ambiguous (no axis is uniquely determined by arguments or dialogue) or the corresponding artifact is absent (the specified intent-tree / compass / packet / steering does not exist or is unfilled), generate no natural-language Spec and write nothing under .intent/nl-spec/. Name and present what is ambiguous (the available scope: existing subtrees, packet list, presence of steering) or the missing artifact (the relevant skill to prepare it: discover / compass / packets, etc.), and stop.
• Apply that gate according to the definition of missing foundational materials in rules/source-scope.md. Do not stop solely because a legacy aggregate file is absent when split canonical files exist. Distinguish unresolved individual designs from insufficient reading, and generate the known scope.
• Once scope and depth are confirmed, proceed to Step 2.