intent-compass

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.
disable-model-invocation	true
allowed-tools	Read, Write, Glob, Grep, AskUserQuestion, Bash
argument-hint	<focus of this change (optional)>

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. Read the skeleton (L0–L4) from the body; read case records (機能追記/機能撤去/履歴/再起案) via the split store .intent/tree/ — index.md → the relevant <feature>.md — if it exists, otherwise from the legacy form at the body tail (permanent fallback; tree-normalize / DR133).
• 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 the mode state in order: the inherited issue directory's discovery/<slug>-<rand>/mode.md (A34; inherit the issue name that discover output) → else the single .intent/mode.local.md (legacy) → else old .intent/mode.md (the CONTRACT.md read fallback contract). 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. If the split store .intent/compass/ (one symbol = one file; INV80) has the symbol, read index.md → that file's ## Law first; for symbols not in the store, read the legacy body as before (the legacy path is a permanent fallback = DR133).

Step 1.1: Check important decisions at the Compass entry

• Check at the compass entry. Find every important decision carried over from discover in the Open Questions for the affected scope, then present its answer proposal and stop scope under the shared contract (../CONTRACT.md).
• Even if the discover exit check was completed, do not skip this entry check. Moving an item to an Open Question alone does not release the stop on an important decision.
• Until an allowed outcome is obtained, do not start Compass construction for the affected scope. Work outside that stop scope may continue.
• After resolution, recheck the affected artifacts and resume only the scope supported by the evidence.

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 Bash 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 at a granularity ready for specification or direct implementation).
• 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. In a repo that has the split store .intent/compass/, draft new symbols (INV/DR/Anti) as new files in the store (creating the file = the numbering declaration; DR131) and regenerate index.md on completion (without the store, write into the body as before; DR133). When tagging a new symbol with a domain tag (area: / [領域: <name>]), and in a repo that has .intent/domains/, read and apply rules/domain-write.md (derive the area from the case context and confirm it in one question; do not silently default to always; if the domain being written has an owner declaration from another session, add a read-only one-line note = do not stop; INV91/INV101. Behave as before when domains is absent). When always (cross-cutting) is about to be chosen, then read and apply rules/always-gate.md (the single-question confirmation for always registration; confirm in one question whether it truly affects all domains; do not make it a double question with domain-write's area confirmation; not a gate).

Plainness check for reports (user-facing reports; right before output; shared)

Right before emitting a user-facing report (progress, completion, items needing confirmation — including the end-of-turn summary), run this check (INV105, DR208). It applies only to user-facing report text, not to how internal records (canonical files and logs under .intent/) are written.

• Do not transcribe internal documents verbatim: text you just read or wrote in internal artifacts (tree, compass, packets, Open Questions) is written in internal vocabulary. In the report, restate that content in words a first-time reader understands (without changing facts or meaning).
• Identifiers must not be the subject of the sentence: when presenting an item to confirm or a unit of work, first write one sentence that stands on its own ("what and why"), then append identifiers (Open Question numbers, packet names, symbols, stage names) after it as references (e.g. "... please verify this before starting (ref: OQ-xxx-1)"). Do not delete identifiers or references to records for the sake of plainness (the trail back to the record is lost).
• Signal for overload: three or more unexplained internal terms in one sentence signal overload (read by meaning, not by mechanical count). If a sentence does not stand on its own, rewrite it in plain words before sending (without changing facts or meaning).
• Do not convey meaning only through a metaphor or a vague qualifier: the foundation of a report is precision — write so the meaning reads unambiguously (plain language is a means of staying easy to read while preserving it). Do not report results only with ungrounded qualifiers (e.g. "significantly", "nicely"); state observable facts. If you use a metaphor, pair it immediately with a precise restatement (do not force established technical terms, or ordinary words in their everyday sense, into strained paraphrases).
• This check works as a pair with the after-the-fact record (prevention alone is never enough): when a report failed to get through, log the case to the drift log while drift-watch is on, and feed the next prevention.

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.