intent-planner 0.13.1

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

@@ -0,0 +1,97 @@
+---
+name: intent-packets
+description: From the Intent Tree and Intent Compass, build the Packet Plan before handing off to cc-sdd. Each packet has a parent intent and is behavior-preserving / testable / rollbackable. Does not implement.
+disable-model-invocation: true
+allowed-tools: Read, Write, Glob, Grep, AskUserQuestion, Bash
+argument-hint: <focus of the decomposition (optional)>
+---
+
+# intent-packets Skill
+
+## Core Mission
+- **Success Criteria**:
+  - There are as many packet candidates as the expected change size warrants (do not pad the count; one packet is fine for very small changes; treat 1–7 as a loose guide), and each packet references a parent intent
+  - Each packet is drafted as an individual file under `.intent/packets/active/` (1 packet = 1 file)
+  - Each packet has Scope / Non-scope / Expected Behavior / Decisions / Safety(Invariants) / Validation / Evidence / Rollback / cc-sdd Mapping (keep `Evidence` as an empty section when there is no result)
+  - In each packet's `## Decisions` section, the common-core slots from `decision-slots.md` (plus the mode-specific diffs) are each closed with one of the 4 statuses (answered / undetermined / not-applicable / ADR candidate) (do not fill in defaults; do not silently skip)
+  - Each packet is at a behavior-preserving / testable / rollbackable granularity
+  - No existing packet file has been destroyed (changes are presented as differential update proposals)
+  - No application code has been changed at all
+
+## Execution Steps
+
+### Step 1: Read the prerequisites
+- Read `.intent/intent-tree.md` and `.intent/intent-compass.md`. If either is missing, guide the user to "run the corresponding command first" and stop.
+- While reading, when you see an unsettled verb slipped into the settled phrasing of the compass / intent-tree (assume / reuse / planned / TBD / tentative, etc.), do not fix it by guessing; present it as a conversion proposal into Open Questions or an undetermined slot (with the reason and the revisit condition (Revisit when)). Promotion to a fixed value is left to the user's confirmation. Do not re-convert spots already recorded in Open Questions / Deferred / an undetermined slot.
+- Read `.intent/mode.local.md` (falling back to `.intent/mode.md` if absent) for the mode state. If both are absent, default to standard and announce it in Open Questions (do not stop).
+- Read `.intent/packets/index.md` and the existing packet files under `.intent/packets/active/` (the basis for differential updates).
+- Legacy-install handling: if `.intent/packets/`, `plan.md`, `index.md`, or `README.md` is missing, the skill creates them itself before proceeding (do not wait for a scaffold reinstall).
+- After-the-fact drafting (when implementation ran ahead): when the invocation context or the user's report makes clear that **implementation proceeded / completed without a corresponding Packet**, treat it with the same procedure as normal drafting (raise the Packet even after the fact; being already implemented is not a reason to skip drafting). In this case:
+  - Record the established facts (the wiring / behavior already implemented) as `what + constraints + oracle` in the packet file.
+  - For the **spec that cannot yet be fixed** (the trigger, threshold, judgment means, etc. — decisions not yet committed to, or placed provisionally), do not fill them by guessing; put them explicitly into the container as Open Questions and Deferred (`undecided (deferred, with a revisit condition)`, always with the revisit condition). "Not drafting a Packet because the spec cannot be fixed" is wrong — holding the unfixed as-is is exactly the Packet's role.
+  - Guide the order: **first raise the Packet with this skill (the drafting phase), then return the learnings gained from the implementation reality to canonical via a delta with `/intent-writeback` (the post-implementation phase)**. These two run in opposite directions; do not perform only writeback while skipping the Packet drafting (the phase boundary follows writeback-protocol.md §3).
+
+### Step 2: Apply the mode definition's algorithm
+- Open the mode definition that `.intent/mode.local.md` (falling back to `.intent/mode.md`) `definition` points to, and read and apply the algo rule (`rules/algo-*.md`) assigned to the Packet decomposition phase (standard → `rules/algo-example-mapping.md`; refactor → `rules/algo-migration-slicing.md`; behavior-unknown → `rules/algo-example-mapping.md` + `rules/algo-characterization-test.md`). The examples are not exhaustive; the mode definition's table is always authoritative.
+
+### Step 3: Decompose into Packets
+- Following Example Mapping, expand each L2/L3 capability into "rules, examples, questions, deferred".
+- Derive Expected Behavior, Validation, and Rollback from the examples.
+- Consolidate into as many packets as the expected change size warrants (do not target a count or pad it; one packet is fine for very small changes; treat 1–7 as a loose guide). Measure size qualitatively by "the number of concerns touched × the breadth of impact on existing boundaries"; do not bring in effort estimates or other numeric metrics. Always give each packet a parent intent (a reference to L0/L1/L2/L3).
+- Draft each packet as an individual file at `.intent/packets/active/<packet_id>.md`. Read `rules/packet-format.md` and follow it for ID assignment, filling in the frontmatter keys, and the body section structure (including the `## Decisions` and `## Evidence` sections) — the canonical source is the single source of truth for the key set and value domains.
+- Stamp `updated_at` (the writer's responsibility): after writing a packet file, record its update timestamp in the frontmatter `updated_at` (ISO 8601). On a new packet, set `updated_at` to the same timestamp as `created_at`; when you change the content of an existing packet, update `updated_at` to that moment. On a re-run that involves no content change, do not change `updated_at` (idempotent; do not stamp when nothing changed). Obtain the timestamp with Bash `date`, the same way as `created_at`. If you cannot obtain the date/time, do not write a guessed date — report that instead. Stamping is the writer's (this skill's) responsibility and is not given to the read-only verification layer (intent-validate).
+- Read `rules/decision-slots.md` and seed the completeness-schema slots into each packet's `## Decisions` section (the canonical source for the slot definitions, value domains, and IDs is decision-slots.md; this section is its projection).
+  - Seed the common-core slots (the 8 IDs seeded in every mode) into every packet, and add the mode-specific diff slots according to `.intent/mode.local.md` (falling back to `.intent/mode.md`) mode (standard / refactor / behavior-unknown / feature-growth). The slot definitions are authoritative in the decision-slots.md table; do not hardcode them into the SKILL body.
+  - Close each slot with **exactly one** of the 4 statuses (answered / undetermined / not-applicable / send to ADR candidate) (structurally preventing "silently skipping"). Do not fill in a "reasonable default" or "recommended value" (anchoring avoidance). Do not infer or auto-fill a slot's applicability or value from the artifacts (a human declares them).
+  - Reflect the posture that discover recorded directly under tree L3 as "points that need a decision (④)" (even when no concrete value exists, treat the slot's existence as something to close).
+  - For slots already covered by existing artifacts, do not recreate them; reference their close target (e.g. `decision-fit-criterion` → `## Validation`, `decision-exception-flow` → `## Expected Behavior`, `decision-characterization` → `algo-characterization-test.md`). Do not write the value twice in `## Decisions`; declare that it "is closed in the existing section" (no duplicate definition).
+  - For an `undetermined` slot, also note the reason, the caveat for downstream, and the revisit condition (Revisit when). For a `not-applicable` slot, also note the rationale for non-applicability and do not silently drop it.
+- Dosage triage (front-load / defer): sort each decision into "a human fixes it up front (visible rule)" or "delegate it to the agent and defer it (hidden / discretion)".
+  - A decision that meets any of the 5 front-loading criteria (irreversible / costly to change later; ripples across multiple modules or external users (external impact); makes acceptance tests or observation weak when left ambiguous (acceptance oracle); a security / regulatory floor; binds multiple packets) is **fixed up front**. An architecture-significant decision meeting two or more is sent to the compass's Decision Rules as an ADR candidate.
+  - A decision that can be localized inside the design rules and is reversible (cheap-to-reverse) and explorable is kept as `undetermined (deferred, with revisit condition)` and may be delegated to the agent's discretion zone (do not leave it neglected; always note the revisit condition).
+  - Front-loading is not limited to "finalizing the decision itself early"; prioritize **front-loading learning, risk discovery, and test-oracle formation** (do not force an early lock-in of the conclusion).
+- Fill in `state` declaratively from the 5-value domain in `packet-format.md`. Do not finalize a progression stage (especially `verifying`/`done`) on the AI's self-report alone; base it on a human or a check gate (results from intent-validate / drift-watch). `state=done` presupposes finalized verification results in the `## Evidence` section.
+- In `depends_on`, declaratively list the `packet_id`s of the packets this one depends on (default `[]`; never omit the key even when empty). Tools do not infer or compute dependencies.
+- In the `## Evidence` section, record the verification result, the date, the check-axis ID (kebab-case ID from `validate-checks.md`), and the source (intent-validate / drift-watch / human confirmation). Evidence is based on check results or human confirmation, not the AI's self-report, and is recorded so the source is traceable. Keep it as an empty section when there is no result; never fill it in by guessing.
+- Present an existing packet's `state: active` as a migration proposal to `implementing`, and a missing `depends_on`/`## Evidence` as a lazy-completion proposal (a differential addition of `depends_on: []`), riding on the existing differential-update-proposal discipline (no forced bulk migration; move only; never delete).
+- If existing packet files exist, read them and present additions as differential update proposals rather than overwriting or destroying them.
+- Reflect the Compass's **project-universal** invariants into each packet's Safety, and draft packet-specific invariants directly in the packet file's Safety / Invariants (do not write them into the compass).
+- Read the constraints held in `.intent/intent-compass.md`'s `## Open Questions` as "packet-specific constraints (candidates)". For each candidate that matches this packet's work scope (Scope/Non-scope), confirm it with the user via AskUserQuestion, then transcribe it into that packet file's Safety / Invariants and remove the transcribed entry from the compass's `## Open Questions` (do not leave the hold duplicated). Candidates that match no packet remain held in the compass's `## Open Questions`.
+
+### Step 4: Judge termination, then present priorities and splits
+- Decomposition termination (composite stop condition): stop splitting once a packet satisfies all six conditions. (1) one packet maps to one primary concern; (2) the acceptance criteria reduce to observable inputs, conditions, and expected results; (3) the boundaries of the solution space (fixed / discretionary / forbidden) are explicit; (4) cheap-to-reverse (backing out is cheap); (5) the trace target is clear (you can follow the parent intent / spec_refs); (6) standalone completeness: a packet's own done is a coherent behavioral boundary that is not half-baked as seen by the user / caller (do not create a done for half-done behavior). (6) is an independent condition distinct from (4) — (4) is "the builder-side rollback safety (intermediate states can be backed out)", while (6) is "the caller-side semantic consistency of the completed form"; the observer differs (do not fold (6) into (4)). Before these hold it is too coarse; splitting further after they hold is over-decomposition.
+- The verifiability floor is discriminative testability: "a test can be written (testability)" is not enough; there must be "an oracle that can reject a wrong implementation". A packet for which no such rejecting oracle can be found has immature acceptance criteria — rework its Validation / Expected Behavior into observable form.
+- A packet whose acceptance criteria span multiple concerns or multiple quality-attribute trade-offs is judged "still too coarse"; propose splitting it along concern lines (move toward one packet = one concern).
+- Do not decompose a work unit down to implementation steps (a full specification of the how). Keep it at `what + constraints + oracle` (what / boundary constraints / an oracle that rejects wrong implementations), and leave the inside of the rules to the agent's discretion.
+- Maintain the existing granularity discipline (behavior-preserving / testable / rollbackable; the count is variable with the change size, with 1–7 as a loose guide, and do not pad the count), and use "one packet = one concern" and (6) standalone completeness explicitly in the termination judgment.
+- Indicate the packets' priority.
+- Read `rules/walking-skeleton.md` and apply it according to the rule's applicability conditions.
+- Read `rules/first-packet.md` and apply it.
+- Present split proposals for packets that are too large.
+- For packets confirmed by the user, declaratively update `state` from draft to `ready` (ready to start; dependencies resolved) and regenerate `index.md` (see `rules/packet-format.md` for the value domain and the regeneration procedure). Progression to in-progress/awaiting-verification/done (`implementing`/`verifying`/`done`) is done by subsequent declarations based on a human or a check gate.
+- Supersede: when a plan revision replaces an existing packet with a successor, fill in `superseded_by` on the old packet at the same time the successor packet is drafted, move it to `archive/<year>/`, and regenerate the index.
+- **In-flight guard**: if the packet being replaced has been exported (has a row in `.intent/export-log.md`) and has no terminal-state (promoted / closed) delta, warn that implementation may be in progress and do not move it without user confirmation.
+- Treat a rename request for an exported packet as a supersede, not a rename (the name-mutability rule in `rules/packet-format.md`).
+- Do not make implementation changes.
+
+## Output Description
+
+**Reader**: a human developer who carves out the work units and hands them to the implementation flow.
+**What this output makes them grasp first**: "**this is the packet to start with first (= the packet to export next). The next move is the exit that matches the case type.**" The packet list / priorities / split proposals are the detail that backs it up.
+
+Lead the output with the conclusion (the packet to start and the next command).
+
+- **The packet to start with first (top, with reasons)**: the recommended packet = the packet to export next (the same one). Attach the reason why it is led with.
+- **Next move (one line, branched by case type)**: apply `rules/export-route.md` (the exit decision lane) read-only and present the exit chosen from the case type. Do not recommend cc-sdd unconditionally (no hardcoding):
+  - If the target format (the `format` line in `.intent/mode.local.md`) is set to a valid value, recommend that exit: `cc-sdd` → `/intent-export-cc-sdd` / `openspec` → `/intent-export-openspec` / `to-spec` → `/intent-to-spec`.
+  - If `format` is unspecified (absent / placeholder / out of range), infer the top candidate from mode (non-code / standard-family) and the prerequisite (presence of `.kiro/`) (non-code + no `.kiro/` → `/intent-to-spec` / standard + `.kiro/` present → `/intent-export-cc-sdd`).
+  - When it cannot be uniquely determined, do not collapse to a single exit — list candidates (the exit depends on the user's intent; the decision detail is owned by `rules/export-route.md`).
+- **Details**: the packet files under `.intent/packets/active/` (new drafts / differential update proposals for existing ones; as many packets as the change size warrants, with 1–7 as a loose guide, each with a parent intent), updates to `.intent/packets/plan.md` and `.intent/packets/index.md`, the packet priorities, and split proposals for packets that are too large.
+
+## Safety & Fallback
+- If there is no Intent Tree / Compass, stop and guide the user to the corresponding command.
+- The absence of mode.md does not stop; continue with the standard default and announce it.
+- Do not drop packets too far down into implementation tasks (above an Issue, before a spec).
+- Do not delete packet files (move only).
+- Bash usage is limited to getting the date/time, directory creation (mkdir) and moves under `.intent/packets/` (the invariant of not changing application code stays).
+- Do not change application code.

package/templates/en/claude/skills/intent-packets/rules/algo-additive-slicing.md

@@ -0,0 +1,55 @@
+# Algorithm: Additive Slicing
+
+A technique for decomposing a new feature into "additive slices" that are added in an order that does not affect existing behavior. Used together with Example Mapping in the Packet decomposition phase of `feature-growth` mode. It composes the slices in three stages — establish the seam → additively stack the new feature → wire it into the existing system — deriving a path where each slice can be delivered independently while preserving the existing behavior. Where Migration Slicing takes a drift list (gaps to fix) as input, Additive Slicing takes the impact list and the new feature's intent — the inputs differ, so the two are not interchangeable.
+
+## Procedure
+
+Input = the new feature's intent (structured via GORE-lite and concretized via Example Mapping) and the impact list produced by Impact Analysis in discover (each item = boundary touched / existing contract depended on / kind of impact). A thin impact list turns the slices into guesswork — if it lacks the depth to design the seams, go back to discover.
+
+1. **Cut the slice that establishes the seam**
+   - From the impact list's "extend / requires change" items, identify the junction points where the new feature meets the existing system, and put first a **behavior-preserving slice that creates the junction with the minimal change to the existing code**.
+   - Reference the established tactics: the interface insertion of **Branch by Abstraction** (Fowler / Hammant), the expand stage of **Parallel Change (expand-contract)** (Danilo Sato), and the **seam concept** (Feathers, Working Effectively with Legacy Code). All are moves for "creating a point where a new implementation can be plugged in without changing existing behavior".
+   - When the seam-establishing slice completes, the existing observable behavior must be unchanged.
+
+2. **Stack the new feature additively**
+   - Beyond the seam, stack the new feature as a **set of slices consisting only of new code that does not touch existing code**. The slices in this stage are unreachable from the existing system before wiring, so they can be stacked while keeping the impact on existing behavior at zero.
+   - The examples concretized by Example Mapping flow into each slice's Expected Behavior.
+
+3. **Wire it in and activate**
+   - Finally, place the **wiring slice that activates the new feature via the seam**. The wiring must be revertible to disabled on its own (each packet's Toggle Plan makes this concrete).
+
+4. **Explore and split candidates with SPIDR**
+   - For exploring slice candidates and splitting slices that are too large, use **SPIDR** (Mike Cohn: the five cuts of Spike / Paths / Interfaces / Data / Rules) as an auxiliary heuristic.
+   - Rough affinity with the stages: seam stage = Interfaces, additive stage = Paths / Rules, wiring stage = Data / Rules.
+
+5. **Attach a verification point, rollback, and toggle plan to each slice**
+   - Attach a regression verification point for existing behavior, so that behavior preservation is observable → **Validation**.
+   - How to revert on failure (each slice must be reversible on its own) → **Rollback**.
+   - Which scope is off-by-default / under what condition the toggle gets removed → **Toggle Plan**.
+
+6. **Confirm the termination of the impact list**
+   - Confirm that every item in the impact list terminates as one of — "protected by the Safety / Invariants of some slice" or "sent to Open Questions". Leave no item that is neither.
+
+## Assembling the packet
+
+Consolidate the three-stage ordered additive slices into packets. Each packet satisfies the following.
+
+- **Parent Intent**: a reference to the corresponding L1/L2/L3 (required). If it protects an impact-list item, also indicate the original item.
+- **Scope / Non-scope**: the addition this slice includes / does not include.
+- **Expected Behavior**: derived from the "examples" of Example Mapping. For the seam and wiring slices, also note "the existing behavior preserved".
+- **Safety / Invariants**: invariants that must not be broken during the transition. State explicitly which impact-list items it protects (derived from the Compass invariants).
+- **Validation / Rollback**: derived from the above.
+- **Toggle Plan**: which scope is off-by-default / under what condition the toggle gets removed (Hodgson's Release Toggles). Estimating the toggle's implementation difficulty is outside the planning scope — write up to the plan for its existence and lifetime.
+- **cc-sdd Mapping**: the policy for how to hand off to cc-sdd.
+
+## Discipline
+
+- Each slice must be **behavior-preserving / testable / rollbackable**.
+- **Impact-list traceability**: every item in the input impact list must terminate as one of — protected by the Safety / Invariants of some slice, or sent to Open Questions. Never silently drop an item.
+- **Keep the stage order**: establish the seam → add → wire. Do not embed directly into existing modules without creating a seam.
+- Keep the count variable with the expected change size; do not pad it (one is fine for very small changes; treat 1–7 as a loose guide). For slices that are too large, present split proposals along the SPIDR cuts.
+- This is the structuring of intent (a packet-decomposition technique), not addition execution code. Do not change code.
+
+## Output
+
+An ordered set of additive slices (establish the seam → add → wire). Each slice has the structure above, and its Scope / Validation / Rollback / Toggle Plan flow into each packet. Update (present as a proposal) the packet files (under `active/`).

package/templates/en/claude/skills/intent-packets/rules/algo-characterization-test.md

@@ -0,0 +1,40 @@
+# Algorithm: Characterization Test
+
+A technique for capturing the "observable behavior" of unknown legacy as test points that pin it down exactly as it is now. Used together with Example Mapping in the Packet decomposition phase of `behavior-unknown` mode. **For a target with unknown behavior, run this technique first** and hand the observed facts to Example Mapping (you cannot write "examples" for behavior you do not know, so observation comes first). Before structuring intent, it fixes "how it behaves now" as a safety net and derives the packet's Expected Behavior and Validation from observed facts.
+
+## Procedure
+
+Input = the target whose behavior is unknown (legacy code / existing behavior). It does not depend on Example Mapping's output (rather, this technique's observation becomes Example Mapping's input).
+
+1. **Observe the current behavior and pin it down without judging**
+   - Observe the target's current inputs/outputs and side effects, and write them down as characterization test points (tests that pin the current behavior exactly as it is) without judging "whether it is correct".
+   - This is the planning of test points, not actual test code implementation.
+
+2. **Sort the pinned behavior into intentional / accidental and hand it to Example Mapping**
+   - For each pinned behavior, sort which are intentional and which are accidental. The intentional observed facts become the material that the subsequent Example Mapping organizes into "rules / examples".
+   - Send the accidental ones (side effects / dependencies that cannot be separated from intent) to **Open Questions**; do not promote them to intent by guessing.
+
+3. **Make the characterization tests the starting point of Validation**
+   - Use the sorted behavior points as the starting point of each packet's **Validation**, so they can be used for regression detection during refactoring.
+   - How to revert on failure → **Rollback**.
+
+## Assembling the packet
+
+Consolidate the pinned behavior points into packets. Each packet satisfies the following.
+
+- **Parent Intent**: a reference to the corresponding L1/L2/L3 (required). If it stems from an observation, also indicate the original behavior.
+- **Scope / Non-scope**: the behavior included / not included.
+- **Expected Behavior**: derived from the current observed behavior pinned above.
+- **Safety / Invariants**: among the pinned behaviors, the invariants that must not be broken.
+- **Validation / Rollback**: derived from the above.
+- **cc-sdd Mapping**: the policy for how to hand off to cc-sdd.
+
+## Discipline
+
+- **Observation, not judgment**: pin the current behavior as fact exactly as it is, and do not delve into judging correctness or into causes.
+- For anything where you cannot judge whether it is intentional or accidental, do not fill it with guesses; send it to **Open Questions**.
+- This is the structuring of intent (a technique that pins down intent by observing behavior), not actual test code implementation. Do not change code.
+
+## Output
+
+A set of test points that pin the current behavior (with the intentional / accidental sorting). The Expected Behavior / Validation of each point flows into each packet. Update (present as a proposal) the packet files (under `active/`).

package/templates/en/claude/skills/intent-packets/rules/algo-example-mapping.md

@@ -0,0 +1,47 @@
+# Algorithm: Example Mapping
+
+A technique for grounding abstract capabilities into observable concrete examples. Used in the Packet decomposition phase of the `standard` and `behavior-unknown` modes. It expands a capability into "rules, examples, questions, deferred" and derives the packet's Expected Behavior and Validation. In behavior-unknown mode, the observed facts pinned by the preceding Characterization Test become the input for the "examples" (observe first, organize after).
+
+## Procedure
+
+For each L2/L3 capability, expand it as if writing four-color cards.
+
+1. **Rules (the rules the capability follows)**
+   - Bullet the rules/constraints the capability must satisfy.
+
+2. **Examples (observable concrete scenarios)**
+   - For each rule, give concrete examples of "when this happens, behave like this".
+   - These become the packet's **Expected Behavior** (the behavior observable after completion).
+
+3. **Questions (undetermined)**
+   - Anything that cannot be filled in when trying to write an example, or that requires a decision, leave it as a "question".
+   - This becomes the packet's **Open Questions**, or is sent back to the Compass.
+
+4. **Deferred (what you decided not to do this time)**
+   - Anything judged mid-expansion as "this rule/example is excluded from this packet" must not be silently dropped — record it explicitly as **deferred**. It becomes the seed of a follow-up packet, or an Open Question.
+
+5. **Derive Validation and Rollback from the examples**
+   - How to verify each example (tests / manual check / type checking / log check) → **Validation**.
+   - How to revert on failure → **Rollback**.
+
+## Assembling the packet
+
+Consolidate the expansion results into packets. Each packet satisfies the following.
+
+- **Parent Intent**: a reference to the corresponding L0/L1/L2/L3 (required).
+- **Scope / Non-scope**: what is included / what is not.
+- **Expected Behavior**: derived from the "examples" above.
+- **Safety / Invariants**: derived from the Compass invariants.
+- **Validation / Rollback**: derived from the above.
+- **cc-sdd Mapping**: the policy for how to hand off to cc-sdd.
+
+## Discipline
+
+- Packets must be **behavior-preserving / testable / rollbackable**. In greenfield work with no existing behavior to preserve, read behavior-preserving as "can be introduced and removed standalone without affecting anything else".
+- Keep the count variable with the expected change size; do not pad it (one is fine for very small changes; treat 1–7 as a loose guide). For packets that are too large, present split proposals.
+- Do not drop them too far down into implementation tasks (above an Issue, before a spec).
+- Do not change code.
+
+## Output
+
+Update (present as a proposal) the packet files (under `active/`). Each packet has the structure above. Of the four expansion columns (Rules / Examples / Questions / Deferred), the rules and examples flow into each packet's Expected Behavior, the questions go to Open Questions, and the deferred items are kept in the `Deferred` section of `plan.md`.

package/templates/en/claude/skills/intent-packets/rules/algo-migration-slicing.md

@@ -0,0 +1,47 @@
+# Algorithm: Migration Slicing
+
+A technique for decomposing a large change into "migration slices" that preserve behavior and can be shipped individually. Used in the Packet decomposition phase of `refactor` mode. It cuts the gap between the intended design and the current state into behavior-preserving / testable / rollbackable units, deriving a path that advances from the current state one step at a time.
+
+## Procedure
+
+Input = the Intent of the refactor target (the intended design) and the current state, plus the drift list produced by Drift Analysis.
+
+1. **Mikado pre-pass: back-calculate the prerequisites**
+   - For resolving each drift (the goal), recursively back-calculate "what must be true first for this to be changed safely", and write the prerequisite graph (the Mikado Method's Mikado Graph) as an indented bullet list.
+   - The **leaves** — entries with no prerequisites — are the changes you can start with. This is a desk back-calculation at planning time; do not experimentally change code to find out (write the implementation-time Mikado discipline of "revert immediately when an experiment fails, and attack from the leaves" into each slice's Rollback so it flows into the exported implementation hints).
+
+2. **Cut the gap into minimal migration units**
+   - Split the current → intended gap into the smallest units that can be applied without breaking behavior. Raise slices starting from the changes close to the leaves of the prerequisite graph (think of dependency discovery as the graph's job and unit decomposition as the slice's job, separately).
+   - Make each slice individually deployable and have it advance the design one step while preserving the existing behavior.
+
+3. **Order by dependency, into a chain of unblocks**
+   - Order the slices by their dependencies so that each slice unblocks the next.
+   - Confirm that at whichever slice you stop, the state up to that point is consistent (intermediate states are also behavior-preserving).
+   - When multiple slices are startable within the dependency constraints, **put first the one that reduces the most risk / unblocks the most downstream slices**, and attach a one-sentence reason (no numeric scoring — that would be groundless pseudo-quantification).
+
+4. **Attach a verification point and rollback to each slice**
+   - Attach a characterization / regression verification point to each slice so that behavior preservation is observable → **Validation**.
+   - How to revert on failure (each slice must be reversible on its own) → **Rollback**.
+
+## Assembling the packet
+
+Consolidate the ordered migration slices into packets. Each packet satisfies the following.
+
+- **Parent Intent**: a reference to the corresponding L1/L2/L3 (required). If it stems from a drift, also indicate the original drift.
+- **Scope / Non-scope**: the migration this slice includes / does not include.
+- **Expected Behavior**: the existing behavior preserved after the migration.
+- **Safety / Invariants**: invariants that must not be broken during the migration.
+- **Validation / Rollback**: derived from the above.
+- **cc-sdd Mapping**: the policy for how to hand off to cc-sdd.
+
+## Discipline
+
+- Each slice must be **behavior-preserving / testable / rollbackable**.
+- **Drift traceability**: every drift in the input drift list must terminate as one of — a slice (packet), an Open Question, or an explicit deferral with a reason. Never silently drop a drift.
+- Order slices by dependency, and each must be individually deployable.
+- Keep the count variable with the expected change size; do not pad it (one is fine for very small changes; treat 1–7 as a loose guide). For slices that are too large, present split proposals.
+- This is the structuring of intent (a packet-decomposition technique), not migration execution code. Do not change code.
+
+## Output
+
+An ordered set of migration slices. Each slice has the structure above, and its Scope / Validation / Rollback flow into each packet. Update (present as a proposal) the packet files (under `active/`).

package/templates/en/claude/skills/intent-packets/rules/decision-slots.md

@@ -0,0 +1,88 @@
+# Decision Slots Catalog (completeness schema)
+
+The **single canonical source of the completeness schema** that lists easy-to-miss topics as a "table of contents". Instead of leaving coverage to free-form requirement prose, it structurally bounds the kinds of omissions. `intent-discover` (posture check), `intent-packets` (slot seeding), and `intent-validate` (satisfaction check) all read this catalog as the single reference.
+
+This catalog is a "sample (a table of contents of easy-to-miss topics)", not a fixed net. Filling gaps for a project type is delegated to discover's posture check and the mode-specific deltas.
+
+## Value range and status
+
+Each slot takes one of the value range `decided value | undecided (with reason) | not applicable`, and **must be closed** with one of the following 4 statuses (structurally preventing "silently skipping").
+
+| Status | Meaning | What to record alongside |
+|--------|---------|--------------------------|
+| Answered | A decided value exists | The decided value (in the packet's `## Decisions` or the closing section) |
+| Undecided | Not yet decided (deferred) | Reason, a downstream caveat, and a revisit condition (Revisit when) |
+| Not applicable | This slot does not apply to this packet | The rationale for non-applicability (do not silently drop it) |
+| Send to ADR candidate | An architecture-significant decision | Send it to the compass's Decision Rules (the target of up-front fixing) |
+
+- `Answered` corresponds to the value range `decided value`, `Undecided` to `undecided (with reason)`, and `Not applicable` to `not applicable`. `Send to ADR candidate` is a declaration until the value is decided on the compass side.
+- For a slot whose "closes in" is an existing section (`## Validation` / `## Expected Behavior`, etc.), you may declare in `## Decisions` that it "is closed in the existing section" rather than duplicating the value (do not define it twice).
+
+## Common core slots (seeded in all modes)
+
+8 slots seeded into every packet. The first 4 (centered on ④) stem from "decision-making under constraints"; the latter 4 fill gaps that existing artifacts did not cover.
+
+| ID | Slot name | What to confirm | Completion condition | Closes in | Up-front/deferred door | Rationale |
+|----|-----------|-----------------|----------------------|-----------|------------------------|-----------|
+| `decision-consistency` | Consistency model | On data change, strong (immediate) or eventual consistency | Which consistency model is declared and downstream can rely on it | packet `## Decisions` (new) | Up-front (one-way: costly external impact if overturned later) | Irreversible, binds multiple packets. ISO/IEC/IEEE 42010 decision/rationale |
+| `decision-idempotency` | Idempotency & retry | Preventing inconsistency on write retry (idempotency keys, etc.) | The behavior on retry is declared | packet `## Decisions` (new) | Deferrable (two-way: discretionary if localizable and reversible) | Affects the acceptance oracle; a retry-premised quality attribute |
+| `decision-error-semantics` | Error semantics & boundary validation | Boundary validation and error return when input is empty/unexpected (Fail-Fast, etc.) | The return contract on abnormal input is declared | packet `## Decisions` (new) | Deferrable (two-way) | Affects the acceptance oracle and external contracts |
+| `decision-authz` | Authorization | Which actors may act, and row-level permission to accessible data | Who can access what is declared | packet `## Decisions` (new) | Up-front (one-way: security/regulatory floor) | Irreversible, security floor. A high-cost decision |
+| `decision-quality-priority` | Quality-goal prioritization | Among performance/reliability/maintainability/security, the load-bearing top 2-3 attributes | The top attributes are declared with a ranking | packet `## Decisions` (new; may link with compass Invariants) | Deferrable (two-way) | A quality trade-off point. ISO/IEC 25010 quality vocabulary |
+| `decision-fit-criterion` | Numeric/fit criterion | How acceptance is measured (fit criterion / SLO / test oracle) | The numeric/observable acceptance condition is declared | Reference packet `## Validation` (existing). If undecided, declare in `## Decisions` | Deferrable (two-way) | Affects the acceptance oracle. Volere's fit criterion |
+| `decision-exception-flow` | Exception flow | Whether representative abnormal-path flows are defined, not only the happy path | Representative abnormal-path flows are declared | Reference packet `## Expected Behavior` (existing). If missing, declare in `## Decisions` | Deferrable (two-way) | Fills the happy-path-bias gap (PBR test/operations viewpoints) |
+| `decision-downstream-trace` | Downstream trace | Links to the work/tests that realize/verify this packet (realized-by / verified-by) | Downstream links are declared (or judged minimally-sufficient and left empty) | packet `## Verification protocol` / trace links (new, optional) | Deferrable (two-way) | Bidirectional trace (fills the pre-RS gap) |
+
+- Because `decision-fit-criterion` / `decision-exception-flow` close in existing sections, if they are closed in the existing section, place only a reference in `## Decisions` stating it "is closed in the existing section" (do not define it twice).
+- The common core is seeded in all modes. `intent-validate`'s `decision-slot-unsown` check detects "none of these 8 IDs is seeded in `## Decisions`" (common core unsown).
+
+## Mode-specific delta slots (added per mode)
+
+Delta slots **added** to the common core according to the mode in `.intent/mode.md`. The slot definitions are canonical in this table and are not hardcoded into the skill body (riding on the Mode/Algorithm/Skill three-layer separation).
+
+### standard
+
+| ID | Slot name | What to confirm | Completion condition | Closes in | Up-front/deferred door |
+|----|-----------|-----------------|----------------------|-----------|------------------------|
+| `decision-perf-budget` | Performance budget | The allowable envelope for latency/throughput/resources | The performance envelope is declared | packet `## Decisions` | Deferrable (two-way) |
+| `decision-data-ownership` | Data ownership | Where this data's source of truth is and who may modify it | The data's source of truth and the modifying party are declared | packet `## Decisions` | Up-front (one-way: large external impact if overturned later) |
+
+### refactor
+
+| ID | Slot name | What to confirm | Completion condition | Closes in | Up-front/deferred door |
+|----|-----------|-----------------|----------------------|-----------|------------------------|
+| `decision-characterization` | Behavior to preserve / characterization tests | Test points that pin the current observable behavior exactly as it is | The observed behavior is pinned | Reference the existing `algo-characterization-test.md` (do not define it twice) | Up-front (one-way: pin the safety net first) |
+| `decision-change-boundary` | Change boundary | How far it is OK to change, and what must not be touched | The changeable range and the untouchable range are declared | packet `## Decisions` | Up-front (one-way) |
+| `decision-rollout-safety` | Rollout safety | How to revert and what to observe when rolling out the change in stages | The rollout strategy and how to revert are declared | packet `## Decisions` / reference `## Rollback` (existing) | Deferrable (two-way) |
+
+### behavior-unknown
+
+| ID | Slot name | What to confirm | Completion condition | Closes in | Up-front/deferred door |
+|----|-----------|-----------------|----------------------|-----------|------------------------|
+| `decision-observed-facts` | Observed facts and their source | What was observed and where its source is | The observed facts and their source are declared | packet `## Decisions` / reference `## Expected Behavior` (existing) | Up-front (one-way: pin the facts first) |
+| `decision-hypothesis-confidence` | Distinguishing hypothesis from confidence | Which are facts and which are hypotheses, and to what degree of confidence | Facts/hypotheses and confidence are distinguished | packet `## Decisions` | Deferrable (two-way) |
+| `decision-current-vs-future` | Separating current behavior from future intent | Whether "it behaves like this now" and "we want it to behave like this" are conflated | Current behavior and future intent are declared separately | packet `## Decisions` | Deferrable (two-way) |
+
+### feature-growth
+
+| ID | Slot name | What to confirm | Completion condition | Closes in | Up-front/deferred door |
+|----|-----------|-----------------|----------------------|-----------|------------------------|
+| `decision-existing-boundary` | Consistency with existing boundaries | Whether it is consistent with existing module boundaries/contracts | The policy for consistency with existing boundaries is declared | packet `## Decisions` | Up-front (one-way) |
+| `decision-backward-compat` | Backward compatibility | Whether it breaks existing users / existing data | The backward-compatibility policy is declared | packet `## Decisions` | Up-front (one-way: a high-cost decision) |
+| `decision-data-migration` | Data migration | How to migrate existing data and consistency during migration | The migration strategy is declared | packet `## Decisions` | Up-front (one-way: irreversible) |
+| `decision-staged-rollout` | Staged rollout | How to run old and new in parallel and how to switch over | The staged-rollout strategy is declared | packet `## Decisions` | Deferrable (two-way) |
+| `decision-legacy-impact` | Impact on legacy features | The side effects this extension has on existing features | The impact on legacy features is declared | packet `## Decisions` | Deferrable (two-way) |
+
+## Three disciplines
+
+A skill applying this catalog observes the following three disciplines.
+
+1. **Do not offer defaults (anchoring avoidance)**: do not present a "reasonable default" or "recommended value" for a slot. This avoids the anchoring bias where judgment is dragged toward the first value presented. Symmetric side-by-side presentation of multiple options is reserved as a future extension candidate.
+2. **The tool does not infer applicability or values**: do not infer or auto-fill whether a slot applies, or which value it takes, from the artifact contents. People declare them (the same declaration-based discipline as not inferring `depends_on`). `intent-validate` only checks the slots/statuses actually declared.
+3. **Do not fix the ceiling (How)**: a slot declares "what to decide (what + constraints + oracle)" and does not make the packet carry the implementation How. The local search inside the rules is delegated to the agent's discretion zone.
+
+## How to extend
+
+- **Extension completes by just adding a row to the table** (no structural change to other files needed — the "table is canonical" pattern). To grow the common core, add a row to the common-core table; to grow a mode delta, add a row to that mode's table.
+- **For a slot covered by an existing artifact, reference the "closes in" and do not create a new container**. Intent/scope/stakeholders/constraints/acceptance evidence, etc. are covered by the existing tree / compass / packet existing sections, so do not recreate them in `## Decisions`; reference their closing section.
+- For a slot with the same subject as an existing rule (e.g. `decision-characterization`), keep it as a reference to the existing file (`algo-characterization-test.md`) and do not duplicate the definition.

package/templates/en/claude/skills/intent-packets/rules/export-route.md

@@ -0,0 +1,54 @@
+# Export Route (exit decision lane)
+
+A **read-only decision convention** that, after the planning phase (discover→compass→packets), chooses which exit to take based on the case type. There are three exits:
+
+- **cc-sdd implementation export** → `/intent-export-cc-sdd`
+- **OpenSpec implementation export** → `/intent-export-openspec`
+- **readable Spec projection** → `/intent-to-spec`
+
+This convention is the **single source of truth in intent-packets**; the exit suggestion in `/intent-packets` and the preflight in the export skills reference this rule (the rule body is not copied into other skills). The decision is semantic and is not pushed onto a mechanical check script such as `intent-check.mjs` (INV2).
+
+## Inputs (all read-only observation)
+
+The decision takes three inputs. Each is observed with Read / Glob and never creates, modifies, or deletes a file (read-only, INV5):
+
+1. **target format**: the value of the `format` line in `.intent/mode.local.md` (or the legacy `.intent/mode.md`), with range `cc-sdd` / `openspec` / `to-spec`.
+2. **mode**: the `mode` value in the same file (`non-code` / `standard`-family).
+3. **prerequisite**: whether the `.kiro/` directory exists (a hint for whether cc-sdd is set up).
+
+## Decision (first-match, deterministic)
+
+The same inputs always yield the same result (deterministic). Evaluate top-down and take the first matching row.
+
+### A. When format is explicitly set to a valid value (highest priority)
+
+| `format` | recommended exit |
+|----------|------------------|
+| `openspec` | `/intent-export-openspec` (**for an OpenSpec case, promote OpenSpec**) |
+| `cc-sdd` | `/intent-export-cc-sdd` |
+| `to-spec` | `/intent-to-spec` |
+
+When set, deterministically recommend that exit.
+
+### B. When format is unspecified (infer from mode + prerequisite)
+
+When `format` is "unspecified" (any of: (1) the line is absent, (2) a placeholder value `(undetermined — …)`, (3) a value outside the range — per the read contract in mode.local.md), infer and **present candidates** from mode and the presence of `.kiro/`. Cover all four quadrants as follows:
+
+| mode | `.kiro/` | result |
+|------|----------|--------|
+| non-code | absent | `/intent-to-spec` as the top candidate (a readable artifact is the goal, DR15) |
+| standard-family | present | `/intent-export-cc-sdd` as the top candidate (implementation case, cc-sdd already set up) |
+| non-code | present | **list candidates** (`/intent-to-spec` on top, but also list `/intent-export-cc-sdd`; a non-code case can still have cc-sdd set up, so do not collapse to one) |
+| standard-family | absent | **list candidates** (`/intent-export-cc-sdd` [needs setup], `/intent-to-spec`, `/intent-export-openspec`; not uniquely determined) |
+
+### C. Fallback
+
+Including any case not above: when format is unspecified and the exit cannot be uniquely determined from the inputs, **do not collapse to a single exit — list candidates** (present rather than assert; the exit depends on the user's intent).
+
+## Discipline
+
+- **Do not hardcode a single exit**: the problem is "collapsing to one exit without looking at the case type." Do not swap in another fixed destination (a to-spec-only or openspec-only path). When ambiguous, present candidates.
+- **read-only**: the decision only observes; it does not mutate state (INV5).
+- **Do not push onto a mechanical check**: keep the semantic decision in this rule plus context; do not move it into a script such as `intent-check.mjs` (INV2).
+- **Do not depend on asking the user back**: settle the exit suggestion via this rule's convention and defaults; do not assume interactive follow-up.
+- **Do not touch external tools**: reading whether `.kiro/` exists is observation, not a change to kiro / cc-sdd / OpenSpec (INV1).

package/templates/en/claude/skills/intent-packets/rules/first-packet.md

@@ -0,0 +1,35 @@
+# First Packet Recommendation
+
+The procedure for recommending and recording exactly one packet to start with, together with qualitative reasons. Always used at the priority presentation (Step 4) of `/intent-packets`.
+
+## Applicability
+
+- **Always apply.** Does not depend on designer-questions in `.intent/mode.md` (apply even when it is off or unrecorded).
+- In SKILL.md Step 4, apply this procedure **after** applying walking-skeleton (apply this procedure even when walking-skeleton was not applied).
+
+## Procedure
+
+1. **Read the materials**
+   - Read the packet candidates and their priorities, the "Walking Skeleton" section of `.intent/packets/plan.md` (if recorded), and the purpose in `.intent/mode.md`.
+
+2. **Choose exactly one packet to start with**
+   - For the reasons, cite the applicable ones among the following qualitative criteria: **risk reduction** / **unblocking dependencies** / **ease of rollback** / **size of learning**.
+   - When purpose=poc is recorded, always include the criterion "whether it can refute the hypothesis most cheaply" in the reasons (when purpose is unrecorded or product, do not reference purpose).
+
+2.5. **Confirm the priorities and acceptable trade-offs with the user**
+   - Before finalizing the recommendation, confirm the priorities and acceptable trade-offs with the user: **which to prioritize, speed vs. quality**, and **which scope may be cut or deferred for this starting point**.
+   - This is a confirmation, not a prompt to override the recommendation. The recommendation is a proposal; when the user's priority judgment obtained here conflicts with the recommendation, prefer the user's judgment and revise the recommendation and its reasons.
+   - Ask in a form where "not applicable / unknown / decide later" can be chosen, and do not force an answer. When a hold or "decide later" is chosen, do not fill it in by guessing; route the item to the "Open Questions" section of `.intent/packets/plan.md` (appending it while preserving the existing content if the section is absent) and continue the recommendation.
+
+3. **Align with the Walking Skeleton**
+   - If the decision on the walking skeleton (the minimal implementation that cuts end to end) is recorded, align the recommendation with it. When making a recommendation that does not align, state the reason explicitly.
+
+4. **Record the recommendation**
+   - Record in the "Recommended First Packet" section of `.intent/packets/plan.md`: **Recommended packet** (packet name) / **Reasons** (qualitative criteria) / **Alignment with Walking Skeleton** (aligned / if not aligned, the reason / Walking Skeleton not recorded).
+   - **Non-destructive append for older scaffolds**: if `plan.md` lacks a "Recommended First Packet" section, append the section while preserving the existing recorded content, then record.
+
+## Discipline
+
+- Do not use numeric scoring (weighted sums, point ratings).
+- The recommendation is a proposal; it does not override the user's own priority judgment.
+- Do not change code.