Allow an optional decision round for vague plans

CHANGELOG.md

@@ -2,6 +2,8 @@
 
 ## Unreleased
 
+- When a planning assignment is vague or underspecified, allow an optional short decision round with a recommendation. Clear assignments still need no interview. Raise the plan-and-readiness context limit to hold that instruction.
+
 ## 7.6.0
 
 - Establish and maintain project north stars through setup and explicit user decisions, carrying pending updates across read-only phases without duplicate approval. Add isolated project-direction verification scenarios.

docs/behavior-validation.md

@@ -89,6 +89,7 @@ For each example ask: What is the result? What does it mean for the goal? What f
 | Situation | Expected decision | Instructions to inspect |
 |---|---|---|
 | A small change has a clear goal, known entrypoint, and suitable existing checks. | Stop planning research when the meaningful decisions are settled. Give a short actionable plan, no interview or blanket verifier offer, and direct the human to the native implementation action. Omit the second-order note. Do not load the playbook catalog unless the user asks about methods or a concrete methodological choice would materially help. | [Planning](../skills/plan-work/SKILL.md) |
+| The assignment is vague or underspecified: the goal, boundaries, interfaces, success checks, or a material trade-off that would change the plan is missing. | An optional short decision round may ask only what blocks a sound plan, with a concrete recommendation the user can accept or steer, in a few focused questions. Do not add a separate skill for that round, require a glossary, expand a design tree, or turn planning or Auto-Work into an interview gate. | [Planning](../skills/plan-work/SKILL.md) |
 | A material change affects architecture, a breaking contract, several surfaces, or schema and deploy. | Note second-order effects in one line each where relevant: caller impact, data or migration, deploy and rollback, and security or auth. Mark speculation as speculation. | [Planning](../skills/plan-work/SKILL.md) |
 | A product choice changes the expected behavior or scope. | Ask the decisive question with a reasoned recommendation before dependent work; do not turn routine technical choices into approval gates. | [Planning](../skills/plan-work/SKILL.md), [working agreement](../references/workflow.md) |
 | Native implementation has only the approved plan and assignment. | The plan carries reporting expectations and the host's review invocation. The executor reports actual checks and recommends a separately commissioned Review, without claiming it passed. | [Planning](../skills/plan-work/SKILL.md), [implementation handoff](manual-workflow.md#plan-and-implementation), built host instructions |

docs/manual-workflow.md

@@ -40,7 +40,7 @@ For example, in Codex:
 
 In Cursor, replace `$plan-work` with `/plan-work`.
 
-The agent inspects your project and prepares a plan. It explains the intended result, scope, important decisions, risks, and checks. It also reads relevant saved project lessons and checks that they still apply. Questions should resolve real uncertainty; a clear, small task should produce a proportionate plan. When the change is material (architecture, a breaking change, several surfaces, or schema and deploy), the plan also notes second-order effects in one line each where relevant: caller impact, data or migration, deploy and rollback, and security or auth. Speculation is marked as speculation. A routine fix or small plan leaves that note out.
+The agent inspects your project and prepares a plan. It explains the intended result, scope, important decisions, risks, and checks. It also reads relevant saved project lessons and checks that they still apply. Questions should resolve real uncertainty; a clear, small task should produce a proportionate plan. When the assignment is vague or underspecified, planning may use a short optional decision round: a few questions that block a sound plan, each with a recommendation to accept or steer. When the change is material (architecture, a breaking change, several surfaces, or schema and deploy), the plan also notes second-order effects in one line each where relevant: caller impact, data or migration, deploy and rollback, and security or auth. Speculation is marked as speculation. A routine fix or small plan leaves that note out.
 
 For this example, look for checks covering filtered orders, visible columns, and empty exports. Resolve important choices before approving the plan. Planning may also offer optional [setup, maintenance, methods, or verifier work](project-improvement.md) for concrete task-relevant needs.
 

docs/methodology-sources.md

@@ -37,6 +37,12 @@ Maintenance retains index hygiene, source comparison, user-path recipes, live co
 
 The preference order for a repeated correction is adapted from Lauren Tan's description of pstack 0.15.9 `/correct` (<https://x.com/poteto/status/2106542593656111276>): eliminate the class through architecture or data structures, then a lint or test that CI catches, then a skill or rule, then human review. Workflow applies it through the [learning guidance](../references/learning-work.md), considering effectiveness, effort, and commissioned scope rather than the first technically feasible rung. A first finding can also justify in-scope prevention. It does not import poteto-mode, the Grok Bot prompt, `/architect`, or a separate correction command. The playbook adaptations above are unchanged. Learning saves supported, bounded guidance only when commissioned and appropriate. Product, tool, and verifier repairs outside the assignment stay future assignments.
 
+## Vague-scope planning
+
+An optional short decision round for a vague or underspecified assignment is the lean alternative to Matt Pocock's grill-me specialization (<https://x.com/mattpocockuk/status/2107376343537385946>). It stays inside [plan-work](../skills/plan-work/SKILL.md): ask only what blocks a sound plan, and offer a concrete recommendation the user can accept or steer. Clear assignments still need no interview.
+
+Workflow does not add a grill-me or grill-with-docs skill, a required glossary, a product-design interview, or a mandatory interview before planning or Auto-Work. Product-design judgment stays with the Design plugin when that plugin is in use. Material security or auth effects stay on plan-work's existing second-order line. Change sketches stay with Efficiency's change-communication. Packaged instructions remain original Workflow wording. This note attributes the idea; it does not load an upstream skill.
+
 ## Shared integration decisions
 
 Each method remains one reference file. Catalog and skill entrypoints load only the selected method. The playbooks describe useful result content, not mandatory user-document headings, metadata, or machine state.

scripts/context-limits.json

@@ -110,7 +110,7 @@
     "setupImplementation": 3000,
     "maintenanceInspection": 2500,
     "maintenanceUpdate": 3000,
-    "planSetupGap": 3500,
+    "planSetupGap": 3900,
     "doctorSetupGap": 3900,
     "reviewSetup": 3100,
     "correctionSetup": 2600,
@@ -373,6 +373,19 @@
           "limit": 2700
         }
       }
+    },
+    {
+      "date": "2026-10-07",
+      "reason": "Hold the optional vague-scope decision round in plan-work. The instruction stays; only the plan-and-readiness scenario needed more room.",
+      "selection": "Only planSetupGap exceeded its limit after that clarification. The other limits remain unchanged. This criterion does not trigger future automatic changes or approvals.",
+      "method": "Largest current host measurement plus 10%, rounded up to 100 estimated tokens. Existing baselines are retained; normal checks never update limits.",
+      "scenarios": {
+        "planSetupGap": {
+          "maximum": 3519,
+          "previousLimit": 3500,
+          "limit": 3900
+        }
+      }
     }
   ]
 }

skills/plan-work/SKILL.md

@@ -9,6 +9,8 @@ Apply the [working agreement](../../references/workflow.md); read it if missing
 
 Check relevant plan choices against the north star, assignment and success criteria; resolve consequential conflicts with the user. Stop when goal, boundaries, interfaces and checks suffice. Clear assignments need no interview or advance design of routine details.
 
+When the assignment is vague or underspecified (missing the goal, boundaries, interfaces, success checks, or a material trade-off that would change the plan), an optional short decision round may ask only what blocks a sound plan. Offer a concrete recommendation the user can accept or steer, in a few focused questions. Do not add a separate skill for that round, require a glossary, expand a design tree, or turn planning or Auto-Work into an interview gate.
+
 For a repeated correction, read the [learning guidance](../../references/learning-work.md) and plan prevention proportionate to the assignment.
 
 Explain the goal, benefit, observable success criteria, scope, exclusions, material risks, dependencies, decisions, and checks. Add files, interfaces, commands or sequencing where needed. A small change may need only a few paragraphs. When the change is material (architecture, a breaking change, several surfaces, or schema and deploy), note second-order effects in one line each where relevant: caller impact, data or migration, deploy and rollback, and security or auth. Mark speculation as speculation. Omit this for a routine fix or a small plan.