القائمة
Create, view, or update your project gameplan. Breaks your vision into Goals, Steps, and Tasks.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Think out loud with full project context. Explore ideas one question at a time.
Capture an idea for later without interrupting your flow.
Review your saved ideas and decide what to do with them.
Handle a change in direction for your project. Maps impact and updates your gameplan.
Re-scan your codebase and optionally re-run research. Keeps your project context current.
Work on the next ready task in your project. Picks up where you left off automatically.
| name | director:blueprint |
| description | Create, view, or update your project gameplan. Breaks your vision into Goals, Steps, and Tasks. |
First, check if .director/ exists. If it does not, run the init script silently:
bash "${CLAUDE_PLUGIN_ROOT}/scripts/init-director.sh"
Say only: "Director is ready." Then continue with the steps below.
Read .director/VISION.md and check whether it has real content beyond the default template.
Template detection for VISION.md: If the file contains placeholder text like > This file will be populated when you run /director:onboard, or italic prompts like _What are you calling this project?_, or headings with no substantive content beneath them (just blank lines, template markers, or italic instructions), the project has NOT been onboarded yet.
If VISION.md is empty or still the default template:
Say something like:
"Before creating a gameplan, we need to understand what you're building. Want to start with
/director:onboard? It's a quick interview to capture your vision."
Wait for the user's response. If they agree, proceed as if they invoked /director:onboard -- run through the onboard flow to capture their vision first.
If VISION.md has real content, read .director/GAMEPLAN.md and check whether it has real content.
Template detection for GAMEPLAN.md: Check for ALL of these signals:
This file will be populated when you run /director:blueprint_No goals defined yet_If GAMEPLAN.md contains only template/placeholder text and no actual goal definitions, this is NEW gameplan mode. Continue to Handle Arguments below.
If GAMEPLAN.md has real content (actual goal names with descriptions, steps listed, etc.), this is UPDATE mode. Skip to the Update Mode section below.
This section applies only in new gameplan mode. Update mode has its own argument handling.
If $ARGUMENTS is non-empty, acknowledge it before proceeding:
"You want to focus on [arguments]. Let me read your vision and create a gameplan."
If $ARGUMENTS is empty, say something like:
"Let me read your vision and put together a gameplan."
Before generating goals, scan the VISION.md content for [UNCLEAR] markers.
If [UNCLEAR] markers are found, present them to the user:
"Before we plan, I noticed some open questions in your vision:"
- [First UNCLEAR item]
- [Second UNCLEAR item]
"Want to resolve these now, or should I plan around them? If we skip them, some tasks might need adjustment later."
Wait for the user's response. If they want to resolve the questions, work through each one conversationally. Update your understanding of the vision accordingly (but do NOT rewrite VISION.md here -- that happens via /director:onboard).
If the user wants to defer, note the unresolved items and proceed. Keep them in mind when generating tasks -- tasks affected by unclear items should note this in their "Needs First" section.
If no [UNCLEAR] markers are found, proceed directly to goal generation.
Before loading research context, check whether the project's research and codebase analysis files are still current.
Read .director/config.json and extract context_generation.completed_goals_at_generation. If the context_generation field does not exist (backward compatibility with pre-Phase 16 projects), default to 0.
Count the current number of completed goals by scanning .director/goals/ directories. A goal is "completed" if its GOAL.md Status section shows "Complete" or all its steps' tasks are .done.md files.
Calculate the delta: current_completed_goals - completed_goals_at_generation.
If delta >= 2: show a brief, non-blocking alert to the user before proceeding. Something like:
"Your project research and codebase analysis were done a while ago -- you've finished [N] goals since then. You might want to run
/director:refreshto update them. Continuing with what we have for now."
If delta < 2: proceed silently.
This alert is NON-BLOCKING. After showing it (or skipping it), continue to Load Research Context below. The user can choose to act on the suggestion or ignore it.
Before generating goals, check if domain research exists from onboarding:
Read .director/research/SUMMARY.md silently using cat .director/research/SUMMARY.md 2>/dev/null.
If the file exists and has content, store its contents internally wrapped in a <research_summary> tag:
<research_summary>
[Contents of SUMMARY.md]
</research_summary>
This research context informs goal generation and step planning -- use it to:
If the file does not exist or is empty, proceed silently. Do NOT mention missing research to the user or agent. Do NOT include an empty <research_summary> tag.
This context is a bonus -- it makes planning smarter when available but changes nothing when absent.
Read the full content of VISION.md to understand the project. Then generate goals following the planning rules below.
These rules govern how the gameplan is structured. Follow them throughout the entire planning process.
A goal describes what the user will HAVE when it's complete, not what you'll DO to get there.
Good goals (outcomes -- what users can do):
Bad goals (activities -- what you'll build):
If you catch yourself writing a goal that starts with "Build", "Create", "Implement", "Set up", or "Configure", rewrite it as what users can do when it's complete.
Each step delivers something the user can see or interact with. A step is complete when you can point to what it produced.
Good steps:
Bad steps:
A task is something that can be completed in one focused session. It should be clear enough that someone could start working immediately.
Each task includes five fields:
If the login page needs user accounts in the database, the database setup comes before the login page. Express this as "Needs the user database set up first" not "Depends on TASK-03."
Never use task IDs, technical identifiers, or jargon for prerequisites. Users think in capabilities, not identifiers.
Never say: "Depends on TASK-03" or "Blocked by AUTH-01" or "Prerequisite: database migration" Always say: "Needs the user database set up first" or "Needs the login page built first"
Mark tasks as "ready" only when everything they need is already complete. When presenting the gameplan, make it clear which tasks can be started right now.
Build complete features one at a time, not all database models first, then all API routes, then all UI.
Good order (vertical slices -- users see working features sooner):
Bad order (horizontal layers -- nothing works until everything is done):
Help users understand the scope of each task:
| Size | What It Means | Typical Scope |
|---|---|---|
| Small | Quick change, straightforward | Single file, clear approach, under 30 minutes |
| Medium | Some decisions involved | Multiple files, a few choices to make, 30-90 minutes |
| Large | Significant work, may need research | Multiple files, important decisions, possibly new tools or libraries, 90+ minutes |
These are effort indicators, not time estimates. "Small" means "simple and clear," not "exactly 15 minutes."
Using the vision content and the rules above, generate 2-4 goals as outcomes. Each goal should have a name (what users can do) and a 1-2 sentence explanation of why it matters.
Present ALL goals together (not one at a time) in numbered format:
Based on your vision, here are the goals I'd suggest:
- [Goal as outcome] -- [Why this matters for the project]
- [Goal as outcome] -- [Why this matters for the project]
- [Goal as outcome] -- [Why this matters for the project]
Does this feel right? Want to add, remove, or rearrange anything?
Wait for the user's response. If they give feedback (add a goal, remove one, rename one, reorder them), adjust the goal set and re-present. Iterate until the user approves.
Important: Do NOT generate Steps or Tasks yet. Goals must be approved before proceeding.
Once the user approves the goals (before generating Steps and Tasks), write an early version of GAMEPLAN.md immediately. This persists the high-level structure so the user can find it outside the chat.
Write .director/GAMEPLAN.md with the approved goals:
# Gameplan
## Overview
[A brief summary of what this project is building and how we're approaching it. 2-3 sentences drawn from the vision.]
## Goals
1. **Goal 1: [Goal Name]** -- [One-line description]
2. **Goal 2: [Goal Name]** -- [One-line description]
3. **Goal 3: [Goal Name]** -- [One-line description]
## Current Focus
Steps and tasks are being planned...
This is a SILENT operation -- do NOT tell the user you wrote the file. The full gameplan (with steps and tasks) will overwrite this file later in "Write Gameplan." The purpose is to persist the goal structure early so it's not trapped in the chat window.
After the user approves the goals, generate Steps and Tasks for each goal.
For each approved goal:
Present the full outline with one-line descriptions and size indicators:
Here's the complete gameplan:
Goal 1: [Goal Name]
Step 1: [Step name] - [Task name] (size) -- Ready - [Task name] (size) -- Needs [capability]
Step 2: [Step name] - [Task name] (size) -- Needs [capability] - [Task name] (size) -- Needs [capability]
Goal 2: [Goal Name]
Step 1: [Step name] - [Task name] (size) -- Needs [capability from Goal 1] - [Task name] (size) -- Needs [capability]
Does this look good? Want to change the order, add anything, or remove anything?
Wait for explicit approval. If the user gives feedback, adjust and re-present. Iterate until they approve.
Important: Do NOT write any files until the user explicitly approves this outline.
After the user approves the full hierarchy outline and before writing files, extract decisions from the conversation.
A decision is a statement the user made about HOW something should be built. Look for:
What is NOT a decision (these belong in vision or task descriptions):
Review the entire conversation (both Phase 1 goal discussion and Phase 2 hierarchy discussion) for statements matching the categories above.
For each decision found, determine which step it most affects. If a decision is cross-cutting (e.g., "use PostgreSQL for everything"), assign it to EVERY step where it is relevant. Duplicate the decision into each affected step rather than creating an inheritance mechanism.
Categorize each decision:
Associate each decision with the step(s) it affects.
After capturing step-level decisions and before writing gameplan files, run step-level research for steps that need it. This investigates the technical domain of each qualifying step and produces a RESEARCH.md in the step directory for the planner to use when writing task files.
Skip this entire section if ANY of the following are true:
workflow.step_research is false in .director/config.json (read with fallback: default to true if the field doesn't exist -- backward compatibility for projects initialized before this feature)$ARGUMENTS includes --skip-researchForce fresh research for all pending steps if $ARGUMENTS includes --research (delete existing RESEARCH.md files for pending steps and re-research).
For each step in the approved outline, determine whether it needs research. This is a judgment call -- not every step warrants investigation.
Research likely NEEDED when:
Research likely NOT needed when:
Note which steps need research. If none do, skip directly to Write Gameplan.
If any steps need research, show ONE brief message:
"Let me look into the technical details for a couple of these steps..."
Do NOT list which steps are being researched or explain the research process. This runs silently.
Before spawning researchers, create directories for steps that need research:
mkdir -p .director/goals/NN-goal/NN-step/
This ensures researchers have a target directory for writing RESEARCH.md.
Read .director/config.json and resolve the model for deep-researcher:
model_profile field (defaults to "balanced")model_profiles to get the model for deep-researcherBefore spawning a researcher for a step, check if RESEARCH.md already exists in the step directory:
--research flag is NOT set: Read the Reuse Metadata section of the existing RESEARCH.md. Compare current step scope (name, deliverables, planned tasks) and current decisions (Locked, Flexible, Deferred) against what's recorded in the metadata.
--research flag IS set: Delete old RESEARCH.md, mark for re-research.For each goal, spawn a director:director-deep-researcher agent for ALL steps that need research within that goal IN PARALLEL using the Task tool. All researcher Task tool calls for steps within the same goal go in a SINGLE message so they execute in parallel.
Each director:director-deep-researcher spawn uses these instructions:
<instructions>
Scope: step-level
<vision>
[Full VISION.md contents]
</vision>
<step_context>
Step name: [step name from approved outline]
What this delivers: [from step description]
Tasks planned: [brief task list from outline]
</step_context>
<decisions>
Locked:
- [locked decisions for this step, from Capture Step-Level Decisions]
Flexible:
- [flexible areas for this step]
Deferred:
- [deferred items for this step -- DO NOT research these]
</decisions>
<onboarding_research>
[If .director/research/SUMMARY.md exists and is relevant to this step's domain, include relevant sections here. If it doesn't exist or isn't relevant, omit this tag entirely.]
</onboarding_research>
Research the technical domain for this step. Focus on:
- Libraries and tools needed for the specific work in this step
- Architecture patterns for this step's deliverables
- Common pitfalls when building what this step delivers
- Problems with existing solutions (don't hand-roll)
For Locked decisions: investigate the chosen approach deeply.
For Flexible areas: rank 2-3 options with tradeoffs.
Do NOT research Deferred items.
Write your findings to [step directory path]/RESEARCH.md using the
step research template at skills/blueprint/templates/step-research.md.
Return only a brief confirmation when done. Do NOT include file
contents in your response.
</instructions>
The step context is passed INLINE via instructions, NOT read from disk. This is because STEP.md files haven't been written to disk yet during initial blueprint -- they're written during Write Gameplan. The researcher receives all step information via the <step_context> and <decisions> tags in instructions.
If a researcher fails or returns an error:
After ALL researchers for a goal complete, read each newly-written RESEARCH.md and check the "Conflicts with User Decisions" section.
If any HIGH-severity conflicts are found, present them ONE AT A TIME to the user:
"While looking into [step name], I noticed something about your choice of [decision]: [conflict in plain language]. Want to keep your original choice, or would you like to change it?"
Wait for user response:
If no HIGH-severity conflicts: proceed silently to Write Gameplan.
Conflict criteria (strict -- avoid being too aggressive):
After the user approves the full outline, write all gameplan files.
Write .director/GAMEPLAN.md following this structure:
# Gameplan
## Overview
[A brief summary of what this project is building and how we're approaching it. 2-3 sentences drawn from the vision.]
## Goals
1. **Goal 1: [Goal Name]** -- [One-line description]
2. **Goal 2: [Goal Name]** -- [One-line description]
3. **Goal 3: [Goal Name]** -- [One-line description]
## Current Focus
**Current Goal:** Goal 1
**Current Step:** Step 1 ([Step name])
**Next Up:** [What comes after the current step]
For each goal, step, and task in the approved outline:
Goal directories and files:
.director/goals/NN-goal-slug/ (e.g., 01-user-accounts/)GOAL.md in each goal directory:
# Goal N: [Goal Name]
## What Success Looks Like
[Describe what "done" means for this goal -- what will the project be able to do?]
## Steps
1. **Step 1: [Step Name]** -- [What this delivers]
2. **Step 2: [Step Name]** -- [What this delivers]
## Status
**Progress:** Not started
**Steps complete:** 0 of [total steps]
Step directories and files:
Create directory: .director/goals/NN-goal/NN-step-slug/ (e.g., 01-user-accounts/01-login-flow/)
Write STEP.md in each step directory:
# Step N: [Step Name]
## What This Delivers
[What will be working or available when this step is done?]
## Tasks
- [ ] Task 1: [Task Name]
- [ ] Task 2: [Task Name]
## Needs First
[What needs to be done before this step can start? Plain language.]
[If nothing: "Nothing -- this step can start right away."]
## Decisions
### Locked
- [Decision from conversation]
### Flexible
- [Area where builder can choose -- with context]
### Deferred
- [Item explicitly set aside]
Note: Only include the Decisions section if the "Capture Step-Level Decisions" step identified relevant decisions for this step. Omit the entire section (including the ## Decisions heading) if there are no decisions. Only include categories (Locked, Flexible, Deferred) that have items -- omit empty categories.
Task directories and files:
.director/goals/NN-goal/NN-step/tasks/NN-task-slug.md in the tasks directory:
# Task: [Task Name]
## What To Do
[Clear description of what this task accomplishes.]
## Why It Matters
[How does this task contribute to the current step and goal?]
## Size
**Estimate:** [small | medium | large]
[Brief explanation of scope.]
## Done When
- [ ] [First observable criteria]
- [ ] [Second observable criteria]
- [ ] [Third observable criteria]
## Needs First
[What needs to be done before this task can start?]
[If nothing: "Nothing -- this can start right away."]
Research-informed task writing:
When writing task files for a step, check if a RESEARCH.md exists in the step directory (produced by Step-Level Research above). If it exists, read it and use the research findings to:
The planner reads RESEARCH.md on demand -- it is NOT force-injected into context. This keeps context manageable and lets the planner decide which sections are relevant for each task.
Directory naming conventions:
01-user-accounts/, 02-habit-tracking/How to create the files:
mkdir -p to create directoriesAfter all files are written, save progress by committing all .director/ changes:
git add .director/
git commit -m "blueprint: create gameplan with [N] goals, [M] steps, [T] tasks"
This is a SILENT operation -- the user does not see git commands or commit details. If the commit fails (e.g., nothing to commit, git not initialized), proceed silently. The important thing is that the files were written; the commit is a convenience to prevent "unsaved changes" warnings in /director:build.
After files are written and progress is saved, tell the user conversationally:
"Your gameplan is saved. I created [N] goals with [M] steps and [T] tasks total. You can browse the full plan in
.director/goals/if you're curious, but Director handles everything from here."
Do NOT list file paths, directory structures, or technical details. The user just needs to know it's done and how big the plan is.
After the wrap-up, suggest the next action. Blueprint consumes significant context (goal discussion, hierarchy review, research, file writing), so recommend clearing context before building.
"Ready to start building? Run
/clear, then/director:buildto kick things off fresh."
Wait for the user's response. Do not auto-execute the next command.
This section applies when the project already has a gameplan with real content (UPDATE mode detected above). The update flow re-evaluates the entire gameplan holistically, presents what changed, gets explicit approval, and writes updated files -- all while keeping completed work safe.
If $ARGUMENTS is non-empty, acknowledge it as the focus for this update:
"You want to [arguments]. Let me look at your current gameplan and see how that fits in."
Use the inline text as the primary context for what changed, but still re-evaluate the gameplan holistically. Even a focused request like "add payment processing" may affect ordering, grouping, or other parts of the plan.
If $ARGUMENTS is empty, ask what prompted the update:
"What's changed? New features to add, something to reorganize, or just want to review the plan?"
Wait for the user's response before continuing.
Read the current state of the gameplan:
.director/GAMEPLAN.md for the overview -- goals listed, current focus, general structure..director/goals/ directory to understand the full structure: read each GOAL.md, STEP.md, and task files to build a picture of what exists.Before loading research context, check whether the project's research and codebase analysis files are still current. Follow the same logic as the "Check Context Freshness" section in the new gameplan flow:
.director/config.json and extract context_generation.completed_goals_at_generation (default to 0 if the field does not exist)..director/goals/.After the check (or skip), continue to Load Research Context below.
Read .director/research/SUMMARY.md silently using cat .director/research/SUMMARY.md 2>/dev/null.
If the file exists and has content, store its contents internally wrapped in a <research_summary> tag:
<research_summary>
[Contents of SUMMARY.md]
</research_summary>
Use research findings to inform re-evaluation of goals -- the same way research informs initial planning:
If the file does not exist or is empty, proceed silently. Do NOT mention missing research to the user or agent. Do NOT include an empty <research_summary> tag.
Goals, steps, or tasks that are already done are FROZEN during updates. They are never removed, reordered, or modified.
If new context from the user would logically require changes to completed work, flag it conversationally:
"[Completed item] was already finished, but [new requirement] might need some adjustments to it. Want to add a task for that?"
Do NOT silently remove or modify completed items. The user must explicitly agree to any work that revisits something already done.
Before re-evaluating, scan VISION.md for [UNCLEAR] markers, just as in new gameplan mode. Present any found and offer to resolve or defer them.
Read the full content of VISION.md to understand the current vision state. Compare the existing goals against the vision plus any new context from the user (via $ARGUMENTS or the conversation).
Generate an updated goal set following the same Planning Rules from the new gameplan flow (Rule 1 through Rule 6 still apply).
Present updated goals together, highlighting what changed:
Here's how I'd update your goals:
- [Existing goal -- unchanged] -- [Same description]
- [Modified goal] -- [Updated description] (was: [old description])
- [New goal] -- [Why this was added]
[If any goals are being removed:] I'd suggest removing [goal name] because [reason].
[If completed goals exist:] Already done: [completed goal] -- keeping as-is.
What do you think?
Wait for the user's response. If they give feedback (add, remove, rename, reorder), adjust the goal set and re-present. Iterate until the user approves.
Important: Do NOT generate the updated Steps and Tasks yet. Goal changes must be approved first -- same two-phase flow as new gameplan mode.
After the user approves the updated goals, generate the full updated Steps and Tasks.
For each goal in the approved set:
Order everything following vertical slices (Rule 6) and what's needed first (Rule 4). Re-evaluate which tasks are "Ready" based on the updated structure -- new work may change what's ready and what's blocked.
Before showing the full updated outline, present a delta summary so the user can see exactly what changed:
Here's what I'd change:
Added:
- [New item with explanation of why]
Changed:
- [Modified item: was X, now Y, because Z]
Removed:
- [Removed item with reasoning]
Reordered:
- [Item moved: was in Step X, now in Step Y, because Z]
Already done (keeping as-is):
- [Completed items preserved]
Every removal must be explicitly stated with reasoning. No silent deletions.
The "Already done" section reassures the user that completed work is safe. Always include it, even if just to say "Nothing completed yet."
After the delta summary, present the full updated outline (same format as new gameplan mode -- goals, steps, tasks with one-line descriptions and size indicators):
Here's the complete updated gameplan:
Goal 1: [Goal Name] [done]
Step 1: [Step name] [done] - [Task name] (size) -- Done
Goal 2: [Goal Name] [updated]
Step 1: [Step name] - [Task name] (size) -- Ready - [New task name] (size) -- Needs [capability]
Step 2: [New step name] - [Task name] (size) -- Needs [capability]
Goal 3: [Goal Name] [new]
Step 1: [Step name] - [Task name] (size) -- Needs [capability from Goal 2]
Does this look good?
Wait for explicit approval. If the user gives feedback, adjust and re-present. Iterate until they approve.
Important: Do NOT write any files until the user explicitly approves this outline.
After the user approves the full updated outline, write the updated gameplan files.
Rewrite .director/GAMEPLAN.md with the updated overview, goals list, and current focus (same format as new gameplan mode).
For each goal, step, and task in the approved outline:
Step-Level Research in Update Mode:
Before writing updated files, step-level research runs for pending/new steps following the same logic as initial blueprint (see Step-Level Research section above). The following rules apply:
--research flag forces fresh research for all pending/new steps (not completed steps).--skip-research flag skips all step-level research during this update.Use the same file templates and directory structure as new gameplan mode. Use Bash for mkdir -p to create directories and the Write tool for file content. Do NOT narrate each file path or operation to the user.
When running in update mode:
Completed steps: Their Decisions sections are FROZEN. Do not modify, add, or remove decisions in completed steps, just as completed steps' tasks and content are frozen.
Modified/pending steps: Review the update conversation for new decisions. Merge new decisions with any existing decisions in the step's current STEP.md:
New steps: Capture decisions from the update conversation the same way as new gameplan mode.
Apply the same passive extraction approach -- do NOT ask the user to enumerate decisions for the update. Extract from the natural conversation.
After all updated files are written, save progress by committing all .director/ changes:
git add .director/
git commit -m "blueprint: update gameplan -- [brief summary of changes]"
This is a SILENT operation -- the user does not see git commands or commit details. If the commit fails, proceed silently. The important thing is that the files were written; the commit prevents "unsaved changes" warnings in /director:build.
After files are written and progress is saved, tell the user conversationally:
"Your gameplan is updated. [Brief summary of what changed -- e.g., 'Added 2 new steps for payment processing and moved the settings page after the dashboard.']"
Do NOT list file paths, directory structures, or technical details.
After the wrap-up, suggest the next action. Blueprint updates consume significant context, so recommend clearing context before building.
"Ready to keep building? Run
/clear, then/director:buildto pick up where you left off."
Wait for the user's response. Do not auto-execute the next command.
Throughout the entire blueprint flow, follow these rules:
$ARGUMENTS