sungjunlee · sungjunlee · Jun 2, 2026 · Jun 2, 2026
diff --git a/skills/spec-charter/SKILL.md b/skills/spec-charter/SKILL.md
@@ -35,9 +35,11 @@ Resolve helper scripts from the installed `spec-charter` skill directory, not fr
 
 End every mode with a short summary:
 
-- `create`: created files, unresolved assumptions, and whether `spec-system-map` and `spec-grill` are recommended next steps.
+- `create`: created files, unresolved assumptions, and a concrete next natural-language action. On brownfield repos, recommend creating `spec/system-map.md` before asking `spec-grill` to review capability boundaries.
 - `amend`: accepted changes, refused/parked changes, proof cited for status advances, and size-check result.
-- `reassess`: required report sections from the Reassess Mode dispatch contract, with one recommended next step.
+- `reassess`: required report sections from the Reassess Mode dispatch contract, with one recommended next natural-language action.
+
+When recommending follow-up spec work, do not require users to memorize downstream arguments such as `map`, `fill`, or `audit`. Prefer plain actions like "create the system map" or "ask spec-grill to review candidate capability boundaries." Include 2-5 candidate boundary names only when they are supported by evidence from README, `spec/system-map.md`, scripts, tests, docs, or recent commit scopes.
 
 ## What spec/charter.md Is
 
@@ -71,7 +73,7 @@ Use create mode when neither `spec/charter.md` nor legacy root `CHARTER.md` exis
 1. Draft from repo signals: product/user-facing signals (`README.md`, open epics/issues, `CHANGELOG.md`) before development-harness signals (`CLAUDE.md`, `AGENTS.md`). Harness files may inform workflow conventions, local commands, and repo-specific guardrails, but they do not override README, charter, issues, code structure, or user interview answers for product/capability authority unless they explicitly describe product boundaries. When signals conflict, surface the conflict in the interview rather than picking silently.
 2. Interview the user to fill and sharpen Problem, Approach, Non-Goals, and initial Objectives. Follow the checklist in `references/create.md`: Problem framing options, the wedge test for Approach, Non-Goals elicitation, and Objective framing that cites `references/objectives.md`.
 3. Create `spec/` if needed, then write `spec/charter.md` from `templates/charter.md` with `revision: 1` and today's `last_amended`. The Decisions table may be left empty. Seed 3-5 rows only when prior design docs, ADRs, or notable merged PRs already record direction; whatever lands becomes immutable from revision 2.
-4. If the target repo is brownfield, recommend `spec-system-map` and `spec-grill` as the next steps. Brownfield signals include existing source roots (`src/`, `app/`, `lib/`, `packages/`, `skills/`), commit history, tests/scripts/config, open issues, or multiple top-level feature/workflow surfaces.
+4. If the target repo is brownfield, recommend `spec-system-map` as the next step when `spec/system-map.md` is absent. After the map exists, recommend asking `spec-grill` to review candidate capability boundaries. Brownfield signals include existing source roots (`src/`, `app/`, `lib/`, `packages/`, `skills/`), commit history, tests/scripts/config, open issues, or multiple top-level feature/workflow surfaces.
 
 Objective conventions:
 
@@ -107,6 +109,8 @@ Use reassess mode when the user asks whether `spec/charter.md`, `spec/system-map
 
 Reassess never edits files. It diagnoses drift and recommends next actions; accepted fixes must run through `spec-charter amend`, `spec-system-map amend`, `spec-grill <capability>`, or a separate user-approved Learning Action.
 
+If reassess finds that `spec/system-map.md` is missing on a brownfield repo, recommend creating the system map before capability grilling. If `spec/system-map.md` exists and `spec/capabilities.md` is missing or thin, recommend asking `spec-grill` to review the candidate capability boundaries. Name concrete candidates only when evidence supports them; otherwise say which evidence is missing.
+
 Dispatch contract:
 
 1. Resolve helper scripts from the installed dev-backlog skill directory; if unavailable, report **Missing Evidence**.

diff --git a/skills/spec-grill/SKILL.md b/skills/spec-grill/SKILL.md
@@ -1,6 +1,6 @@
 ---
 name: spec-grill
-argument-hint: "[capability-slug]"
+argument-hint: "[natural-language request]"
 description: "Create or refine spec/capabilities.md by grilling existing repo signals into capability contracts, Behaviors, and Hard Constraints. Use after spec-charter on existing repos, or when users ask for capability specs, component contracts, middle-layer specs, repo capability boundaries, 능력 명세, or grill."
 compatibility: Requires git. Works on Claude Code and Codex.
 metadata:
@@ -15,18 +15,27 @@ Use this after `spec-charter create` on existing/brownfield repos, or whenever t
 
 ## Execution Contract
 
-### Invocation
+### Intent Router
 
-- `spec-grill`: greenfield or brownfield capability-spec creation. If `spec/capabilities.md` does not exist, create it from `templates/capabilities.md`, then interview one capability at a time.
-- `spec-grill <capability-slug>`: refine exactly one existing capability block. If the file is absent, fall back to greenfield mode and surface the absence.
+Do not require users to memorize arguments. Interpret the user's request and choose the safest matching route. Power-user aliases such as `map`, `fill`, `audit`, and exact capability slugs are accepted, but they are optional shorthand, not the primary workflow.
+
+| User intent | Route | Writes? |
+|-------------|-------|---------|
+| No argument, ambiguous capability request, or "look at the capabilities" | **Grill Report**: diagnose current evidence and recommend next action. | No |
+| "Find capability candidates", "map repo capability boundaries", or `map` | **Candidate Boundary Report**: collect raw candidates and classify them as accepted / rejected / merged / split candidates. | No |
+| "Add the next missing capability", "fill the missing capability", or `fill` | **Next Capability Proposal**: propose exactly one missing capability and ask for confirmation before editing. | Only after confirmation |
+| Mentions a known capability slug or natural-language capability area | **Specific Capability Review**: resolve the mention to one capability or candidate and deep-review only that block or candidate. | No by default |
+| "Audit capabilities", "find overlap", "find stale contracts", "find weak predicates", or `audit` | **Capability Audit Report**: report stale, overlapping, weak, or unsupported capability predicates. | No |
+
+If intent is unclear, prefer report-only. If the user asks for an edit while evidence is weak, emit the report first, identify the missing evidence, and ask before writing.
 
 Capability slugs are strict routing handles used by sprint `component:` frontmatter. Keep them lowercase and singular, then put nuance in Goal/Scope prose.
 
 ### Helper Scripts
 
 Resolve helper scripts from the installed `spec-grill` skill directory, not from the target repo. In a source checkout, that means the local `scripts/` directory beside this `SKILL.md`. Always pass the target repo explicitly (`--repo-root <target-repo>`) so helpers do not inspect the skill directory by accident.
 
-On a brownfield repo with no `spec/capabilities.md`, run `extract-signals.js --repo-root <target-repo> --json` first. The script reports raw capability signals with draft Goal + draft Scope. It never writes `spec/capabilities.md`; admission, merging, splitting, and naming belong to this skill.
+On a brownfield repo with no `spec/capabilities.md`, or when candidate evidence is requested, run `extract-signals.js --repo-root <target-repo> --json` first. The script reports raw capability evidence. It never writes `spec/capabilities.md`; admission, merging, splitting, and naming belong to this skill.
 
 ### Completion Contract
 
@@ -36,11 +45,53 @@ End every run with a short summary:
 - predicates rejected or rewritten
 - constraints added
 - raw candidates merged/split/refused
+- behaviors promoted to constraints
+- missing proof or evidence
 - follow-up Learning Actions if any
 
+### Grill Report Contract
+
+Use this report shape for no-arg, ambiguous, candidate-discovery, and audit routes unless the user asks for a shorter answer:
+
+```md
+## Grill Report
+
+### Evidence Read
+- <file/script/signal and what it proves>
+
+### Evidence Missing
+- <missing charter/system-map/tests/docs/surface that weakens confidence>
+
+### Raw Candidates
+- <candidate> - evidence: <signals>; caveat: <why it is not accepted yet>
+
+### Accepted / Rejected / Merged / Split Candidates
+- Accepted: <candidate> - <reason>
+- Rejected: <candidate> - <reason>
+- Merged: <candidate A> + <candidate B> -> <candidate C> - <reason>
+- Split: <candidate> -> <candidate A>, <candidate B> - <reason>
+
+### Sharp Questions
+- <candidate>: <pressure question that must be answered before editing>
+
+### 3-Axis Predicate Findings
+- Rejected predicates: <predicate> - failed <axis>
+- Rewritten predicates: <before> -> <after>
+- Behaviors promoted to constraints: <behavior> -> <constraint>
+- Missing proof/evidence: <predicate> - needs <test/doc/runtime invariant/receipt>
+
+### Proposed Next Capability
+- <slug> - <why this is the next safest contract to write or revise>
+
+### Recommended Edit
+- <specific edit command or "no edit yet">
+```
+
+Separate diagnosis from mutation. The report can recommend edits, but it must not edit `spec/capabilities.md` unless the user clearly asked for editing or confirms the proposed edit.
+
 ## Brownfield Signal Rules
 
-`extract-signals.js` draws from README, `spec/charter.md` with legacy root `CHARTER.md` fallback, `CLAUDE.md`/`AGENTS.md`, top-level source dirs, and recent commit messages.
+`extract-signals.js` draws from README, `spec/charter.md` with legacy root `CHARTER.md` fallback, `spec/system-map.md`, `CLAUDE.md`/`AGENTS.md`, top-level source dirs, skill files, script surfaces, docs, tests, and recent commit messages.
 
 Use the draft as interview seed only. The script labels signal authority:
 
@@ -49,7 +100,7 @@ Use the draft as interview seed only. The script labels signal authority:
 - commit scopes are history.
 - `CLAUDE.md`/`AGENTS.md` are development-harness context.
 
-Harness context can seed questions about conventions and workflow, but it must not create accepted capability boundaries by itself. The script clusters by code organization, while real capabilities are functional contracts; expect grill mode to merge, split, or regroup raw signals rather than adopt them verbatim.
+Harness context can seed questions about conventions and workflow, but it must not create accepted capability boundaries by itself. The script clusters evidence from code organization and command surfaces, while real capabilities are functional contracts; expect grill mode to merge, split, or regroup raw signals rather than adopt them verbatim.
 
 ## File Shape
 
@@ -102,7 +153,7 @@ Classify positive normal outcomes as Expected Behaviors. Classify bright-line ne
 
 ## Writing Rules
 
-On first run, copy `templates/capabilities.md` to `spec/capabilities.md` at the repo root, then walk the interview for one capability. On rerun, edit only the named capability block and leave the rest of the file untouched.
+When the user accepts a first capability edit and `spec/capabilities.md` is absent, copy `templates/capabilities.md` to `spec/capabilities.md` at the repo root, then write only the accepted capability. On rerun, edit only the named capability block and leave the rest of the file untouched.
 
 After applying an accepted change, do not bump a revision number on `spec/capabilities.md`; `git blame` is the source of truth. Note in the conversation which capability was edited. Echo charter Decisions at capability level only when they explain a Behavior or Hard Constraint; promote cross-cutting capability Decisions through `spec-charter amend`.