intent-export-cc-sdd

name	intent-export-cc-sdd
description	Convert one chosen packet into a condensed draft that can be handed to cc-sdd without wasting tokens. Does not intrude on cc-sdd's main generation. Can invoke /kiro-spec-init when instructed to proceed.

intent-export-cc-sdd Skill

Core Mission

• Success Criteria:
  • One target packet is converted into a condensed cc-sdd Project Description + design/tasks hints
  • With the common contract, input is limited to the target packet + selected from the common selection result; only contract absence uses the existing packet + Compass path, and no full Tree/Compass is transcribed into cc-sdd
  • The tasks hints carry parent intent / invariant references, forming a propagation structure to impl
  • The output is led by natural-language guidance, and /kiro-spec-init can be invoked when instructed to proceed
  • No application code has been changed at all

Execution Steps

Step 1: Narrow down to one target packet

• Read .intent/packets/index.md and present the active packet candidates. If index.md is absent, build the candidate list directly from the frontmatter of the files under .intent/packets/active/, continue, and prompt regeneration of the index. If .intent/packets/ itself is absent (or active/ is empty), guide the user to "run /intent-packets first" and stop.
• If a packet is specified by argument, use it; otherwise narrow down to one from the candidates by priority or by asking the user in natural language and waiting for their answer, and read only the file of the confirmed target packet (under .intent/packets/active/) — do not bulk-read all packet files.
• Parked exclusion: when presenting candidates, leave out packets with state: parked (on hold = not now) from the candidate listing (parked is not an export target). Only when a parked packet is explicitly given as an argument, ask the user in natural language "this is a parked packet; continue the export?" and wait for their answer (never export a parked packet without confirmation).
• Warn on a parked dependency: if the confirmed target packet's depends_on includes a packet with state: parked, warn on one line "a dependency is parked ()" (do not stop; false positives are expected — the export continues, since proceeding while a dependency stays parked is sometimes valid).
• Draft guard: when the confirmed target packet's state is draft, ask the user in natural language whether to "activate it and continue the export" and wait for their answer; once the user approves, update the frontmatter state to active and regenerate index.md before continuing (never export a draft as is without confirmation; this activation is the only canonical write the export makes).
• Read the mode state in order: the inherited issue directory's discovery/<slug>-<rand>/mode.md (A34; inherit the issue name that discover output) → else the single .intent/mode.local.md (legacy) → else old .intent/mode.md (the CONTRACT.md read fallback contract). If both are absent, continue with the standard default and announce it.

Step 1.5: Enforcement gate (writeback freshness check)

• From the ## Enforcement (user-managed) section of the .intent/mode.md read in Step 1, check the value of enforcement. If it is off, missing, or an invalid value (including mode.md being absent), skip this check and continue to Step 2 as today.
• When it is remind or gate, run node .intent/scripts/intent-check.mjs (a read-only script; it creates, modifies, and deletes no files) and follow its stdout.
• Interpretation rules for the verdict line: the stop decision is governed solely by block= on the first stdout line (do not re-derive or reinterpret). Whether a warning is needed is decided by result=stale or pending>0. Even when result=not-applicable, use the value of pending= from the verdict line as is.
• When gate and block=yes: present the grounds (the pending packet names and the elapsed commit count / threshold; quote intent-check's human-readable lines from the second line onward verbatim), stop the export, and guide the user to run /intent-writeback. Then ask the user in natural language whether to "proceed with the export anyway" and wait for their answer; only when the user explicitly instructs to proceed, run the export with a warning attached (the escape hatch for false positives).
• When remind and a violation is detected (result=stale or pending>0): present the same grounds as a warning and continue without stopping.
• Only when intent-check itself cannot run (command execution unavailable, script absent, or exit 2): treat staleness as not-applicable, read .intent/deltas.md to check for pending Delta entries (those carrying - Status: pending), and enter the same branches above using that result as pending.

Step 1.6: Drift Check (drift-watch)

• Check the value of drift-watch in the ## Drift-watch (user-managed) section of the .intent/mode.md read in Step 1. When it is not on (including off, unspecified, invalid value, missing section, or missing mode.md), do not perform this check; continue to Step 1.7 as today (byte-identical to current behavior).
• Only when it is on, read and apply rules/drift-export-check.md. The matching of the target packet's design/tasks hints × compass (North Star / Anti-direction / Invariants), the named presentation of conflicts, appending a stage: export entry to drift-log, and resolving the outcome by the user's verdict are all delegated to the rule's procedure (do not duplicate the procedure here).
• This check is warn-only and does not stop the export (only the Step 1.5 enforcement gate can stop; drift-watch never stops because it assumes false positives).
• Order and orthogonality of the three checkpoints: enforcement (procedure, may stop, Step 1.5) → drift-watch (direction, never stops, Step 1.6) → Open Questions (deadline, never stops, Step 1.7). Their inspection targets are orthogonal (procedure / direction / deadline).

Step 1.7: Confirm unanswered Open Questions

• Read and apply rules/export-questions.md.

Step 1.8: Preflight check of the cc-sdd prerequisite (warn only — do not stop)

• Observe read-only whether the .kiro/ directory exists (Read/Glob; do not push this onto a mechanical check such as intent-check.mjs).
• When .kiro/ is absent: warn that cc-sdd (kiro) may not be set up. Guide: "The cc-sdd prerequisite (.kiro/) was not found. Set up cc-sdd, or — if a readable artifact is the goal — the format-axis projection (an exit to a readable Spec) is also available." (The choice of exit follows the exit decision lane in rules/export-route.md; this SKILL does not name other export/projection skills' commands.) Do not stop the draft generation (continue to Step 2 onward).
• When .kiro/ exists: emit nothing and continue to Step 2 (as before — no warn).
• This check is warn only — it does not stop the export (only the Step 1.5 enforcement gate can stop; the preflight follows drift-watch's false-positive-tolerant stance and does not stop — it does not foreclose adding .kiro/ later). The exit's appropriateness follows the convention in rules/export-route.md (the exit decision lane).
• Check for an early-preview record (warn only — stay silent if the vessel is absent): read the "Walking Skeleton" section of .intent/packets/plan.md read-only and check whether an Early preview: record line is present. If it is absent, warn once: "You do not seem to have shown the user any progress yet. If there is an intermediate deliverable that can be shown before implementation (a running skeleton, the Intent Tree overview, the plan), consider showing it." (This pairs with intent-packets's walking-skeleton procedure 5.) Stay silent (no warn) in these environments: designer-questions in .intent/mode.md is not on / plan.md has no "Walking Skeleton" section / plan.md itself is absent (do not warn where the vessel is absent = backward compatible; silence over false positives). This check too is warn only — it does not stop the export.

Step 2: Apply the mapping rules

• Read and apply rules/map-cc-sdd.md.
• When .intent/execution-contract.md exists, read it JIT and produce the common selection result once from the target packet and relevant decisions. The cc-sdd-specific rules place only its selected entries; they do not redefine candidate discovery or the meaning of pull | exclude | confirm.
• When .intent/execution-contract.md is absent, use selection_status: legacy-not-applied and continue with the existing input: one target packet file (including packet-specific invariants in Safety / Invariants) plus project-wide Invariants/Anti-direction from .intent/intent-compass.md. Do not claim that the new selection was applied.
• Do not read the full Tree or other packets; only refer to Tree L0–L1 as a summary when direction is needed.

Step 3: Generate the draft

• Write the drafts under the per-packet directory .intent/cc-sdd/<slug>/. The slug derivation and collision handling follow the "Output layout" section of rules/map-cc-sdd.md.
• Write the condensed Project Description (the cc-sdd input body) into .intent/cc-sdd/<slug>/requirements.md.
• Write design hints (bullets) into .intent/cc-sdd/<slug>/design.md, and an "Intent-derived constraints" section + tasks check items into .intent/cc-sdd/<slug>/tasks.md.
• Write the selection record defined by the common contract to .intent/cc-sdd/<slug>/constraint-selection.md. Replace the entire file in the same run as the three drafts, and do not treat a run that updates only one side as successful.
• Do not complete the cc-sdd main body. Always leave parent intent and invariant references in the tasks hints.
• Once the drafts are generated, write the export record into a per-packet split file .intent/export-log/<packet-slug>.md (following CONTRACT "Split and archive convention for append-only records"). Derive <packet-slug> from the packet name via the existing slug rule (intent-packets/rules/packet-format.md) — do not create new/sequential numbering. The file holds the same table header as the scaffold (| packet | exported_at | commit |) plus the row | <packet name> | <export datetime (ISO 8601 UTC)> | <commit hash> | (append a row if the file exists; do not erase past rows). Obtain the commit hash by running git rev-parse --short HEAD (read-only); if it cannot be obtained, record -. Create the .intent/export-log/ directory if absent.
• Then regenerate the old .intent/export-log.md as a generated active mirror: concatenate all data rows from .intent/export-log/*.md in exported_at ascending order and overwrite the mirror with the scaffold header + all rows (the split files are the source of truth; the mirror is derived, never hand-edited). This keeps single-file readers (status / validate / writeback / intent-check) from breaking. The mirror is folded in the later slice (wire) once reader cross-following is complete.

Step 4: Guide the handoff (natural-language led)

• The lead of the output is natural-language guidance: show the path of the target packet's .intent/cc-sdd/<slug>/requirements.md and confirm "may this be handed to cc-sdd as is" by asking the user in natural language and waiting for their answer.
• When the user instructs to proceed, read the body of the target packet's .intent/cc-sdd/<slug>/requirements.md and invoke /kiro-spec-init with that body as the argument (do not force the user to copy-paste).
• Pass requirements.md only as the cc-sdd start input. Do not pass the internal constraint-selection.md downstream, and preserve the existing phase-specific handoff of the design/tasks hints.
• Record the feature name as a real link (DR121): once /kiro-spec-init has generated the feature name, immediately afterwards and in the same flow, append the single line - feature: <feature name> (<record date YYYY-MM-DD>) below the table of the split file .intent/export-log/<packet-slug>.md written in Step 3 (never rewrite existing table rows or past lines = append-only). This makes the packet → generated spec correspondence traceable later by a real link (there is no guarantee that the packet name survives into the downstream spec). Do not append when the same feature name is already recorded (prevents duplicates on re-export. When the feature name changed, add a new line and never erase the past ones). When the feature name cannot be obtained (the user does not go as far as /kiro-spec-init in this session, the invocation failed, etc.), write nothing and emit no warning (fail-open; never let it affect the export's success). Write only the feature name (an identifier) and the date — no sensitive content, no raw detail (the same discipline as the Intent trailer in commit history). Being a non-table line, this appended line is invisible to the existing readers (status / validate / writeback / intent-check) and to the mirror regeneration, and it does not change the existing three-column schema.
• As a fallback, also include a newline-minimized copy block for /kiro-spec-init (not the lead).
• Delegation goes only up to invoking /kiro-spec-init. The subsequent requirements → design → tasks follow cc-sdd's 3-phase approval, waiting for the user's instruction to proceed at each phase. Do not push ahead automatically.
• Phase-by-phase hint handoff guidance (DR120): include this one line in the guidance — "When you proceed to the design phase, also hand over the body of .intent/cc-sdd/<slug>/design.md; when you proceed to the tasks phase, the body of ." The cc-sdd side skills do not read these hint files by themselves, so unless they are handed over, the intent-derived constraints never reach the design/tasks phases. The handoff itself is left to the user, and nothing stops when it is skipped (not a gate).

Output Description

• Proposed update to the target packet's .intent/cc-sdd/<slug>/{requirements, design, tasks}.md
• Regeneration proposal for the target packet's .intent/cc-sdd/<slug>/constraint-selection.md (internal record, not passed downstream)
• One export-record row appended to .intent/export-log.md
• One real-link record of the feature name when the flow went as far as /kiro-spec-init (appended below the table of the split file; DR121. Omitted when it did not)
• The target packet file's state update and the regeneration of .intent/packets/index.md when a draft was activated (omitted when none apply)
• Confirmation result for unanswered [by export] questions (the questions presented and the user's decision; omitted when none apply)
• Confirmation of whether it may be handed to cc-sdd (natural-language guidance; the lead)
• Handoff guidance for the phase-specific hints (design.md / tasks.md) when proceeding to the design/tasks phases, plus the preface for the missing-steering warning (included in the guidance; DR120)
• Copy block for /kiro-spec-init (fallback; secondary)
• Points to confirm before implementation
• Return-path guidance after the implementation goes around once (return to canonical via /intent-writeback; do not settle for writing Evidence directly into the packet)

Plainness check for reports (user-facing reports; right before output; shared)

Right before emitting a user-facing report (progress, completion, items needing confirmation — including the end-of-turn summary), run this check (INV105, DR208). It applies only to user-facing report text, not to how internal records (canonical files and logs under .intent/) are written.

• Do not transcribe internal documents verbatim: text you just read or wrote in internal artifacts (tree, compass, packets, Open Questions) is written in internal vocabulary. In the report, restate that content in words a first-time reader understands (without changing facts or meaning).
• Identifiers must not be the subject of the sentence: when presenting an item to confirm or a unit of work, first write one sentence that stands on its own ("what and why"), then append identifiers (Open Question numbers, packet names, symbols, stage names) after it as references (e.g. "... please verify this before starting (ref: OQ-xxx-1)"). Do not delete identifiers or references to records for the sake of plainness (the trail back to the record is lost).
• Signal for overload: three or more unexplained internal terms in one sentence signal overload (read by meaning, not by mechanical count). If a sentence does not stand on its own, rewrite it in plain words before sending (without changing facts or meaning).
• Do not convey meaning only through a metaphor or a vague qualifier: the foundation of a report is precision — write so the meaning reads unambiguously (plain language is a means of staying easy to read while preserving it). Do not report results only with ungrounded qualifiers (e.g. "significantly", "nicely"); state observable facts. If you use a metaphor, pair it immediately with a precise restatement (do not force established technical terms, or ordinary words in their everyday sense, into strained paraphrases).
• This check works as a pair with the after-the-fact record (prevention alone is never enough): when a report failed to get through, log the case to the drift log while drift-watch is on, and feed the next prevention.

Safety & Fallback

• If .intent/packets/ is absent (or active/ is empty), stop and guide the user to /intent-packets.
• The absence of index.md does not stop; build the candidates directly from the files under active/, continue, and prompt regeneration of the index.
• The only canonical write is the draft-guard activation (state update + index.md regeneration), and only with the user's approval. Never rewrite intent-tree / intent-compass / packet bodies.
• The absence of mode.md does not stop; continue with the standard default and announce it.
• The enforcement check is fail-open: even when intent-check cannot run, do not block the export. The export stops only when enforcement is gate and the verdict line says block=yes, or when the unrunnable fallback finds pending deltas under gate; even then the user's explicit instruction to proceed lets it run.
• The Open Questions check is a confirmation, not a stop; the user's explicit instruction to proceed lets the export run.
• The feature-name real-link record is fail-open: when it cannot be obtained or written, write nothing, emit no warning, and never let it affect the export's success (DR121).
• Do not complete the main body of cc-sdd's requirements/design/tasks (drafts/hints only).
• Do not auto-invoke cc-sdd phases beyond /kiro-spec-init.
• Do not change application code (INV6. Invoking other skills is a concept distinct from INV6 and is allowed).