intent-planner 0.13.1

package/templates/en/claude/skills/intent-discover/rules/designer-questions.md

@@ -0,0 +1,78 @@
+# Designer Questions
+
+The procedure for confirming and recording whether to delegate the designer-role questions (designer-questions), and for the additional questions asked when it is on. Used in `/intent-discover` after the mode is confirmed (Step 1) and when presenting the Tree update proposal (Step 4). All dialogue is done as confirmation with the user (the means of confirmation follows the conventions in SKILL.md).
+
+## Procedure
+
+### After the mode is confirmed (Step 1)
+
+1. **Confirm whether to delegate the designer-role questions**
+   - Read `designer-questions` in `.intent/mode.md`. The canonical values are the two tokens `on` / `off`.
+   - If undetermined, first explain what the designer-role questions confirm (list these 4 points: making the L1 (outcomes) success criteria measurable / confirming whether the first packet (unit of work) is a walking skeleton (a minimal implementation that runs end to end from input to output) / the existence of a screen rough when there are user-facing screens / the hypothesis and completion judgment in the case of validation (PoC)), then, without recommending, present the two choices (`on` = wanted / `off` = not wanted) and confirm with the user.
+   - If already recorded, present the recorded content (designer-questions / purpose) and confirm only whether it should change.
+   - If the user defers the decision, do not fill it in by guessing; record "whether to delegate the designer-role questions is undetermined" in Open Questions and continue.
+
+2. **Record the confirmed designer-questions**
+   - Write the confirmed token to the `designer-questions` line in `.intent/mode.md`. Downstream skills (intent-packets / intent-validate) refer to this line.
+   - **Non-destructive append for older scaffolds**: if mode.md has no designer-questions / purpose line, append the missing lines while keeping the existing mode / selected / reason / definition lines. If intent-tree.md has no "PoC Experiment Definition" / "Screen Rough Reference" section, append them while keeping the existing sections, then record.
+
+2.5. **Affirm the purpose, success, and intended users (fires regardless of the designer-questions value)**
+   - Affirm with the user the L0 purpose and the definition of success derived by inference: present the inferred content placed in L0 (Product Purpose) and L1 (Desired Outcomes) of `.intent/intent-tree.md`, and confirm "whether this reading of the purpose and success is correct".
+   - Affirm with the user the inferred intended users and usage context (Actor): present "who, in what situation, is assumed to use this", and confirm whether it is correct.
+   - Present each confirmation in a form that lets the user choose "not applicable / unknown / check later", and do not force an answer. This is an affirmation grounded in the infer + confirm philosophy, and does **not** expand into a full active questioning of the functional requirements (rather than eliciting L2–L4 one by one, it only checks that the reading of the root purpose, success, and intended users is not mistaken).
+   - Content the user affirms is fixed as canonical directly under that L0/L1. The intended users are recorded as the L1 Actor directly under L1. If the user corrects it, replace the canonical with the corrected content.
+   - For items the user defers or chooses "check later", do not fill them in by guessing; route them to Open Questions of `.intent/intent-tree.md` (with the `[by export]` tag if an answer is required by export) or to Assumptions (when placed as a tentative premise) and continue. Do not stop planning.
+
+2.6. **Judge the solution convergence and do the aim-the-solution confirmation (fires regardless of the designer-questions value)**
+   - Immediately after step 2.5, read the user's request (the idea and target scope) and the Intent Tree being built, and judge the **solution convergence** of the target architecture the request aims at. The judgment is done by LLM reading and does not depend on external analysis tools or mechanical scoring.
+   - Handle it with three branches — convergent / divergent / undecidable:
+     - **Convergent** (the request implies a specific architecture almost uniquely; it matches an established pattern) → proceed to the aim-the-solution single-question confirmation below.
+     - **Divergent** (multiple valid solutions hold) → do not aim the solution first; proceed via the conventional route (apply the anchoring avoidance of step 7, the Impact Analysis stocktake and neutral option presentation).
+     - **Undecidable** → do not finalize by guessing; **treat it as divergent**, and record that it cannot be judged in Open Questions of `.intent/intent-tree.md` and continue.
+   - Keep the examples of established patterns to a few and do not enumerate them exhaustively (e.g. cron-ization, CLI-ization, one-shot-ization, etc.; avoiding fixation — examples are cues, not the space of solutions).
+   - **Aim-the-solution single-question confirmation when convergent**:
+     - **Before** the Impact Analysis stocktake and neutral option presentation, confirm the inferred architecture in **a single question** — "the architecture you are aiming for is this, right?" (do not break it into neutral multiple options).
+     - Present the confirmation in a form that lets the user choose "not applicable / unknown / check later", and do not force an answer.
+     - Handle the result with the same recording discipline as step 2.5: **affirmed** → record the inferred target architecture as canonical in `.intent/intent-tree.md` (record it directly under the relevant L3 (architectural intent), or as an architecture policy directly under L1/L2, using an existing section; do not add a new section). **corrected** → replace the canonical with the corrected architecture. **deferred / check later** → do not finalize by guessing; route it to Open Questions (with the `[by export]` tag if an answer is required by export) and continue (do not stop planning).
+     - Aiming the solution goes only as far as **confirming and recording** the architecture; do not implement or generate code.
+
+3. **Confirm the validation nature (only when designer-questions=on)**
+   - Confirm with the user whether this development is "validation that verifies something (PoC = `poc`)" or "production / continuous development (= `product`)", and record it on the `purpose` line in `.intent/mode.md`.
+   - Do this confirmation not only immediately after on is confirmed, but also on a re-run when designer-questions is already recorded as on and purpose is undetermined.
+   - If the user defers the decision, do not fill it in by guessing; record "purpose undetermined" in Open Questions and continue.
+
+4. **The 3 PoC questions (hypothesis / falsification criteria / GO-NO-GO; only immediately after purpose=poc is confirmed)**
+   - Ask the user in this order: Hypothesis (what this PoC is meant to verify) → Falsification Criteria (what, if it cannot be observed, rejects the hypothesis) → GO-NO-GO Criteria (the conditions for deciding whether to proceed or stop after the PoC completes).
+   - Record the answers as canonical in "PoC Experiment Definition" of `.intent/intent-tree.md`. For items the user cannot answer, do not fill them in by guessing; record them in Open Questions and continue.
+   - **When purpose is not poc, do not fire these questions.**
+
+### When presenting the Tree update proposal (Step 4, designer-questions=on only)
+
+5. **Confirm L1 measurement criteria**
+   - For each L1 item, confirm with the user "how achievement is observed and judged", and record it as a `Measurement criteria:` line on that L1 item.
+   - For items where the criteria cannot be settled, keep the L1 item itself and record "criteria undecided" in Open Questions.
+
+6. **Confirm whether a screen rough exists**
+   - First, judge whether L2/L3 includes user-facing screens.
+   - If it does, confirm the existence of a screen rough with the user: exists → record the reference (file path or link) in "Screen Rough Reference". Does not exist → recommend creating one. If the user defers, record that decision with the reason in Open Questions or "Screen Rough Reference" and continue.
+   - If it does not, do not confirm with the user; **always** record "Not applicable" in "Screen Rough Reference" (so that intent-validate can judge without inference).
+   - Do not create or generate the rough itself (only confirm existence, recommend, and record the reference).
+
+6.5. **Confirm omissions and excess with the tree-level omission recap**
+   - Before finalizing the Tree update proposal, return a short summary of the inferred and collected L0–L3 (purpose, success, intended users, and the main outcome and feature branches), and confirm with the user "whether anything is missing or, conversely, whether any premise is excessive" (presented as material for a human to correct the LLM's oversights and hallucinations). This is an omission recap applied to the functional requirements as well, not an eliciting of L2–L4 one by one.
+   - If the user points out a **missing** item, reflect it into the relevant section of `.intent/intent-tree.md` and re-present: a missing purpose / success → directly under L0 (Product Purpose) / L1 (Desired Outcomes); a missing intended user → directly under L1 as the L1 Actor; a missing outcome / feature branch → the branch directly under the relevant L1.
+   - If the user points out something **excessive**, after confirming, remove that item from the canonical (the relevant section of intent-tree.md). If unsure, do not remove it but demote it to Assumptions of `.intent/intent-tree.md` (keep it as a tentative premise). Always confirm with the user before removing.
+   - Present each confirmation in a form that lets the user choose "not applicable / unknown / check later", and do not force an answer. For points the user defers or chooses "check later", do not fill them in by guessing; route them to Open Questions of `.intent/intent-tree.md` (with the `[by export]` tag if an answer is required by export) and continue.
+   - Keep the re-editing to at most one round trip (do not converse endlessly in the recap). Route any remaining points to Open Questions of `.intent/intent-tree.md`.
+
+7. **Confirm the posture for decisions-under-constraints (④)**
+   - Among the L2/L3 capabilities, briefly summarize those that involve mutating data, external input / system boundaries, or access control, and confirm **all at once, just once**: "in this set of features, which places should we decide on — consistency, idempotency, behavior on error, who may access". (Do not turn each ④ item into an active question one by one; do this as the same "confirm nothing is missing" as the omission recap.)
+   - This is not a step that fills in the decisions here and now; it is a step that **captures the posture of which capabilities should have decision slots (④) sown**. **Only for design decisions whose solution is divergent**, do not present a reasonable default value (avoiding anchoring bias). Conversely, for an architecture request judged **convergent** in step 2.6, do not apply anchoring avoidance — aim the inferred solution first (see the aim-the-solution step in 2.6). The list and firing conditions of the slots are owned by `intent-packets/rules/decision-slots.md` (its anchoring-avoidance discipline is unchanged regardless of this step's scoping).
+   - For what the user points to as "this should be decided", record it directly under the relevant L3 in `.intent/intent-tree.md` as "a point requiring a decision (④)" (do not write concrete values yet; the actual slot sowing and value finalization are done by intent-packets per packet).
+   - **Prompt consider-the-opposite only for high-cost decisions**: only when the user has chosen a stance on a high-cost decision (authorization, consistency, error semantics, backward compatibility), prompt them to name at least one condition under which that stance could become inappropriate (a threat, edge case, or out-of-scope situation) (mitigating confirmation bias). Record the named conditions alongside that "point requiring a decision (④)" in `.intent/intent-tree.md`.
+   - Impose this falsification prompt only on high-cost decisions. Do not impose friction on every slot and weigh the dialogue down (avoiding decision fatigue).
+   - Present each confirmation in a form that lets the user choose "not applicable / unknown / check later", and do not force an answer. Do not fill in deferrals by guessing; route them to Open Questions and continue.
+
+## When designer-questions is off
+
+When off, the only things that fire are the opt-in confirmation in steps 1-2, step 2.5 (affirming the purpose, success, and intended users), and step 2.6 (judging the solution convergence and the aim-the-solution confirmation). Steps 3-7 (validation-nature confirmation, the 3 hypothesis questions, L1 measurement criteria, screen rough, the ④ posture) and step 6.5 (the tree-level recap) do not fire. The L0 purpose, success, and intended users, and the form of the solution (target architecture), differ in nature from the PoC-only information (steps 3-6) and are needed as the root of intent even in product development, so they are included in the minimal off configuration (the effect of preventing detours on requests with an obvious solution holds even when off). Even if a purpose value remains, it is not consulted unless designer-questions is recorded as on.

package/templates/en/claude/skills/intent-discover/rules/drift-terrain.md

@@ -0,0 +1,105 @@
+# Drift Terrain
+
+The symptom × in-progress Intent Tree matching logic used at Step 3.5 of `/intent-discover`. Runs only when `drift-watch: on` (off / missing / invalid does nothing). The goal is to name, before work starts, "this subject is easy-to-drift terrain," and to make the anti-direction / invariant get written first, before you drift all the way out.
+
+## The only basis for diagnosis is the type catalog
+
+- **The only basis for diagnosis is the type catalog in `.intent/drift-patterns.md`.** At the discover stage there is no compass and no packet yet, so the type catalog is the only material to match against (an essential constraint). Matching based on the compass's Invariant / Anti-direction is the job of the export stage (a different drift-watch hook) and is not done here.
+- Terrain diagnosis **assumes false positives**. "Matching" a type is not a confirmation of drift. Name it early on a weak cue, and record swings-and-misses too.
+
+## Procedure
+
+1. **Read drift-patterns.md**
+   - Read `.intent/drift-patterns.md` and take all types (the seeds plus every type the user has grown).
+   - **When absent**: skip terrain diagnosis and notify the user accordingly (do not stop / do not write to drift-log). Do not run the remaining steps.
+
+2. **Match each type's symptom against the in-progress Intent Tree**
+   - Hold each type's `symptom` against the **subject (topic) and L0–L3** (purpose / outcome / capability / behavior & design intent) of the Intent Tree you are currently building.
+   - `symptom` is a **weak cue**, not a strong decision condition meaning "if it matches it is definitely drift." Assume false positives; pick it up if it looks suspicious.
+
+3. **When a type matches**
+   - **Name it explicitly** to the user. Example: "This subject is terrain where you can easily hit `<id>`."
+   - Write that type's "Things to write first" (Anti-direction / Invariant candidates) into the Intent Tree's **Open Questions / anti-direction candidates**. Concretize the subject-dependent parts from context (do not paste the catalog's generic wording verbatim; phrase it for the current subject).
+   - Append one entry to `drift-log.md` (see the append procedure below). The values are:
+     - `pattern: <the matched type's id>`
+     - `stage: discover`
+     - `packet: -` (no packet is fixed yet at the discover stage)
+     - `mechanism: pattern-catalog`
+     - `outcome: prevented` (**a draft**: this is drift-watch's estimate; the verdict is the user's `user-verdict`)
+     - `user-verdict: unjudged`
+     - `recorded_at: <ISO 8601>`
+     - `commit: <short hash | ->`
+     - `note: <1-2 lines>` (what you named and what you had written first)
+   - If multiple types match, append one entry per type.
+
+4. **When no type matches (a swing and a miss / not-applicable)**
+   - **Always record the swing-and-miss too.** So that `missed=0` is not misread as "evidence it worked," record the moments when nothing matched just as evenly (structural avoidance of confirmation bias).
+   - Append one entry to `drift-log.md`. The values are:
+     - `pattern: -` (no type matched; `uncatalogued:<short name>` is the value for an actual drift outside the catalog, so do not use it for a swing-and-miss — use `-`)
+     - `stage: discover`
+     - `packet: -`
+     - `mechanism: none`
+     - `outcome: not-applicable`
+     - `user-verdict: unjudged`
+     - `recorded_at: <ISO 8601>`
+     - `commit: <short hash | ->`
+     - `note: <1-2 lines>` (that no type was present in the terrain)
+
+## The append procedure for drift-log
+
+- **Write in split form (CONTRACT "Split and archive convention for append-only records")**: drift-log is event-origin, so instead of appending to the end of a single `drift-log.md`, write one entry to a **per-date+slug split file** `drift-log/<date>-<slug>.md`. `<date>` is the recorded_at date; `<slug>` is derived from the pattern (the event) via the existing slug rule (`intent-packets/rules/packet-format.md`) — do not create new/sequential numbering. Because a different event touches a different file, tail collisions disappear by construction. Never rewrite or delete an existing entry (**append-only**).
+- **Always write all 9 keys in the fixed order**: `pattern` → `stage` → `packet` → `mechanism` → `outcome` → `user-verdict` → `recorded_at` → `commit` → `note`. Do not write an entry that is missing even one of the 9 keys.
+- **recorded_at**: write the time of recording in ISO 8601 (transaction time).
+- **commit**: write the result of `git rev-parse --short HEAD`. When it cannot be obtained (non-repository, git CLI absent, etc.), use `-` (fail-open: keep recording).
+- **When the `drift-log/` directory is absent**: create the directory, then write the split file. An old single `drift-log.md`, if still present, can be read side-by-side by readers (migration is handled by this slice's migration step).
+- Follow the sample in the "Entry format" section of `.intent/drift-log.md` (`### drift-log entry`) for the entry format.
+
+## Context cost cues (tied to drift-watch)
+
+Alongside terrain diagnosis, run a matching that makes you **notice** a way of progressing that eats context (tokens). This is a **separate catalog** from drift-patterns (types of intent drift); only the symptom differs — it is "a situation that eats context" rather than "intent drift". This is awareness, not a norm, and because it differs in nature from the drift-patterns matching above, it is **kept as a separate procedure**.
+
+- **Only when `drift-watch: on`** do this matching (do nothing when off / unset / invalid). When `.intent/context-cost-cues.md` is absent, skip the matching and announce that (do not stop).
+- **This is not recorded to any log.** Unlike the drift-patterns matching above (which appends to `drift-log.md` on both a match and a miss), context cost cues are **not appended to `drift-log.md` or to any other log**. Reason: consumption cannot be measured and its outcome cannot be evaluated, so mixing it into the log would pollute the drift-log tally with guesses; furthermore, what eats context legitimately differs per person, so recording it would intrude on privacy. **Do not apply the "append procedure for drift-log" above to this matching.**
+
+### Procedure
+
+1. **Read context-cost-cues.md**
+   - Read `.intent/context-cost-cues.md` and obtain all types (seed + every type the user has grown). If absent, skip and announce (do not stop).
+
+2. **Match each type's symptom against the Intent Tree under construction**
+   - Check each type's `symptom` against the subject / way of progressing (topic and L0–L3) of the Intent Tree you are currently building. The `symptom` is a weak cue; if the fit is weak, stay silent (lean toward staying silent over false positives — to keep the awareness feature trustworthy).
+   - Use only the subject of the Intent Tree under construction for matching. Do not read token consumption, git diffs, or runtime metrics.
+
+3. **When a type matches (present the cue; do not write to any log)**
+   - Name it to the user in a noticing tone. Example: "This subject may match `<id>` — this might be eating context."
+   - Add the type's "if this is unintentional" light alternative (thin entry point / JIT pull / limited input) as an **optional choice**. Example: "If this is unintentional, there is also <light alternative> (the judgment is yours)."
+   - **Do not correct or instruct.** Phrase it as a cue rather than an imperative or a verdict. Installing many skills or loading full content can be a legitimate high-cost choice, so do not dismiss a context-eating choice as unnecessary. Leave the judgment to the user.
+   - **Do not append to any log** (do not reuse the drift-patterns append procedure).
+
+4. **When no type matches**
+   - Name nothing. **Write nothing to any log** (do not record a miss either — this matching has no log at all).
+
+## Constraint starter awareness (linked to drift-watch)
+
+Alongside terrain diagnosis, perform a light match to give **early awareness** of domain-convention starters. This is the discover-side supplement to constraint-starter surfacing whose primary touchpoint is the compass (`intent-compass/rules/constraint-surfacing.md`); it reads a different catalog from the above (`.intent/constraint-starters.md` = reusable constraint conventions). Its symptom differs from intent-drift and context-cost, so **keep its procedure separate**.
+
+- **Only when `drift-watch: on`** perform this match (do nothing when off / unset / invalid). When `.intent/constraint-starters.md` is absent, skip the matching and say so (do not stop).
+- **Record this to no log.** Unlike the drift-patterns match above (which appends to `drift-log.md`), constraint-starter awareness appends to **neither `drift-log.md` nor any other log** (same treatment as context-cost-cues awareness).
+- **This is surfacing, not auto-transcription.** It only gives awareness of candidates; it does not auto-write into Anti-direction / Invariants. Adoption and wording are done by a human in the compass (the primary touchpoint).
+
+### Procedure
+
+1. **Read constraint-starters.md**
+   - Read `.intent/constraint-starters.md` (bundled conventions) and, if present, `.intent/constraint-library.md` (constraints the user grew) read-only, and obtain all conventions (per `## id:`). If both are absent, skip and say so (do not stop).
+
+2. **Match each convention's "fits when" against the Intent Tree under construction**
+   - Match each convention's `fits when` against the material/domain of the Intent Tree you are building. `fits when` is a weak cue; if the fit is weak, stay silent (lean toward silence over false positives).
+   - Use only the material of the Intent Tree under construction for matching. Do not read code diffs or runtime metrics.
+
+3. **When a convention matches (surface awareness; write to no log)**
+   - Name it to the user in an awareness tone. Example: "This material may match `<id>` (<name>) — you can consider it as a starter in the compass." Do not push; narrow the candidates.
+   - The detailed starter (Anti-direction candidate / Invariant candidate) and the adoption decision are **left to the compass (the primary touchpoint)**. In discover, only give early awareness that "this convention may help."
+   - **Append to no log.**
+
+4. **When no convention matches**
+   - Name nothing. **Write nothing to any log** (this matching has no log).

package/templates/en/claude/skills/intent-discover/rules/mode-selection.md

@@ -0,0 +1,31 @@
+# Mode Selection
+
+The logic for recommending the mode for working out the Intent based on the repository situation. Used at the start of `/intent-discover`. This is also an extension point (when you add a new mode, add its recommendation conditions here).
+
+## Procedure
+
+1. **Enumerate available modes**
+   - Glob for `.intent/modes/*.md`. Read each mode's "Applicable situations" section.
+
+2. **Lightly observe the repository situation**
+   - Presence/scale of existing code, presence of tests, richness of README/docs, presence of existing `.intent/` deliverables.
+   - Do not read deeply. Only the clues needed for a recommendation.
+
+3. **Recommend a mode**
+   - The bundled modes at present are the four: `standard` / `refactor` / `behavior-unknown` / `feature-growth`. Recommend based on the repository situation using these conditions:
+     - New / intent not yet articulated → `standard` (default)
+     - Large existing codebase / refactor target (large existing code, design drift) → `refactor` (intent-less / vibe-coded existing code also routes to refactor, with Intent Recovery in discover)
+     - Legacy with unknown behavior (no/few tests, lost specification) → `behavior-unknown`
+     - A **feature addition** to an existing system (extend / integrate / add-to style requests, behavior known, redesign is not the goal) → `feature-growth` (distinguishing: if you want to change the existing structure, use `refactor`; if you want to add onto the existing system, use `feature-growth`)
+   - When no condition clearly applies, recommend `standard`.
+
+4. **Confirm with the user**
+   - Present the recommended mode and the reason, and request confirmation/change via `AskUserQuestion`.
+   - **Whether there is one mode candidate or several, always run the recommend → confirm → record wiring**. This keeps the user experience unchanged as modes are added or removed.
+
+5. **Record the confirmed result**
+   - Write the confirmed mode to `.intent/mode.local.md` (the local canonical source for mode state; not tracked by git) (mode / selected / reason / definition). In legacy environments where `mode.local.md` does not exist, reads are handled by the backward-compatible fallback (`mode.local.md` → `mode.md` → standard). Enforcement / Drift-watch reads continue to reference `mode.md`.
+
+## Adding a new mode to the recommendation targets
+
+When you create a new `.intent/modes/<name>.md`, add to the recommendation guidelines in step 3 above "under what repository situations to recommend <name>".

package/templates/en/claude/skills/intent-export-cc-sdd/SKILL.md

@@ -0,0 +1,88 @@
+---
+name: intent-export-cc-sdd
+description: Convert one chosen packet into a condensed draft that can be handed to cc-sdd without wasting tokens. Does not intrude on cc-sdd's main generation. Can invoke /kiro-spec-init when instructed to proceed.
+disable-model-invocation: true
+allowed-tools: Read, Write, Glob, Grep, AskUserQuestion, Skill, Bash
+argument-hint: <target packet name (optional)>
+---
+
+# intent-export-cc-sdd Skill
+
+## Core Mission
+- **Success Criteria**:
+  - One target packet is converted into a condensed cc-sdd Project Description + design/tasks hints
+  - The input is limited to the target packet file + the compass's project-universal Invariants/Anti-direction, and the full Tree/Compass is not transcribed into cc-sdd
+  - The tasks hints carry parent intent / invariant references, forming a propagation structure to impl
+  - The output is led by natural-language guidance, and `/kiro-spec-init` can be invoked when instructed to proceed
+  - No application code has been changed at all
+
+## Execution Steps
+
+### Step 1: Narrow down to one target packet
+- Read `.intent/packets/index.md` and present the active packet candidates. If index.md is absent, build the candidate list directly from the frontmatter of the files under `.intent/packets/active/`, continue, and prompt regeneration of the index. If `.intent/packets/` itself is absent (or `active/` is empty), guide the user to "run `/intent-packets` first" and stop.
+- If a packet is specified by argument, use it; otherwise narrow down to one from the candidates by priority or user confirmation, and read only the file of the confirmed target packet (under `.intent/packets/active/`) — do not bulk-read all packet files.
+- **Draft guard**: when the confirmed target packet's `state` is draft, confirm via AskUserQuestion whether to "activate it and continue the export"; once the user approves, update the frontmatter `state` to active and regenerate `index.md` before continuing (never export a draft as is without confirmation; this activation is the only canonical write the export makes).
+- Read `.intent/mode.local.md` (falling back to `.intent/mode.md` if absent) for the mode state. If both are absent, continue with the standard default and announce it.
+
+### Step 1.5: Enforcement gate (writeback freshness check)
+- From the `## Enforcement (user-managed)` section of the `.intent/mode.md` read in Step 1, check the value of `enforcement`. If it is off, missing, or an invalid value (including mode.md being absent), skip this check and continue to Step 2 as today.
+- When it is remind or gate, run `node .intent/scripts/intent-check.mjs` with Bash (a read-only script; it creates, modifies, and deletes no files) and follow its stdout.
+- **Interpretation rules for the verdict line**: the stop decision is governed solely by `block=` on the first stdout line (do not re-derive or reinterpret). Whether a warning is needed is decided by `result=stale` or `pending>0`. Even when `result=not-applicable`, use the value of `pending=` from the verdict line as is.
+- When gate and `block=yes`: present the grounds (the pending packet names and the elapsed commit count / threshold; quote intent-check's human-readable lines from the second line onward verbatim), stop the export, and guide the user to run `/intent-writeback`. Then confirm via AskUserQuestion whether to "proceed with the export anyway", and only when the user explicitly instructs to proceed, run the export with a warning attached (the escape hatch for false positives).
+- When remind and a violation is detected (`result=stale` or `pending>0`): present the same grounds as a warning and continue without stopping.
+- Only when intent-check itself cannot run (Bash unavailable, script absent, or exit 2): treat staleness as not-applicable, check `.intent/deltas.md` for pending Delta entries (those carrying `- Status: pending`) via Read/Grep, and enter the same branches above using that result as `pending`.
+
+### Step 1.6: Drift Check (drift-watch)
+- Check the value of `drift-watch` in the `## Drift-watch (user-managed)` section of the `.intent/mode.md` read in Step 1. When it is not `on` (including off, unspecified, invalid value, missing section, or missing mode.md), do not perform this check; continue to Step 1.7 as today (byte-identical to current behavior).
+- Only when it is `on`, read and apply `rules/drift-export-check.md`. The matching of the target packet's design/tasks hints × compass (North Star / Anti-direction / Invariants), the named presentation of conflicts, appending a `stage: export` entry to drift-log, and resolving the outcome by the user's verdict are all delegated to the rule's procedure (do not duplicate the procedure here).
+- This check is **warn-only and does not stop the export** (only the Step 1.5 enforcement gate can stop; drift-watch never stops because it assumes false positives).
+- Order and orthogonality of the three checkpoints: **enforcement (procedure, may stop, Step 1.5) → drift-watch (direction, never stops, Step 1.6) → Open Questions (deadline, never stops, Step 1.7)**. Their inspection targets are orthogonal (procedure / direction / deadline).
+
+### Step 1.7: Confirm unanswered Open Questions
+- Read and apply `rules/export-questions.md`.
+
+### Step 1.8: Preflight check of the cc-sdd prerequisite (warn only — do not stop)
+- Observe read-only whether the `.kiro/` directory exists (Read/Glob; do not push this onto a mechanical check such as `intent-check.mjs`).
+- When `.kiro/` is **absent**: **warn** that cc-sdd (kiro) may not be set up. Guide: "The cc-sdd prerequisite (`.kiro/`) was not found. Set up cc-sdd, or — if a readable artifact is the goal — the format-axis projection (an exit to a readable Spec) is also available." (The choice of exit follows the exit decision lane in `rules/export-route.md`; this SKILL does not name other export/projection skills' commands.) **Do not stop the draft generation** (continue to Step 2 onward).
+- When `.kiro/` **exists**: emit nothing and continue to Step 2 (as before — no warn).
+- This check is **warn only — it does not stop the export** (only the Step 1.5 enforcement gate can stop; the preflight follows drift-watch's false-positive-tolerant stance and does not stop — it does not foreclose adding `.kiro/` later). The exit's appropriateness follows the convention in `rules/export-route.md` (the exit decision lane).
+
+### Step 2: Apply the mapping rules
+- Read and apply `rules/map-cc-sdd.md`.
+- The input is only the one target packet file (including the packet-specific invariants in Safety / Invariants) + the project-universal Invariants/Anti-direction of `.intent/intent-compass.md` (do not read the full Tree or other packets. Only when direction is needed, reference a summary of Tree L0–L1).
+
+### Step 3: Generate the draft
+- Write the drafts under the per-packet directory `.intent/cc-sdd/<slug>/`. The slug derivation and collision handling follow the "Output layout" section of `rules/map-cc-sdd.md`.
+- Write the condensed Project Description (the cc-sdd input body) into `.intent/cc-sdd/<slug>/requirements.md`.
+- Write design hints (bullets) into `.intent/cc-sdd/<slug>/design.md`, and an "Intent-derived constraints" section + tasks check items into `.intent/cc-sdd/<slug>/tasks.md`.
+- Do not complete the cc-sdd main body. Always leave parent intent and invariant references in the tasks hints.
+- Once the drafts are generated, write the export record into a **per-packet split file** `.intent/export-log/<packet-slug>.md` (following CONTRACT "Split and archive convention for append-only records"). Derive `<packet-slug>` from the packet name via the existing slug rule (`intent-packets/rules/packet-format.md`) — do not create new/sequential numbering. The file holds the same table header as the scaffold (`| packet | exported_at | commit |`) plus the row `| <packet name> | <export datetime (ISO 8601 UTC)> | <commit hash> |` (append a row if the file exists; do not erase past rows). Obtain the commit hash by running `git rev-parse --short HEAD` (read-only) with Bash; if it cannot be obtained, record `-`. Create the `.intent/export-log/` directory if absent.
+- Then regenerate the old `.intent/export-log.md` as a **generated active mirror**: concatenate all data rows from `.intent/export-log/*.md` in `exported_at` ascending order and overwrite the mirror with the scaffold header + all rows (the split files are the source of truth; the mirror is derived, never hand-edited). This keeps single-file readers (status / validate / writeback / intent-check) from breaking. The mirror is folded in the later slice (wire) once reader cross-following is complete.
+
+### Step 4: Guide the handoff (natural-language led)
+- The lead of the output is natural-language guidance: show the path of the target packet's `.intent/cc-sdd/<slug>/requirements.md` and confirm "may this be handed to cc-sdd as is".
+- When the user instructs to proceed, read the body of the target packet's `.intent/cc-sdd/<slug>/requirements.md` and invoke `/kiro-spec-init` with that body as the argument (use `Skill`. Do not force the user to copy-paste).
+- As a fallback, also include a newline-minimized copy block for `/kiro-spec-init` (not the lead).
+- **Delegation goes only up to invoking `/kiro-spec-init`**. The subsequent requirements → design → tasks follow cc-sdd's 3-phase approval, waiting for the user's instruction to proceed at each phase. Do not push ahead automatically.
+- **Make the return path explicit (the entry to the writeback phase)**: at the end of the guidance, add one line that once the cc-sdd implementation has gone around once (once learnings emerge from the reality of implementation), they are returned to the canonical deliverables via `/intent-writeback`. Do not settle for writing post-implementation learnings directly into the packet file as Evidence; always go through writeback (via a delta). This guidance makes the phase boundary explicit to the user: "pre-implementation drafting (compass/packets write canonical directly)" vs. "post-implementation extraction (writeback via a delta)".
+
+## Output Description
+- Proposed update to the target packet's `.intent/cc-sdd/<slug>/{requirements, design, tasks}.md`
+- One export-record row appended to `.intent/export-log.md`
+- The target packet file's `state` update and the regeneration of `.intent/packets/index.md` when a draft was activated (omitted when none apply)
+- Confirmation result for unanswered `[by export]` questions (the questions presented and the user's decision; omitted when none apply)
+- Confirmation of whether it may be handed to cc-sdd (natural-language guidance; the lead)
+- Copy block for `/kiro-spec-init` (fallback; secondary)
+- Points to confirm before implementation
+- Return-path guidance after the implementation goes around once (return to canonical via `/intent-writeback`; do not settle for writing Evidence directly into the packet)
+
+## Safety & Fallback
+- If `.intent/packets/` is absent (or `active/` is empty), stop and guide the user to `/intent-packets`.
+- The absence of index.md does not stop; build the candidates directly from the files under `active/`, continue, and prompt regeneration of the index.
+- The only canonical write is the draft-guard activation (`state` update + `index.md` regeneration), and only with the user's approval. Never rewrite intent-tree / intent-compass / packet bodies.
+- The absence of mode.md does not stop; continue with the standard default and announce it.
+- The enforcement check is fail-open: even when intent-check cannot run, do not block the export. The export stops only when enforcement is gate and the verdict line says `block=yes`, or when the unrunnable fallback finds pending deltas under gate; even then the user's explicit instruction to proceed lets it run.
+- The Open Questions check is a confirmation, not a stop; the user's explicit instruction to proceed lets the export run.
+- Do not complete the main body of cc-sdd's requirements/design/tasks (drafts/hints only).
+- Do not auto-invoke cc-sdd phases beyond `/kiro-spec-init`.
+- Do not change application code (INV6. Invoking other skills is a concept distinct from INV6 and is allowed).

package/templates/en/claude/skills/intent-export-cc-sdd/rules/drift-export-check.md

@@ -0,0 +1,75 @@
+# Drift Export Check
+
+The matching logic used at Step 1.6 of `/intent-export-cc-sdd`: the target packet's design/tasks hints against the compass. It runs only when `drift-watch: on` (off / absent / invalid values do nothing). It sits after the enforcement gate (Step 1.5, which may stop) and before the Open Questions check (Step 1.7, which does not stop), and warns—right before handoff to cc-sdd, the moment before going-back stops working—whether the packet has drifted from the compass's direction.
+
+## The basis of the matching is the compass
+
+- **The basis of the matching is the North Star / Anti-direction / Invariants of `.intent/intent-compass.md`.** At the export stage the compass already exists, so here the basis is the compass, not the pattern catalog (`.intent/drift-patterns.md`) (the discover terrain diagnosis has neither compass nor packet yet, so it uses the pattern catalog as its basis. Export is its sibling stage, and the difference is that the basis is the compass).
+- The export matching is **premised on false-positives**. "Hitting" a compass element is not a confirmation of drift. We build in from the start that a valid design may be wrongly caught (false-positive), and we record swings and misses too.
+- **This matching is a direction checkpoint, and it does not stop.** Its inspection target is orthogonal to the enforcement gate (a procedure checkpoint that may stop). We never stop export over a drift detection (only the Step 1.5 enforcement gate may stop).
+
+## Procedure
+
+1. **Obtain the inputs**
+   - Take the target packet's **design/tasks hint generation content** (the body of the draft export is about to generate) as the input.
+   - Read the **North Star** / **Anti-direction** / **Invariants** (project-universal Invariants) of `.intent/intent-compass.md`.
+   - **When the compass is absent / unfilled**: skip the export matching and inform the user of that fact (do not stop / do not write to drift-log either). Do not run the remaining steps.
+
+2. **Match the design/tasks hints against the compass**
+   - Hold the design/tasks hints about to be generated against the compass's **Invariants** (do they breach a constraint that must not be broken?), **Anti-direction** (are they leaning toward a direction decided to be avoided?), and **North Star** (have they drifted from the final state?).
+   - This is a **semantic match**, not a mechanical decision. Premised on false-positives, pick it up if in doubt.
+
+3. **When there is a conflict**
+   - Present a **warning only** to the user—**do not stop export**. Name what was breached (which Invariant / Anti-direction / North Star) and which part of the design/tasks hints is off.
+   - Append one entry to `drift-log.md` (see the append procedure below). The values are:
+     - `pattern: <a matching drift-patterns id | uncatalogued:<short name> | ->`（an id if identifiable; `uncatalogued:<short name>` for an actual drift outside the catalog; `-` if undeterminable）
+     - `stage: export`
+     - `packet: <target packet name>`
+     - `mechanism: compass-anti-direction`（when an Anti-direction was breached）or `compass-invariant`（when an Invariant was breached; pick by which compass element was breached）
+     - `outcome: caught`（a **draft**. This is drift-watch's estimate; the verdict is decided by the user's `user-verdict` and the resolution below）
+     - `user-verdict: unjudged`
+     - `recorded_at: <ISO 8601>`
+     - `commit: <short hash | ->`
+     - `note: <1-2 lines>`（what was breached and what was warned about）
+   - If multiple places conflict, append one entry per conflict.
+
+4. **outcome is confirmed by the user's judgment (resolving the draft)**
+   - Step 3 only **drafts** `caught` for `outcome`; the final value is decided by the user's judgment:
+     - When the user heeds the warning and pulls the design back → `caught` (capture succeeded, the "worked" family)
+     - When the user ignores it and passes it through anyway → `missed` (could not prevent it, it got through, the "did not work" family)
+     - When the design was actually valid and it was a false alarm → `false-positive` (it was a false alarm, the "did not work" family)
+   - `user-verdict` backs the final value: `valid` if the point was sound / `false-alarm` if it was a false alarm / `unjudged` if not judged. Even if the user has not judged it, it stays `unjudged` and remains a target for recording and tallying.
+
+## The append procedure to drift-log
+
+- **Write in split form (CONTRACT "Split and archive convention for append-only records")**: drift-log is event-origin, so instead of appending to the end of a single `drift-log.md`, write one entry to a **per-date+slug split file** `drift-log/<date>-<slug>.md`. `<date>` is the recorded_at date; `<slug>` is derived from the pattern (the event) via the existing slug rule (`intent-packets/rules/packet-format.md`) — do not create new/sequential numbering. Because a different event touches a different file, tail collisions disappear by construction. Never rewrite or delete an existing entry (**append-only**).
+- **Always write all 9 keys in fixed order**: `pattern` → `stage` → `packet` → `mechanism` → `outcome` → `user-verdict` → `recorded_at` → `commit` → `note`. Do not write an entry that is missing even one of the 9 keys.
+- **recorded_at**: write the recording time in ISO 8601 (transaction time).
+- **commit**: write the result of `git rev-parse --short HEAD`. When it cannot be obtained (non-repository, git CLI absent, etc.), use `-` (fail-open; recording continues).
+- **When the `drift-log/` directory is absent**: create the directory, then write the split file. An old single `drift-log.md`, if still present, can be read side-by-side by readers (migration is handled by this slice's migration step).
+- Follow the sample in the "Entry format" section of `.intent/drift-log.md` (`### drift-log entry`) for the entry format.
+
+## Scope-overflow check (DR9 second defense · packet-scope-overflow)
+
+A second check whose **grounds differ from** the compass check above. Whereas the compass check looks at "did this conflict with a universal compass Invariant", this one looks at "**is an implementation instruction arriving that exceeds the target packet's declared scope (`## Scope` / `## Non-scope`)**". When it does, it warns that the **packet-specific invariants** that newly become necessary in that new territory (authorization, data consistency, transaction boundaries, idempotency) are absent from the cc-sdd artifacts—recorded as drift. It runs only when `drift-watch: on`, and—like the compass check—**warns only, never stops, and assumes false positives**. It is also the instrument that measures whether the first defense (the convention-doc rule "go back to intent on scope overflow"—recall only) is working.
+
+The check is performed at two points (user-confirmed 2026-06-20, "both"):
+
+1. **At the export waterline (this Step 1.6)**: check whether the draft about to be exported exceeds the target packet's `## Scope` and reaches into the `## Non-scope` side. If the draft itself departs from scope, it is caught at export time.
+2. **A light cue afterward (re-check at the implementation stage)**: when the **implementation instruction** the user issues after export exceeds the target packet's `## Scope` (e.g., a front-end-only packet being told to implement back-end / authorization / transaction boundaries), re-check lightly and name it. This is the entry point that prompts a return to "go back to intent" (raise a packet for the new territory with `/intent-packets` and re-export); it does not stop.
+
+### Input and discipline of the check
+
+- **The input is only the implementation-instruction text and the packet's `## Scope` / `## Non-scope` declarations.** Do not read code diffs or implementation results (INV5/INV6 · DR14). It is a semantic check, not a mechanical decision.
+- The grounds of the check are the **absence of packet-specific invariants**. Do not conflate its logic with the universal compass Invariant check (above). The fact that universal Invariants were transcribed at export does not cover the new territory's specific constraints (a different layer).
+- **Abnormal case**: when the target packet is missing / `## Scope` is blank, skip the check and announce it (do not stop · do not write to drift-log).
+
+### When there is a scope overflow
+
+- Present **only a warning** to the user—neither export nor implementation stops. Name what exceeds the packet scope (e.g., front-end), which new territory it reaches (e.g., back-end / authorization / transactions), and which packet-specific invariants (authorization, consistency, transaction boundaries, idempotency) are absent, and advise "raise a packet for the new territory with `/intent-packets` and re-export (go back to intent)".
+- Append one entry to `drift-log.md` (same append procedure as above). The value differences are:
+  - `mechanism: packet-scope-overflow` (a second-defense origin distinct from the two compass values; separable in tallies)
+  - `pattern: uncatalogued:scope-overflow` (the id of a scope-creep type seed if the type catalog has one; otherwise `uncatalogued:scope-overflow`)
+  - `stage: export` (when caught at the waterline). When caught at the later implementation stage, use `stage: export` as well, as an extension of the export-origin check, and state "re-check at the implementation stage" in `note` (do not add a new stage value—keep the existing three-value `discover | export | improve` schema unchanged).
+  - The other keys (`packet` / `outcome: caught` draft / `user-verdict: unjudged` / `recorded_at` / `commit` / `note`) follow the same discipline as the compass check.
+- The confirmation of `outcome` is the same as the compass check (`caught` if the user goes back to intent / `missed` if they push through ignoring it / `false-positive` if it was actually a valid extension and a false alarm).

package/templates/en/claude/skills/intent-export-cc-sdd/rules/export-questions.md

@@ -0,0 +1,23 @@
+# Export Questions Check
+
+The procedure for confirming unanswered `[by export]` Open Questions before running the export. Used at Step 1.7 of `/intent-export-cc-sdd`. All dialogue is conducted as confirmation with the user (the means of confirmation follows the SKILL.md conventions).
+
+## Detection
+
+- Read the Open Questions sections of `.intent/intent-tree.md` and `.intent/intent-compass.md`, and detect questions containing `[by export]`. A question remaining in the section is treated as unanswered.
+- Detection targets only these two files. The canonical source of questions is the Open Questions sections of both files; the Deferred section of `.intent/packets/plan.md` is a record of intentional deferrals, not questions, and is therefore out of scope.
+- **Do not reference the enforcement setting (the Enforcement section of `.intent/mode.md`)** (this operates independently of the Step 1.5 enforcement gate).
+
+## Procedure
+
+1. **When nothing is detected (including older scaffolds without the tag convention)**
+   - Present nothing and proceed to the next step (no behavior change).
+
+2. **When questions are detected**
+   - Present the list of detected questions.
+   - Confirm with the user whether to "answer them before exporting, or proceed as is".
+   - This is a confirmation, not a stop. When the user explicitly instructs to proceed, run the export.
+
+## Discipline
+
+- Do not change code.

package/templates/en/claude/skills/intent-export-cc-sdd/rules/map-cc-sdd.md

@@ -0,0 +1,62 @@
+# Mapping: packet → cc-sdd
+
+The rules for converting one chosen packet into a cc-sdd draft. Used by the `intent-export-cc-sdd` skill. This is one of the per-export-target mappings (for cc-sdd). To add another target (e.g. OpenSpec), add `rules/map-<target>.md` and create a corresponding `intent-export-<target>` skill (the seam).
+
+## Input scope (strict / information-source contract)
+
+- Read only **the one target packet** and **the Invariants / Anti-direction of `.intent/intent-compass.md`**.
+- **Do not read** the full Intent Tree or other packets. Only when the overall direction is needed, reference Tree L0–L1 **as a summary** in a pinpoint manner (no body transcription).
+- This keeps the amount of information passed to cc-sdd to about 1 packet's worth (preventing token explosion).
+
+## Output (drafts of 3 files / do not create the main body)
+
+Write the drafts under the per-packet directory `.intent/cc-sdd/<packet-slug>/` (slug derivation is in the next section, "Output layout").
+
+### `.intent/cc-sdd/<packet-slug>/requirements.md`
+- The **Project Description body** (condensed text) fed into cc-sdd's `/kiro-spec-init`.
+- What to include: (a) whose problem it is, (b) the current state, (c) what you want to change / In·Out scope / invariants to protect / parent intent.
+- **Required headings (output contract)**: always include the three headings `## Source Packet`, `## Parent Intent`, and `## Invariants`. The value of `## Source Packet` is the **exact transcription** of the packet name (the anchor that identifies which packet this directory belongs to).
+- The information source is limited to the target packet (Why/Scope/Expected Behavior/Safety) and the compass's Invariants.
+
+### `.intent/cc-sdd/<packet-slug>/design.md`
+- **Hints to prevent oversights (bullets)** for when cc-sdd generates the design. Not the main body.
+- Origin: the packet's Scope/Non-scope/Rollback + the compass's technical-constraint Invariants. Perspectives: responsibility boundaries, dependency direction, side effects, migration/rollback, risk, technical constraints (if the compass Invariants include technology-stack, infrastructure, or license constraints, transcribe them into the hints so that cc-sdd's design technology selection does not deviate from them).
+
+### `.intent/cc-sdd/<packet-slug>/tasks.md`
+- Place an **"Intent-derived constraints" section** (a summary of parent intent / invariant / Anti-direction) at the top.
+- After that, cc-sdd's tasks-generation check items (characterization test / migration slice / each task's invariant reference).
+- Origin: the packet's Validation/Rollback + parent intent + the compass's Invariants/Anti-direction.
+
+## Output layout (slug rule and collision rule)
+
+### Slug rule (deterministic)
+
+Derive the directory name (slug) from the packet name **deterministically** in the following order. The same packet name always yields the same slug.
+
+1. Apply NFC normalization.
+2. Trim leading/trailing whitespace.
+3. Lowercase ASCII uppercase letters.
+4. Replace whitespace and path-dangerous characters (`/ \ : * ? " < > |`) with `-`.
+5. Collapse consecutive `-` into one.
+6. Strip leading/trailing `-`.
+
+- Non-ASCII characters (Japanese etc.) are preserved as-is.
+- If the result is an empty string, use `unnamed-packet` as the slug and notify the user.
+
+### Collision rule
+
+- A collision occurs only when the slug matches an existing directory AND that directory's requirements.md `## Source Packet` heading names a **different** packet. Assign a numbered alternative starting at `-2`, and notify the user of the packet-name → directory-name mapping. Never silently overwrite.
+- If `## Source Packet` names the **same** packet, it is not a collision but a re-export: update the drafts in that same directory in place.
+
+## Propagation to impl (strategy X)
+
+- Write the tasks hints at the granularity of "**invariant references tied to individual tasks**".
+- Aim: that parent intent and invariants are **transcribed** into each task of the main `tasks.md` that cc-sdd generates. This lets an impl subagent that is invoked in a different session without reading `.intent/` still reference the invariants / Anti-direction via the cc-sdd deliverable (tasks.md).
+- **Responsibility boundary**: intent-planner's responsibility goes only as far as "passing hints in a structure that is easy to transcribe". The actual transcription is left to cc-sdd's tasks generation (do not depend on cc-sdd's behavior). Complete transcription is **not a guarantee, but a probability maximized by structure**.
+
+## Invariants
+
+- Do not complete **the main body** of cc-sdd's requirements/design/tasks (drafts/hints only).
+- The tasks hints must always include references to parent intent and invariants.
+- **Never write into another packet's directory** (write only under the target packet's slug directory).
+- Do not intervene in cc-sdd's skills.

package/templates/en/claude/skills/intent-export-openspec/SKILL.md

@@ -0,0 +1,90 @@
+---
+name: intent-export-openspec
+description: Convert one chosen packet into a proposal draft + delta spec hints that can be handed to OpenSpec without wasting tokens. Does not intrude on OpenSpec's main generation. Can invoke /opsx:propose when instructed to proceed.
+disable-model-invocation: true
+allowed-tools: Read, Write, Glob, Grep, AskUserQuestion, Skill, Bash
+argument-hint: <target packet name (optional)>
+---
+
+# intent-export-openspec Skill
+
+## Core Mission
+- **Success Criteria**:
+  - One target packet is converted into an OpenSpec proposal draft (Why/What Changes/Impact) + delta spec hints
+  - The input is limited to the target packet file + the compass's project-universal Invariants/Anti-direction, and the full Tree/Compass is not transcribed into OpenSpec
+  - The delta hints carry parent intent / invariant references, forming a propagation structure to impl
+  - The output is led by natural-language guidance, and `/opsx:propose` can be invoked when instructed to proceed
+  - The output is confined to `.intent/openspec/` and does not touch `.intent/cc-sdd/`
+  - No application code has been changed at all
+
+## Execution Steps
+
+### Step 1: Narrow down to one target packet
+- Read `.intent/packets/index.md` and present the active packet candidates. If index.md is absent, build the candidate list directly from the frontmatter of the files under `.intent/packets/active/`, continue, and prompt regeneration of the index. If `.intent/packets/` itself is absent (or `active/` is empty), guide the user to "run `/intent-packets` first" and stop.
+- If a packet is specified by argument, use it; otherwise narrow down to one from the candidates by priority or user confirmation, and read only the file of the confirmed target packet (under `.intent/packets/active/`) — do not bulk-read all packet files.
+- **Draft guard**: when the confirmed target packet's `state` is draft, confirm via AskUserQuestion whether to "activate it and continue the export"; once the user approves, update the frontmatter `state` to active and regenerate `index.md` before continuing (never export a draft as is without confirmation; this activation is the only canonical write the export makes).
+- Read `.intent/mode.local.md` (falling back to `.intent/mode.md` if absent) for the mode state. If both are absent, continue with the standard default and announce it.
+
+### Step 1.5: Enforcement gate (writeback freshness check)
+- From the `## Enforcement (user-managed)` section of the `.intent/mode.md` read in Step 1, check the value of `enforcement`. If it is off, missing, or an invalid value (including mode.md being absent), skip this check and continue to Step 1.6 as today.
+- When it is remind or gate, run `node .intent/scripts/intent-check.mjs` with Bash (a read-only script; it creates, modifies, and deletes no files) and follow its stdout.
+- **Interpretation rules for the verdict line**: the stop decision is governed solely by `block=` on the first stdout line (do not re-derive or reinterpret). Whether a warning is needed is decided by `result=stale` or `pending>0`. Even when `result=not-applicable`, use the value of `pending=` from the verdict line as is.
+- When gate and `block=yes`: present the grounds (the pending packet names and the elapsed commit count / threshold; quote intent-check's human-readable lines from the second line onward verbatim), stop the export, and guide the user to run `/intent-writeback`. Then confirm via AskUserQuestion whether to "proceed with the export anyway", and only when the user explicitly instructs to proceed, run the export with a warning attached (the escape hatch for false positives).
+- When remind and a violation is detected (`result=stale` or `pending>0`): present the same grounds as a warning and continue without stopping.
+- Only when intent-check itself cannot run (Bash unavailable, script absent, or exit 2): treat staleness as not-applicable, check `.intent/deltas.md` for pending Delta entries (those carrying `- Status: pending`) via Read/Grep, and enter the same branches above using that result as `pending`.
+
+### Step 1.6: Drift Check (drift-watch)
+- Check the value of `drift-watch` in the `## Drift-watch (user-managed)` section of the `.intent/mode.md` read in Step 1. When it is not `on` (including off, unspecified, invalid value, missing section, or missing mode.md), do not perform this check; continue to Step 1.7 as today (byte-identical to current behavior).
+- Only when it is `on`, read and apply `rules/drift-export-check.md`. The matching of the target packet's proposal/delta hints × compass (North Star / Anti-direction / Invariants), the named presentation of conflicts, appending a `stage: export` entry to drift-log, and resolving the outcome by the user's verdict are all delegated to the rule's procedure (do not duplicate the procedure here).
+- This check is **warn-only and does not stop the export** (only the Step 1.5 enforcement gate can stop; drift-watch never stops because it assumes false positives).
+- Order and orthogonality of the three checkpoints: **enforcement (procedure, may stop, Step 1.5) → drift-watch (direction, never stops, Step 1.6) → Open Questions (deadline, never stops, Step 1.7)**. Their inspection targets are orthogonal (procedure / direction / deadline).
+
+### Step 1.7: Confirm unanswered Open Questions
+- Read and apply `rules/export-questions.md`.
+
+### Step 1.8: Preflight check of the OpenSpec prerequisite (warn only — do not stop)
+- Observe read-only whether the **`openspec/` directory at the repository root** (the OpenSpec tool's marker) exists (Read/Glob; do not push this onto a mechanical check such as `intent-check.mjs`). It is **distinct from `.intent/openspec/` (this skill's own draft output directory)**; do not mistake the output directory for the prerequisite marker.
+- When the repository-root `openspec/` is **absent**: **warn** that OpenSpec may not be set up. Guide: "The OpenSpec prerequisite (the `openspec/` directory at the repository root) was not found. Set up OpenSpec, or — if a readable artifact is the goal — the format-axis projection (an exit to a readable Spec) is also available." (The choice of exit follows the exit decision lane in `rules/export-route.md`; this SKILL does not name other export/projection skills' commands.) **Do not stop the draft generation** (continue to Step 2 onward).
+- When the repository-root `openspec/` **exists**: emit nothing and continue to Step 2 (as before — no warn).
+- This check is **warn only — it does not stop the export** (only the Step 1.5 enforcement gate can stop; the preflight follows drift-watch's false-positive-tolerant stance and does not stop — it does not foreclose adding `openspec/` later). Because OpenSpec's entry contract `/opsx:propose` cannot be observed read-only, the repository-root `openspec/` is used as a proxy marker for it being set up.
+
+### Step 2: Apply the mapping rules
+- Read and apply `rules/map-openspec.md`.
+- The input is only the one target packet file (including the packet-specific invariants in Safety / Invariants) + the project-universal Invariants/Anti-direction of `.intent/intent-compass.md` (do not read the full Tree or other packets. Only when direction is needed, reference a summary of Tree L0–L1).
+
+### Step 3: Generate the draft
+- Write the drafts under the per-packet directory `.intent/openspec/<slug>/`. The slug derivation and collision handling follow the "Output layout" section of `rules/map-openspec.md`. Continuing to export multiple packets never overwrites another packet's directory.
+- Write the proposal draft (`## Why` / `## What Changes` / `## Impact`) into `.intent/openspec/<slug>/proposal.md`, shaped so the minimal and always-valid "change description" text for `/opsx:propose` can be derived from its opening.
+- Write the delta spec hint skeleton into `.intent/openspec/<slug>/spec-delta.md` (`## ADDED Requirements` by default + conditional `## MODIFIED Requirements` / `## REMOVED Requirements`, with the `### Requirement: <name>` / `#### Scenario: <name>` skeleton).
+- Do not complete the OpenSpec main body. Keep the delta to a hint skeleton; the reconciliation and completion are delegated to OpenSpec (from `/opsx:propose` onward) (INV4). Always leave parent intent and invariant references in the proposal/delta.
+- Once the drafts are generated, write the export record into a **per-packet split file** `.intent/export-log/<packet-slug>.md` (following CONTRACT "Split and archive convention for append-only records"; since both cc-sdd and openspec write to each packet's file under the same split convention, the old tail-append collision on "the single log shared across export targets" disappears structurally). Derive `<packet-slug>` from the packet name via the existing slug rule (`intent-packets/rules/packet-format.md`) — do not create new/sequential numbering. The file holds the same table header as the scaffold (`| packet | exported_at | commit |`) plus the row `| <packet name> | <export datetime (ISO 8601 UTC)> | <commit hash> |` (append a row if the file exists; do not erase past rows). Obtain the commit hash by running `git rev-parse --short HEAD` (read-only) with Bash; if it cannot be obtained, record `-`. Create the `.intent/export-log/` directory if absent.
+- Then regenerate the old `.intent/export-log.md` as a **generated active mirror**: concatenate all data rows from `.intent/export-log/*.md` in `exported_at` ascending order and overwrite the mirror with the scaffold header + all rows (the split files are the source of truth; the mirror is derived, never hand-edited). This keeps single-file readers (status / validate / writeback / intent-check) from breaking. The mirror is folded in the later slice (wire) once reader cross-following is complete.
+
+### Step 4: Guide the handoff (natural-language led)
+- The lead of the output is natural-language guidance: show the paths of the target packet's `.intent/openspec/<slug>/proposal.md` and `spec-delta.md` and confirm "may this be handed to OpenSpec as is".
+- When the user instructs to proceed, read the minimal change description from the target packet's `.intent/openspec/<slug>/proposal.md` and invoke `/opsx:propose` with that as the argument (use `Skill`. Do not force the user to copy-paste).
+- As a fallback, also include a copyable change-description block for `/opsx:propose` (not the lead).
+- **Delegation goes only up to invoking `/opsx:propose`**. The subsequent apply / sync / archive workflows follow OpenSpec, and we do not push ahead automatically.
+- **Make the return path explicit (the entry to the writeback phase)**: at the end of the guidance, add one line that once the OpenSpec implementation has gone around once (once learnings emerge from the reality of implementation), they are returned to the canonical deliverables via `/intent-writeback`. Do not settle for writing post-implementation learnings directly into the packet file as Evidence; always go through writeback (via a delta). This guidance makes the phase boundary explicit to the user: "pre-implementation drafting (compass/packets write canonical directly)" vs. "post-implementation extraction (writeback via a delta)".
+
+## Output Description
+- The target packet's `.intent/openspec/<slug>/{proposal, spec-delta}.md` drafts (the `/opsx:propose` input proposal + delta hint skeleton)
+- One export-record row appended to `.intent/export-log.md`
+- The target packet file's `state` update and the regeneration of `.intent/packets/index.md` when a draft was activated (omitted when none apply)
+- Confirmation result for unanswered `[by export]` questions (the questions presented and the user's decision; omitted when none apply)
+- Confirmation of whether it may be handed to OpenSpec (natural-language guidance; the lead)
+- Copy block for `/opsx:propose` (fallback; secondary)
+- Points to confirm before implementation
+- Return-path guidance after the implementation goes around once (return to canonical via `/intent-writeback`; do not settle for writing Evidence directly into the packet)
+
+## Safety & Fallback
+- If `.intent/packets/` is absent (or `active/` is empty), stop and guide the user to `/intent-packets`.
+- The absence of index.md does not stop; build the candidates directly from the files under `active/`, continue, and prompt regeneration of the index.
+- The only canonical write is the draft-guard activation (`state` update + `index.md` regeneration), and only with the user's approval. Never rewrite intent-tree / intent-compass / packet bodies.
+- The absence of mode.md does not stop; continue with the standard default and announce it.
+- The enforcement check is fail-open: even when intent-check cannot run, do not block the export. The export stops only when enforcement is gate and the verdict line says `block=yes`, or when the unrunnable fallback finds pending deltas under gate; even then the user's explicit instruction to proceed lets it run.
+- The Open Questions check is a confirmation, not a stop; the user's explicit instruction to proceed lets the export run.
+- Do not complete the main body of OpenSpec's proposal / delta spec (drafts/hint skeleton only).
+- Do not auto-invoke the OpenSpec workflow beyond `/opsx:propose` (apply / sync / archive, etc.).
+- Confine the output to `.intent/openspec/` and do not write into `.intent/cc-sdd/`.
+- Do not change application code (INV6. Invoking other skills is a concept distinct from INV6 and is allowed).