intent-planner 0.13.1 → 0.14.0

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "intent-planner",
-  "version": "0.13.1",
-  "description": "AI コーディングエージェント (Claude Code / Codex) に実装を頼む前に「何を作りたいか・何を守りたいか」を一緒に整理し、実装中も意図をブレさせない軽量 Intent Planning workflow。新規プロダクト開発から大規模リファクタ・レガシー改修まで、npx 一発で skill + scaffold を配置。",
+  "version": "0.14.0",
+  "description": "AI コーディングエージェント (Claude Code / Codex / Gemini CLI) に実装を頼む前に「何を作りたいか・何を守りたいか」を一緒に整理し、実装中も意図をブレさせない軽量 Intent Planning workflow。詰めた意図を kiro / cc-sdd / OpenSpec の spec フローへ橋渡しし、新規プロダクト開発から大規模リファクタ・レガシー改修まで、npx 一発で skill + scaffold を配置。",
   "type": "module",
   "author": "Yoshishige Tsuji <tsuji@coccole.biz>",
   "repository": {
@@ -23,7 +23,8 @@
     "LICENSE"
   ],
   "scripts": {
-    "test": "node --test"
+    "test": "node --test",
+    "prepublishOnly": "node scripts/publish-check.mjs"
   },
   "engines": {
     "node": ">=18.17"
@@ -32,6 +33,8 @@
     "claude",
     "claude-code",
     "codex",
+    "gemini",
+    "gemini-cli",
     "agent-skills",
     "intent",
     "intent-planning",
@@ -39,8 +42,9 @@
     "ai-coding-agent",
     "spec-driven-development",
     "cc-sdd",
-    "refactoring",
-    "greenfield"
+    "openspec",
+    "kiro",
+    "refactoring"
   ],
   "license": "MIT"
 }

package/templates/en/claude/skills/CONTRACT.md

@@ -65,6 +65,7 @@ Align to the cc-sdd style.
 - **Self-contained questions**: every question or confirmation addressed to the user must be a self-contained sentence that can be answered without knowing the terminology. When a term is used, include a one-line explanation inside the question text itself (e.g., "Confirm whether the first packet (unit of work) is a walking skeleton (a minimal implementation that runs end to end from input to output)").
 - **English terms + one-line explanations**: keep terms in English; do not replace them with translated coinages. When an explanation is needed, attach a one-line explanation that states the function or meaning (in parentheses or as a blockquote) at the first occurrence.
 - **Do not invent coined terms**: do not invent new coined terms that are absent from the canonical vocabulary (the ubiquitous language already in use across the intent deliverables); reuse an existing term. If you must introduce a new term, attach a one-line explanation at its first occurrence.
+- **Terms introduced in design docs must be identifiers; metaphor names in prose are written as plain descriptive words**: when introducing a term in design docs (SKILL.md / rules / convention docs / `.intent` deliverables), keep only cross-referenced identifiers (command names, frontmatter keys, file names, log values, glossary headings); do not coin metaphor names used only in prose (writer-coined words that do not even describe the function) — write them as plain descriptive words. Keep identifiers (deleting them breaks references) with a one-line explanation. Open metaphor names into plain language (so the reader can grasp the meaning without separately learning the word).
 
 ## State sharing across skills
 

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

@@ -38,4 +38,4 @@ This is a **supplement that does not replace** C2's derivation (the container th
 
 ## 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.
+- In discover's drift-prone-situation pre-check 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/claude/skills/intent-discover/SKILL.md

@@ -14,8 +14,8 @@ argument-hint: <problem / idea / target scope>
   - 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)
+  - When drift-watch is on, drift-prone-situation pre-check 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 non-directive, noticing way (recorded to no log; when off, nothing is done)
   - No application code has been changed at all
 
 ## Execution Steps
@@ -37,9 +37,9 @@ argument-hint: <problem / idea / target scope>
 - 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 3.5: Drift-Prone-Situation Pre-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 drift-prone-situation pre-check; 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 non-directive, noticing way, 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`.

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

@@ -1,24 +1,24 @@
 # 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 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 prone to drift," 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.
+- The drift-prone-situation pre-check **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.
+   - **When absent**: skip drift-prone-situation pre-check 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>`."
+   - **Name it explicitly** to the user. Example: "This subject is a situation 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>`
@@ -43,7 +43,7 @@ The symptom × in-progress Intent Tree matching logic used at Step 3.5 of `/inte
      - `user-verdict: unjudged`
      - `recorded_at: <ISO 8601>`
      - `commit: <short hash | ->`
-     - `note: <1-2 lines>` (that no type was present in the terrain)
+     - `note: <1-2 lines>` (that no type was present in the situation)
 
 ## The append procedure for drift-log
 
@@ -56,7 +56,7 @@ The symptom × in-progress Intent Tree matching logic used at Step 3.5 of `/inte
 
 ## 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**.
+Alongside drift-prone-situation pre-check, 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.**
@@ -71,7 +71,7 @@ Alongside terrain diagnosis, run a matching that makes you **notice** a way of p
    - 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."
+   - Name it to the user in a non-directive, noticing way. 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).
@@ -81,7 +81,7 @@ Alongside terrain diagnosis, run a matching that makes you **notice** a way of p
 
 ## 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**.
+Alongside drift-prone-situation pre-check, 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).
@@ -97,7 +97,7 @@ Alongside terrain diagnosis, perform a light match to give **early awareness** o
    - 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.
+   - Name it to the user in an non-directive, noticing way. 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.**
 

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

@@ -4,7 +4,7 @@ The matching logic used at Step 1.6 of `/intent-export-cc-sdd`: the target packe
 
 ## 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 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 drift-prone-situation pre-check 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).
 

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

@@ -4,7 +4,7 @@ The matching logic used at Step 1.6 of `/intent-export-openspec`: the target pac
 
 ## 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 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 drift-prone-situation pre-check 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).
 

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

@@ -16,7 +16,7 @@ argument-hint: <target scope (optional)>
   - When an unrecorded write-back learning is detected, the skill does not write a delta itself but prompts the user to run `/intent-writeback`
   - On a run whose 5 classifications include `Decision Rules update recommended` or `invariant violation detected`, following the provisions of `rules/improve-axes.md`, it also prompts the user to run `/intent-validate` (the check for conformance catch-up) (on a run that does not include them, it does not prompt; it only guides and does not itself make a conformance judgment)
   - When drift-watch is on, the coherence detections are recorded into drift-log as stage:improve / outcome:missed and a pattern×outcome improvement report is presented (when off / missing / invalid / missing section / missing mode.md, nothing is done; the 5 classifications are unchanged)
-  - 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, not included in the pattern×outcome tally, the 5 classifications unchanged; 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 non-directive, noticing way (recorded to no log, not included in the pattern×outcome tally, the 5 classifications unchanged; when off, nothing is done)
   - No application code has been changed at all
 
 ## Execution Steps
@@ -36,7 +36,7 @@ argument-hint: <target scope (optional)>
 - Classify the evaluation results into the 5 classifications (aligned / intent reinforcement recommended / corrective packet recommended / Decision Rules update recommended / invariant violation detected; multiple may apply) and present them organized per classification.
 - When unrecorded write-back learnings or declined items with the "on-hold" tag are detected, also include guidance to `/intent-writeback` following the provisions of `rules/improve-axes.md`.
 - On a run whose 5 classifications include `Decision Rules update recommended` or `invariant violation detected`, following the "Validate catch-up guidance" provisions of `rules/improve-axes.md`, also include guidance to `/intent-validate` (the check for conformance catch-up) alongside the writeback guidance (on a run that does not include them, do not include it; only guide and do not make the judgment yourself).
-- When drift-watch is on (when off / missing / invalid / missing section / missing mode.md, do nothing): check the `drift-watch` value in the `## Drift-watch (user-managed)` section of `.intent/mode.md`, and only when it is `on`, following the provisions of `rules/improve-axes.md`, record the drift detected on the coherence axis (invariant violation / anti-direction conflict) into `.intent/drift-log.md` as a `stage: improve` / `outcome: missed` draft, and present a `pattern × outcome` cross-tabulated improvement report. Delegate the recording details (the fixed 9-key order, append-only, obtaining commit, creating drift-log when absent) to `rules/improve-axes.md` (do not duplicate them here). This recording **does not create a new correction class** (the 5 classifications above are unchanged), and does not write into deltas.md or hook writeback. When off / missing / invalid / missing section / missing mode.md, do not record or aggregate drift and proceed as before (byte-equivalent to current behavior). Note that the report of the 5 classifications above is always done regardless of the drift-watch value. In addition, when `drift-watch: on`, following the "Context cost cues" section at the end of `rules/improve-axes.md`, match `.intent/context-cost-cues.md` and name, in a noticing tone, ways of progressing that eat context (**recorded to no log, not included in the pattern × outcome tally, and the 5 classifications stay unchanged**; skip if the catalog is absent).
+- When drift-watch is on (when off / missing / invalid / missing section / missing mode.md, do nothing): check the `drift-watch` value in the `## Drift-watch (user-managed)` section of `.intent/mode.md`, and only when it is `on`, following the provisions of `rules/improve-axes.md`, record the drift detected on the coherence axis (invariant violation / anti-direction conflict) into `.intent/drift-log.md` as a `stage: improve` / `outcome: missed` draft, and present a `pattern × outcome` cross-tabulated improvement report. Delegate the recording details (the fixed 9-key order, append-only, obtaining commit, creating drift-log when absent) to `rules/improve-axes.md` (do not duplicate them here). This recording **does not create a new correction class** (the 5 classifications above are unchanged), and does not write into deltas.md or hook writeback. When off / missing / invalid / missing section / missing mode.md, do not record or aggregate drift and proceed as before (byte-equivalent to current behavior). Note that the report of the 5 classifications above is always done regardless of the drift-watch value. In addition, when `drift-watch: on`, following the "Context cost cues" section at the end of `rules/improve-axes.md`, match `.intent/context-cost-cues.md` and name, in a non-directive, noticing way, ways of progressing that eat context (**recorded to no log, not included in the pattern × outcome tally, and the 5 classifications stay unchanged**; skip if the catalog is absent).
 
 ### Step 4: Confirm approval per proposal for the corrections
 - For each item that needs correction, present the correction proposal (a deliverable update proposal or a corrective packet proposal) and confirm the user's approval **per proposal** (do not force bulk approval).

package/templates/en/claude/skills/intent-improve/rules/improve-axes.md

@@ -112,7 +112,7 @@ Alongside the coherence-axis evaluation, run a matching that makes you **notice*
    - Use only the subject 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: "The way this realignment is proceeding may match `<id>` — this might be eating context."
+   - Name it to the user in a non-directive, noticing way. Example: "The way this realignment is proceeding 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 coherence-deviation append procedure or tally).

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

@@ -14,6 +14,11 @@ argument-hint: none
   - Orphan-spec check: when `.kiro/specs/` has a spec that is in progress / done yet cannot be text-matched to any packet under `active/` or any delta in `deltas.md`, it is reported in the details as "possible un-drafted implementation (suspected to have been implemented without going through a Packet)" (candidate presentation, not an assertion; non-matchability is the normal case so false positives are tolerated, and the next-move first-match is not taken away; this check is not performed in environments without `.kiro/specs/`)
   - intent-tree unfiled check (discover skip): when `.kiro/specs/` has a spec whose design/implementation has advanced yet it cannot be text-matched to any of the **L0–L4 headings and bodies** of `.intent/intent-tree.md` (intent-planner has no ID anchors such as O#/C#/B#/P#, so determination is by text matching only), it is reported in the details as "possible implementation not filed into intent-tree (discover skip)" (candidate presentation, not an assertion; non-matchability is the normal case so false positives are tolerated, and the next-move first-match is not taken away; this check is not performed in environments without `.intent/intent-tree.md` or without `.kiro/specs/`). This unfiled check (tree layer), the existing orphan-spec check (Packet layer), and writeback omission (downstream layer) are partitioned into three layers, and when one spec matches multiple layers it is presented only in the single most-upstream layer so that no double warning is emitted
   - A leading mini progress rail (all packets laid out vertically with the five signals ✅/🔵/⚪/🔴/◻, each row also carrying `[current stage → next stage(s) to pass through]`) is placed at the top of the report so that "which packet is 🔵 you are here now, which stages each will pass through next, and where the ⚪ remaining work / 🔴 unreflected items are" is visible at a glance. Internal terms (the matching procedure, the integrity check, enforcement terms) are pushed down into the details (later) rather than led with
+  - The default output is slimmed into three layers (default = you-are-here + the next move emphasized on one line + Candidate Packets count/names + a one-line Ice box notice / details = the folded position / option = only on a natural-language trigger), and the one-line summary of the next move is never folded and is always emphasized at a prominent leading position
+  - The "dangerous notices" (freshness warning, packets integrity violations, unreflected `🔴`) are **shown in full as bare glyphs in the actual-impact context** (never folded), and a one-line summary "`⚠` N present (see details)" is also left on the folded details side to prevent them from being missed. In the explanatory context (legend, glossary, 0-count summary, etc.), the warning signals are toned down to inline code / words rather than bare glyphs so a zero-impact status does not startle the reader (INV32)
+  - The L4 "future addition candidates" of `.intent/intent-tree.md` are read using Read/Glob/Grep only, cross-checked against `archive/` and `.kiro/specs/` with the same text-matching means as the existing checks (orphan-spec / unfiled-state), and the unconsumed (neither packeted nor implemented) candidates are presented as a permanent default display of count + names (frozen-marked ones excluded; non-matchability tolerates false positives without assertion; if L4/archive/specs are absent, treat as 0)
+  - Ice box candidates with a frozen mark (`Deferred` / `保留` / `当面しない` / conditional hold, etc.) are not shown in the body in the default; instead a one-line notice "Frozen (Ice box): N. Show them with 'show me the icebox'" is included, and on a natural-language trigger they are expanded as count + names + freeze reason (ambiguous-boundary ones go on the Candidate side; no assertion)
+  - Only the presentation (output composition) is changed; the first-match selection logic for the "next move" is not changed (which move to recommend is untouched)
   - Exactly one "next move" is recommended via the first-match of `rules/decision-table.md`, accompanied by the reason and the judgment basis (which state of which deliverable it rests on)
   - The recommendation candidates are selected from discover / compass / packets / export / validate / improve / writeback / "no action needed"
   - When the enforcement in mode.md is remind or gate, a freshness check via intent-check is performed, and on detecting a violation (`result=stale` on the judgment line, or `pending` of 1 or more) a freshness warning quoting the intent-check stdout is included alongside the current-position summary (when off, unstated, an invalid value, or not executable, no warning is shown, as before)
@@ -21,7 +26,7 @@ argument-hint: none
   - The section update dates of intent-compass.md (`Updated (Invariants):` / `Updated (Decision Rules):`) and the `updated_at` of the packets under active/ are cross-checked using Read/Glob/Grep only, and when the count of packets that are "not yet caught up after a compass update" reaches the threshold or more, `/intent-validate` is recommended as the right moment (decision table row 12), with its basis (which section was updated, how many are not caught up) included. It does not make a definitive diagnosis but stays at an estimate, and does not propose below the threshold (read-only preserved)
   - Each event in `.intent/milestones.md` is read using Read/Glob/Grep only, and any event for which neither "a `Updated (Decision Rules):` reflection stamp in compass" nor "a reference to the corresponding Decision in deltas" exists after the event's recorded time is grasped as an "unconsumed milestone (recorded but its corresponding revisit is unhandled)" and included as a residual in the current-position report (the same comparison shape as Step 3.6: lexicographic order of ISO 8601, only pairs where both ends are actually stamped; candidate presentation, not an assertion; when `.intent/milestones.md` is absent this check is omitted; read-only preserved)
   - No file has been created, modified, or deleted at all (read-only)
-  - Major terms in the output always carry a one-line plain-language explanation in the `term (explanation)` form
+  - Major terms in the output carry a one-line plain-language explanation in the `term (explanation)` form (two layers: lead = first occurrence / table headers only; details = every time; the glossary is kept and not abolished)
 
 ## Execution Steps
 
@@ -73,19 +78,32 @@ argument-hint: none
 - Never list multiple candidates side by side (the reason and basis are listed alongside). Even ambiguous cases where multiple recommendations seem visible are folded mechanically into one by the priority order of the decision table.
 
 ### Step 5: Report
-Structure the report in the order that gets the reader to "where am I, and what do I do next" by the shortest path. Do not lead with internal terms (the matching procedure, the integrity check, enforcement terms); push them down into the details from (3) onward.
+Structure the report in the order that gets the reader to "where am I, and what do I do next" by the shortest path, and slim down the default output. Compose the output in three layers — **default (never folded) / details (the folded position) / option (only on a natural-language trigger)**. The default carries only the essentials ((1)–(4)) and the "dangerous notices"; push internal terms (the matching procedure, the integrity check, enforcement terms) and check details down into (5) details.
+
+**[Default] essentials that are never folded**
 
 - (1) **Progress rail (leading mini-rail)**: lay out all packets vertically and assign each one of the five signals (✅ reflected / 🔵 you are here / ⚪ not started / 🔴 unreflected / ◻ merged), **followed by `[current stage → next stage(s) to pass through]`**. Both the signal determination and the stage annotation follow the same discipline as overview's `progress-readout.md` "Progress rail" (the five signals cross-check `state` × whether export-log has a row × whether deltas has a corresponding entry via first-match; the stage annotation re-reads packet `state` as a position on the fixed pipeline `discover→compass→packets→export→implement→verify→writeback`; neither computes nor infers). Examples: `P2  🔵 you are here [implementing → next: verify→writeback]` / `P3  ⚪ not started [ready → next: export→implement]`. This makes **"which P is you-are-here now, which stages remain after this, and where the ⚪ remaining work / 🔴 unreflected items are" visible at a glance on a single sheet**. Annotate each signal's meaning per the glossary. The rail is a read-only mirror; status changes nothing.
-- (2) **The next move (exactly one, one line)**: present the skill name or "no action needed" **on one line** first, then append the recommendation reason + judgment basis (which state of which deliverable it rests on) concisely. Translate the first-match result of the decision table (`rules/decision-table.md`) into **the action a human takes next**, not into the internal row number.
-- (3) **Details (the folded position)**: each deliverable's present/absent/unfilled state and notable points that back the signals in (1); the current Source Packet (the packet name based on the latest row of export-log) and whether its directory (`.intent/cc-sdd/<slug>/`) exists. When packets integrity violations were detected (index ↔ active/ divergence, lingering done / superseded_by, the latest export-log row's packet absent from active/), include their content; when index.md is absent, include the regeneration prompt; when a violation was detected in Step 3, include the freshness warning quoting the intent-check stdout; when drift-watch is `on` in Step 3.5, include the drift-log light tally (`caught N / missed N / false-positive N / unjudged N`) as one block at the same position and temperature as the freshness warning; when conformance staleness's right moment (the not-caught-up count at or above the threshold) was detected in Step 3.6, include the basis "which compass section was updated, and how many packets are not caught up" at the same position and temperature as the freshness warning. When an intent-tree unfiled state (a suspected discover skip) was detected in Step 2, include one block with its spec name and the guidance "Design/implementation has advanced, but it could not be text-matched to any L0–L4 node of `.intent/intent-tree.md`. The discover phase itself may have been skipped. File it into intent-tree (L0–L4) via `/intent-discover`, then raise a Packet with `/intent-packets`, and return the implementation reality to canonical via `/intent-writeback` — that is the order", at the candidate-presentation temperature that avoids assertion (it does not change the decision-table result for the next move). When an orphan spec (a suspected un-drafted implementation) was detected in Step 2, include one block with its spec name and the guidance "This may have been implemented without going through a Packet. Even after the fact, raise a Packet with `/intent-packets` (making the unfixed spec explicit as Open Questions / Deferred), then return the implementation reality to canonical via `/intent-writeback` — that is the order", at the candidate-presentation temperature that avoids assertion (it does not change the decision-table result for the next move). **These two checks and the writeback omission (the freshness warning) are partitioned from upstream into three layers — tree layer → Packet layer → downstream layer — and when one spec matches multiple layers it is presented only in the single most-upstream layer so that no double warning is emitted** (do not re-emit a spec that matched upstream in the downstream orphan-spec / freshness warning; guide it as a staged remedy of `discover → packets → writeback`). When an unconsumed milestone (a milestone event recorded but whose corresponding revisit is unhandled) was detected in Step 3.7, include one block with its event name and the guidance "A milestone event is recorded, but the corresponding Decision revisit (Revisit reflection) may not yet have been consumed. Check the `Revisit when` matching / re-proposal for the corresponding Decision Rule via `/intent-improve` — that is the order", at the same position and temperature as the freshness warning (the candidate-presentation temperature that avoids assertion; it does not change the decision-table result for the next move).
-- (4) Open Questions: points that need user confirmation. Confirmation stays at presenting candidates in natural language, leaving the next-action decision to the user (one-way reporting).
+- (2) **The next move (exactly one, one line, always emphasized)**: present the skill name or "no action needed" **as a one-line summary** at a prominent leading position (**even when the default is slimmed down, this one line is never folded and is always shown**), then append the recommendation reason + judgment basis (which state of which deliverable it rests on) concisely. Translate the first-match result of the decision table (`rules/decision-table.md`) into **the action a human takes next**, not into the internal row number (**only the presentation changes; the first-match selection logic for which move to recommend is not changed**).
+- (3) **Candidate Packets (the pool of not-yet-packeted candidates)**: read the L4 "future addition candidates" of `.intent/intent-tree.md` with **Read / Glob / Grep only**, cross-check against `.intent/packets/archive/` and `.kiro/specs/` with the same text-matching means as the Step 2 orphan-spec / unfiled-state checks, narrow to the **unconsumed (neither packeted nor implemented) candidates**, and present them in the default as a bulleted list of **count + names**. Treat unmatchable cases as the norm, tolerate false positives, and stay at candidate presentation without assertion. **Candidates with a frozen mark (the Ice box below) are excluded from the count + names**. If L4 / archive / `.kiro/specs/` is absent, treat it as 0 and do not error.
+- (4) **Ice box notice (one line announcing the existence of frozen candidates)**: frozen candidates text-matched with **Read / Grep only** against frozen marks (`Deferred` / `保留` / `当面しない` / conditional hold, etc.) **are not shown in the body in the default**; instead, always include the one-line notice **"Frozen (Ice box): N. Show them with 'show me the icebox'"** in the default (if 0, omit the notice too to make the lead even lighter). Candidates with an ambiguous boundary (no mark but effectively shelved) are not treated as frozen and are shown on the (3) Candidate side (no assertion).
+- ⊕ **Dangerous notices (always shown in full in the default, never folded)**: the three kinds — **freshness warning (Step 3), packets integrity violations (index ↔ active/ divergence, lingering done / superseded_by, the latest export-log row's packet absent from active/), and unreflected 🔴** — are dangerous to miss, so **keep them shown in full in the default and do not fold them into (5) details**. When enforcement / drift-watch is off or unset, no freshness warning is emitted as before (existing behavior unchanged). **Warning-signal display split (INV32)**: here (the actual-impact context) `🔴` etc. are **emphasized as bare glyphs**, but in the explanatory context (legend, glossary, 0-count summary, empty rail) they are **not bare — toned down to inline code (`🔴`) / words ("unreflected")**. When the count is 0, show "no unreflected items" in words and emit no bare warning glyph (the warning's meaning is preserved).
+
+**[Details] pushed down to the folded position**
+
+- (5) **Details (the folded position)**: each deliverable's present/absent/unfilled state and notable points that back the signals in (1); the current Source Packet (the packet name based on the latest row of export-log) and whether its directory (`.intent/cc-sdd/<slug>/`) exists. The dangerous notices shown in the default at ⊕ also leave **a one-line summary "⚠ N present (see details)"** here to connect to the detail body (without removing them from the default). When index.md is absent, include the regeneration prompt; when drift-watch is `on` in Step 3.5, include the drift-log light tally (`caught N / missed N / false-positive N / unjudged N`) as one block here; when conformance staleness's right moment (the not-caught-up count at or above the threshold) was detected in Step 3.6, include the basis "which compass section was updated, and how many packets are not caught up" here. When an intent-tree unfiled state (a suspected discover skip) was detected in Step 2, include one block with its spec name and the guidance "Design/implementation has advanced, but it could not be text-matched to any L0–L4 node of `.intent/intent-tree.md`. The discover phase itself may have been skipped. File it into intent-tree (L0–L4) via `/intent-discover`, then raise a Packet with `/intent-packets`, and return the implementation reality to canonical via `/intent-writeback` — that is the order", at the candidate-presentation temperature that avoids assertion (it does not change the decision-table result for the next move). When an orphan spec (a suspected un-drafted implementation) was detected in Step 2, include one block with its spec name and the guidance "This may have been implemented without going through a Packet. Even after the fact, raise a Packet with `/intent-packets` (making the unfixed spec explicit as Open Questions / Deferred), then return the implementation reality to canonical via `/intent-writeback` — that is the order", at the candidate-presentation temperature that avoids assertion (it does not change the decision-table result for the next move). **These two checks and the writeback omission (the freshness warning) are partitioned from upstream into three layers — tree layer → Packet layer → downstream layer — and when one spec matches multiple layers it is presented only in the single most-upstream layer so that no double warning is emitted** (do not re-emit a spec that matched upstream in the downstream orphan-spec / freshness warning; guide it as a staged remedy of `discover → packets → writeback`). When an unconsumed milestone (a milestone event recorded but whose corresponding revisit is unhandled) was detected in Step 3.7, include one block with its event name and the guidance "A milestone event is recorded, but the corresponding Decision revisit (Revisit reflection) may not yet have been consumed. Check the `Revisit when` matching / re-proposal for the corresponding Decision Rule via `/intent-improve` — that is the order", at the same position and temperature as the freshness warning (the candidate-presentation temperature that avoids assertion; it does not change the decision-table result for the next move).
+- (6) Open Questions: points that need user confirmation. Confirmation stays at presenting candidates in natural language, leaving the next-action decision to the user (one-way reporting).
+
+**[Option] only on a natural-language trigger**
+
+- (7) **Ice box expansion**: only when the user requests via a natural-language trigger ("show me the icebox", etc.), expand the frozen candidates of (4) as **count + names + a short note of the freeze reason**. The expansion is also read-only with Read / Grep only; status changes nothing.
+
 - **Unset-or-absent display**: when a deliverable is unset or absent, show it in the `term (explanation): state` form — e.g. `Intent Tree (the hierarchical map of what you want to do): not created` — in plain English so that a reader who does not know the term can tell that the deliverable **does not yet exist / has no content**. Consistency-check violations (a stuck `superseded_by`, divergence from the index, an item remaining in archive, etc.) are shown the same way: annotate the term with its explanation and present in plain English **what is stuck / diverging and how**.
 
 ## Always-annotate rule for terms
 
-The terms that appear in the output are annotated with their meaning in the `term (explanation)` parenthetical form, by referring to the "Glossary" below. The concrete conventions are as follows.
+The terms that appear in the output are annotated with their meaning in the `term (explanation)` parenthetical form, by referring to the "Glossary" below. The annotation is **split into two layers — the lead (default) and the details (the folded position)**. The concrete conventions are as follows.
 
-- **Always-annotate rule**: the intent-planner-specific terms that appear in status output (deliverable names, state values, check terms, command names) are **kept in English as the canonical form and are never replaced by a translation**. Each term is annotated with a short plain-language explanation of its meaning, written in the `term (explanation)` parenthetical form. The annotation is **not limited to the first occurrence** — it is repeated every time the term appears in the output (status output is a fragmentary report whose visible items vary with the situation, so "first occurrence" is not stable; the priority is that the meaning is clear on the spot, every time).
+- **Two-layer annotation rule (lead = first occurrence / headers only; details = every time)**: the intent-planner-specific terms that appear in status output (deliverable names, state values, check terms, command names) are **kept in English as the canonical form and are never replaced by a translation**. Each term is annotated with a short plain-language explanation of its meaning, written in the `term (explanation)` parenthetical form. The annotation density is split by output layer: **in the lead (the slimmed-down default essentials), the annotation is limited to the first occurrence and table headers only** (to avoid lead redundancy and not bury "the next move"). **In the details (the folded position), the term is annotated every time it appears** (the details are a fragmentary report whose visible items vary with the situation, so "first occurrence" is not stable; the priority is that the meaning is clear on the spot, every time). The glossary itself is kept and the annotation is not abolished (the status-readability value of "readable even without knowing the term" is preserved on the details side).
 - **Avoiding redundancy in practice**: even when the same term recurs within a single output and full annotation would be redundant, no item is **left as the bare term**. In list / table item headers, keep the parenthetical annotation; in repeated in-prose mentions, the form may be tightened as long as the meaning remains traceable from context. When tightening the form, the condition is that the term's meaning stays traceable.
 
 ### Glossary
@@ -114,13 +132,15 @@ The terms that status refers to when producing output, with a one-line explanati
 
 **Progress rail (5 signals + stage annotation)** (cross-check a packet by `state` × whether export-log has a row × whether deltas has a corresponding entry, and assign one via first-match. Further, annotate each row with `[current stage → next stage(s) to pass through]`, re-reading packet `state` as a position on the fixed pipeline `discover→compass→packets→export→implement→verify→writeback`. The canonical determination lives in overview's `progress-readout.md` "Progress rail," not in `rules/decision-table.md`, but status's leading mini-rail uses the same five-signal vocabulary + stage annotation)
 
+> The signals in the legend are toned down to inline code (do not line up bare warning colors in the explanatory context = INV32). In the actual-impact context where a matching packet exists, they are shown in full as bare glyphs per INV31.
+
 | Signal | One-line explanation |
 |--------|----------------------|
-| ✅ reflected | implementation complete and written back into intent (`state: done` and a corresponding delta is promoted/closed) |
-| 🔵 you are here | the one stage currently being worked on (of the exported-not-yet-reflected, the current Source Packet = the latest export-log row) |
-| 🔴 unreflected | evidence of implementation exists but not yet reflected (of the exported-not-yet-reflected, those other than the current Source Packet = past leftovers) |
-| ⚪ not started | not yet exported to cc-sdd (no row in export-log) |
-| ◻ merged | merged into a successor packet and done with its role (`superseded_by` is non-empty) |
+| `✅` reflected | implementation complete and written back into intent (`state: done` and a corresponding delta is promoted/closed) |
+| `🔵` you are here | the one stage currently being worked on (of the exported-not-yet-reflected, the current Source Packet = the latest export-log row) |
+| `🔴` unreflected | evidence of implementation exists but not yet reflected (of the exported-not-yet-reflected, those other than the current Source Packet = past leftovers) |
+| `⚪` not started | not yet exported to cc-sdd (no row in export-log) |
+| `◻` merged | merged into a successor packet and done with its role (`superseded_by` is non-empty) |
 
 **Replacement axis**
 
@@ -154,12 +174,16 @@ The terms that status refers to when producing output, with a one-line explanati
 ## Output Description
 
 **Reader**: a human developer who wants to know, by the shortest path, "where am I now and what should I do next".
-**What this makes them grasp first**: (1) from the progress rail, "which packet is 🔵 you are here, and which stages remain after this", then (2) "exactly one next move". Internal terms (the matching, the integrity check, enforcement) are relegated to the details that follow. Compose the output in the order of Step 5 ((1) progress rail → (2) the next move → (3) details → (4) Open Questions).
-
-- (1) **Progress rail** (top, conclusion): lay out all packets vertically and annotate each row with the five signals + `[current stage → next stage(s) to pass through]` (the ⚪ remaining work and 🔴 unreflected items visible at a glance)
-- (2) **Exactly one next move** (with the recommendation reason and judgment basis)
-- (3) **Details**: the summary of the current position (existence and fill state per deliverable + notable points; includes the current Source Packet and whether its packet directory exists; when an enforcement violation is detected, includes the freshness warning quoting the intent-check stdout; when drift-watch is `on`, includes the drift-log light tally `caught N / missed N / false-positive N / unjudged N` as one block, and when it is not `on`, includes no such block; when conformance staleness's right moment (Step 3.6) is detected, includes the not-caught-up basis as one block, and when below the threshold, includes no such block). Also place here the result of the packets integrity check (the report of index ↔ active/ divergence, lingering done / superseded_by, and the latest export-log row's packet absent from active/; includes the regeneration prompt when the index is absent).
-- (4) Open Questions for a human to confirm
+**What this makes them grasp first**: slim down the default and present (1) from the progress rail, "which packet is 🔵 you are here, and which stages remain after this", then (2) "exactly one next move (one-line summary, never folded, always emphasized)", (3) Candidate Packets (the count + names of not-yet-packeted candidates), (4) a one-line Ice box notice. The "dangerous notices" (freshness warning, integrity violations, unreflected 🔴) are kept in full in the default. Internal terms (the matching, the integrity check, enforcement), check details, and the every-time term annotation are relegated to (5) details (the folded position) that follow. Compose the output in the three layers of Step 5 (default (1)–(4) + ⊕ dangerous notices → (5) details → (6) Open Questions → (7) Ice box expansion only on a trigger).
+
+- (1) **Progress rail** (default, conclusion): lay out all packets vertically and annotate each row with the five signals + `[current stage → next stage(s) to pass through]` (the `⚪` remaining work and `🔴` unreflected items visible at a glance; rows with an actual matching packet show bare glyphs)
+- (2) **Exactly one next move** (default, the one-line summary never folded and always emphasized, with the recommendation reason and judgment basis; only the presentation changes, the first-match selection logic is unchanged)
+- (3) **Candidate Packets** (default, count + names; the L4 unconsumed candidates read read-only; frozen-marked ones excluded; no assertion)
+- (4) **Ice box notice** (default, one line "Frozen (Ice box): N. Show them with 'show me the icebox'"; omitted if 0)
+- ⊕ **Dangerous notices** (kept in full in the default, never folded): freshness warning (quoting the intent-check stdout when an enforcement violation is detected), packets integrity violations (index ↔ active/ divergence, lingering done / superseded_by, the latest export-log row's packet absent from active/), unreflected 🔴
+- (5) **Details** (the folded position): the summary of the current position (existence and fill state per deliverable + notable points; includes the current Source Packet and whether its packet directory exists). The dangerous notices shown in the default at ⊕ also leave a one-line summary "⚠ N present (see details)" here. When drift-watch is `on`, includes the drift-log light tally `caught N / missed N / false-positive N / unjudged N` as one block, and when it is not `on`, includes no such block; when conformance staleness's right moment (Step 3.6) is detected, includes the not-caught-up basis as one block, and when below the threshold, includes no such block; includes the regeneration prompt when the index is absent.
+- (6) Open Questions for a human to confirm
+- (7) **Ice box expansion** (option, only on a natural-language trigger): expand the frozen candidates as count + names + a short note of the freeze reason
 
 ## Safety & Fallback
 - **Read-only declaration**: never create, modify, or delete any file (the frontmatter does not carry Write; Bash is limited to launching the read-only script `node .intent/scripts/intent-check.mjs` and does not change this property). drift-log is read via Read / Grep only (without widening what Bash launches and without writing to drift-log), and this read-only property is not changed.

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

@@ -28,7 +28,7 @@ argument-hint: <target packet name (optional)>
 
 ### Step 2: Extract and present the learnings
 - Cross-check the implementation reality (the codebase, tests, and `.kiro/specs/`; all read-only) against the packet definition (the target packet file), the cc-sdd drafts, and intent-compass.md.
-- Extract learnings via the 5 perspectives of the rules ([decision] / [invariant-violation] / [implicit-behavior] / [deferred-resolved] / [question]) and present them as a tagged list.
+- Extract learnings via the 5 perspectives of the rules ([decision] / [invariant-violation] / [implicit-behavior] / [deferred-resolved] / [question]) and present them as a tagged list. Show each learning as `[tag] <a plain one-sentence summary (REQUIRED)>` (a plain sentence an approver can read directly and grasp), adding an optional `解説 (note):` only when background, rationale, or implications are needed (the note is not required; a summary-only learning is the normal form; see rules §2/§9).
 
 ### Step 3: Record the delta (canonical untouched)
 - Record the extracted learnings into `.intent/deltas.md` as a new entry (Status: pending).
@@ -36,7 +36,7 @@ argument-hint: <target packet name (optional)>
 - At this stage, do not edit the canonical deliverables (intent-tree.md / intent-compass.md / the files under `.intent/packets/`) at all.
 
 ### Step 4: Confirm promotion (vary the approval granularity)
-- Vary the approval granularity by the kind of learning (rules §3 Stage 2). Do not ask about every item uniformly, one at a time.
+- Vary the approval granularity by the kind of learning (rules §3 Stage 2). Do not ask about every item uniformly, one at a time. The primary information for approval is each learning's plain one-sentence summary; the note is secondary, supplied only when needed.
 - **Gated items** (`[invariant-violation]` and `[decision]` that changes Decision Rules) are confirmed item by item.
 - **Everything else** (L3-append kind and `[question]` transcription) is presented as a list of reflection targets; ask whether there is any item to hold back, and promote in bulk if none is named.
 - For items held back (not approved), confirm one of "rejected (no re-proposal) | on-hold (re-propose at the next writeback)".
@@ -59,7 +59,7 @@ Lead the output with the conclusion (the promotion result and the completion pro
 - **Promotion result (top)**: what was promoted to canonical (intent-tree / intent-compass / packets), with reflection-target details. Show the deferred items distinguished by their declined tag "rejected (no re-proposal) / on-hold (re-propose next time)".
 - **Completion processing result (next)**: the target packet's `state: done` / `closed_at` / `spec_refs` entries, the move to `archive/<year>/`, and the index.md regeneration. Phrased so it is clear that "this packet is now closed".
 - **Promotion proposals** (if shown at the stage that asks for approval): gated items (invariant violations / Decision Rules changes) confirmed item by item; the L3-append kind presented as a list + naming the items to hold back.
-- **Details**: the list of extracted learnings (tagged with the 5 perspectives [decision]/[invariant-violation]/[implicit-behavior]/[deferred-resolved]/[question]) and the delta recording result (the entry in deltas.md).
+- **Details**: the list of extracted learnings (tagged with the 5 perspectives [decision]/[invariant-violation]/[implicit-behavior]/[deferred-resolved]/[question]; each line leads with its plain one-sentence summary and adds an optional note only when needed) and the delta recording result (the entry in deltas.md).
 
 ## Safety & Fallback
 - If the target packet cannot be identified, present the situation, ask the user to specify the write-back target, and stop.

package/templates/en/claude/skills/intent-writeback/rules/writeback-protocol.md

@@ -21,6 +21,8 @@ If the target still cannot be identified, present the situation (that it was not
 
 Cross-check the target packet's definition (the target packet file), the cc-sdd drafts (including the Intent-derived constraints), and intent-compass.md against the implementation reality (the codebase, tests, and `.kiro/specs/`; all read-only), and extract learnings from the following 5 perspectives. Tags map 1:1 to the perspectives. When reading the implementation reality, also include in the grep cross-check scope the code modules (file names, module names) named by Decision Rules (intent-compass.md), and you may extract a divergence between a Rule's main text and the implementation as an `[invariant-violation]`.
 
+Write each extracted learning as `[tag] <a plain one-sentence summary (REQUIRED)>`. The summary should be a plain sentence an approver who did not implement the packet can read directly and grasp — not a jargon-compressed noun phrase — even if it runs a little long for the sake of clarity. Only when background, rationale, or implications are needed, add an indented `  - 解説 (note): <…>` sub-line optionally below it (the note is not required; a summary-only learning is the normal form). This is the same format as the canonical deltas.md template in §9, and a learning extracted here is recorded into §9 in that very format.
+
 | Tag | Perspective |
 |------|------|
 | `[decision]` | A new decision (a judgment made during implementation that is not written in the packet definition) |
@@ -126,11 +128,15 @@ The following is **the source of truth** of the canonical deltas.md template; th
 
 ### Learnings
 
-- [decision] <a new decision>
-- [invariant-violation] <a discovered invariant violation>
-- [implicit-behavior] <implicit behavior not written in the intent>
-- [deferred-resolved] <a resolved Deferred>
-- [question] <a new unresolved Question>
+Write each learning as `[tag] <a plain one-sentence summary (REQUIRED)>`. The summary should be a plain sentence an approver can read directly and grasp — not a jargon-compressed noun phrase — even if it runs a little long for the sake of clarity. Only when background, rationale, or implications are needed, add an indented `  - 解説 (note): <…>` sub-line **optionally** below it (the note is not required; a summary-only learning is the normal form).
+
+- [decision] <a decision made during implementation that wasn't in the packet definition, in plain words>
+  - 解説 (note): <why this decision was reached — background or rationale (optional; omit if unneeded)>
+- [invariant-violation] <where an existing Invariant conflicts with the implementation reality, in plain words>
+  - 解説 (note): <which Invariant conflicts and how, and the intended response (optional)>
+- [implicit-behavior] <behavior not written in the intent that the implementation already exhibits, in plain words (usually summary-only)>
+- [deferred-resolved] <how a previously deferred item was resolved, in plain words>
+- [question] <a newly surfaced unresolved question, in plain words>
 
 ### Promotion record (when promoted / closed)
 

package/templates/en/codex/skills/CONTRACT.md

@@ -56,6 +56,7 @@ Align to the cc-sdd style.
 - **Self-contained questions**: every question or confirmation addressed to the user must be a self-contained sentence that can be answered without knowing the terminology. When a term is used, include a one-line explanation inside the question text itself (e.g., "Confirm with the user whether the first packet (unit of work) is a walking skeleton (a minimal implementation that runs end to end from input to output)").
 - **English terms + one-line explanations**: keep terms in English; do not replace them with translated coinages. When an explanation is needed, attach a one-line explanation that states the function or meaning (in parentheses or as a blockquote) at the first occurrence.
 - **Do not invent coined terms**: do not invent new coined terms that are absent from the canonical vocabulary (the ubiquitous language already in use across the intent deliverables); reuse an existing term. If you must introduce a new term, attach a one-line explanation at its first occurrence.
+- **Terms introduced in design docs must be identifiers; metaphor names in prose are written as plain descriptive words**: when introducing a term in design docs (SKILL.md / rules / convention docs / `.intent` deliverables), keep only cross-referenced identifiers (command names, frontmatter keys, file names, log values, glossary headings); do not coin metaphor names used only in prose (writer-coined words that do not even describe the function) — write them as plain descriptive words. Keep identifiers (deleting them breaks references) with a one-line explanation. Open metaphor names into plain language (so the reader can grasp the meaning without separately learning the word).
 
 ## State sharing across skills
 

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

@@ -38,4 +38,4 @@ This is a **supplement that does not replace** C2's derivation (the container th
 
 ## 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.
+- In discover's drift-prone-situation pre-check 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

@@ -11,8 +11,8 @@ description: The entry point of Intent Planning. From the repository's pain poin
   - 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)
+  - When drift-watch is on, drift-prone-situation pre-check 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 non-directive, noticing way (recorded to no log; when off, nothing is done)
   - No application code has been changed at all
 
 ## Execution Steps
@@ -34,9 +34,9 @@ description: The entry point of Intent Planning. From the repository's pain poin
 - 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 3.5: Drift-Prone-Situation Pre-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 drift-prone-situation pre-check; 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 non-directive, noticing way, 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`.

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

@@ -1,24 +1,24 @@
 # 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 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 prone to drift," 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.
+- The drift-prone-situation pre-check **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.
+   - **When absent**: skip drift-prone-situation pre-check 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>`."
+   - **Name it explicitly** to the user. Example: "This subject is a situation 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>`
@@ -43,7 +43,7 @@ The symptom × in-progress Intent Tree matching logic used at Step 3.5 of `/inte
      - `user-verdict: unjudged`
      - `recorded_at: <ISO 8601>`
      - `commit: <short hash | ->`
-     - `note: <1-2 lines>` (that no type was present in the terrain)
+     - `note: <1-2 lines>` (that no type was present in the situation)
 
 ## The append procedure for drift-log
 
@@ -56,7 +56,7 @@ The symptom × in-progress Intent Tree matching logic used at Step 3.5 of `/inte
 
 ## 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**.
+Alongside drift-prone-situation pre-check, 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.**
@@ -71,7 +71,7 @@ Alongside terrain diagnosis, run a matching that makes you **notice** a way of p
    - 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."
+   - Name it to the user in a non-directive, noticing way. 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).
@@ -81,7 +81,7 @@ Alongside terrain diagnosis, run a matching that makes you **notice** a way of p
 
 ## 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**.
+Alongside drift-prone-situation pre-check, 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).
@@ -97,7 +97,7 @@ Alongside terrain diagnosis, perform a light match to give **early awareness** o
    - 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.
+   - Name it to the user in an non-directive, noticing way. 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.**