intent-discover

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
  • For divergent work, the AI presents hypotheses, counterexamples, and alternative problem framings as inferred so the human can set decision boundaries in the next compass
  • A design principle is handed to downstream phases: explore broadly, have the human confirm decision boundaries in the compass, and keep implementation as bounded autonomy within those confirmed boundaries
  • 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)
  • No application code has been changed at all

When designing or changing responsibility/dependency boundaries, read “Compare boundaries” in ../intent-packets/rules/design-boundaries.md before drafting.

Execution Steps

• When drafting, read “Recording the plan” and “Checking meaning” in ../intent-packets/rules/requirement-coverage.md; retain requirement sources and acceptance conditions in the relevant Tree prose.

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 with the user via AskUserQuestion (run the recommend→confirm wiring even if standard is the only candidate).
• Create an issue directory and record the confirmed result there (A34 — resolving same-machine concurrent collision): on each discover run, create .intent/discovery/<slug>-<rand>/ (an issue directory mirroring packets; <slug> derived from the issue name; <rand> is 4 [a-z0-9] chars generated by the shell, no central numbering) and record the confirmed result in its mode.md (the local canonical source for mode state; not tracked by git). State the issue directory name in the Output so downstream skills inherit it for reading (reader identification). Keep the existing single .intent/mode.local.md as the backward-compatible legacy read target. Enforcement / Drift-watch (shared policy) stay in .intent/mode.md and are not touched. See .intent/discovery/README.md.
• Create one drafting claim (to tell parallel sessions "this is being drafted" — DR163/INV91): in the same step that creates the issue directory, create .intent/assignments/discovery-<issue-dir-name>-<session-rand>.md (<session-rand> = 4 [a-z0-9] chars generated by the shell). Its frontmatter: phase: drafting / issue_dir: <issue-dir-name> / packet_id: "" (no packet exists yet at drafting time — never fabricate an ID) / declared_at (shell date) / session / note (optional). Creation is automatic; deletion is manual (deciding that drafting has ended is a human judgment, so a machine never deletes a live claim; INV91). If a claim for the same issue directory already exists, do not create a duplicate (re-runs must not stack claims). Never stop or take over (a claim is read-only guidance and never refuses another session's start). The schema and its rules are governed by .intent/assignments/README.md; the reading contract lives in CONTRACT.md.
• Recommend → confirm → record the target format (optional, deferrable): after confirming the mode, when the target format (which exit to take = cc-sdd / openspec / speckit / to-spec / direct) 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) and the setup markers of the downstream spec tools (whether .kiro/ for cc-sdd, a repository-root openspec/ for OpenSpec, or a repository-root .specify/ for Spec Kit exists; read-only observation); the format→exit correspondence and the handling of setup status (set-up tools first; never drop the not-set-up ones from the candidates; never invent a priority among set-up tools) are kept consistent with intent-packets/rules/export-route.md (the exit decision lane, the single source of truth) — do not copy its tables into this file. Choose direct for a case implemented directly without a tool (no spec tool launched — e.g. a small-to-medium change that edits code or documents directly); recording it lets /intent-writeback use that record as the primary signal for target identification (INV34). 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; if direct is likewise unrecorded, writeback falls back to the 3-condition AND 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).