메뉴
Stress-test an existing ExecPlan through a relentless, interactive grilling session. Challenges plan assumptions against the codebase, sharpens terms, resolves decision branches one at a time, and updates the ExecPlan as decisions crystallize.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Sequentially drain ready br issues or tk tickets through the existing ship chains with retry limits and progress state.
Update a work item with a concise execution note and close it only when validation and review evidence prove the acceptance criteria. Use for prompts that finalize work-item status after manual execution chains.
Review work items, ExecPlan delivery, or arbitrary code changes with evidence-backed findings. Reviews are read-only by default and create tracker follow-ups only when explicitly requested with --create-followups.
Implement or fix a work item using minimal diffs while preserving scope, local conventions, and testability. Use for prompts that change code or apply validation/review fixes.
Validate work-item changes using concrete evidence, exact commands, and explicit gap reporting. Use for validation prompts and review passes that audit proof.
Create a self-contained ExecPlan from a brainstorm artifact and/or a user brief. Follows the project's .execflow/PLANS.md spec. Applies the Ousterhout design lens. Use when creating execution plans, turning ideas into implementable steps, or wants a PRD/RFC/brainstorm turned into a step-by-step plan.
| name | grill-plan |
| description | Stress-test an existing ExecPlan through a relentless, interactive grilling session. Challenges plan assumptions against the codebase, sharpens terms, resolves decision branches one at a time, and updates the ExecPlan as decisions crystallize. |
Use this skill when an ExecPlan exists but the design needs pressure-testing before it is split into work items or implemented.
This skill is inspired by grill-style planning sessions: interview the user relentlessly, ask one question at a time, provide a recommended answer, and inspect the codebase whenever the repository can answer the question better than the user can.
.execflow/plans/<topic-slug>/execplan.md..execflow/PLANS.md must exist and be read in full before modifying the plan./create-plan first and stop.<topic-slug> (kebab-case, lowercase) before resolving plan paths..execflow/plans/ for directories containing execplan.md. If exactly one match exists, use it.Before asking the user any question:
.execflow/PLANS.md in full.If a question can be answered by reading the codebase, answer it from code evidence instead of asking the user.
Walk down the design tree one branch at a time. Ask exactly one focused question per turn. For each question, include:
Do not ask multipart question bundles. If a topic has several branches, ask the highest-leverage one first and save the rest for later turns.
Pressure-test at least these areas when relevant:
When the plan uses vague language, propose a precise canonical term. If the repository already uses a different term, call out the mismatch immediately and ask which term should win.
When a term is accepted, update the ExecPlan's Domain Language, Context and Orientation, or relevant milestone prose so later implementers do not need the conversation transcript.
When a proposed improvement could expand the plan, ask whether it belongs in scope or under non-goals. Prefer recording exclusions in Scope and Non-Goals rather than leaving them implicit.
Use concrete examples to probe domain boundaries and edge cases. Prefer scenarios that would force different implementation choices or validation expectations.
If an important scenario is missing, update User Stories / Observable Scenarios or Validation and Acceptance so success remains observable.
Challenge whether milestones are vertical, independently verifiable slices. If the plan needs an enabler, migration, prototype, or cleanup milestone, make that classification and rationale explicit.
Ask for RED/GREEN strategy only when testability cannot be inferred from the repo. Record either the failing test or command that should prove RED, or an explicit exemption for docs-only, exploratory, or untestable work.
Call out parallelism hazards such as shared config files, registries, migrations, generated files, and public interfaces. Update the ExecPlan with safe parallel slices and serialization points instead of leaving concurrency assumptions implicit.
When a decision crystallizes, update .execflow/plans/<topic-slug>/execplan.md immediately. Do not batch all updates until the end.
Update the smallest necessary sections, usually one or more of:
Decision LogSurprises & DiscoveriesContext and OrientationPlan of WorkConcrete StepsValidation and AcceptanceInterfaces and DependenciesDomain LanguageScope and Non-GoalsUser Stories / Observable ScenariosTask GraphTDD StrategyParallelization and Worktree StrategyIdempotence and RecoveryEvery update must keep the ExecPlan self-contained and compliant with .execflow/PLANS.md.
This package's primary planning artifact is the ExecPlan. Do not create CONTEXT.md or ADR files by default.
If the repository already has glossary or ADR conventions and a decision is both hard to reverse and surprising without context, mention that an ADR or glossary update may be warranted, but keep the ExecPlan update as the required action.
Stop the grilling session when one of these is true:
Before stopping, ensure the ExecPlan reflects every resolved decision.
During the session, ask one question at a time and wait for the user's answer.
When stopping, report:
/ef-tasks <topic> when the plan is ready for work-item creation