intent-planner 0.13.1

package/templates/en/codex/skills/intent-compass/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: intent-compass
+description: From the Intent Tree, build the decision criteria for this change (North Star / Anti-direction / Invariants / Decision Rules). Prevents Claude from escaping into local optimizations. Does not implement.
+---
+
+# intent-compass Skill
+
+## Core Mission
+- **Success Criteria**:
+  - North Star / Current Drift / Direction / Anti-direction / Invariants / Decision Rules / Evidence / Open Questions are all present
+  - The local optimizations Claude tends to make are explicitly enumerated in Anti-direction
+  - Only project-universal invariants are kept in the compass; packet-specific invariants are canonical in the packet file (Safety / Invariants)
+  - No application code has been changed at all
+
+## Execution Steps
+
+### Step 1: Read the prerequisites
+- Read `.intent/intent-tree.md`. If absent, guide the user to "run `/intent-discover` first" and stop.
+- While reading, when you see an unsettled verb slipped into the settled phrasing of the compass / intent-tree (assume / reuse / planned / TBD / tentative, etc.), do not fix it by guessing; present it as a conversion proposal into Open Questions or an undetermined slot (with the reason and the revisit condition (Revisit when)). Promotion to a fixed value is left to the user's confirmation. Do not re-convert spots already recorded in Open Questions / Deferred / an undetermined slot.
+- Read `.intent/mode.local.md` (falling back to `.intent/mode.md` if absent) for the mode state. If both are absent, default to standard and add "mode undetermined; `/intent-discover` recommended" to the Open Questions (do not stop).
+- If an existing `.intent/intent-compass.md` exists, read it.
+
+### Step 2: Apply the mode definition's algorithm
+- Open the mode definition that `.intent/mode.local.md` (falling back to `.intent/mode.md`) `definition` points to, and read and apply the algo rule (`rules/algo-*.md`) assigned to the Compass construction phase (currently `rules/algo-qoc.md` for every mode). The examples are not exhaustive; the mode definition's table is always authoritative.
+
+### Step 3: Build the Compass
+- As a step before derivation, read and apply `rules/constraint-surfacing.md`. Match the bundled domain-convention catalog read-only and surface draft candidates for Anti-direction / Invariants (candidates only; do not auto-transcribe. Do not replace the existing derivation. Stay silent when the catalog is absent).
+- Following QOC, draw the North Star, and condense the Decision Rules as lightweight ADRs (the field structure of an entry is canonically defined by `rules/algo-qoc.md`).
+- Explicitly enumerate the local optimizations / quick-fix refactors Claude tends to make in Anti-direction (most important).
+- Resolve the Invariants into two layers:
+  - **Project-universal invariants** (common to all work, small in quantity) → keep them in the compass Invariants, and recommend placing them in `.kiro/steering/` via `/kiro-steering-custom` so they take effect across all work (do not place automatically; keep them small to avoid increasing startup context).
+  - **Packet-specific invariants** (a specific work unit) → draft them directly in the packet file's Safety / Invariants (do not write them in the compass; `/intent-packets` fills them in when drafting the packet).
+- Stamp the section update date (the writer's responsibility): when writing the compass, stamp **only the line of the section whose content you actually updated**. If you update the Invariants section, record that moment in `Updated (Invariants):`; if you update the Decision Rules section, record that moment in `Updated (Decision Rules):` (ISO 8601). Do not always stamp both — stamp a line only when its section was updated. Leave a section's line unchanged when its content did not change (idempotent; do not stamp when nothing changed). Replace the initial marker `—` (the scaffold default) with the timestamp at the moment you actually update that section. Obtain the timestamp with the shell `date`. If you cannot obtain the date/time, do not write a guessed date — report that instead. Stamping is the writer's (this skill's) responsibility and is not given to the read-only verification layer (intent-validate).
+
+### Step 4: Present
+- Present the proposed update to `.intent/intent-compass.md`. Do not make implementation changes.
+
+## Output Description
+
+**Reader**: a human developer who is about to head into implementation (and the AI that does the implementing).
+**What this output makes them grasp first**: "**these are the local optimizations to avoid in this change (Anti-direction)**. The decision criteria are in place, so next is `/intent-packets`." The core of this skill is making the Anti-direction explicit, so lead with it.
+
+Lead the output with the conclusion.
+
+- **Local optimizations to avoid this time (Anti-direction, top)**: name the quick-fix refactors / local optimizations Claude tends to make (the most important output of this skill).
+- **Next move (one line)**: `/intent-packets` (decomposition into work units; carving out packets at a granularity that can be handed to cc-sdd).
+- **Details**: the proposed update to `.intent/intent-compass.md` (North Star / Direction / Invariants / Decision Rules), the universal invariants recommended for steering placement (if any), and the Open Questions needed for decisions.
+
+## Safety & Fallback
+- If there is no Intent Tree, stop and guide the user to `/intent-discover`.
+- The absence of mode.md does not stop; continue with the standard default and announce it.
+- Do not change application code.

package/templates/en/codex/skills/intent-compass/rules/algo-qoc.md

@@ -0,0 +1,62 @@
+# Algorithm: QOC (Questions-Options-Criteria)
+
+A technique for recording design decisions as "question, options, selection criteria". Used in the Intent Compass construction phase common to all modes. By preserving the grounds for decisions, it prevents drifting into local optimizations later (especially at the impl stage).
+
+## Procedure
+
+1. **Draw the North Star from the Intent Tree**
+   - From L0/L1, condense "the final state this change wants to approach" into one.
+
+2. **Expand decision points with QOC**
+   - **Question**: the point of hesitation ("how to realize X").
+   - **Options**: list multiple options that could be taken.
+   - **Criteria**: by what criteria to choose. Check against the Intent Tree's L1 (outcomes) and invariants (constraints that must not be broken).
+   - Condense the adopted option into `Decision Rules` as a **lightweight ADR** (Architecture Decision Record, Nygard format). One decision per entry, with **Context** (the question and situation) / **Decision** (the option taken) / **Why** (the selection criteria) / **Alternatives considered** (the alternatives examined; transcribe a summary of the Options compared in QOC but not adopted, together with the reasons they were rejected) / **Consequences** (what this decision imposes — explicitly connect to the Invariants it enforces and the Anti-direction it forbids) / **Revisit when** (the conditions under which this decision should be revisited; if the conditions cannot be determined, explicitly record "undetermined" — do not leave the field blank).
+   - Division of roles: QOC is the **exploration tool for comparing options**; the ADR-shaped Decision Rule is the **canonical record that binds future implementation sessions**. Keep the comparison process in Evidence, and promote only the adopted decisions into Decision Rules.
+
+3. **Explicitly enumerate Anti-direction**
+   - Write the directions to avoid. In particular, concretely enumerate **the local optimizations / quick-fix refactors Claude tends to make**. This is the most important section of the Compass.
+   - Use a **pre-mortem** to generate the list: **assume** this change has been implemented and the overall design ended up broken or off-intent — then ask "what did the agent do?" Looking back from that imagined future (prospective hindsight) surfaces failure paths to record as Anti-direction. It detects failure factors better than ad-hoc enumeration.
+   - Examples: "fix some other processing while at it", "bulk replacement without tests", "push domain logic into the UI".
+
+4. **Fix the Invariants in two layers**
+   - Behavior / API / data / UX / operational constraints that must not be broken.
+
+   - **Before deriving anything by inference, confirm with the user using a fixed set of categories**. Establish user-supplied constraints as canonical first, then add inference-derived constraints afterward only to fill the gaps (complement, not replacement). Present the following categories **in order of importance** (to control cognitive load):
+     1. Data / personal information (PII) — what data must never be deleted or leaked.
+     2. External dependencies / existing contracts — what behavior must hold even if they go down or change.
+     3. Operations / failure-mode behavior — what to protect first under failure, high load, or partial outage.
+     4. Security / privacy / legal — what conventions or regulations are fatal to violate.
+     5. Performance / availability — whether there is a threshold below which it counts as failure.
+     6. Technical constraints — whether there is a technology stack / language / framework / platform / license that must be used or must not be used. For this category, loss-reverse reasoning is unnatural, so ask in the **affirmative (direct form)** rather than the negative ("is there any technology that must be used or must not be used?"). Run whatever surfaces through an **over-promotion filter**: is it a constraint that becomes an external problem when broken (a requirement-level How), rather than a preference or default choice (a solution-level How)? Turn only the former into an Invariant. Note that this is distinct from the design decisions (L3) derived by this change; place here only external, change-independent boundaries (do not duplicate with L3).
+     7. Invariants / prohibitions — anything else that "must never be the case".
+   - For each category, attach **2–3 weak cues of differing nature, generated on the spot** from the read project context (tech stack / domain / existing code / README) — do not embed fixed example strings. Always state that the examples are **not exhaustive ("this is not a complete list; raise anything else")** so thinking is not fixated on the shown examples.
+   - When no concrete examples can be generated from the context, present only the category frame (the heading) so the user can fill it in from their own context (fallback).
+   - Phrase the question not in the affirmative ("is X needed?") but as a **failure premise / in the negative** (e.g. "what is the worst that happens if this is completely ignored", "what must be protected even if an external dependency goes down", "what data must never be deleted"). Turn only what truly must be protected into an Invariant, from the loss scenario; do not mix in excessive assumptions (the technical-constraints category uses the direct form; see that category for the reason).
+   - For each category, present it so the user can choose "not applicable / unknown / confirm later"; do not force an answer. For items the user defers or marks "confirm later", do not fill them with guesses — escape them to `Open Questions` (with the `[by export]` tag where appropriate) and do not halt compass construction.
+
+   - Sort the collected constraints into the **two Invariant layers**. **Project-universal invariants** (common to all work, small in quantity) are fixed into the compass `## Invariants`. **Packet-specific invariants** (constraints limited to a specific work unit) are held in `## Open Questions` as "packet-specific constraints (candidates)", since during the compass phase packets are normally not yet drafted (later `/intent-packets` transcribes them into the relevant packet's Safety/Invariants). Among the non-functional requirements, those that are **target values** (performance / availability thresholds, etc.) are sorted into `Decision Rules` or the Intent Tree's L1 (measurement criteria).
+   - For the project-universal ones, recommend placing them in `.kiro/steering/` via `/kiro-steering-custom` so they take effect across all work (do not place automatically; keep them small to avoid increasing startup context).
+
+5. **Leave Evidence and Open Questions**
+   - Put the evidence supporting each decision (README / code / tests / logs / issues) into `Evidence`.
+   - Put questions needed for decisions but still undetermined into `Open Questions`.
+   - Attach the `[by export]` tag only to questions that must be answered before export (untagged questions can be answered at any time).
+
+6. **Confirm omissions and excess with an omission recap**
+   - Before presenting the `intent-compass.md` update proposal, briefly summarize the collected and inferred constraints / non-functional requirements / invariants and ask the user "is anything missing, or conversely is any assumption excessive?" (present it as material for a human to correct the LLM's oversights and hallucinations).
+   - When the user points out a **missing** item, add that constraint to the record location appropriate to its kind and re-present: universal Invariant → `## Invariants` / packet-specific → held in `## Open Questions` as a "packet-specific constraint (candidate)" / target value → `Decision Rules` or L1. Missing purpose/success items are out of compass scope (handled on the Intent Tree side); in this file, correct only the compass constraints.
+   - When the user points out an **excess**, after confirmation remove that entry from canonical (`## Invariants`, etc.). If unsure, do not delete it but demote it to `## Open Questions`. Always confirm with the user before deleting.
+   - Keep the re-edit to at most one round trip (do not converse endlessly in the recap). Escape any remaining points to `## Open Questions`.
+
+## Discipline
+
+- A Decision Rule must always include the "why". Do not write only the conclusion.
+- When overturning a decision, mark the old entry as superseded and add a new entry. Do not silently let contradictory decisions sit side by side.
+- Old 4-field entries recorded before the introduction of the 6-field format (those without Alternatives considered / Revisit when) remain valid; do not treat the missing fields as an error, flag them, or rewrite them.
+- Do not leave Anti-direction empty. List at least a few concrete examples of local optimizations.
+- Do not change code.
+
+## Output
+
+Update (present as a proposal) the `North Star / Current Drift / Direction / Anti-direction / Invariants / Decision Rules / Evidence / Open Questions` of `intent-compass.md`.

package/templates/en/codex/skills/intent-compass/rules/constraint-surfacing.md

@@ -0,0 +1,41 @@
+# Constraint Surfacing (surfacing constraint starting points)
+
+A procedure that matches the bundled domain-convention catalog (`.intent/constraint-starters.md`) read-only and surfaces **draft candidates** for Anti-direction / Invariants. Used during the Compass construction phase of `/intent-compass`, **as a step before** deriving Anti-direction / Invariants. If the user has grown their own constraints (`.intent/constraint-library.md`), add those to the candidates as well.
+
+This is a **supplement that does not replace** C2's derivation (the container that makes Anti-direction/Invariants explicit in the compass to suppress local optima): impact list → Invariants, premortem → Anti-direction. The existing derivation runs as is; this only injects "draft candidates of conventions that fit the context" ahead of it.
+
+## Discipline (must hold)
+
+- **Surfacing stays a read-only draft.** Do not **auto-write** matched conventions into Anti-direction / Invariants. Transcription into the compass happens by hand after the user picks what to adopt (confirmation with the user uses this skill's own confirmation mechanism).
+- **Do not push.** Do not surface conventions that do not fit the context. Narrow the candidates; involve no stop or coercion. If the fit is weak, stay silent (lean toward silence over false positives, to keep the draft feature trustworthy).
+- **Match semantically.** Judge by reading "fits when" against the context. Do not lean on mechanical string scoring or regular-expression matching.
+- **Do not replace or duplicate the existing derivation.** The impact-list → Invariants and premortem → Anti-direction steps stay as is. This procedure only adds a supply of candidates ahead of them.
+- **Stay silent when the catalog is absent.** When `.intent/constraint-starters.md` is absent, skip the matching and say so (do not stop). Same for `.intent/constraint-library.md` (skip if absent).
+- **Do not record to any log.** Surfacing stays a read-only suggestion and keeps no record.
+
+## Procedure
+
+1. **Read the catalog**
+   - 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 context**
+   - Match each convention's `fits when` against the case you are about to write the compass for (material, domain, boundaries touched). `fits when` is a cue, not a strong rule; if the fit is weak, do not surface that convention.
+   - Use only the case context for matching. Do not read code diffs or runtime metrics.
+
+3. **Surface matched conventions as draft candidates (do not write)**
+   - Surface the `starter` (Anti-direction candidate / Invariant candidate) of matched conventions to the user as candidates. Example: "This case may match `<id>` (<name>) — how about <Anti-direction candidate> / <Invariant candidate> as a starter (adoption is up to you)?".
+   - **Do not auto-write into the compass.** Whether to adopt is the user's call; only adopted ones are taken into Anti-direction / Invariants by hand.
+   - Do not surface non-matching conventions. Narrow so there are not too many candidates.
+
+4. **Proceed to the existing derivation**
+   - After surfacing candidates, run the existing Anti-direction / Invariant derivation (impact list → Invariants, premortem → Anti-direction) as usual. Candidates the user adopted are taken in by hand within that derivation.
+
+5. **Accumulate adopted constraints into the personal ledger (optional, by hand / with consent)**
+   - Among the starters surfaced in ③, if the user **adopted** a constraint as "this is my standard," guide them to append it to the personal ledger `.intent/constraint-library.md` in its fixed schema (`## id:` / name / domain / fits when / constraint / origin). Next time it is surfaced as a candidate alongside the bundled catalog and is reused within the repo.
+   - **Do not auto-write into the ledger.** Appending happens by the user's manual action, or only under the user's explicit approval (it carries no auto-accumulate behavior — a read-only gate). **If the user does not adopt, append nothing.** Leave the existing surfacing behavior unchanged.
+   - **Keep accumulation inside this project only.** The append target is only inside this project's `.intent/` directory; provide no mechanism to share or persist constraints across projects (do not guide cross-project accumulation).
+   - When the personal ledger `.intent/constraint-library.md` is absent, skip the accumulation and say so (do not stop — backward compatible).
+
+## Relationship to discover
+
+- In discover's terrain-diagnosis lane (`drift-terrain.md`), the same catalog is matched lightly when `drift-watch: on` to give early awareness. This procedure (compass) is the primary touchpoint; discover is supplementary.

package/templates/en/codex/skills/intent-discover/SKILL.md

@@ -0,0 +1,60 @@
+---
+name: intent-discover
+description: The entry point of Intent Planning. From the repository's pain points, README, and an overview of existing code, build an Intent Tree (L0-L4) and recommend/confirm the mode for working out the Intent. Does not implement.
+---
+
+# intent-discover Skill
+
+## Core Mission
+- **Success Criteria**:
+  - The L0–L4 Intent Tree is structured, with canonical (confirmed) and inferred (guessed) separated
+  - The mode for working out the Intent is recommended/confirmed and recorded in `.intent/mode.local.md` (the local canonical source for mode state)
+  - Whether question delegation (designer-questions) is needed is confirmed and recorded in `.intent/mode.local.md` (the purpose as well when on; if deferred, it is noted in Open Questions)
+  - Open Questions that the human should review are made explicit
+  - When drift-watch is on, terrain diagnosis is performed, the matching pattern is named, and it is recorded in drift-log (when off, nothing is done)
+  - When drift-watch is on, context-cost-cues are matched and ways of progressing that eat context are named in a noticing tone (recorded to no log; when off, nothing is done)
+  - No application code has been changed at all
+
+## Execution Steps
+
+### Step 1: Select the mode
+- Read and apply `rules/mode-selection.md`.
+- Check the available modes (`.intent/modes/*.md`) and recommend a mode based on the repository situation.
+- Confirm by asking the user in natural language and waiting for their answer (run the recommend→confirm wiring even if standard is the only candidate).
+- Record the confirmed result in `.intent/mode.local.md` (the local canonical source for mode state; not tracked by git). Enforcement / Drift-watch (shared policy) stay in `.intent/mode.md` and are not touched.
+- **Recommend → confirm → record the target format (optional, deferrable)**: after confirming the mode, when the target format (which exit to take = `cc-sdd` / `openspec` / `to-spec`) can be inferred from the case, ask the user to confirm it, and on confirmation record it in the `format` line of `.intent/mode.local.md`. The inference signals are the case type (mode; whether the artifact is code or a document; presence of `.kiro/` or a repository-root `openspec/`, etc.), and the format→exit correspondence is kept consistent with `intent-packets/rules/export-route.md` (the exit decision lane). Follow the **same confirmation discipline as mode / designer-questions / purpose**: if it cannot be inferred, or the user defers/declines, **do not fill it in by guessing — do not record it** (continue with it unspecified; the exit decision later falls back to inference). Recording the format is optional; discover continues as before even without it. **Only `/intent-discover` writes the format** (other skills read it read-only — DR26).
+- Read `rules/designer-questions.md` and confirm/record question delegation (designer-questions).
+
+### Step 2: Apply the algorithm according to the mode definition
+- Read the confirmed mode definition (e.g. `.intent/modes/standard.md`).
+- Open the mode definition that `.intent/mode.local.md`'s `definition` (falling back to the old `.intent/mode.md`) points to, and read and apply the algo rule (`rules/algo-*.md`) assigned to the Intent Tree construction phase (standard → `rules/algo-gore-lite.md`; refactor → `rules/algo-gore-lite.md` + `rules/algo-drift-analysis.md`, plus `rules/algo-intent-recovery.md` for intent-less code). The examples are not exhaustive; the mode definition's table is always authoritative.
+
+### Step 3: Build the Intent Tree
+- Following GORE-lite, decompose L0 (purpose) → L1 (outcomes) → L2 (capabilities) → L3 (behavior/architectural intent) → L4 (candidate packets).
+- Separate confirmed intent from guesses (Assumptions). Put anything undetermined into Open Questions.
+- If an existing `.intent/intent-tree.md` exists, read it and present additions/updates as a proposal rather than overwriting.
+
+### Step 3.5: Terrain Diagnosis (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 terrain diagnosis; continue to Step 4 as before (byte-identical to current behavior).
+- Only when it is `on`, read and apply `rules/drift-terrain.md`. The symptom × in-progress Intent Tree matching, the named presentation of matching patterns, drafting anti-direction / invariant candidates into Open Questions, and appending to drift-log are all delegated to the rule's procedure (do not duplicate the procedure here). Also apply the "Context cost cues" section at the end of that rule: match the types in `.intent/context-cost-cues.md` and name, in a noticing tone, ways of progressing that eat context (recorded to no log; skip if the catalog is absent).
+
+### Step 4: Present
+- Present the proposed update to `.intent/intent-tree.md`.
+- Apply the additional Intent Tree confirmations in `rules/designer-questions.md` (L1 measurement criteria / screen rough), following the rule's applicability conditions.
+- Do not make implementation changes. Do not jump ahead with refactoring proposals.
+
+## Output Description
+
+**Reader**: the human developer about to start pinning down intent.
+**What this output makes them grasp first**: "The skeleton of the Intent Tree is in place. **Next is `/intent-compass`.** The only Open Questions to answer before confirming are these."
+
+Lead with the conclusion.
+
+- **Next move (first, one line)**: `/intent-compass` (building the decision criteria; define the Invariants/Anti-direction that prevent local optima).
+- **Open Questions needing confirmation**: points the human must settle (left as questions rather than filled in by guessing). Framed so it is clear that clearing just these is enough before moving on.
+- **Details (proposed artifact updates)**: the proposed update to `.intent/intent-tree.md` (L0–L4 / Open Questions / Assumptions; canonical and inferred kept distinct), the confirmed mode (`.intent/mode.local.md`), and the confirmed designer-questions / purpose.
+
+## Safety & Fallback
+- If the input (problem / target scope) is ambiguous, do not fill in with guesses; ask the user in natural language and wait for their answer.
+- If an existing Intent Tree exists, do not destroy it; present the diff as a proposed update.
+- Do not change application code.

package/templates/en/codex/skills/intent-discover/rules/algo-drift-analysis.md

@@ -0,0 +1,34 @@
+# Algorithm: Drift Analysis
+
+Makes the gap (drift) between the current implementation/structure and the intended design observable. Used together with GORE-lite in the discover phase of `refactor` mode to surface, among L0–L4, the divergence between the current state and especially L3 (behavioral / design intent).
+
+## Procedure
+
+1. **Inventory the current state (input)**
+   - Grasp the target repository's structure, dependency direction, key behaviors, and whether tests exist. Exhaustiveness is not required, but **thicken the drift to a depth sufficient for the downstream Migration Slicing to cut practical slices** (a thin inventory yields a thin drift list and slices that become guesswork). Use a granularity that can be matched against intent as the guide.
+   - Keep at hand the implicit design intent (L1–L3 drawn out via GORE-lite). If the intended design cannot be recovered from the current state (the spec has been fully lost), `behavior-unknown` mode may fit better than refactor; if that signal surfaces during discover, note the mode reconsideration in Open Questions.
+
+2. **Match with a Reflexion worksheet**
+   - For the matching, use a lightweight worksheet borrowing the structure of Software Reflexion Models (Murphy & Notkin). Narrow the key components to **5–15 elements per analysis** (not broad and shallow — important spots, narrow and deep), and for each element lay out:
+     - **Intended responsibility / dependency** (from the Intent: the corresponding L1 Desired Outcome / L2 Capability / L3 Behavioral / Architectural Intent)
+     - **Observed responsibility / dependency** (from code reading: reading imports/references, directory structure, and call direction is sufficient) and its **evidence** (file / code location)
+   - Classify each element as **convergence (matches) / divergence (deviates) / absence (in the intent but not found in the implementation)**.
+   - This turns the drift list from "an enumeration of things that bother you" into a diff list defined in relation to the intent model.
+
+3. **Enumerate the drifts**
+   - Raise the worksheet's divergence / absence entries as drifts. Write each drift as a "current → intended" pair, attaching **diff kind (divergence / absence), evidence, and confidence (whether the evidence is direct or includes inference)**. Do not delve into speculative causes.
+   - As interpretation, distinguish the types: deviation (design that contradicts intent), decay (boundaries / dependencies that have eroded over time), and accumulated local optima (point optimizations that encroach on the overall intent).
+
+4. **Classify each drift under a parent intent**
+   - Identify "which Intent each drift deviates from" and tie it to the corresponding L1/L2/L3.
+   - Send any whose tied Intent is ambiguous or undetermined to Open Questions.
+
+## Discipline
+
+- **A planning technique, not execution**: capturing drift is the structuring of intent; do not perform refactoring or code changes here.
+- **Separate facts from guesses**: record the observed current state as fact, and separate conjecture about causes / response direction into `Assumptions`.
+- **Send undetermined items to Open Questions**: anything where you cannot judge which intent it deviates from, do not fill with guesses; write it into Open Questions.
+
+## Output
+
+A list of drifts (current → intended, diff kind and type of deviation, evidence and confidence, corresponding parent intent). Reflect them (present as a proposal) into the L3 and Open Questions / Assumptions of GORE-lite's `intent-tree.md`.

package/templates/en/codex/skills/intent-discover/rules/algo-gore-lite.md

@@ -0,0 +1,35 @@
+# Algorithm: GORE-lite
+
+A lightweight version of Goal-Oriented Requirements Engineering. It progressively decomposes implicit intent into an L0–L4 goal hierarchy. Used in the Intent Tree construction phase common to all modes (standard / refactor / behavior-unknown all build on this algo).
+
+## Procedure
+
+1. **L0: Fix the Product Purpose in 1–2 sentences**
+   - "What does this product/subsystem exist for". Write the reason for existing, not the means.
+
+2. **L1: Draw out the Desired Outcomes**
+   - To satisfy L0, whose state / what state do you want to change and how. Perspectives: user / business / operations / developer experience.
+   - Write in terms of "the state change you want to cause", not "features".
+   - **Actor pass**: for each Outcome, write one line each for "who benefits / who could block or oppose / who is responsible for realizing it / what environmental assumptions it depends on" (the actor/dependency perspective of the i* family). A goal hierarchy without actors misleads where responsibilities are placed at implementation time. Lines you are not confident about go to Assumptions.
+
+3. **L2: Decompose into Capabilities**
+   - List the capabilities that support each Desired Outcome. Write them as responsibilities/capabilities, not feature names.
+   - The unit of "able to do X". Do not delve into implementation means.
+
+4. **L3: Derive the Behavioral / Architectural Intents**
+   - The behavior / design intent that makes each Capability hold. Include boundaries, dependency direction, side effects, data consistency, and UI/UX constraints.
+   - This is the intent of "why this design", not the implementation itself.
+
+5. **L4: Produce the Candidate Packets**
+   - Candidate work units just before implementation. A granularity above an Issue and before a spec.
+   - Be mindful of which L1/L2/L3 each candidate supports (this becomes the parent intent at packet-ization time).
+
+## Discipline
+
+- **Do not mix canonical and inferred**: put confirmed intent in the body and separate guesses into the `Assumptions` section. Do not assert without grounds.
+- **Send undetermined items to Open Questions**: anything that requires a decision during decomposition but lacks the information, do not fill with guesses; write it into Open Questions.
+- **Do not change code**: discover is the structuring of intent, not implementation.
+
+## Output
+
+Update (present as a proposal) the `L0 / L1 / L2 / L3 / L4 / Open Questions / Assumptions` sections of `intent-tree.md`.

package/templates/en/codex/skills/intent-discover/rules/algo-impact-analysis.md

@@ -0,0 +1,37 @@
+# Algorithm: Impact Analysis
+
+Inventories, before implementation, which existing boundaries, contracts, and data flows a new feature touches. Used together with GORE-lite in the discover phase of `feature-growth` mode. It translates the idea of Change Impact Analysis (Bohner & Arnold) from tool-based dependency analysis into a planning technique based on LLM reading. Where Drift Analysis asks "what is the gap between the current state and the intent" (discover of refactor), Impact Analysis asks "what existing things does this addition touch" — the questions differ, so the two are not interchangeable.
+
+## Procedure
+
+Input = the new feature's intent (L1–L4 already structured via GORE-lite) and the existing codebase.
+
+1. **Identify the starting set**
+   - From the new feature's intent (especially L3/L4), list the starting points (modules, layers, APIs, data) in the existing codebase that it is likely to touch — the candidates the new feature will "read, call, or extend".
+   - Grasp the existing codebase's structure by LLM reading: reading imports/references, directory structure, and call direction is sufficient (do not assume AST analysis or static-analysis tooling).
+
+2. **Trace the ripple**
+   - From each starting point, follow "if this is touched, what else is affected" one step at a time along the dependency direction, widening the candidates (the CIA idea of a starting impact set → candidate impact set). Exhaustiveness is not required, but **thicken the impact list to a depth sufficient for the downstream Additive Slicing to design the seams** (a thin inventory turns the seams into guesswork).
+   - Attach **evidence** (file / code location) to each candidate. Treat ripples that cannot be confirmed by reading as conjecture and separate them into `Assumptions`.
+
+3. **Structure into the impact list**
+   - Raise the candidates as the impact list. Structure each item with the following three points:
+     - **Boundary touched**: module / layer / API
+     - **Existing contract depended on**: API signature, data schema, events, behavior
+     - **Kind of impact**: read / call / extend / requires change
+   - This structure becomes the downstream contract: in compass, each item is raised into a protective Invariant ("do not change X's existing contract"); in packets, Additive Slicing takes it as the input for seam design.
+   - If "requires change" dominates, that is a sign of redesign rather than addition — note a mode reconsideration (refactor) in Open Questions.
+
+4. **When you find drift, route it elsewhere**
+   - If, during the investigation, you discover a structural problem in the existing design (drift: decayed boundaries, dependencies contradicting the intent — problems outside feature-growth's purpose), **do not fix it within this mode**; record it in Open Questions and recommend separate work in `refactor` mode. Keep only the fact "the new feature touches it" in the impact list.
+
+## Discipline
+
+- **A planning technique, not execution**: inventorying impact is the structuring of intent; do not perform code changes or seam implementation here.
+- **Structural prohibition of drive-by refactoring**: even if you find drift, do not fix it within feature-growth. Send it to Open Questions + a refactor recommendation.
+- **Separate facts from guesses**: record impacts confirmed by reading as evidence-backed facts, and separate conjecture about unconfirmed ripples into `Assumptions`.
+- **Send undetermined items to Open Questions**: for boundaries where you cannot judge whether they are touched, do not fill with guesses; write them into Open Questions.
+
+## Output
+
+The impact list (each item: boundary touched / existing contract depended on / kind of impact, with evidence). It becomes the input for the Invariants in compass and for the seam design by Additive Slicing in packets. Reflect undetermined items and discovered drift (present as a proposal) into the Open Questions / Assumptions of `intent-tree.md`.

package/templates/en/codex/skills/intent-discover/rules/algo-intent-recovery.md

@@ -0,0 +1,39 @@
+# Algorithm: Intent Recovery
+
+A technique for recovering intent after the fact from existing code that was written without recording any intent (vibe coding). It sits between GORE-lite and Drift Analysis in the discover phase of `refactor` mode. Drift Analysis measures the gap between an intended design and the current state, but vibe-coded code lacks that baseline entirely. This technique back-derives candidate intent from the observable facts of the code and produces a baseline that Drift Analysis can consume.
+
+## When to use
+
+- The existing code was written without explicit design intent, spec, or design documentation (vibe coding, a prototype pushed into production, the legacy of someone who has left, etc.).
+- Even when you try to draw out L0–L3 with GORE-lite, the "how it should be" exists neither in anyone's head nor in documentation, and can only be drawn from the code.
+- The behavior itself is observable (so this is not a `behavior-unknown` case), but the **intent that produced that behavior is absent**.
+
+## Procedure
+
+Input = existing code whose intent is absent (structure, dependencies, key behaviors). Output = back-derived candidate intent (L0–L3, all inferred).
+
+1. **Back-derive candidate intent from the code**
+   - From the structure, dependency direction, key data flows, and recurring patterns, draw out "what this code appears to be trying to achieve" as L1 (outcomes) / L2 (capabilities) / L3 (behavior / design intent).
+   - This is a **conjecture** from the observed code, not the author's true intent.
+
+2. **Always place recovered intent as inferred**
+   - Place the back-derived L0–L3 not as canonical (confirmed) but as **inferred (guessed = Assumptions)**. In vibe coding, the distinction between "happened to write it this way" and "designed it this way" is not preserved in the code, so mixing it with the confirmed side falls into the trap of treating fabricated intent as fact.
+   - Note the basis for the recovery (which code observation it was drawn from) alongside each inferred intent.
+
+3. **Sort intentional vs. accidental, and send confirmation back to humans**
+   - For each recovered intent, sort whether it is "the result of a design decision" or "incidental / by happenstance". Do not finalize unjudgeable ones by guessing; send them to **Open Questions** and seek human confirmation.
+   - Only intent that a human has confirmed / endorsed may later be promoted to canonical.
+
+4. **Pass it to Drift Analysis as a baseline**
+   - Use the recovered (inferred) candidate intent as the "intended design" side of the input to the subsequent Drift Analysis. This lets Drift Analysis measure the drift of "recovered intent → current code".
+   - If the recovered intent is thin, the drift will be thin too, so draw out L1–L3 to a degree sufficient for Drift Analysis to produce a practical drift.
+
+## Discipline
+
+- **Recovery, not justification**: draw out intent from the fact that the code is written as it is; do not endorse "the existing code is correct". Raise even mistaken designs and unnecessary complexity as candidate intent, and handle them via Drift / Open Questions.
+- **Always inferred**: do not mix recovered intent with canonical. Do not promote it to confirmed without human endorsement (strictly observe GORE-lite's canonical/inferred separation).
+- **A planning technique, not execution**: do not change code here.
+
+## Output
+
+Back-derived candidate intent (L0–L3, all inferred, with recovery basis and intentional/accidental sorting). Reflect it (present as a proposal) into the corresponding L levels and the Assumptions / Open Questions of `intent-tree.md`, and use it as the input to Drift Analysis.

package/templates/en/codex/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/codex/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).