intent-planner 0.13.1

package/templates/en/codex/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/codex/skills/intent-export-cc-sdd/SKILL.md

@@ -0,0 +1,85 @@
+---
+name: intent-export-cc-sdd
+description: Convert one chosen packet into a condensed draft that can be handed to cc-sdd without wasting tokens. Does not intrude on cc-sdd's main generation. Can invoke /kiro-spec-init when instructed to proceed.
+---
+
+# intent-export-cc-sdd Skill
+
+## Core Mission
+- **Success Criteria**:
+  - One target packet is converted into a condensed cc-sdd Project Description + design/tasks hints
+  - 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 by asking the user in natural language and waiting for their answer, and read only the file of the confirmed target packet (under `.intent/packets/active/`) — do not bulk-read all packet files.
+- **Draft guard**: when the confirmed target packet's `state` is draft, ask the user in natural language whether to "activate it and continue the export" and wait for their answer; once the user approves, update the frontmatter `state` to active and regenerate `index.md` before continuing (never export a draft as is without confirmation; this activation is the only canonical write the export makes).
+- Read `.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` (a read-only script; it creates, modifies, and deletes no files) and follow its stdout.
+- **Interpretation rules for the verdict line**: the stop decision is governed solely by `block=` on the first stdout line (do not re-derive or reinterpret). Whether a warning is needed is decided by `result=stale` or `pending>0`. Even when `result=not-applicable`, use the value of `pending=` from the verdict line as is.
+- When gate and `block=yes`: present the grounds (the pending packet names and the elapsed commit count / threshold; quote intent-check's human-readable lines from the second line onward verbatim), stop the export, and guide the user to run `/intent-writeback`. Then ask the user in natural language whether to "proceed with the export anyway" and wait for their answer; only when the user explicitly instructs to proceed, run the export with a warning attached (the escape hatch for false positives).
+- When remind and a violation is detected (`result=stale` or `pending>0`): present the same grounds as a warning and continue without stopping.
+- Only when intent-check itself cannot run (command execution unavailable, script absent, or exit 2): treat staleness as not-applicable, read `.intent/deltas.md` to check for pending Delta entries (those carrying `- Status: pending`), and enter the same branches above using that result as `pending`.
+
+### Step 1.6: Drift Check (drift-watch)
+- Check the value of `drift-watch` in the `## Drift-watch (user-managed)` section of the `.intent/mode.md` read in Step 1. When it is not `on` (including off, unspecified, invalid value, missing section, or missing mode.md), do not perform this check; continue to Step 1.7 as today (byte-identical to current behavior).
+- Only when it is `on`, read and apply `rules/drift-export-check.md`. The matching of the target packet's design/tasks hints × compass (North Star / Anti-direction / Invariants), the named presentation of conflicts, appending a `stage: export` entry to drift-log, and resolving the outcome by the user's verdict are all delegated to the rule's procedure (do not duplicate the procedure here).
+- This check is **warn-only and does not stop the export** (only the Step 1.5 enforcement gate can stop; drift-watch never stops because it assumes false positives).
+- Order and orthogonality of the three checkpoints: **enforcement (procedure, may stop, Step 1.5) → drift-watch (direction, never stops, Step 1.6) → Open Questions (deadline, never stops, Step 1.7)**. Their inspection targets are orthogonal (procedure / direction / deadline).
+
+### Step 1.7: Confirm unanswered Open Questions
+- Read and apply `rules/export-questions.md`.
+
+### Step 1.8: Preflight check of the cc-sdd prerequisite (warn only — do not stop)
+- Observe read-only whether the `.kiro/` directory exists (Read/Glob; do not push this onto a mechanical check such as `intent-check.mjs`).
+- When `.kiro/` is **absent**: **warn** that cc-sdd (kiro) may not be set up. Guide: "The cc-sdd prerequisite (`.kiro/`) was not found. Set up cc-sdd, or — if a readable artifact is the goal — the format-axis projection (an exit to a readable Spec) is also available." (The choice of exit follows the exit decision lane in `rules/export-route.md`; this SKILL does not name other export/projection skills' commands.) **Do not stop the draft generation** (continue to Step 2 onward).
+- When `.kiro/` **exists**: emit nothing and continue to Step 2 (as before — no warn).
+- This check is **warn only — it does not stop the export** (only the Step 1.5 enforcement gate can stop; the preflight follows drift-watch's false-positive-tolerant stance and does not stop — it does not foreclose adding `.kiro/` later). The exit's appropriateness follows the convention in `rules/export-route.md` (the exit decision lane).
+
+### 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); if it cannot be obtained, record `-`. Create the `.intent/export-log/` directory if absent.
+- Then regenerate the old `.intent/export-log.md` as a **generated active mirror**: concatenate all data rows from `.intent/export-log/*.md` in `exported_at` ascending order and overwrite the mirror with the scaffold header + all rows (the split files are the source of truth; the mirror is derived, never hand-edited). This keeps single-file readers (status / validate / writeback / intent-check) from breaking. The mirror is folded in the later slice (wire) once reader cross-following is complete.
+
+### Step 4: Guide the handoff (natural-language led)
+- The lead of the output is natural-language guidance: show the path of the target packet's `.intent/cc-sdd/<slug>/requirements.md` and confirm "may this be handed to cc-sdd as is" by asking the user in natural language and waiting for their answer.
+- When the user instructs to proceed, read the body of the target packet's `.intent/cc-sdd/<slug>/requirements.md` and invoke `/kiro-spec-init` with that body as the argument (do not force the user to copy-paste).
+- 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/codex/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/codex/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/codex/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/codex/skills/intent-export-openspec/SKILL.md

@@ -0,0 +1,87 @@
+---
+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.
+---
+
+# 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 by asking the user in natural language and waiting for their answer, and read only the file of the confirmed target packet (under `.intent/packets/active/`) — do not bulk-read all packet files.
+- **Draft guard**: when the confirmed target packet's `state` is draft, ask the user in natural language whether to "activate it and continue the export" and wait for their answer; once the user approves, update the frontmatter `state` to active and regenerate `index.md` before continuing (never export a draft as is without confirmation; this activation is the only canonical write the export makes).
+- Read `.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` (a read-only script; it creates, modifies, and deletes no files) and follow its stdout.
+- **Interpretation rules for the verdict line**: the stop decision is governed solely by `block=` on the first stdout line (do not re-derive or reinterpret). Whether a warning is needed is decided by `result=stale` or `pending>0`. Even when `result=not-applicable`, use the value of `pending=` from the verdict line as is.
+- When gate and `block=yes`: present the grounds (the pending packet names and the elapsed commit count / threshold; quote intent-check's human-readable lines from the second line onward verbatim), stop the export, and guide the user to run `/intent-writeback`. Then ask the user in natural language whether to "proceed with the export anyway" and wait for their answer; only when the user explicitly instructs to proceed, run the export with a warning attached (the escape hatch for false positives).
+- When remind and a violation is detected (`result=stale` or `pending>0`): present the same grounds as a warning and continue without stopping.
+- Only when intent-check itself cannot run (command execution unavailable, script absent, or exit 2): treat staleness as not-applicable, read `.intent/deltas.md` to check for pending Delta entries (those carrying `- Status: pending`), and enter the same branches above using that result as `pending`.
+
+### Step 1.6: Drift Check (drift-watch)
+- Check the value of `drift-watch` in the `## Drift-watch (user-managed)` section of the `.intent/mode.md` read in Step 1. When it is not `on` (including off, unspecified, invalid value, missing section, or missing mode.md), do not perform this check; continue to Step 1.7 as today (byte-identical to current behavior).
+- Only when it is `on`, read and apply `rules/drift-export-check.md`. The matching of the target packet's 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); 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" by asking the user in natural language and waiting for their answer.
+- 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 (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).

package/templates/en/codex/skills/intent-export-openspec/rules/drift-export-check.md

@@ -0,0 +1,50 @@
+# Drift Export Check
+
+The matching logic used at Step 1.6 of `/intent-export-openspec`: 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 OpenSpec, 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.

package/templates/en/codex/skills/intent-export-openspec/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-openspec`. 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/codex/skills/intent-export-openspec/rules/map-openspec.md

@@ -0,0 +1,75 @@
+# Mapping: packet → OpenSpec
+
+The rules for converting one chosen packet into an OpenSpec proposal draft + delta spec hint. Used by the `intent-export-openspec` skill. This is one of the per-export-target mappings (for OpenSpec). To add another target (e.g. cc-sdd), add `rules/map-<target>.md` and create a corresponding `intent-export-<target>` skill (the seam). Do not change `map-cc-sdd`.
+
+## 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 OpenSpec to about 1 packet's worth (preventing token explosion).
+- **Do not quote/transcribe other packets or the Intent Tree body** into the deliverables (proposal / delta). Limit sources to the target packet and the compass.
+
+## Output (drafts of 2 files / do not create the main body)
+
+Write the drafts under the per-packet directory `.intent/openspec/<packet-slug>/` (slug derivation is in the next section, "Output layout"). Align **one-directionally** with OpenSpec's entry contract (`/opsx:propose <natural-language change description>`, the proposal's Why/What Changes/Impact, the delta spec's ADDED/MODIFIED/REMOVED + `### Requirement:` / `#### Scenario:`). Do not depend on OpenSpec's internal implementation.
+
+### `.intent/openspec/<packet-slug>/proposal.md`
+
+The **proposal draft** fed into OpenSpec's `/opsx:propose`. Always include the three headings.
+
+- `## Why` — Transcribe the packet's intent / Why and state the **parent intent** (the higher-level aim this packet serves). Describe why this change is needed now.
+- `## What Changes` — List the packet's deliverables / Scope as **bullets**. State the compass's **Anti-direction** within this section **as out-of-scope (what not to do)**.
+- `## Impact` — The specs / contracts this change affects and the constraints to protect. Transcribe the compass's **Invariants**, listing the affected scope (contracts / capabilities touched) alongside the invariants.
+- **primary output**: Write it so that a **minimal and always-valid change description** that can be fed into `/opsx:propose` is derivable from the top of the proposal (the structured proposal is added value on top of that).
+- Limit the information source to the target packet (Why/Scope/Expected Behavior/Safety) and the compass's Invariants / Anti-direction.
+
+### `.intent/openspec/<packet-slug>/spec-delta.md`
+
+A **hint skeleton** for OpenSpec's delta spec (not the main body).
+
+- Map the packet's acceptance criteria / Expected Behavior onto the skeleton of `### Requirement: <name>` (**normative SHALL / MUST statements**) and `#### Scenario: <name>` (**GIVEN / WHEN / THEN**).
+- **Seed the heading syntax accurately** (`### Requirement:` / `#### Scenario:`) to guide toward a structure that passes OpenSpec's validate.
+- Follow the dispatch rule in the next section, "Delta dispatch".
+- Do not complete the main body. Reconciliation and completion are left to OpenSpec (from `/opsx:propose` onward) (INV4).
+
+## Delta dispatch (ADDED / MODIFIED / REMOVED)
+
+- **Default**: Place all of the packet's acceptance criteria under `## ADDED Requirements`.
+- **Conditional**: Only when the packet's **Scope** or the compass's **Anti-direction** **explicitly references a change/removal** of an existing capability or behavior, place a hint of "**the name of the capability changed + the direction of change**" under `## MODIFIED Requirements` / `## REMOVED Requirements`.
+- MODIFIED / REMOVED stay as identification hints for the change target; reconciliation with the existing spec and finalization are left to OpenSpec. If there is no explicit reference, do not place MODIFIED / REMOVED.
+
+## 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. This rule is **identical** to the slug rule in `packet-format.md` and `map-cc-sdd` (aligning output-path derivation across export targets).
+
+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 proposal.md points to a **different** packet name. Assign a numbered alternative starting at `-2`, and notify the user of the packet-name → directory-name mapping. Never silently overwrite.
+- If it points to the **same** packet name, it is not a collision but a re-export: update the drafts in that same directory in place.
+
+## Intent propagation (carry it into the deliverables OpenSpec generates)
+
+- State the **parent intent** in the proposal's `## Why` and the **invariants** in `## Impact`, passing them in a structure that is easy to take into the deliverables (spec / design / tasks) OpenSpec generates.
+- Render the compass's **Invariants** into OpenSpec's **normative statements (SHALL / MUST)** and the constraints of `## Impact`. When an invariant is relevant to a delta's `### Requirement:`, seed that constraint as a normative statement there too.
+- Aim: that parent intent and invariants keep working even at the stage of moving from an OpenSpec change to implementation, so that local-optimum prevention does not evaporate via OpenSpec either.
+- **Responsibility boundary**: intent-planner's responsibility goes only as far as "propagating parent intent / invariants **through the structure of what is passed alone**". Do not intervene in OpenSpec's internal implementation. The actual incorporation is left to OpenSpec (do not depend on OpenSpec's behavior). Complete incorporation is **not a guarantee, but a probability maximized by structure**.
+
+## Invariants
+
+- Do not complete **the main body** of OpenSpec's proposal / delta spec (drafts / hint skeleton only). Completing the delta is left to `/opsx:propose` onward (INV4).
+- The proposal's `## Why` / `## Impact` must always include references to parent intent and invariants.
+- Do not quote/transcribe other packets or the Intent Tree body into the deliverables (limit sources to the target packet + compass).
+- **Never write into another packet's directory** (write only under the target packet's slug directory).
+- Do not intervene in OpenSpec's skills / internal implementation. Confine output to `.intent/openspec/` and do not touch `.intent/cc-sdd/`.