feat: refresh shared skills catalog

skills/grill/SKILL.md

@@ -1,83 +1,24 @@
 ---
 name: grill
 description: >
-  Calibrated interrogation to stress-test a fuzzy plan, design, or architecture before writing a spec or code.
-  Asks one question at a time with recommended answers to extract concrete goals (§G) and constraints (§C).
-  Use when asked to "grill me", "stress-test this", "challenge my plan", or before authoring a spec.
-concerns: [system-one-balance]
+  Stress-test a fuzzy plan through questions when asked to grill, challenge, or interrogate the plan. Do not activate automatically before every spec.
+scope: global
 ---
 
-# Grill — Calibrated Plan Stress-Testing
+# Plan questions
 
-Drags ambiguity into concrete goals (§G) and constraints (§C) *before* execution begins. A bad assumption caught here costs one question; caught later, it costs an architectural refactor.
+Inspect the conversation and relevant code before asking. Infer routine details;
+ask only about a product choice or uncertainty that materially changes the plan.
 
----
+1. Identify the most consequential unknown about the goal, completion criteria,
+   scope, constraints, interfaces, or failure behavior.
+2. Ask one concise question with a recommended answer and a sentence explaining
+   its impact. Respect the user's chosen level of detail and pressure.
+3. Incorporate the answer and continue only while consequential unknowns remain.
+   Do useful independent investigation while waiting when possible.
+4. Stop when the goal and boundaries are clear. Summarize decisions and remaining
+   uncertainties; distinguish deferred non-blocking questions from true blockers.
 
-## Phase 0: Setup and Protocols
-
-1. **Interrogation Invariants**:
-   - **One Question at a Time**: Never ask multiple questions in a single turn. Ask one question, provide a recommended answer, and wait.
-   - **Recommend an Answer**: Always provide a concrete default so the user can reply with "yes" or choose an alternative.
-   - **Inspect Context First**: If an answer can be found in files, code, docs, or git history, inspect them directly instead of asking the user.
-   - **Propose, Don't Decide**: Challenge tradeoffs and surface hidden edge cases, but leave final product choices to the user.
-
----
-
-## Phase 1: Ingest and Check
-
-1. Determine user knowledge and desired pressure level from context:
-   - **Knowledge Level**:
-     - *New*: Explain missing frames briefly (2 sentences); focus on first principles and goals.
-     - *Working*: Challenge standard tradeoffs, alternatives, and validation criteria.
-     - *Expert*: Probe failure modes, boundary limits, migration costs, and reversibility.
-   - **Pressure Level**:
-     - *Light*: Clarify goals, scope, and missing definitions.
-     - *Standard*: Challenge assumptions, resource bottlenecks, and execution paths.
-     - *Hard*: Probe edge cases, adverse incentives, failure modes, and rollback mechanisms.
-
----
-
-## Phase 2: Processing (Core Logic)
-
-Climb the Question Ladder in sequence. Stop as soon as the plan is clear; do not ask every rung by reflex:
-1. **Goal (§G)**: What must the code or feature accomplish in one single, unambiguous sentence?
-2. **Done Criteria (§C / §V)**: What observable signal (test, metric, terminal output) proves this works?
-3. **Boundaries (§C)**: What is explicitly *out of scope* for this change?
-4. **Non-Negotiables (§C)**: What architectural patterns, libraries, or constraints are strictly required or forbidden?
-5. **Surfaces (§I)**: What external membranes (API endpoints, CLI flags, DB tables, schemas) will be modified?
-6. **Failure Modes (§V)**: What is the primary edge case or input that breaks the happy path?
-7. **Unknowns (`?`)**: What do we not yet know? (Park unresolved items as `?` bullets; do not guess them).
-
-### Question Format
-```text
-Question: ...
-Recommended answer: ...
-Why it matters: [1 sentence rationale]
-```
-
----
-
-## Phase 3: The System One Balance Pass
-
-- **Augment, Don't Handcuff**:
-  - Stop grilling immediately once the goal and boundaries are defined.
-  - Never interrogate the user on routine file edits, typo fixes, or straightforward tasks.
-  - Accept the user's recommended answer or override without debate.
-
----
-
-## Phase 4: Output Execution & Verification
-
-Stop grilling when **all** of the following hold:
-- §G is one line, one reading, zero "or maybe".
-- §C covers every non-negotiable stated or implied.
-- Every blocking unknown is answered or parked as an explicit `?`.
-
-Emit the structured handoff block to pass to the **spec** or **build** workflow:
-```markdown
-## Grill Handoff
-- **§G**: [One-line goal]
-- **§C**: [Constraints and non-negotiables]
-- **§I**: [Surfaces touched]
-- **Parked Unknowns (`?`)**: [Items deferred to research]
-```
+An explicit request to interrogate can use a question-at-a-time exchange. Otherwise
+follow [shared workflow](../../protocols/workflow.md); routine edits and already-clear
+implementation requests need no interview or mandatory handoff report.