intent-planner 0.13.1

package/templates/en/claude/skills/intent-status/SKILL.md

@@ -0,0 +1,171 @@
+---
+name: intent-status
+description: Read-only guidance skill that reads the current state of .intent/ and recommends a summary of where you are plus exactly one "next move". Never creates, modifies, or deletes any file.
+allowed-tools: Read, Glob, Grep, Bash
+argument-hint: none
+---
+
+# intent-status Skill
+
+## Core Mission
+- **Success Criteria**:
+  - The existence and fill state of the deliverables under `.intent/` (mode, intent-tree, intent-compass, the packets/ index and packet files, the per-packet cc-sdd draft directories, deltas) are read and a summary of the current position is presented
+  - The consistency between `.intent/packets/index.md` and the entities under `active/` (a packet missing from the index, a row without an entity, mismatches in name / state / summary), the lingering of files with done / superseded_by filled in inside active/, and the absence of the latest export-log row's packet from active/ (residing in archive) are checked, and violations are reported in the current-position summary
+  - Orphan-spec check: when `.kiro/specs/` has a spec that is in progress / done yet cannot be text-matched to any packet under `active/` or any delta in `deltas.md`, it is reported in the details as "possible un-drafted implementation (suspected to have been implemented without going through a Packet)" (candidate presentation, not an assertion; non-matchability is the normal case so false positives are tolerated, and the next-move first-match is not taken away; this check is not performed in environments without `.kiro/specs/`)
+  - intent-tree unfiled check (discover skip): when `.kiro/specs/` has a spec whose design/implementation has advanced yet it cannot be text-matched to any of the **L0–L4 headings and bodies** of `.intent/intent-tree.md` (intent-planner has no ID anchors such as O#/C#/B#/P#, so determination is by text matching only), it is reported in the details as "possible implementation not filed into intent-tree (discover skip)" (candidate presentation, not an assertion; non-matchability is the normal case so false positives are tolerated, and the next-move first-match is not taken away; this check is not performed in environments without `.intent/intent-tree.md` or without `.kiro/specs/`). This unfiled check (tree layer), the existing orphan-spec check (Packet layer), and writeback omission (downstream layer) are partitioned into three layers, and when one spec matches multiple layers it is presented only in the single most-upstream layer so that no double warning is emitted
+  - A leading mini progress rail (all packets laid out vertically with the five signals ✅/🔵/⚪/🔴/◻, each row also carrying `[current stage → next stage(s) to pass through]`) is placed at the top of the report so that "which packet is 🔵 you are here now, which stages each will pass through next, and where the ⚪ remaining work / 🔴 unreflected items are" is visible at a glance. Internal terms (the matching procedure, the integrity check, enforcement terms) are pushed down into the details (later) rather than led with
+  - Exactly one "next move" is recommended via the first-match of `rules/decision-table.md`, accompanied by the reason and the judgment basis (which state of which deliverable it rests on)
+  - The recommendation candidates are selected from discover / compass / packets / export / validate / improve / writeback / "no action needed"
+  - When the enforcement in mode.md is remind or gate, a freshness check via intent-check is performed, and on detecting a violation (`result=stale` on the judgment line, or `pending` of 1 or more) a freshness warning quoting the intent-check stdout is included alongside the current-position summary (when off, unstated, an invalid value, or not executable, no warning is shown, as before)
+  - When drift-watch in mode.md is `on`, drift-log is read and a light tally (`caught N / missed N / false-positive N / unjudged N`) is included as one block alongside the current-position summary (when off, unstated, an invalid value, the section is absent, or mode.md is absent, no block is shown and processing continues as before). drift-log is read only and never written (read-only preserved)
+  - The section update dates of intent-compass.md (`Updated (Invariants):` / `Updated (Decision Rules):`) and the `updated_at` of the packets under active/ are cross-checked using Read/Glob/Grep only, and when the count of packets that are "not yet caught up after a compass update" reaches the threshold or more, `/intent-validate` is recommended as the right moment (decision table row 12), with its basis (which section was updated, how many are not caught up) included. It does not make a definitive diagnosis but stays at an estimate, and does not propose below the threshold (read-only preserved)
+  - Each event in `.intent/milestones.md` is read using Read/Glob/Grep only, and any event for which neither "a `Updated (Decision Rules):` reflection stamp in compass" nor "a reference to the corresponding Decision in deltas" exists after the event's recorded time is grasped as an "unconsumed milestone (recorded but its corresponding revisit is unhandled)" and included as a residual in the current-position report (the same comparison shape as Step 3.6: lexicographic order of ISO 8601, only pairs where both ends are actually stamped; candidate presentation, not an assertion; when `.intent/milestones.md` is absent this check is omitted; read-only preserved)
+  - No file has been created, modified, or deleted at all (read-only)
+  - Major terms in the output always carry a one-line plain-language explanation in the `term (explanation)` form
+
+## Execution Steps
+
+### Step 1: Confirm that `.intent/` exists
+- If `.intent/` does not exist, guide the user through the setup procedure (running `npx intent-planner`) and finish.
+- Read mode state from `.intent/mode.local.md` (falling back to the old `.intent/mode.md` if absent). If neither exists, continue with the standard default and add "mode undetermined; `/intent-discover` recommended" to the Open Questions (do not stop). Enforcement / Drift-watch read from `.intent/mode.md`.
+
+### Step 2: Read the deliverables
+- Read `.intent/intent-tree.md` / `.intent/intent-compass.md` / `.intent/packets/index.md` plus the target packet files (under `.intent/packets/active/`; in normal processing read only these two kinds and never bulk-read the bodies of every packet file) / `.intent/cc-sdd/<slug>/*.md` (the per-packet draft directories) / `deltas` (the split form `.intent/deltas/*.md` set if present, else the old `.intent/deltas.md` mirror; the split-form cross-read of `rules/decision-table.md` footnote 10) and grasp, for each, its present/absent/unfilled state and notable points (unresolved Questions, deltas with Status: pending, declined items tagged "on-hold", etc.).
+- Packets integrity check: cross-check `.intent/packets/index.md` against the entities under `.intent/packets/active/` (reading only the frontmatter of each entity file) and grasp divergences — a packet missing from the index, a row without an entity, mismatches in name / state / summary — as integrity violations. Additionally, when a packet file with `state: done` or a filled `superseded_by` lingers under active/, grasp that lingering as an integrity violation too (report only; never auto-repair).
+- When index.md is absent, build the listing directly from the frontmatter under `active/`, continue processing, and prompt in Step 5 for regeneration of the index (by running a skill that changes the canonical).
+- Identify the current Source Packet (latest export) by taking the packet name on the latest row (the last data row) of export-log (the split form `.intent/export-log/*.md` set if present, source of truth, `exported_at` ascending / else the old `.intent/export-log.md` mirror; the split-form cross-read of `rules/decision-table.md` footnote 10) as canonical. Resolution order: (1) explicit user specification → (2) the latest row of export-log (canonical) → (3) the `## Source Packet` heading of the drafts (adopt it only when exactly one packet directory exists; when multiple exist, list each directory's heading as candidates and do not assert) → (4) text matching between the draft bodies and index.md / the packet files (stay at presenting candidates in natural language; do not assert). When export-log is absent or its latest row cannot be interpreted and you fall back to (3) or later, include that fact in the Step 5 report. When the current Source Packet (the packet on the latest row of export-log) is absent from `active/` (residing in archive), also include that fact in the Step 5 report.
+- Check whether the current packet's directory (`.intent/cc-sdd/<slug>/`) exists. Identification between a packet name and a directory takes "the `## Source Packet` heading in the requirements.md inside the directory matches the packet name" as canonical (slug recomputation stays a fast path for searching; do not identify when the heading does not match).
+- Read `.kiro/specs/` only when it exists, and use the spec.json and tasks.md check states of each spec as context. The corresponding spec is identified by text matching the Source Packet name against the spec directory names and the body of each spec's requirements.md "Project Description (Input)" (for the detailed matching rules, follow the footnotes of `rules/decision-table.md`).
+- Orphan-spec check (detecting a skipped drafting): only when `.kiro/specs/` exists, grasp as an "orphan spec" any spec that is in progress / done (spec.json is at the requirements phase or later, or tasks.md has one or more checked tasks) yet cannot be text-matched to any packet under `active/`, any packet under `archive/`, or any delta in `deltas` (the split form `.intent/deltas/*.md` set if present, else the old `.intent/deltas.md` mirror; the split-form cross-read of `rules/decision-table.md` footnote 10). Match by the same means as the existing corresponding-spec identification (text matching the spec directory name and the requirements.md "Project Description (Input)" body against packet names and spec_refs; rules per the footnotes of `rules/decision-table.md`), limited to **what is mechanically observable from files** (do not look at git history, code diffs, or timestamps). Report an orphan spec in Step 5 (3) Details as "suspected to have been implemented without going through a Packet (a skipped drafting phase)". Non-matchability is the normal case (a known limitation in the footnotes), so **do not assert** — keep it to a candidate presentation and let it have no effect on the next-move first-match (the same "report only" temperature as the integrity check; false positives are tolerated).
+- intent-tree unfiled check (detecting a discover skip): only when both `.kiro/specs/` and `.intent/intent-tree.md` exist, grasp as a "possible implementation not filed into intent-tree (discover skip = a skip of the filing phase itself)" any spec that is in progress / done (spec.json is at the requirements phase or later, or tasks.md has one or more checked tasks) yet cannot be text-matched to any of the **L0–L4 headings and bodies** of `.intent/intent-tree.md` (L0 Product Purpose / L1 Desired Outcomes / L2 Capabilities / L3 Behavioral・Architectural Intents / L4 Candidate Packets. intent-planner's current notation is these **L0–L4 level symbols**; **ID anchors such as `O#`/`C#`/`B#`/`P#` do not exist, so do not use them for matching — match by text only**). Match by the same means as the existing corresponding-spec identification (text matching the spec directory name and the requirements.md "Project Description (Input)" body against the L0–L4 headings and bodies of intent-tree; rules per the footnotes of `rules/decision-table.md`), limited to **what is mechanically observable from files** (do not look at git history, code diffs, or timestamps). This is an unfiled state **further upstream** than the orphan-spec check (Packet absence), and the two checks are handled as separate layers (the three-layer partition described below). Report intent-tree unfiled into Step 5 (3) Details. Non-matchability is the normal case (a known limitation in the footnotes), so **do not assert** — keep it to a candidate presentation and let it have no effect on the next-move first-match (the same "report only" temperature as the integrity check and the orphan-spec check; false positives are tolerated). This check is not performed in environments without `.intent/intent-tree.md` or without `.kiro/specs/`.
+- Three-layer partition of unfiled / orphan spec / writeback omission: because one spec may match multiple layers, position it from upstream in the order **(1) intent-tree unfiled (discover skip = tree layer) → (2) orphan spec = Packet absence (Packet layer) → (3) writeback omission (enforcement / freshness; downstream layer)**, and present a matching spec **only in the single most-upstream layer** so that no double warning is emitted (do not re-warn in a downstream layer about a spec that matched upstream). When presenting, guide as a staged remedy of `discover → packets → writeback` (details per the footnotes of `rules/decision-table.md`).
+
+### Step 3: Check freshness (enforcement-linked)
+- Check the `enforcement` value in the `## Enforcement (user-managed)` section of `.intent/mode.md` read in Step 1. When it is `off`, unstated, or an invalid value, do not perform this Step (do not run intent-check and show no freshness warning; current behavior is preserved).
+- When it is `remind` or `gate`, run `node .intent/scripts/intent-check.mjs` via Bash. When it cannot run (Bash unavailable, script absent, or exit 2), omit this Step and continue with the existing behavior.
+- Trust the judgment line on the first line of stdout — `intent-check: result=<ok|stale|not-applicable> enforcement=<off|remind|gate> commits=<N|-> threshold=<M> grace=<in-implementation|-> pending=<K> block=<yes|no>` — as is, and never re-derive it. Treat it as a violation when `result=stale` or `pending` is 1 or more.
+- When a violation is detected, include in the current-position summary of Step 5 a freshness warning quoting the intent-check stdout (the judgment line + the human-readable evidence lines). intent-check is a read-only script (it creates, modifies, and deletes no files), so the read-only nature of this skill is preserved.
+
+### Step 3.5: Drift Summary (drift-watch-linked)
+- Check the `drift-watch` value in the `## Drift-watch (user-managed)` section of `.intent/mode.md` read in Step 1. When it is not `on` (`off`, unstated, an invalid value, the section absent, or mode.md absent), do not perform this Step (do not add a drift block and continue as before; current behavior is preserved).
+- When it is `on`, **read `.intent/drift-log.md` only via Read / Grep** (never Write; do not change the principle that Bash is limited to launching intent-check) and tally the `outcome` and `user-verdict` of each entry. Count `caught` / `missed` / `false-positive` from the `outcome` values, and `unjudged` from the number of `user-verdict=unjudged`.
+- Present the tally lightly, at the same position and temperature as the freshness warning, as one block `caught N / missed N / false-positive N / unjudged N` in the current-position summary of Step 5 (do not overload with information). When `.intent/drift-log.md` is absent, omit this block (do not error).
+- drift-log is read only and never written (read-only preserved). Read `missed=0` as "a suspicion of missing records," not as "it worked," and present it without asserting.
+
+### Step 3.6: Estimate the right moment for conformance staleness (read-only)
+- Purpose: estimate the "right moment" where compass (Invariants / Decision Rules) was updated but a packet has not yet caught up, as material for recommending `/intent-validate` in decision table row 12. The definitive diagnosis (must-fix/recommended) is made by validate's `invariant-stale-vs-compass` etc.; status stays at an estimate.
+- Perform the reads with **Read / Glob / Grep only** (do not use Bash = intent-check; like drift-log, do not widen the read-only scope):
+  - Read the ISO 8601 values of the `Updated (Invariants):` / `Updated (Decision Rules):` lines of `.intent/intent-compass.md` (`—` is unstamped).
+  - Read the frontmatter `updated_at` of each packet under `.intent/packets/active/` (`archive/` is out of scope).
+- Determination: count, as "not yet caught up after a compass update," each active packet for which any compass section update date > that packet's `updated_at`. The comparison is the lexicographic order of the ISO 8601 strings. Target only pairs where both ends are actually stamped, and exclude packets with no `updated_at` (do not fill in by guessing = backward-compatibility discipline). When both compass section update dates are `—`, do not perform this Step (produce no right-moment).
+- When the not-caught-up count reaches the threshold (default 1, made explicit in decision table row 12) or more, include in the Step 5 (3) Details, as the basis, "which compass section was updated, and how many packets are not caught up". When below the threshold, do not include it (avoid the boy-who-cried-wolf effect). This Step writes nothing (read-only preserved).
+
+### Step 3.7: Grasp unconsumed milestones as residuals (read-only)
+- Purpose: among the milestone events recorded in `.intent/milestones.md` (the milestone-event record), raise as "unconsumed milestones" those whose corresponding Decision revisit (Revisit reflection) has not yet been consumed. The recording is left to the user's declarative entry; status only matches (no computation, inference, or auto-correction).
+- Perform the reads and comparison with the same **Read / Glob / Grep only** as Step 3.6 (do not use Bash = intent-check; do not widen the read-only scope):
+  - From each event row of `.intent/milestones.md`, read `event` (the natural-language string) and `recorded_at` (the ISO 8601 recorded time).
+  - Read the ISO 8601 value of the `Updated (Decision Rules):` line of `.intent/intent-compass.md` (the Revisit reflection stamp; `—` is unstamped), and whether each delta in `.intent/deltas.md` references the corresponding Decision.
+- Determination: for each event, count as an "unconsumed milestone (recorded but its corresponding revisit is unhandled)" any event for which, after its `recorded_at`, neither "a `Updated (Decision Rules):` reflection stamp in compass exists" nor "a reference to the corresponding Decision exists in deltas" can be observed. The date-time comparison uses the same lexicographic order of ISO 8601 strings as Step 3.6, and targets only pairs where both ends are actually stamped (events with no `recorded_at` or where `Updated (Decision Rules):` is `—` are excluded without filling in by guessing = backward-compatibility discipline).
+- When an unconsumed milestone is detected, include in the Step 5 (3) Details, as a residual, "which event is unconsumed" (candidate presentation, not an assertion; non-matchability is the normal case so false positives are tolerated, and the next-move first-match is not taken away). When `.intent/milestones.md` is absent, do not perform this Step (skip the check and continue; do not error). This Step writes nothing (read-only preserved).
+
+### Step 4: Decide on one next move with the decision table
+- Read `rules/decision-table.md` and decide exactly one "next move" via first-match (evaluate top-down and adopt only the first matching row).
+- Never list multiple candidates side by side (the reason and basis are listed alongside). Even ambiguous cases where multiple recommendations seem visible are folded mechanically into one by the priority order of the decision table.
+
+### Step 5: Report
+Structure the report in the order that gets the reader to "where am I, and what do I do next" by the shortest path. Do not lead with internal terms (the matching procedure, the integrity check, enforcement terms); push them down into the details from (3) onward.
+
+- (1) **Progress rail (leading mini-rail)**: lay out all packets vertically and assign each one of the five signals (✅ reflected / 🔵 you are here / ⚪ not started / 🔴 unreflected / ◻ merged), **followed by `[current stage → next stage(s) to pass through]`**. Both the signal determination and the stage annotation follow the same discipline as overview's `progress-readout.md` "Progress rail" (the five signals cross-check `state` × whether export-log has a row × whether deltas has a corresponding entry via first-match; the stage annotation re-reads packet `state` as a position on the fixed pipeline `discover→compass→packets→export→implement→verify→writeback`; neither computes nor infers). Examples: `P2  🔵 you are here [implementing → next: verify→writeback]` / `P3  ⚪ not started [ready → next: export→implement]`. This makes **"which P is you-are-here now, which stages remain after this, and where the ⚪ remaining work / 🔴 unreflected items are" visible at a glance on a single sheet**. Annotate each signal's meaning per the glossary. The rail is a read-only mirror; status changes nothing.
+- (2) **The next move (exactly one, one line)**: present the skill name or "no action needed" **on one line** first, then append the recommendation reason + judgment basis (which state of which deliverable it rests on) concisely. Translate the first-match result of the decision table (`rules/decision-table.md`) into **the action a human takes next**, not into the internal row number.
+- (3) **Details (the folded position)**: each deliverable's present/absent/unfilled state and notable points that back the signals in (1); the current Source Packet (the packet name based on the latest row of export-log) and whether its directory (`.intent/cc-sdd/<slug>/`) exists. When packets integrity violations were detected (index ↔ active/ divergence, lingering done / superseded_by, the latest export-log row's packet absent from active/), include their content; when index.md is absent, include the regeneration prompt; when a violation was detected in Step 3, include the freshness warning quoting the intent-check stdout; when drift-watch is `on` in Step 3.5, include the drift-log light tally (`caught N / missed N / false-positive N / unjudged N`) as one block at the same position and temperature as the freshness warning; when conformance staleness's right moment (the not-caught-up count at or above the threshold) was detected in Step 3.6, include the basis "which compass section was updated, and how many packets are not caught up" at the same position and temperature as the freshness warning. When an intent-tree unfiled state (a suspected discover skip) was detected in Step 2, include one block with its spec name and the guidance "Design/implementation has advanced, but it could not be text-matched to any L0–L4 node of `.intent/intent-tree.md`. The discover phase itself may have been skipped. File it into intent-tree (L0–L4) via `/intent-discover`, then raise a Packet with `/intent-packets`, and return the implementation reality to canonical via `/intent-writeback` — that is the order", at the candidate-presentation temperature that avoids assertion (it does not change the decision-table result for the next move). When an orphan spec (a suspected un-drafted implementation) was detected in Step 2, include one block with its spec name and the guidance "This may have been implemented without going through a Packet. Even after the fact, raise a Packet with `/intent-packets` (making the unfixed spec explicit as Open Questions / Deferred), then return the implementation reality to canonical via `/intent-writeback` — that is the order", at the candidate-presentation temperature that avoids assertion (it does not change the decision-table result for the next move). **These two checks and the writeback omission (the freshness warning) are partitioned from upstream into three layers — tree layer → Packet layer → downstream layer — and when one spec matches multiple layers it is presented only in the single most-upstream layer so that no double warning is emitted** (do not re-emit a spec that matched upstream in the downstream orphan-spec / freshness warning; guide it as a staged remedy of `discover → packets → writeback`). When an unconsumed milestone (a milestone event recorded but whose corresponding revisit is unhandled) was detected in Step 3.7, include one block with its event name and the guidance "A milestone event is recorded, but the corresponding Decision revisit (Revisit reflection) may not yet have been consumed. Check the `Revisit when` matching / re-proposal for the corresponding Decision Rule via `/intent-improve` — that is the order", at the same position and temperature as the freshness warning (the candidate-presentation temperature that avoids assertion; it does not change the decision-table result for the next move).
+- (4) Open Questions: points that need user confirmation. Confirmation stays at presenting candidates in natural language, leaving the next-action decision to the user (one-way reporting).
+- **Unset-or-absent display**: when a deliverable is unset or absent, show it in the `term (explanation): state` form — e.g. `Intent Tree (the hierarchical map of what you want to do): not created` — in plain English so that a reader who does not know the term can tell that the deliverable **does not yet exist / has no content**. Consistency-check violations (a stuck `superseded_by`, divergence from the index, an item remaining in archive, etc.) are shown the same way: annotate the term with its explanation and present in plain English **what is stuck / diverging and how**.
+
+## Always-annotate rule for terms
+
+The terms that appear in the output are annotated with their meaning in the `term (explanation)` parenthetical form, by referring to the "Glossary" below. The concrete conventions are as follows.
+
+- **Always-annotate rule**: the intent-planner-specific terms that appear in status output (deliverable names, state values, check terms, command names) are **kept in English as the canonical form and are never replaced by a translation**. Each term is annotated with a short plain-language explanation of its meaning, written in the `term (explanation)` parenthetical form. The annotation is **not limited to the first occurrence** — it is repeated every time the term appears in the output (status output is a fragmentary report whose visible items vary with the situation, so "first occurrence" is not stable; the priority is that the meaning is clear on the spot, every time).
+- **Avoiding redundancy in practice**: even when the same term recurs within a single output and full annotation would be redundant, no item is **left as the bare term**. In list / table item headers, keep the parenthetical annotation; in repeated in-prose mentions, the form may be tightened as long as the meaning remains traceable from context. When tightening the form, the condition is that the term's meaning stays traceable.
+
+### Glossary
+
+The terms that status refers to when producing output, with a one-line explanation (this glossary is kept self-contained within this SKILL).
+
+**Deliverable names**
+
+| Term | One-line explanation |
+|------|----------------------|
+| Intent Tree | the hierarchical map of what you want to do (L0 = purpose … L4 = candidate work units) |
+| Intent Compass | the decision criteria for preventing local optimizations |
+| Packets / packet | the work unit before handing off to cc-sdd (broader than an Issue, just before a spec) |
+| Source Packet | the packet a draft originated from (identifies the export origin) |
+| delta | the diff record used to update a canonical deliverable after the fact |
+
+**state (5 values)**
+
+| Term | One-line explanation |
+|------|----------------------|
+| state: draft | drafting / undetermined |
+| state: ready | ready to start (dependencies resolved, awaiting implementation) |
+| state: implementing | under implementation |
+| state: verifying | implemented, awaiting verification (Evidence undetermined) |
+| state: done | evidence obtained / complete |
+
+**Progress rail (5 signals + stage annotation)** (cross-check a packet by `state` × whether export-log has a row × whether deltas has a corresponding entry, and assign one via first-match. Further, annotate each row with `[current stage → next stage(s) to pass through]`, re-reading packet `state` as a position on the fixed pipeline `discover→compass→packets→export→implement→verify→writeback`. The canonical determination lives in overview's `progress-readout.md` "Progress rail," not in `rules/decision-table.md`, but status's leading mini-rail uses the same five-signal vocabulary + stage annotation)
+
+| Signal | One-line explanation |
+|--------|----------------------|
+| ✅ reflected | implementation complete and written back into intent (`state: done` and a corresponding delta is promoted/closed) |
+| 🔵 you are here | the one stage currently being worked on (of the exported-not-yet-reflected, the current Source Packet = the latest export-log row) |
+| 🔴 unreflected | evidence of implementation exists but not yet reflected (of the exported-not-yet-reflected, those other than the current Source Packet = past leftovers) |
+| ⚪ not started | not yet exported to cc-sdd (no row in export-log) |
+| ◻ merged | merged into a successor packet and done with its role (`superseded_by` is non-empty) |
+
+**Replacement axis**
+
+| Term | One-line explanation |
+|------|----------------------|
+| superseded_by | the ID of the successor packet that replaced this packet (a separate axis denoting replacement, not a state) |
+
+**enforcement / staleness**
+
+| Term | One-line explanation |
+|------|----------------------|
+| enforcement | the strength of writeback enforcement (off = no checks / remind = warning only / gate = stops export · push) |
+| stale (staleness) | the writeback is out of date (implementation moved on but it has not been reflected back into intent) |
+| conformance staleness | compass (Invariants/Decision Rules) was updated but a packet has not yet caught up (status estimates the right moment; the definitive diagnosis is made by `/intent-validate`) |
+
+**drift-watch**
+
+| Term | One-line explanation |
+|------|----------------------|
+| drift-watch | monitoring of drift (deviation) from intent (off = does nothing / on = matching warnings and recording; both warn only and never stop) |
+
+**The 4 words of the drift tally** (`caught` / `missed` / `false-positive` are **outcome** values, `unjudged` is a **user-verdict** value; do not confuse the kinds)
+
+| Term | Kind | One-line explanation |
+|------|------|----------------------|
+| caught | outcome | the drift was captured at export (capture succeeded) |
+| missed | outcome | the drift could not be prevented and got through |
+| false-positive | outcome | it was a false alarm |
+| unjudged | user-verdict | a human has not yet judged the validity of the drift (a value of user-verdict, not an outcome) |
+
+## Output Description
+
+**Reader**: a human developer who wants to know, by the shortest path, "where am I now and what should I do next".
+**What this makes them grasp first**: (1) from the progress rail, "which packet is 🔵 you are here, and which stages remain after this", then (2) "exactly one next move". Internal terms (the matching, the integrity check, enforcement) are relegated to the details that follow. Compose the output in the order of Step 5 ((1) progress rail → (2) the next move → (3) details → (4) Open Questions).
+
+- (1) **Progress rail** (top, conclusion): lay out all packets vertically and annotate each row with the five signals + `[current stage → next stage(s) to pass through]` (the ⚪ remaining work and 🔴 unreflected items visible at a glance)
+- (2) **Exactly one next move** (with the recommendation reason and judgment basis)
+- (3) **Details**: the summary of the current position (existence and fill state per deliverable + notable points; includes the current Source Packet and whether its packet directory exists; when an enforcement violation is detected, includes the freshness warning quoting the intent-check stdout; when drift-watch is `on`, includes the drift-log light tally `caught N / missed N / false-positive N / unjudged N` as one block, and when it is not `on`, includes no such block; when conformance staleness's right moment (Step 3.6) is detected, includes the not-caught-up basis as one block, and when below the threshold, includes no such block). Also place here the result of the packets integrity check (the report of index ↔ active/ divergence, lingering done / superseded_by, and the latest export-log row's packet absent from active/; includes the regeneration prompt when the index is absent).
+- (4) Open Questions for a human to confirm
+
+## Safety & Fallback
+- **Read-only declaration**: never create, modify, or delete any file (the frontmatter does not carry Write; Bash is limited to launching the read-only script `node .intent/scripts/intent-check.mjs` and does not change this property). drift-log is read via Read / Grep only (without widening what Bash launches and without writing to drift-log), and this read-only property is not changed.
+- When `.intent/` is absent, guide the user through the setup procedure and finish.
+- The absence of mode.md does not stop; continue with the standard default and announce it.
+- When enforcement is `off`, unstated, or an invalid value, do not run intent-check and show no freshness warning (current behavior). Even under `remind` or `gate`, when intent-check cannot run (Bash unavailable, script absent, or exit 2), omit the freshness check and continue.
+- When drift-watch is not `on` (`off`, unstated, an invalid value, the section absent, or mode.md absent), do not add the drift block and continue byte-equivalent to the current behavior. Even when `on`, when `.intent/drift-log.md` is absent, omit the drift block (do not error).
+- When `.intent/export-log.md` is absent or its latest row cannot be interpreted, fall back in order to the drafts' `## Source Packet` heading and then to text matching against index.md / the packet files (text matching stays at presenting candidates; do not assert), and include the fallback fact in the report.
+- Works even in environments without `.kiro/specs/` (the applicable row follows the proviso-worded recommendation of `rules/decision-table.md`).

package/templates/en/claude/skills/intent-status/rules/decision-table.md

@@ -0,0 +1,47 @@
+# intent-status recommendation decision table (first-match, evaluated top-down)
+
+The canonical source the `intent-status` skill uses to decide exactly one "next move". SKILL.md holds only the procedure and the report format; the decision is made by referencing this table. Every condition must be mechanically observable from files (status has only Read/Glob/Grep and cannot reference git history, timestamps, or code diffs directly; the sole exception is row 9, which is limited to observation via the judgment line of the read-only script `node .intent/scripts/intent-check.mjs` — see footnote 4). Row 12 (the right moment for conformance staleness) is established with Read/Glob/Grep only and does not depend on intent-check — see footnote 7.
+
+| # | Condition (observable from files) | Recommendation |
+|---|------|------|
+| 1 | `.intent/` absent | Setup guidance (then finish) |
+| 2 | intent-tree unfilled or mode undetermined | `/intent-discover` |
+| 3 | compass unfilled | `/intent-compass` |
+| 4 | packets unfilled | `/intent-packets` |
+| 5 | An **explicit wording conflict** with Invariants/Anti-direction detected in packets while reading (limited to the "must-fix" class of validate-checks) | `/intent-validate` |
+| 6 | Deltas with Status: pending are lingering (deltas observed via the split-form cross-read of footnote 10) | `/intent-writeback` (resume promotion) |
+| 7 | No delta entry corresponding to the current Source Packet (latest export), **and evidence of implementation completion exists**. Primary judgment: the current Source Packet's `state` is `done` (with `## Evidence` finalized). Auxiliary signal: only for backward compatibility with existing packets whose `state` is not observable (pre-subdivision), treat all tasks checked in the corresponding `.kiro/specs/` spec as evidence of completion (when `.kiro/` is absent this row still applies, but the recommendation wording must append the proviso "implementation completion is the precondition; if unfinished, continue the cc-sdd implementation"). A discrepancy where packet `state=done` but kiro tasks are unfinished (or vice versa) is reported only as an "inconsistency"; do not automatically treat either side as authoritative (declarative discipline) | `/intent-writeback` |
+| 8 | No delta entry corresponding to the current Source Packet, and **implementation is in progress**. Primary judgment: the current Source Packet's `state` is `draft`/`ready`/`implementing`/`verifying` (not yet `done`; if `depends_on` contains a packet that is not `done`, it is blocked = pre-start). Auxiliary signal: only for backward compatibility with existing packets whose `state` is not observable, treat the corresponding spec's tasks being unfinished as implementation in progress | No action needed (note: continue the cc-sdd implementation; for `verifying`, run `/intent-writeback` after Evidence is finalized and `state=done`) |
+| 9 | enforcement (the `## Enforcement (user-managed)` section of mode.md) is remind or gate, and the intent-check judgment line is stale with no grace (`grace=-` and `result=stale`) | `/intent-writeback` (clear the staleness) |
+| 10 | Declined items tagged "on-hold" remain | `/intent-improve` (prompt re-proposal or confirming the rejection; the final tag update is done by `/intent-writeback`) |
+| 11 | A packet file under active/ has no delta entry (deltas observed via the split-form cross-read of footnote 10), and it does not match the current Source Packet (whether it was exported is determined by observing export-log via the split-form cross-read of footnote 10 and whether a row exists → list candidates + with user confirmation) | `/intent-validate` (if no problem is found, the user then chooses `/intent-export-cc-sdd` or `/intent-writeback`) |
+| 12 | The right moment for conformance staleness: a section update date of intent-compass.md (either `Updated (Invariants):` / `Updated (Decision Rules):`, actually stamped = not `—`) is newer than the `updated_at` (one that is actually stamped) of a packet under active/, and there are **at or above the threshold count (default: 1)** such packets that are "not yet caught up after a compass update" (an estimate of the right moment; the definitive diagnosis is delegated to validate) | `/intent-validate` (cross-check whether a compass update has been caught up by the packets; the conformance staleness check) |
+| 13 | None of the above | No action needed (standing note: recommend periodic `/intent-improve` at implementation milestones) |
+
+## Footnotes
+
+1. The priority order guarantees "exactly one" via first-match (evaluate top-down and adopt only the first matching row; never list multiple candidates side by side). Every row's condition is judged solely from what is written in `.intent/` (+ the spec.json and tasks.md check states under `.kiro/specs/` when present).
+2. The primary source for rows 7/8 implementation progress is the current Source Packet's own `state` (whether `## Evidence` is finalized); kiro tasks are only an auxiliary signal used for backward compatibility with existing packets whose `state` is not observable. For that auxiliary signal, the "corresponding spec" is identified by text matching the Source Packet name against the **spec directory names under `.kiro/specs/` and the body of each spec's requirements.md "Project Description (Input)"**; when it cannot be identified, fall to the `.kiro/`-absent side of row 7 (the recommendation with the proviso wording). Exports do not record a feature name, so unmatchable cases are designed as the normal state, and the limitation when they are frequent is also included in the known limitations of the deltas.md operating notes.
+3. "User confirmation" in row 11 and elsewhere means presenting candidates in natural language and leaving the next-action decision to the user. status is read-only, one-way reporting, and does not use an interactive confirmation tool. Per-packet drafts (`.intent/cc-sdd/<packet-slug>/`, untracked by Git, local-only) persist, and the export history is recorded in export-log (the split-form cross-read of footnote 10), so candidates for "a packet that was exported in the past but never written back" can be enumerated mechanically by cross-checking all rows of export-log × the surviving `.intent/cc-sdd/<packet-slug>/` drafts × deltas (footnote 10) (row 11 adds user confirmation to that candidate list). This cross-check procedure is also stated in the deltas operating notes.
+4. The condition of row 9 is observed solely from the judgment line on the first line of the stdout of `node .intent/scripts/intent-check.mjs` (a read-only script under the Bash-limited exception; it creates, modifies, and deletes no files) and is never re-derived. When enforcement is off, unstated, or an invalid value, or when intent-check cannot run (Bash unavailable, script absent, or exit 2), this row does not match (current behavior). Lingering pending deltas are picked up earlier by row 6, so this row is dedicated to staleness (no grace).
+5. A plain one-line explanation for each command that may be presented in the "next move" (table below). This is a **pure explanation** to accompany the command name in status output and help the reader understand it; it plays no part in identifying the recommendation, the conditions, or the priority order (first-match) — only the main table above decides which command to recommend under which condition.
+
+   | Command | One-line explanation |
+   |------|------|
+   | `/intent-discover` | First intent organization (write what you want to do into the intent-tree and mode) |
+   | `/intent-compass` | Building decision criteria (define the Invariants/Anti-direction that prevent local optimization) |
+   | `/intent-packets` | Splitting into work units (carve out packets at a granularity that can be handed to cc-sdd) |
+   | `/intent-validate` | Checking contradictions and gaps (surface wording conflicts between packets and the decision criteria, etc.) |
+   | `/intent-writeback` | Reflecting implementation results into intent (promote deltas and update artifacts after the fact) |
+   | `/intent-improve` | Proposing re-alignment (prompt confirmation of on-hold items and periodic review) |
+   | `/intent-export-cc-sdd` | Handing off to cc-sdd (export the current Source Packet into the implementation flow) |
+
+6. **Correspondence with the five progress-rail signals**: status's leading mini-rail (SKILL.md Step 5 (1)) is a **presentation layer** that translates this table's result into human-readable form; it does not change this table's logic (first-match, the row conditions). The canonical determination of the signals lives in overview's `progress-readout.md` "Progress rail," and the relationship to this table is as follows (a reference correspondence; the strict branching is the first-match of this table): 🔴 unreflected (exported-not-yet-reflected leftovers) = what rows 6/7 (`/intent-writeback`) pick up. 🔵 you are here (the current Source Packet not yet reflected) = one of rows 6/7/8 (branches by implementation progress). ⚪ not started (not exported) = rows 8/11 (start = continue cc-sdd implementation or export). ✅ reflected only (nothing unreflected or unstarted) = row 13 (no action needed; but if the right moment for conformance staleness in row 12 applies, `/intent-validate` picks it up first). ◻ merged (`superseded_by` non-empty) is for rail display only and does not itself fire a next move (if there is lingering, the integrity check reports it).
+
+7. **The observation and temperature of row 12 (the right moment for conformance staleness)**: this row is established with status's Read/Glob/Grep only (it does not require launching intent-check the way row 9 does, and does not widen read-only at all). The observation procedure is three points: (a) read the ISO 8601 values of the `Updated (Invariants):` / `Updated (Decision Rules):` lines of `.intent/intent-compass.md`, (b) read the frontmatter `updated_at` of each packet under `.intent/packets/active/`, (c) count, as "not caught up," the packets for which a compass section update date > packet `updated_at`, and the comparison is by the lexicographic order of the ISO 8601 strings (the same shape as `invariant-stale-vs-compass`). Target only pairs where both ends are actually stamped (not `—` / not absent), and exclude packets with no `updated_at` (do not fill in by guessing; backward-compatibility discipline). The threshold (the not-caught-up count) is 1 by default, made explicit at the end of the row. This is an **estimate** of "the right moment to run validate," and status makes no definitive diagnosis (the must-fix/recommended verdict is made by `/intent-validate`'s `invariant-stale-vs-compass` etc.). If the validate of row 5/11 (a must-fix-class wording conflict / mismatch) applies first, it takes priority, and this row fires as a "right-moment proposal" when there is no other urgent next move, just before row 13 (no action needed). Pure passage of time that does not update compass is not captured by this row (a design approximation that does not record the time validate was run).
+
+8. **The matching means of the intent-tree unfiled check (discover skip)**: this check fires none of the decision-table rows — it is a **report-only** check (it does not take away the next-move first-match) — grasped in SKILL.md Step 2 and included in Step 5 (3) Details. Matching reuses the existing corresponding-spec matching (the means in footnote 2): text-match the **spec directory names** under `.kiro/specs/` and the **requirements.md "Project Description (Input)" body** of each spec against the **L0–L4 headings and bodies** of `.intent/intent-tree.md` (L0 Product Purpose / L1 Desired Outcomes / L2 Capabilities / L3 Behavioral・Architectural Intents / L4 Candidate Packets). intent-planner's intent-tree nodes are represented by **L0–L4 level symbols**, and **ID anchors such as `O#`/`C#`/`B#`/`P#` do not exist**, so matching is by text only, not by ID. The target is limited to "specs whose design/implementation has advanced" — spec.json at the requirements phase or later, or tasks.md with one or more checked tasks. Matching is limited to **what is mechanically observable from files** (do not look at git history, code diffs, or timestamps). Non-matchability is the normal case (the known limitation that export records no feature name; the same nature as footnote 2), so false positives are tolerated and it stays a candidate presentation **without asserting**. This check is omitted in environments without `.intent/intent-tree.md` or without `.kiro/specs/`.
+
+9. **The three-layer partition of unfiled / orphan spec / writeback omission (avoiding double warnings)**: a spec whose design draft alone ran ahead may match any one (or several) of the following three layers, from upstream to downstream. **(1) intent-tree unfiled (discover skip = tree layer; footnote 8) — the filing into intent-tree itself was skipped. (2) orphan spec = Packet absence (Packet layer; the orphan-spec check in SKILL.md Step 2) — filed into intent-tree but implemented without going through a Packet. (3) writeback omission (downstream layer; the `/intent-writeback`-family of rows 6/7/9 and the freshness warning) — not yet reflected to canonical after Packet implementation.** When one spec matches multiple layers, present it **only in the single most-upstream layer** and do not re-warn in a downstream layer (do not double-emit a spec that matched upstream in the downstream orphan-spec check / freshness warning). When presenting, guide it as a staged remedy of `discover → packets → writeback`, prompting the user to fill the most-upstream gap first. This partition is an arrangement closed to status's report (Step 5 (3)) and has no effect on the decision-table body's first-match (the single next move) ((1) and (2) are report-only; only (3) can fire a next move as a row).
+
+10. **Split-form cross-reading of append-only records (deltas / export-log; INV25, D6)**: when reading `deltas` / `export-log`, cross-read in the order **the split form `.intent/<rec>/*.md` set (source of truth if present; natural-key ascending) → read-fallback to the old `.intent/<rec>.md` (the generated active mirror) if absent** (the same discipline as overview's `aggregate-sources.md`; readable even when split). When the split form and the old single mirror coexist, treat **the split form as the source of truth** and do not double-count the mirror (avoid double-counting the same entry). archive (`.intent/<rec>/archive/`) is history, and for status's active-side judgments (the writeback-omission cross-check, the current position, the orphan-spec matching) read active thinly (do not mix archive into the active tally). Reading only; modify none of the files (read-only; INV2/A3). This discipline does not break on the pre-migration single-file format (the old scaffold) either (the read-fallback returns the same cross-check result = behavior-preserving; Anti-direction 88).

package/templates/en/claude/skills/intent-to-spec/SKILL.md

@@ -0,0 +1,68 @@
+---
+name: intent-to-spec
+description: Outward generation skill that reads, read-only, the three layers — the Intent (intent-tree / compass), steering constraints, and packets/requirements — within a specified scope (source scope), and maps them into a single readable natural-language Spec in the specified format (target format). Traces each generated statement back to its projection source, and marks statements not present in the source as inferred (fabrication suppression). Output is limited to derived artifacts under `.intent/nl-spec/`, and never modifies any canonical artifact.
+allowed-tools: Read, Glob, Grep, Write, AskUserQuestion
+argument-hint: <source scope / format> (the scope hint and the layout. If no format is specified, the default is used and which format the output was generated in is stated explicitly.)
+---
+
+# intent-to-spec Skill
+
+## Core Mission
+- **Success Criteria**:
+  - Reads, read-only, only the `.intent/` artifacts within the user-specified scope (source scope: Intent subtree / packet group / steering constraints / cross-cutting requirements) as source material, and binds the three layers (the Intent's why / invariants / decision rules / steering-grade constraints / requirements' individual demands) across them (R1.1 / R1.2)
+  - 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)
+  - Makes each generated statement traceable to which projection source it derives from (which Intent L-level / which compass section / which packet / which constraint) (R3.1)
+  - Marks statements with no grounding in the projection source as inferred, and never mixes them with the confirmed (canonical-derived, traceable) statements (R3.2). Presents the places supplemented beyond the projection source as a list the user can review (R3.3)
+  - Holds the invariants / constraints present in the projection source within the generated Spec without omission or alteration (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). States at the top of the output that it is derived / regenerable / not the source of truth (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 the scope; do not generate if ambiguous/absent)
+- When the user runs `/intent-to-spec`, first interpret the argument's scope hint and format 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).
+- **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.
+- Once the scope is confirmed, proceed to Step 2.
+
+### Step 2: Three-layer read (read the three layers read-only)
+- Per the "three-layer read (exact, fixed references)" table in `rules/source-scope.md`, read the three layers across the confirmed scope read-only.
+- Bind, as source material for a single document, the Intent's why / invariants / decision rules (`.intent/intent-tree.md`'s L0–L4 / `.intent/intent-compass.md`'s North Star, Invariants, Anti-direction, Decision Rules), the steering-grade constraints (only when specified, tech.md, etc.), and the requirements' individual demands (`.intent/packets/index.md` + `.intent/packets/active/*.md`).
+- Hold canonical-derived material and inferred-derived material (intent-tree's Assumptions / Open Questions) distinct from the reading stage, and never mix them. Do not read out-of-scope artifacts. Treat the projection sources read-only and do not modify them (R1.4).
+
+### Step 3: Target-format mapping (when defaulting, state the format explicitly)
+- Per the confirmed target format, map the three-layer material bound by Step 2 — keeping the provenance of which layer / which heading / which packet it came from — into a single natural-language Spec.
+- For the **upstream layout (why-fronted)**, delegate to `rules/format-upstream.md`; for the **integrated spec (requirements-crossing)**, delegate to `rules/format-integrated.md`. Express the middle format as a degree adjustment between the two rules, without adding another rule.
+- **When no format is specified (R2.4)**: use the default format and state explicitly in the output **which format it was generated in** (whether the default used was the upstream layout or the integrated spec). Do not pick the default silently.
+- Delegate the mapping to this skill's format rules. Do **not** call `map-cc-sdd.md` (the cc-sdd mapping is owned by export-cc-sdd, and this skill does not touch it).
+
+### Step 4: Fabrication check (trace assignment / inferred marking / invariant preservation)
+- Per `rules/fabrication-guard.md`, check whether the natural-language Spec assembled by the format mapping fabricates beyond the projection source.
+- Trace each statement to a referenceable form pointing to its projection source (which Intent L-level / which compass section / which packet / which constraint) (R3.1). Mark statements with no grounding in the source as inferred and never mix them with the confirmed ones (R3.2). Hold the source's invariants / constraints without omission or alteration (R3.4). Present the supplemented (inferred) places as a list the user can review (R3.3; this is a warning and does not stop generation).
+
+### Step 5: Derived write (full replacement to `.intent/nl-spec/`)
+- Only after all reading, mapping, and checking are complete, **last** write the generated natural-language Spec to `.intent/nl-spec/<format>.md` by **full replacement** (rerunning with the same scope+format is idempotent by full replacement. R4.2).
+- State at the top of the output that this Spec is derived / regenerable / not the source of truth / Git-untracked, and that the statements marked inferred are provisional until the user's review (R4.3).
+- Never write to any canonical `.intent/*.md` (intent-tree / compass / packets), steering (tech.md), or application code (R4.1 / R4.4). Limit the write destination to under `.intent/nl-spec/`.
+
+## Output Description
+- `.intent/nl-spec/<format>.md` (derived, regenerable, Git-untracked; the header states it is not the source of truth). Its content follows the confirmed target format:
+  - **Upstream layout**: purpose (why) → invariants / constraints to hold → decision rules → individual demands → assumptions / unresolved (a separate inferred block, if any), in that order (per the composition in `rules/format-upstream.md`).
+  - **Integrated spec**: overview → premise invariants / constraints → integrated demands with acceptance criteria → assumptions / unresolved (a separate inferred block, if any), in that order (per the composition in `rules/format-integrated.md`).
+  - **Format default statement**: when no format was specified, state in the output which format (the default) it was generated in (R2.4).
+  - **Trace / inferred marking**: assign each statement a reference to its projection source, and place statements with no grounding in the source as inferred, in a block / marking distinct from the confirmed ones.
+  - **Review list of supplemented places**: alongside, a list naming which statement was supplemented and for what reason, for the statements marked inferred.
+- Layers / sections without source material are omitted with the reason (unfilled / unobserved) stated explicitly (never filled in by guessing).
+
+## Safety & Fallback
+- **Write boundary**: writes are limited to under `.intent/nl-spec/`. The canonical `.intent/*.md` (intent-tree / compass / packets / mode, etc.), steering (tech.md), and application code are read-only — never created, modified, or deleted there (the `Write` in the frontmatter is permitted solely for writing under `.intent/nl-spec/`. R4.1).
+- **Derived — not the source of truth**: the artifact is derived / regenerable and not the source of truth. State this at the top of the output, and create no dual source of truth against canonical (R4.3).
+- **Fabrication suppression (the outward load-bearing problem)**: never leave a statement without a trace as confirmed (each statement is either traceable to a projection source or marked inferred). Never mix inferred with confirmed, and never omit or alter the source's invariants / constraints. Always present supplemented places as a review list and never dissolve them silently into the body (R3.x).
+- **Mapping ownership boundary**: delegate the format mapping to this skill's `rules/format-upstream.md` / `rules/format-integrated.md`, and do not call `map-cc-sdd.md`. Do not change the behavior of `/intent-export-cc-sdd` (the source/format-fixed special case) (R5.3 / R5.5).
+- **Read-only**: treat the projection sources (intent-tree / compass / packets / steering) read-only and do not create, modify, or delete them (R1.4).
+- **Zero external dependencies** (INV2 / R5.1). Introduces no external package, AST parser, or custom schema; limited to Node standard and natural-language heuristics, completing the projection within a natural-language workflow.
+- **Does not modify application code** (INV6 / R4.4).
+- **Naming / no external modification**: follows the `intent-*` naming convention and does not modify external spec tools or the kiro-* development environment (R5.5).
+- **When prerequisites are absent**: when the source scope is ambiguous or the corresponding artifact is absent, write nothing, state the absence/ambiguity, guide to the available scope or the missing artifact (the relevant skill to prepare it), and stop (fail-fast. R1.3).
+- **On partial gaps**: layers / sections whose source material cannot be read are stated as "unfilled / unobserved" and omitted (never filled in by guessing).

package/templates/en/claude/skills/intent-to-spec/rules/fabrication-guard.md

@@ -0,0 +1,41 @@
+# Fabrication suppression: generated↔projection-source reconciliation (trace, inferred marking, invariant preservation)
+
+The canonical rule by which the `intent-to-spec` skill reconciles whether the natural-language Spec assembled by the format mapping **fabricates beyond the projection source (Intent / packet / constraint)**, and guarantees that the generated output traces back to the projection source. SKILL.md holds only the procedure and reporting format; "how to bind each description to its projection source, what to mark as inferred, what to preserve, and what to present for confirmation" is defined by this rule. This rule is responsible for the **reconciliation** of the generated output against the projection source, and it never modifies the projection source (intent-tree / compass / packets / steering) (reading is the responsibility of source-scope interpretation, placement of the format mapping, and writing of SKILL.md's derived Write).
+
+The outward load-bearing problem is **fabrication suppression**. Whereas the hard problem inward (spec-ingest) is "silence detection," the hard problem outward is suppressing the hallucination of fluently filling in detail absent from the projection source. Precisely because it reads as prose, whether a basis exists cannot be told from reading the body alone. This rule supplies that determination as a reconciliation that checks each description of the generated output against the projection source.
+
+## The reconciliation idea is homologous to drift-export-check (generated↔projection-source)
+
+- This reconciliation is **homologous** to `drift-export-check.md` (the export-time water's-edge reconciliation that checks the design/tasks hints against the compass's direction). That one checks the just-before-export draft against the compass's North Star / Anti-direction / Invariants; this rule directs the same "generated↔projection-source" reconciliation idea at the **whole generated Spec**.
+- The basis of the reconciliation is the **three-layer material itself** that source-scope interpretation read and the format mapping placed while preserving provenance (the intent-tree's L0–L4 / the compass's North Star, Invariants, Anti-direction, Decision Rules / the packets' individual requirements, dependencies, evidence / (only when specified) steering). Hold no new structure; trace that provenance information to confirm the basis of each description.
+- The reconciliation is a **semantic check**, not a mechanical decision. Lean toward catching suspect descriptions (detail that has no findable basis in the projection source yet is blended into the body).
+
+## Procedure
+
+1. **Trace each description back to the projection source (Req 3.1)**
+   - For each description in the generated Spec, attach a traceable reference for which projection source it derives from (which Intent L-level / which compass section / which packet / which constraint).
+   - The reference is based on the provenance information (which layer, which heading, which packet it came from) that source-scope interpretation and the format mapping have preserved. Do not build it by re-reading the projection source anew; map the handed-over provenance straight into the reference.
+   - When one description derives from multiple projection sources, list all of them. Do not leave a description with no attached trace as confirmed.
+
+2. **Mark descriptions with no projection-source basis as inferred (Req 3.2)**
+   - Descriptions for which no correspondence to a projection source is found in Step 1 (detail / acceptance criteria / premises supplemented for fluency) are **marked as inferred**.
+   - Do **not mix** inferred descriptions **with confirmed ones** (descriptions that are canonical-derived and carry a trace). Do not blend them into the body; place them in a separate slot / under a separate marking that is distinguishable from confirmed descriptions.
+   - Material that has been distinguished as inferred from the reading stage on, such as the intent-tree's Assumptions / Open Questions, is likewise placed on the inferred side without mixing with confirmed material (do not collapse here the distinction the format mapping has preserved).
+
+3. **Preserve invariants and constraints without omission or alteration (Req 3.4)**
+   - Reconcile whether the **invariants and constraints** present in the projection source (the compass's Invariants / (only when specified) steering's constraints-to-uphold / those among the packets' dependencies and acceptance criteria that amount to constraints) are **omitted or altered** in the generated Spec.
+   - The generated Spec preserves the projection source's invariants and constraints as they are. Do not drop them for the sake of summary, do not change their meaning by rephrasing, and do not loosen or tighten them. Adjusting phrasing for readability is permitted, but a rewrite that changes the content of a constraint is not.
+   - When an omitted invariant or constraint is found, supplement and preserve it (the generated output must not delete what exists in the projection source).
+
+4. **Present supplemented places for confirmation (Req 3.3)**
+   - Present the **list** of places where detail was supplemented beyond the projection source (the descriptions marked as inferred in Step 2) **in a form the user can confirm**.
+   - The list names which descriptions, and for what reason, have no basis in the projection source (were supplemented), at a granularity that lets the user judge whether to accept or reject the supplementation.
+   - The presentation is a warning; it does not stop generation. Whether to accept the supplementation is left to the user's judgment.
+
+## Invariants
+
+- Do not re-read and reinterpret the projection source (intent-tree / compass / packets / steering), and do not modify it (reconciliation only; reading is the responsibility of source-scope interpretation, placement of the format mapping).
+- Do not leave a description with no attached trace as confirmed (each description is either traceable back to the projection source or else marked as inferred).
+- Do not mix inferred descriptions with confirmed (canonical-derived) ones (do not collapse the separate slot / separate marking).
+- Do not omit or alter the projection source's invariants and constraints (neither dropping by summary, nor changing meaning by rephrasing, nor loosening/tightening).
+- Always present supplemented places as a list for confirmation (do not silently blend them into the body).

package/templates/en/claude/skills/intent-to-spec/rules/format-integrated.md

@@ -0,0 +1,42 @@
+# format mapping: integrated-spec-facing (crossing requirements integrated)
+
+The mapping rule by which the `intent-to-spec` skill assembles the three-layer material read by source-scope interpretation into an **integrated-spec-facing natural-language Spec** (an implementation-near layout where the crossing requirements and acceptance criteria are integrated into one readable whole). SKILL.md holds only the procedure and reporting format; "which material to place in what order, under which heading" is defined by this rule.
+
+## Responsibility boundary (this is a mapping, not reading or reconciliation)
+
+- This rule is a **format mapping**. It is responsible only for the composition, order, and heading assignment of the material.
+- It does **not re-read** the projection source (intent-tree / compass / packets / steering). It holds no custom parser or schema; it merely rearranges the material handed over by source-scope interpretation (which preserves which layer, which heading, and which packet each piece came from).
+- Making each description traceable back to the projection source, marking material absent from the projection source as inferred, and preserving invariants without omission or alteration are the **responsibility of the fabrication-guard rule**; this rule does not do them. This rule receives canonical-derived material and inferred-derived material (Assumptions / Open Questions) **kept distinguished**, and only upholds placing them without collapsing that distinction.
+- The intermediate format (between upstream and integrated) holds no separate, independent rule. This rule and format-upstream (upstream-facing) represent the two poles, and the intermediate is expressed as a **degree** between those poles (an adjustment of how far the upstream-facing "why up front" is shifted toward the integrated side, without adding another rule).
+
+## Basic posture (integrate the crossing requirements into an implementation-near form)
+
+An integrated-spec-facing Spec is a layout that **integrates the crossing requirements and acceptance criteria into one whole an implementer can read straight through**. The assumed reader is someone about to start implementation. Therefore:
+
+- **Integrate** the scattered individual requirements, arranged per functional grouping, and attach to each requirement its acceptance criteria (the conditions to satisfy).
+- Keep the why (purpose) and constraints (invariants, decision criteria) concise as **premises that support** the individual requirements; do not bring them to the front as much as in the upstream-facing layout (the more you bring them to the front, the more it shifts toward upstream-facing — the degree adjustment).
+- Do not add detail or acceptance criteria absent from the material for fluency's sake (places that need completion are handled by the fabrication-guard rule as inferred; this rule must not dissolve them into the body).
+
+## Composition (integrate the crossing requirements, attaching acceptance criteria to each)
+
+Place the three-layer material handed over by source-scope interpretation in the following order. Hand each section's material over with its origin preserved, so that the downstream fabrication-guard rule can trace which layer and which heading it came from.
+
+| Order | Section | What to place | Main material origin |
+|---|---|---|---|
+| 1 | Overview (what is built) | The scope the integrated spec heads toward and a summary of the purpose it satisfies | Intent's North Star (compass) plus intent-tree's L0–L1 (concise) |
+| 2 | Premise invariants / constraints | Invariants and decision criteria to uphold in common across all requirements | compass's Invariants / Anti-direction / Decision Rules (plus steering constraints only when specified) |
+| 3 | Integrated requirements and acceptance criteria | The body that integrates the crossing requirements per functional grouping, attaching to each requirement its acceptance criteria | crossing requirements (packets' individual requirements, dependencies, evidence) plus acceptance criteria |
+| 4 | Premises / unsettled (if any) | Premises and open questions placed in a separate slot, **not mixed** with the confirmed material above | intent-tree's Assumptions / Open Questions (inferred-derived) |
+
+- Compose sections 1–3 from canonical-derived material. The body is section 3, which integrates the crossing requirements per functional grouping and attaches the corresponding acceptance criteria to each requirement (do not separate a requirement from its acceptance criteria).
+- Place section 2's why and constraints concisely as premises that support the body (3). The more you bring them to the front, the more it shifts toward upstream-facing (the intermediate format is expressed as the degree between this section and the upstream-facing "why up front").
+- Place section 4's inferred-derived material (Assumptions / Open Questions) in a **separate slot at the end**, not dissolved into the canonical body. If there is no such material, omit the section entirely (do not create an empty heading).
+- Omit the section for any layer whose material is absent (do not fill in information that is not there). However, the integrated requirements and acceptance criteria (3) are the crux of the integrated-spec-facing layout; if their material has been read, always place them.
+
+## Invariants
+
+- Do not re-read or modify the projection source (mapping only; reading is the responsibility of source-scope interpretation, writing is the responsibility of SKILL.md's derived Write).
+- Do not separate the crossing requirements from their acceptance criteria (do not break the integrated composition that attaches its acceptance criteria to each requirement).
+- Express the intermediate between upstream-facing and integrated-facing as a degree; do not create a separate rule (this rule and format-upstream are the two poles).
+- Do not mix canonical-derived material with inferred-derived material (place them with the distinction preserved, and leave the marking itself to the fabrication-guard rule).
+- Do not add detail or acceptance criteria absent from the material to smooth the prose.

package/templates/en/claude/skills/intent-to-spec/rules/format-nonprogram.md

@@ -0,0 +1,45 @@
+# format mapping: non-program target (documents, operations, research, etc.)
+
+The mapping rule by which the `intent-to-spec` skill assembles the three-layer material read by source-scope interpretation into a **non-program-target natural-language Spec** (a readable artifact for paths that use neither cc-sdd nor openspec — documents, business processes, research / decision-making). SKILL.md holds only the procedure and reporting format; "which material to place in what order, under which heading" is defined by this rule.
+
+## Responsibility boundary (this is a mapping, not reading or reconciliation)
+
+- This rule is a **format mapping**. It is responsible only for the composition, order, and heading assignment of the material. It does not re-read the projection source (intent-tree / compass / packets / steering) and holds no custom parser or schema; it merely rearranges the material handed over by source-scope interpretation (which preserves which layer, which heading, and which packet each piece came from).
+- Making each description traceable to the projection source, marking inferred material, and preserving invariants are the **responsibility of the fabrication-guard rule**; this rule does not do them. It receives canonical-derived and inferred-derived material kept distinguished and places them without collapsing that distinction.
+- This rule holds **no packing strategy (mode)**. Packing intent is the responsibility of `intent/modes/` (DR16); it must not be mixed into this rule, which is the output-layout container.
+
+## Basic posture (let the reader read the artifact in their own words)
+
+A non-program-target Spec is a layout that lets a reader who writes no code (the document's agreeing party, the operations owner, the research / decision stakeholders) read straight through **what is decided, why it is so, how to judge, and what must be satisfied**. It does not bring implementation vocabulary (APIs, modules, test cases, etc.) to the front; it presents the artifact in the words of the target domain. Therefore:
+
+- Show the background and purpose (the why) and the bar to reach (the what) at the head of the artifact, in the reader's words.
+- Place the promises to uphold and the basis for judgment (invariants, decision criteria) before the individual content.
+- State the acceptance basis (was it agreed, or sent back) in **words of agreement / acceptance**, not in code's testable vocabulary (the degrade vocabulary is re-read on the packets side; this rule places that already-re-read material as is).
+- Do not add background or detail absent from the material for fluency's sake (places that need completion are handled by the fabrication-guard rule as inferred; this rule must not dissolve them into the body).
+
+## Composition
+
+Place the three-layer material handed over by source-scope interpretation as a single generic artifact, in the following order (do not cover per-domain count / granularity here). Hand each section's material over with its origin preserved, so that the downstream fabrication-guard rule can trace which layer and which heading it came from.
+
+| Order | Section | What to place | Main material origin |
+|---|---|---|---|
+| 1 | Background and purpose | The direction this artifact heads toward and the problem it solves (in the reader's words) | Intent's North Star (compass) plus intent-tree's L0–L1 |
+| 2 | Promises / premises to uphold | Invariants that must not be deviated from, and the direction to avoid | compass's Invariants / Anti-direction (plus steering constraints only when specified) |
+| 3 | Basis for judgment | The basis for what to prioritize when uncertain | compass's Decision Rules |
+| 4 | Content (the individual bars to reach) | The individual requirements / agreements to satisfy under the above | crossing requirements (packets' individual requirements, dependencies, acceptance grounds) |
+| 5 | Acceptance basis | The acceptance vocabulary (already degraded) for judging whether it is agreed or sent back | packets' verification vocabulary (re-read for non-code: testable→judgeable by acceptance criteria, etc.) |
+| 6 | Premises / unsettled (if any) | Premises and open questions placed in a separate slot, **not mixed** with the confirmed material above | intent-tree's Assumptions / Open Questions (inferred-derived) |
+
+- Compose sections 1–5 from canonical-derived material. Do not reorder them (the order background & purpose → promises → basis for judgment → content → acceptance is the core of the non-program-target layout).
+- Place section 6's inferred-derived material (Assumptions / Open Questions) in a **separate slot at the end**, not dissolved into the canonical body. If there is no such material, omit the section entirely (do not create an empty heading).
+- Omit the section for any layer whose material is absent (do not fill in information that is not there). However, background and purpose (1) and promises / premises to uphold (2) are the crux of this layout; if their material has been read, always place them.
+- Even when steering has not been read (steering is opt-in), sections 1, 2, 4, and 5 can be composed from the Intent and packets two layers. Do not drop the artifact for the sole reason that steering is absent.
+
+## Invariants
+
+- Do not re-read or modify the projection source (mapping only; reading is the responsibility of source-scope interpretation, writing is the responsibility of SKILL.md's derived Write). Output is limited to derived artifacts under `.intent/nl-spec/`, and canonical material (intent-tree / compass / packets) is treated read-only.
+- Keep each description traceable to the projection source, and mark material absent from the projection source as inferred (leave the marking itself to the fabrication-guard rule; this rule only upholds placing them without collapsing the distinction).
+- Do not break the order that places background & purpose (why) and promises / decision criteria **before** the individual content.
+- Do not mix canonical-derived material with inferred-derived material (place them with the distinction preserved).
+- Do not add background, motivation, or detail absent from the material to smooth the prose.
+- Do not mix packing strategy (mode) into the output-layout (format) container (DR16: responsibility separation).

package/templates/en/claude/skills/intent-to-spec/rules/format-upstream.md

@@ -0,0 +1,41 @@
+# format mapping: upstream-facing (why up front)
+
+The mapping rule by which the `intent-to-spec` skill assembles the three-layer material read by source-scope interpretation into an **upstream-facing natural-language Spec** (an RFP / proposal-style layout where why leads). SKILL.md holds only the procedure and reporting format; "which material to place in what order, under which heading" is defined by this rule.
+
+## Responsibility boundary (this is a mapping, not reading or reconciliation)
+
+- This rule is a **format mapping**. It is responsible only for the composition, order, and heading assignment of the material.
+- It does **not re-read** the projection source (intent-tree / compass / packets / steering). It holds no custom parser or schema; it merely rearranges the material handed over by source-scope interpretation (which preserves which layer, which heading, and which packet each piece came from).
+- Making each description traceable back to the projection source, marking material absent from the projection source as inferred, and preserving invariants without omission or alteration are the **responsibility of the fabrication-guard rule**; this rule does not do them. This rule receives canonical-derived material and inferred-derived material (Assumptions / Open Questions) **kept distinguished**, and only upholds placing them without collapsing that distinction.
+- The intermediate format (between upstream and integrated) is treated as the "why up front" degree of this rule shifted toward the integrated side. It holds no separate, independent rule.
+
+## Basic posture (place why up front)
+
+An upstream-facing Spec is a layout that makes the reader read **why it is built (and what must be upheld) before what is built**. The assumed reader is not the implementer but someone judging direction and validity (an upstream decision-maker). Therefore:
+
+- Place purpose, invariants, and decision criteria (the why and constraints) at the **front** of the document.
+- Place implementation-near detail such as individual requirements and acceptance criteria **after** the why and constraints, as material supporting them.
+- Do not add background or motivation absent from the material for fluency's sake (places that need completion are handled by the fabrication-guard rule as inferred; this rule must not dissolve them into the body).
+
+## Composition (top to bottom: why → constraints → decision criteria → individual requirements)
+
+Place the three-layer material handed over by source-scope interpretation in the following order. Hand each section's material over with its origin preserved, so that the downstream fabrication-guard rule can trace which layer and which heading it came from.
+
+| Order | Section | What to place | Main material origin |
+|---|---|---|---|
+| 1 | Purpose (why it is built) | The direction this Spec heads toward and the problem it solves | Intent's North Star (compass) plus intent-tree's L0–L1 (the upper why) |
+| 2 | Invariants / constraints to uphold | Invariants that must not be deviated from, and the direction to avoid | compass's Invariants / Anti-direction (plus steering constraints only when specified) |
+| 3 | Decision criteria | The basis for judgment when design / implementation is uncertain | compass's Decision Rules |
+| 4 | Individual requirements | The individual requirements to satisfy under the above why and constraints | crossing requirements (packets' individual requirements, dependencies, evidence) |
+| 5 | Premises / unsettled (if any) | Premises and open questions placed in a separate slot, **not mixed** with the confirmed material above | intent-tree's Assumptions / Open Questions (inferred-derived) |
+
+- Compose sections 1–4 from canonical-derived material. Do not reorder them (the order why → constraints → decision criteria → individual requirements is the core of the upstream-facing layout).
+- Place section 5's inferred-derived material (Assumptions / Open Questions) in a **separate slot at the end**, not dissolved into the canonical body. If there is no such material, omit the section entirely (do not create an empty heading).
+- Omit the section for any layer whose material is absent (do not fill in information that is not there). However, purpose (1) and invariants / constraints (2) are the crux of the upstream-facing layout; if their material has been read, always place them.
+
+## Invariants
+
+- Do not re-read or modify the projection source (mapping only; reading is the responsibility of source-scope interpretation, writing is the responsibility of SKILL.md's derived Write).
+- Do not break the order that places why (purpose) and constraints (invariants, decision criteria) **before** individual requirements.
+- Do not mix canonical-derived material with inferred-derived material (place them with the distinction preserved, and leave the marking itself to the fabrication-guard rule).
+- Do not add background, motivation, or detail absent from the material to smooth the prose.