Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
"I don't see any code to analyze. If you've added code since setting up, make sure it's in the project root."
Stop here.
Determine Refresh Scope
Check $ARGUMENTS for research-related terms. If arguments contain "research", "everything", "all", or "full": scope = FULL (codebase + research). Otherwise: scope = CODEBASE_ONLY.
Soft Guard for Research Without Vision
If scope is FULL, read .director/VISION.md. Check if it has only placeholder text (, headings with no substantive content, or style markers).
> This file will be populated when you run /director:onboard
_What are you calling this project?_
If VISION.md has only placeholder text:
"Your vision isn't set up yet, so research results may be generic. Want to continue anyway?"
Wait for response. If they decline, switch scope to CODEBASE_ONLY and continue.
Save Current State for Comparison
BEFORE running any pipelines, read the existing summary files so you can compare later:
Read .director/codebase/SUMMARY.md if it exists. Store contents as baseline. If file does not exist, this is a first-time scan (present findings instead of a diff).
If scope is FULL: also read .director/research/SUMMARY.md if it exists. Store as baseline.
If more than 500 source files, add a sampling note to each mapper's instructions: "This is a large codebase. Focus on the main source directories first. Sample representative files rather than reading everything. Note what you skipped."
Model Profile Resolution
Read .director/config.json and resolve the model for each agent:
Read the model_profile field (defaults to "balanced")
Look up the profile in model_profiles to get base model assignments for deep-mapper and synthesizer
For the quality profile, override the arch and concerns mappers to use the most capable model available
If config.json is missing the model_profile or model_profiles fields, fall back to "balanced" defaults (deep-mapper gets haiku, synthesizer gets sonnet).
Mapper Spawning
mkdir -p .director/codebase
Spawn 4 director:director-deep-mapper agents IN PARALLEL using 4 simultaneous Task tool calls. All 4 go in a SINGLE message so they run in parallel.
Agent 1 (tech focus):
<instructions>
Focus area: tech
Analyze the technology stack and external integrations of this codebase. Write your findings to:
- .director/codebase/STACK.md (using the template at skills/onboard/templates/codebase/STACK.md)
- .director/codebase/INTEGRATIONS.md (using the template at skills/onboard/templates/codebase/INTEGRATIONS.md)
Follow your standard mapping process for the tech focus area. Include file paths in backticks for every finding.
Return only a brief confirmation when done. Do NOT return document contents.
</instructions>
Agent 2 (arch focus):
<instructions>
Focus area: arch
Analyze the architecture patterns and file structure of this codebase. Write your findings to:
- .director/codebase/ARCHITECTURE.md (using the template at skills/onboard/templates/codebase/ARCHITECTURE.md)
- .director/codebase/STRUCTURE.md (using the template at skills/onboard/templates/codebase/STRUCTURE.md)
STRUCTURE.md must include a prescriptive "Where to Add New Code" section telling agents exactly where to place new files for each type of addition (new feature, new API route, new component, new test, etc.).
Follow your standard mapping process for the arch focus area. Include file paths in backticks for every finding.
Return only a brief confirmation when done. Do NOT return document contents.
</instructions>
Agent 3 (quality focus):
<instructions>
Focus area: quality
Analyze the coding conventions and testing patterns of this codebase. Write your findings to:
- .director/codebase/CONVENTIONS.md (using the template at skills/onboard/templates/codebase/CONVENTIONS.md)
- .director/codebase/TESTING.md (using the template at skills/onboard/templates/codebase/TESTING.md)
CONVENTIONS.md must use prescriptive voice throughout. Say "Use camelCase for functions" not "Some functions use camelCase." Every convention must be a clear instruction for builder agents.
Follow your standard mapping process for the quality focus area. Include file paths in backticks for every finding.
Return only a brief confirmation when done. Do NOT return document contents.
</instructions>
Agent 4 (concerns focus):
<instructions>
Focus area: concerns
Analyze technical debt, known issues, and fragile areas of this codebase. Write your findings to:
- .director/codebase/CONCERNS.md (using the template at skills/onboard/templates/codebase/CONCERNS.md)
Be specific about the impact of each concern and suggest a fix approach. Prioritize concerns by severity.
Follow your standard mapping process for the concerns focus area. Include file paths in backticks for every finding.
Return only a brief confirmation when done. Do NOT return document contents.
</instructions>
If any mapper fails or times out, continue with whatever mappers succeeded. The synthesizer can work with partial input. If ALL mappers fail, fall back to the v1.0 director:director-mapper agent for a basic overview instead.
Synthesizer Spawning
After ALL 4 mappers complete (or fail), spawn the director:director-synthesizer agent SEQUENTIALLY (not in parallel with mappers).
<instructions>
Mode: codebase
Read all codebase analysis files from .director/codebase/ (STACK.md, INTEGRATIONS.md, ARCHITECTURE.md, STRUCTURE.md, CONVENTIONS.md, TESTING.md, CONCERNS.md). Synthesize them into a unified summary.
Write your output to .director/codebase/SUMMARY.md using the template at skills/onboard/templates/codebase/SUMMARY.md.
Cross-reference findings across all files. If different mappers found related information about the same files or patterns, connect them. Resolve any contradictions.
Return only a brief confirmation when done. Do NOT return document contents.
</instructions>
Research Pipeline
Only execute this section if scope is FULL. If scope is CODEBASE_ONLY, skip to Present Changes.
"Researching your project's ecosystem..."
mkdir -p .director/research
Model Profile Resolution
Read .director/config.json and resolve models for deep-researcher and synthesizer using the same profile lookup as above. Fall back to "balanced" defaults if fields are missing.
Researcher Spawning
Spawn 4 director:director-deep-researcher agents IN PARALLEL using 4 simultaneous Task tool calls. All 4 go in a SINGLE message.
Context for researchers: use .director/VISION.md contents as primary context. If VISION.md has only placeholder text, also pass the NEW .director/codebase/SUMMARY.md (just produced by the mapping pipeline) so researchers have something substantive.
Agent 1 (stack domain):
<instructions>
Domain: stack
<project_context>
[Contents of VISION.md. If VISION.md is placeholder-only, also include the new codebase SUMMARY.md here.]
</project_context>
Research the recommended technology stack for this project. Investigate libraries, frameworks, databases, hosting options, and key supporting tools that would work well for this type of project.
Write your findings to .director/research/STACK.md using the template at skills/onboard/templates/research/STACK.md.
Use WebFetch to check official documentation for current versions and best practices. Verify recommendations against authoritative sources.
Return only a brief confirmation when done. Do NOT include file contents in your response.
</instructions>
Agent 2 (features domain):
<instructions>
Domain: features
<project_context>
[Contents of VISION.md. If VISION.md is placeholder-only, also include the new codebase SUMMARY.md here.]
</project_context>
Research features for this type of product. Investigate table stakes (what users expect), differentiators (what sets this product apart), and anti-features (what to avoid). Flag expected features the user may not have mentioned.
Write your findings to .director/research/FEATURES.md using the template at skills/onboard/templates/research/FEATURES.md.
Use WebFetch to check current product landscapes and feature expectations. Verify recommendations against authoritative sources.
Return only a brief confirmation when done. Do NOT include file contents in your response.
</instructions>
Agent 3 (architecture domain):
<instructions>
Domain: architecture
<project_context>
[Contents of VISION.md. If VISION.md is placeholder-only, also include the new codebase SUMMARY.md here.]
</project_context>
Research architecture patterns for this type of project. Investigate system structure, component boundaries, data flow patterns, and how similar projects are typically organized.
Write your findings to .director/research/ARCHITECTURE.md using the template at skills/onboard/templates/research/ARCHITECTURE.md.
Use WebFetch to check current architecture guides and best practices. Verify recommendations against authoritative sources.
Return only a brief confirmation when done. Do NOT include file contents in your response.
</instructions>
Agent 4 (pitfalls domain):
<instructions>
Domain: pitfalls
<project_context>
[Contents of VISION.md. If VISION.md is placeholder-only, also include the new codebase SUMMARY.md here.]
</project_context>
Research common mistakes and pitfalls for this type of project. Investigate stack-specific pitfalls AND broader domain pitfalls -- things that are harder than they look, common causes of rewrites, and what trips up builders working on this type of project.
Write your findings to .director/research/PITFALLS.md using the template at skills/onboard/templates/research/PITFALLS.md.
Use WebFetch to check current documentation for known issues and common mistakes. Verify findings against authoritative sources.
Return only a brief confirmation when done. Do NOT include file contents in your response.
</instructions>
Researcher Failure Handling
If any researcher fails or times out: check which domains completed by looking for files in .director/research/. If 3 of 4 succeeded, proceed with partial results and note the gap. If 2 or fewer succeeded, tell the user research had limited results. If ALL failed, tell the user research could not complete and move on gracefully.
Synthesizer Spawning (Research)
After ALL 4 researchers complete (or fail), spawn the director:director-synthesizer agent SEQUENTIALLY.
<instructions>
Mode: research
Read all 4 research files from .director/research/:
- STACK.md
- FEATURES.md
- ARCHITECTURE.md
- PITFALLS.md
Synthesize them into a unified summary.
Write your output to .director/research/SUMMARY.md using the template at skills/onboard/templates/research/SUMMARY.md.
The "Implications for Gameplan" section is critical -- recommend how to structure goals and steps based on the combined research. The "Don't Hand-Roll" section must identify problems with existing library solutions.
Cross-reference findings across all files. If STACK.md recommends a technology and PITFALLS.md warns about it, connect them. If FEATURES.md lists a capability and ARCHITECTURE.md shows how to structure it, link them.
Return only a brief confirmation when done. Do NOT return document contents.
</instructions>
Present Changes
Read the newly produced .director/codebase/SUMMARY.md. If scope is FULL, also read .director/research/SUMMARY.md.
If baseline existed (re-scan)
Compare the old and new SUMMARY.md files. Identify the 3-5 most significant changes: technology stack changes, architecture pattern changes, testing status changes, new or resolved concerns, new capabilities detected, structural reorganization. Skip minor changes.
"Your project context is updated. Here's what changed since the last scan:"
Codebase
[Change 1]
[Change 2]
[Change 3]
[If research was refreshed:]
Research
[Change 1]
[Change 2]
If nothing meaningful changed: "Your project context is updated. Everything looks the same as the last scan -- no significant changes detected."
If no baseline existed (first-time scan)
"This is the first time I've scanned your codebase. Here's what I found:"
What this project is -- [1-2 sentence summary]
Built with -- [Main framework], [database], [key libraries]
What it can do -- [2-3 user capabilities]
How it's organized -- [Brief structure]
Things worth noting -- [Top concerns, testing status]
Keep references HIGH-LEVEL. Present findings as collaborative observations, not judgments.
Update Metadata
Read .director/config.json. Count completed goals from .director/goals/. Set context_generation.completed_goals_at_generation to the count. Set context_generation.generated_at to today's date (YYYY-MM-DD). Write updated config.json. This is silent -- no user-facing output.
Save Progress
After all files are written (codebase mapping, research, config.json), save progress by committing all .director/ changes:
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 prevents "unsaved changes" warnings in later commands.
Wrap Up
"All done. Your downstream commands will automatically use the updated context."
