deepen-plan
Skill7 starsChanged 3 months agoMITView on GitHub
Enhance a plan with parallel research agents for each section to add depth, best practices, and implementation details
3 other projects use a version of this, 2 of them edited.
Adopted by
Most recently taken up by
- MoizIbnYousaf/marketing-clitheir own version, first seen Nov 1, 2026
- thedigitalorganizer/soloshipedited, first seen Oct 15, 2026
- CodeWithBehnam/cc-docsedited, first seen Mar 15, 2026
Other versions3 projects use a version of this.
Word for word · 0
None found.
Edited · 2
- CodeWithBehnam/cc-docs★ 295% same
- thedigitalorganizer/soloship★ 081% same
Wrote their own version · 1
- MoizIbnYousaf/marketing-cli★ 33same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository25 other files it gives its agents.
- .github/copilot-instructions.mdCopilot instructions
- enlightenSkill
- brainstormingSkill
- ce-brainstormSkill
- ce-compound-refreshSkill
- ce-compoundSkill
- ce-ideateSkill
- ce-planSkill
- ce-reviewSkill
- ce-workSkill
- claude-permissions-optimizerSkill
- document-reviewSkill
- evolveSkill
- feature-videoSkill
- instinctsSkill
- karpathy-guidelinesSkill
- learnSkill
- lfgSkill
- observeSkill
- ralph-loopSkill
- resolve_todo_parallelSkill
- setupSkill
- slfgSkill
- test-browserSkill
- unslopSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
28 rules. 19 are common, 0 are distinctive, and 9 are very specific to this project.
19
Common
Most of the 3 edited versions we read keep these.
0
Distinctive
This author's own choices. Worth a look.
9
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Common: line 13
Note: The current year is 2026: Use this when searching for recent documentation and best practices.
- Very specific: line 29
Check for recent plans: ls -la docs/plans/
- Very specific: line 30
Ask the user: "Which plan would you like to deepen?
- Common: line 32
Do not proceed until you have a valid plan file path.
- Common: line 85
Important: Check EVERY source. Don't assume compound-engineering is the only plugin.
- Very specific: line 97
Read its SKILL.md description
- Common: line 98
Check if any plan sections match the skill's domain
- Common: line 99
If there's a match, spawn a sub-agent to apply that skill's knowledge
- Common: line 150
Check for documented learnings from /ce-compound.
- Common: line 173
Run these commands to get every learning file:
- Common: line 298
Search for recent (2024-2026) articles, blog posts, and documentation on topics in the plan.
- Common: line 328
Important: Check EVERY source. Include agents from:
- Common: line 332
ALL other installed plugins (agent-sdk-dev, frontend-design, etc.)
- Very specific: line 336
USE: agents/review/* (all reviewers)
- Very specific: line 337
USE: agents/research/* (all researchers)
- Very specific: line 338
USE: agents/design/* (design agents)
- Very specific: line 339
USE: agents/docs/* (documentation agents)
- Common: line 344
Read the first few lines of each agent file to understand what it reviews/analyzes.
- Common: line 355
Do NOT filter agents by "relevance" - run them ALL
- Common: line 356
Do NOT skip agents because they "might not apply" - let them decide
- Common: line 369
Wait for ALL parallel agents to complete - skills, research agents, review agents, everything.
- Common: line 377
Review agents: - All feedback from every reviewer (architecture, security, performance, simplicity, etc.)
- Very specific: line 460
Add -deepened suffix if user prefers a new file
- Common: line 461
Update any timestamps or metadata
- Very specific: line 465
Update the plan file in place (or if user requests a separate file, append -deepened after -plan, e.g., …
- Common: line 479
After writing the enhanced plan, use the AskUserQuestion tool to present these options:
- Common: line 487
Deepen further: - Run another round of research on specific sections
- Common: line 548
NEVER CODE! Just research and enhance the plan.
“Common” is measured: kept by at least 6 in 10 of the 3 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Arguments
[path to plan file]
Deepen Plan - Power Enhancement Mode
Introduction
Note: The current year is 2026. Use this when searching for recent documentation and best practices.
This command takes an existing plan (from /ce-plan) and enhances each section with parallel research agents. Each major element gets its own dedicated research sub-agent to find:
- Best practices and industry patterns
- Performance optimizations
- UI/UX improvements (if applicable)
- Quality enhancements and edge cases
- Real-world implementation examples
The result is a deeply grounded, production-ready plan with concrete implementation details.
Plan File
<plan_path> #$ARGUMENTS </plan_path>
If the plan path above is empty:
- Check for recent plans:
ls -la docs/plans/ - Ask the user: "Which plan would you like to deepen? Please provide the path (e.g.,
docs/plans/2026-01-15-feat-my-feature-plan.md)."
Do not proceed until you have a valid plan file path.
Main Tasks
1. Parse and Analyze Plan Structure
<thinking>
First, read and parse the plan to identify each major section that can be enhanced with research.
</thinking>Read the plan file and extract:
- Overview/Problem Statement
- Proposed Solution sections
- Technical Approach/Architecture
- Implementation phases/steps
- Code examples and file references
- Acceptance criteria
- Any UI/UX components mentioned
- Technologies/frameworks mentioned (Rails, React, Python, TypeScript, etc.)
- Domain areas (data models, APIs, UI, security, performance, etc.)
Create a section manifest:
Section 1: [Title] - [Brief description of what to research]
Section 2: [Title] - [Brief description of what to research]
...2. Discover and Apply Available Skills
<thinking>
Dynamically discover all available skills and match them to plan sections. Don't assume what skills exist - discover them at runtime.
</thinking>Step 1: Discover ALL available skills from ALL sources
# 1. Project-local skills (highest priority - project-specific)
ls .github/skills/
# 2. User's global skills (~/.copilot/)
ls ~/.copilot/skills/
# 3. compound-engineering plugin skills
ls ~/.copilot/plugins/cache/*/compound-engineering/*/skills/
# 4. ALL other installed plugins - check every plugin for skills
find ~/.copilot/plugins/cache -type d -name "skills" 2>/dev/null
# 5. Also check installed_plugins.json for all plugin locations
cat ~/.copilot/plugins/installed_plugins.jsonImportant: Check EVERY source. Don't assume compound-engineering is the only plugin. Use skills from ANY installed plugin that's relevant.
Step 2: For each discovered skill, read its SKILL.md to understand what it does
# For each skill directory found, read its documentation
cat [skill-path]/skill.mdStep 3: Match skills to plan content
For each skill discovered:
- Read its SKILL.md description
- Check if any plan sections match the skill's domain
- If there's a match, spawn a sub-agent to apply that skill's knowledge
Step 4: Spawn a sub-agent for EVERY matched skill
CRITICAL: For EACH skill that matches, spawn a separate sub-agent and instruct it to USE that skill.
For each matched skill:
Task general-purpose: "You have the [skill-name] skill available at [skill-path].
YOUR JOB: Use this skill on the plan.
1. Read the skill: cat [skill-path]/skill.md
2. Follow the skill's instructions exactly
3. Apply the skill to this content:
[relevant plan section or full plan]
4. Return the skill's full output
The skill tells you what to do - follow it. Execute the skill completely."Spawn ALL skill sub-agents in PARALLEL:
- 1 sub-agent per matched skill
- Each sub-agent reads and uses its assigned skill
- All run simultaneously
- 10, 20, 30 skill sub-agents is fine
Each sub-agent:
- Reads its skill's SKILL.md
- Follows the skill's workflow/instructions
- Applies the skill to the plan
- Returns whatever the skill produces (code, recommendations, patterns, reviews, etc.)
Example spawns:
Task general-purpose: "Use the dhh-rails-style skill at ~/.copilot/plugins/.../dhh-rails-style. Read SKILL.md and apply it to: [Rails sections of plan]"
Task general-purpose: "Use the frontend-design skill at ~/.copilot/plugins/.../frontend-design. Read SKILL.md and apply it to: [UI sections of plan]"
Task general-purpose: "Use the agent-native-architecture skill at ~/.copilot/plugins/.../agent-native-architecture. Read SKILL.md and apply it to: [agent/tool sections of plan]"
Task general-purpose: "Use the security-patterns skill at ~/.copilot/skills/security-patterns. Read SKILL.md and apply it to: [full plan]"No limit on skill sub-agents. Spawn one for every skill that could possibly be relevant.
3. Discover and Apply Learnings/Solutions
<thinking>
Check for documented learnings from /ce-compound. These are solved problems stored as markdown files. Spawn a sub-agent for each learning to check if it's relevant.
</thinking>LEARNINGS LOCATION - Check these exact folders:
docs/solutions/ <-- PRIMARY: Project-level learnings (created by /ce-compound)
├── performance-issues/
│ └── *.md
├── debugging-patterns/
│ └── *.md
├── configuration-fixes/
│ └── *.md
├── integration-issues/
│ └── *.md
├── deployment-issues/
│ └── *.md
└── [other-categories]/
└── *.mdStep 1: Find ALL learning markdown files
Run these commands to get every learning file:
# PRIMARY LOCATION - Project learnings
find docs/solutions -name "*.md" -type f 2>/dev/null
# If docs/solutions doesn't exist, check alternate locations:
find .github/docs -name "*.md" -type f 2>/dev/null
find ~/.copilot/docs -name "*.md" -type f 2>/dev/nullStep 2: Read frontmatter of each learning to filter
Each learning file has YAML frontmatter with metadata. Read the first ~20 lines of each file to get:
---
title: "N+1 Query Fix for Briefs"
category: performance-issues
tags: [activerecord, n-plus-one, includes, eager-loading]
module: Briefs
symptom: "Slow page load, multiple queries in logs"
root_cause: "Missing includes on association"
---For each .md file, quickly scan its frontmatter:
# Read first 20 lines of each learning (frontmatter + summary)
head -20 docs/solutions/**/*.mdStep 3: Filter - only spawn sub-agents for LIKELY relevant learnings
Compare each learning's frontmatter against the plan:
tags:- Do any tags match technologies/patterns in the plan?category:- Is this category relevant? (e.g., skip deployment-issues if plan is UI-only)module:- Does the plan touch this module?symptom:/root_cause:- Could this problem occur with the plan?
SKIP learnings that are clearly not applicable:
- Plan is frontend-only → skip
database-migrations/learnings - Plan is Python → skip
rails-specific/learnings - Plan has no auth → skip
authentication-issues/learnings
SPAWN sub-agents for learnings that MIGHT apply:
- Any tag overlap with plan technologies
- Same category as plan domain
- Similar patterns or concerns
Step 4: Spawn sub-agents for filtered learnings
For each learning that passes the filter:
Task general-purpose: "
LEARNING FILE: [full path to .md file]
1. Read this learning file completely
2. This learning documents a previously solved problem
Check if this learning applies to this plan:
---
[full plan content]
---
If relevant:
- Explain specifically how it applies
- Quote the key insight or solution
- Suggest where/how to incorporate it
If NOT relevant after deeper analysis:
- Say 'Not applicable: [reason]'
"Example filtering:
# Found 15 learning files, plan is about "Rails API caching"
# SPAWN (likely relevant):
docs/solutions/performance-issues/n-plus-one-queries.md # tags: [activerecord] ✓
docs/solutions/performance-issues/redis-cache-stampede.md # tags: [caching, redis] ✓
docs/solutions/configuration-fixes/redis-connection-pool.md # tags: [redis] ✓
# SKIP (clearly not applicable):
docs/solutions/deployment-issues/heroku-memory-quota.md # not about caching
docs/solutions/frontend-issues/stimulus-race-condition.md # plan is API, not frontend
docs/solutions/authentication-issues/jwt-expiry.md # plan has no authSpawn sub-agents in PARALLEL for all filtered learnings.
These learnings are institutional knowledge - applying them prevents repeating past mistakes.
4. Launch Per-Section Research Agents
<thinking>
For each major section in the plan, spawn dedicated sub-agents to research improvements. Use the Explore agent type for open-ended research.
</thinking>For each identified section, launch parallel research:
Task Explore: "Research best practices, patterns, and real-world examples for: [section topic].
Find:
- Industry standards and conventions
- Performance considerations
- Common pitfalls and how to avoid them
- Documentation and tutorials
Return concrete, actionable recommendations."Also use Context7 MCP for framework documentation:
For any technologies/frameworks mentioned in the plan, query Context7:
mcp__plugin_compound-engineering_context7__resolve-library-id: Find library ID for [framework]
mcp__plugin_compound-engineering_context7__query-docs: Query documentation for specific patternsUse WebSearch for current best practices:
Search for recent (2024-2026) articles, blog posts, and documentation on topics in the plan.
5. Discover and Run ALL Review Agents
<thinking>
Dynamically discover every available agent and run them ALL against the plan. Don't filter, don't skip, don't assume relevance. 40+ parallel agents is fine. Use everything available.
</thinking>Step 1: Discover ALL available agents from ALL sources
# 1. Project-local agents (highest priority - project-specific)
find .github/agents -name "*.md" 2>/dev/null
# 2. User's global agents (~/.copilot/)
find ~/.copilot/agents -name "*.md" 2>/dev/null
# 3. compound-engineering plugin agents (all subdirectories)
find ~/.copilot/plugins/cache/*/compound-engineering/*/agents -name "*.md" 2>/dev/null
# 4. ALL other installed plugins - check every plugin for agents
find ~/.copilot/plugins/cache -path "*/agents/*.md" 2>/dev/null
# 5. Check installed_plugins.json to find all plugin locations
cat ~/.copilot/plugins/installed_plugins.json
# 6. For local plugins (isLocal: true), check their source directories
# Parse installed_plugins.json and find local plugin pathsImportant: Check EVERY source. Include agents from:
- Project
.github/agents/ - User's
~/.copilot/agents/ - compound-engineering plugin (but SKIP workflow/ agents - only use review/, research/, design/, docs/)
- ALL other installed plugins (agent-sdk-dev, frontend-design, etc.)
- Any local plugins
For compound-engineering plugin specifically:
- USE:
agents/review/*(all reviewers) - USE:
agents/research/*(all researchers) - USE:
agents/design/*(design agents) - USE:
agents/docs/*(documentation agents) - SKIP:
agents/workflow/*(these are workflow orchestrators, not reviewers)
Step 2: For each discovered agent, read its description
Read the first few lines of each agent file to understand what it reviews/analyzes.
Step 3: Launch ALL agents in parallel
For EVERY agent discovered, launch a Task in parallel:
Task [agent-name]: "Review this plan using your expertise. Apply all your checks and patterns. Plan content: [full plan content]"CRITICAL RULES:
- Do NOT filter agents by "relevance" - run them ALL
- Do NOT skip agents because they "might not apply" - let them decide
- Launch ALL agents in a SINGLE message with multiple Task tool calls
- 20, 30, 40 parallel agents is fine - use everything
- Each agent may catch something others miss
- The goal is MAXIMUM coverage, not efficiency
Step 4: Also discover and run research agents
Research agents (like best-practices-researcher, framework-docs-researcher, git-history-analyzer, repo-research-analyst) should also be run for relevant plan sections.
6. Wait for ALL Agents and Synthesize Everything
<thinking>
Wait for ALL parallel agents to complete - skills, research agents, review agents, everything. Then synthesize all findings into a comprehensive enhancement.
</thinking>Collect outputs from ALL sources:
- Skill-based sub-agents - Each skill's full output (code examples, patterns, recommendations)
- Learnings/Solutions sub-agents - Relevant documented learnings from /ce-compound
- Research agents - Best practices, documentation, real-world examples
- Review agents - All feedback from every reviewer (architecture, security, performance, simplicity, etc.)
- Context7 queries - Framework documentation and patterns
- Web searches - Current best practices and articles
For each agent's findings, extract:
- Concrete recommendations (actionable items)
- Code patterns and examples (copy-paste ready)
- Anti-patterns to avoid (warnings)
- Performance considerations (metrics, benchmarks)
- Security considerations (vulnerabilities, mitigations)
- Edge cases discovered (handling strategies)
- Documentation links (references)
- Skill-specific patterns (from matched skills)
- Relevant learnings (past solutions that apply - prevent repeating mistakes)
Deduplicate and prioritize:
- Merge similar recommendations from multiple agents
- Prioritize by impact (high-value improvements first)
- Flag conflicting advice for human review
- Group by plan section
7. Enhance Plan Sections
<thinking>
Merge research findings back into the plan, adding depth without changing the original structure.
</thinking>Enhancement format for each section:
## [Original Section Title]
[Original content preserved]
### Research Insights
**Best Practices:**
- [Concrete recommendation 1]
- [Concrete recommendation 2]
**Performance Considerations:**
- [Optimization opportunity]
- [Benchmark or metric to target]
**Implementation Details:**
```[language]
// Concrete code example from researchEdge Cases:
- [Edge case 1 and how to handle]
- [Edge case 2 and how to handle]
References:
- [Documentation URL 1]
- [Documentation URL 2]
### 8. Add Enhancement Summary
At the top of the plan, add a summary section:
```markdown
## Enhancement Summary
**Deepened on:** [Date]
**Sections enhanced:** [Count]
**Research agents used:** [List]
### Key Improvements
1. [Major improvement 1]
2. [Major improvement 2]
3. [Major improvement 3]
### New Considerations Discovered
- [Important finding 1]
- [Important finding 2]9. Update Plan File
Write the enhanced plan:
- Preserve original filename
- Add
-deepenedsuffix if user prefers a new file - Update any timestamps or metadata
Output Format
Update the plan file in place (or if user requests a separate file, append -deepened after -plan, e.g., 2026-01-15-feat-auth-plan-deepened.md).
Quality Checks
Before finalizing:
- All original content preserved
- Research insights clearly marked and attributed
- Code examples are syntactically correct
- Links are valid and relevant
- No contradictions between sections
- Enhancement summary accurately reflects changes
Post-Enhancement Options
After writing the enhanced plan, use the AskUserQuestion tool to present these options:
Question: "Plan deepened at [plan_path]. What would you like to do next?"
Options:
- View diff - Show what was added/changed
- Run
/technical_review- Get feedback from reviewers on enhanced plan - Start
/ce-work- Begin implementing this enhanced plan - Deepen further - Run another round of research on specific sections
- Revert - Restore original plan (if backup exists)
Based on selection:
- View diff → Run
git diff [plan_path]or show before/after /technical_review→ Call the /technical_review command with the plan file path/ce-work→ Call the /ce-work command with the plan file path- Deepen further → Ask which sections need more research, then re-run those agents
- Revert → Restore from git or backup
Example Enhancement
Before (from /workflows-plan):
## Technical Approach
Use React Query for data fetching with optimistic updates.After (from /workflows-deepen-plan):
## Technical Approach
Use React Query for data fetching with optimistic updates.
### Research Insights
**Best Practices:**
- Configure `staleTime` and `cacheTime` based on data freshness requirements
- Use `queryKey` factories for consistent cache invalidation
- Implement error boundaries around query-dependent components
**Performance Considerations:**
- Enable `refetchOnWindowFocus: false` for stable data to reduce unnecessary requests
- Use `select` option to transform and memoize data at query level
- Consider `placeholderData` for instant perceived loading
**Implementation Details:**
```typescript
// Recommended query configuration
const queryClient = new QueryClient({
defaultOptions: {
queries: {
staleTime: 5 * 60 * 1000, // 5 minutes
retry: 2,
refetchOnWindowFocus: false,
},
},
});Edge Cases:
- Handle race conditions with
cancelQuerieson component unmount - Implement retry logic for transient network failures
- Consider offline support with
persistQueryClient
References:
- https://tanstack.com/query/latest/docs/react/guides/optimistic-updates
- https://tkdodo.eu/blog/practical-react-query
NEVER CODE! Just research and enhance the plan.Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

