research-plan-implement
Skill19 starsChanged 8 months agoMITView on GitHub
End-to-end Research-Plan-Implement pipeline using parallel subagents. Each phase (research, plan, implement) runs in its own context window with file artifacts as the communication channel between phases.
4 other projects use a version of this.
Adopted by
Most recently taken up by
- RaditteAnggoro/skill-for-lazy-developertheir own version, first seen Nov 8, 2026
- thrashr888/thrashr888-agent-kittheir own version, first seen Aug 21, 2026
- kevinlin/skillstheir own version, first seen Jul 17, 2026
- wchen02/cursor-agent-learningtheir own version, first seen Mar 20, 2026
Other versions4 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 4
- kevinlin/skills★ 5same name
- thrashr888/thrashr888-agent-kit★ 5same name
- wchen02/cursor-agent-learning★ 3same name
- RaditteAnggoro/skill-for-lazy-developer★ 1same 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 repository16 other files it gives its agents.
- AGENTS.mdAGENTS.md
- brainstormingSkill
- documenting-decisionsSkill
- finishing-workSkill
- git-worktreesSkill
- implementing-plansSkill
- parallel-agentsSkill
- receiving-code-reviewSkill
- researching-codebaseSkill
- reviewing-codeSkill
- security-reviewSkill
- synthesizing-researchSkill
- systematic-debuggingSkill
- test-driven-developmentSkill
- verification-before-completionSkill
- writing-plansSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
19 rules. 0 are common, 18 are distinctive, and 1 is very specific to this project.
0
Common
Most of the 4 edited versions we read keep these.
18
Distinctive
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 53
Use this pipeline when:
- Distinctive: line 60
Do NOT use when:
- Distinctive: line 65
Only research is needed without implementation
- Distinctive: line 71
Before spawning subagents, break the feature into independent research questions.
- Distinctive: line 127
Verify questions are truly independent before parallelizing
- Distinctive: line 129
Keep to 2-4 subagents for manageability
- Distinctive: line 134
After research subagents complete, spawn a synthesis subagent that consolidates all findings using the synthesis skill.
- Distinctive: line 154
Read the research document and present a brief summary to the user.
- Distinctive: line 201
When the planning subagent completes, read the plan document and present a summary to the user:
- Distinctive: line 223
After plan approval, spawn an implementation subagent that reads the plan and executes it.
- Distinctive: line 256
When the implementation subagent completes, present results:
- Distinctive: line 267
If the subagent reported deviations or blockers, present them and ask the user how to proceed.
- Distinctive: line 273
If partial context already exists:
- Distinctive: line 275
Research exists: Read the file, skip to Phase 2 (plan)
- Distinctive: line 276
Plan exists: Read the file, skip to Phase 3 (implement)
- Distinctive: line 277
Only research needed: Stop after Phase 1
- Distinctive: line 291
If requirements are unclear, prepend brainstorming:
- Very specific: line 310
Use explicit model parameters when spawning subagents:
- Distinctive: line 330
Before each phase transition:
“Common” is measured: kept by at least 6 in 10 of the 4 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
Research-Plan-Implement Pipeline
Orchestrate the full Research → Plan → Implement workflow in a single session using subagents. Each phase runs as a separate subagent with its own context window, coordinated by the orchestrator that handles approval gates and phase transitions.
Purpose
Running RPI phases across separate sessions loses context and requires manual bridging. This skill collapses the three phases into one orchestrated pipeline using subagents via the Agent tool. Each subagent gets maximum context for its work, with file artifacts on disk as the communication channel between phases.
Architecture
The orchestrator (you) stays thin. It spawns subagents for each phase via the Agent tool, reads their output artifacts, presents summaries to the user, and handles approval gates. The orchestrator does NOT do research, planning, or implementation itself.
ORCHESTRATOR (main context — stays thin)
│
├── Phase 1: Spawn research subagents (parallel)
│ ├── Subagent: codebase exploration
│ ├── Subagent: web research
│ └── Subagent: synthesis → writes research file
│ └── Output: docs/plans/YYYY-MM-DD-<topic>-research.md
│
├── [APPROVAL GATE: User confirms research findings]
│
├── Phase 2: Spawn planning subagent
│ └── Subagent: reads research file, writes plan file
│ └── Output: docs/plans/YYYY-MM-DD-<topic>-plan.md
│
├── [APPROVAL GATE: User approves plan]
│
└── Phase 3: Spawn implementation subagent
└── Subagent: reads plan file, executes steps
└── Output: code changes, test resultsKey principle: Subagents communicate through files, not conversation context. Each subagent reads the artifacts from prior phases and writes its own artifacts for the next phase.
When to Use
Use this pipeline when:
- A feature requires understanding unfamiliar code or APIs
- Multiple aspects need investigation before planning
- The full research → plan → implement cycle is needed
- You want to avoid manually bridging sessions between phases
Do NOT use when:
- Requirements are already clear (skip to
rpikit:writing-plans) - A plan already exists (skip to
rpikit:implementing-plans) - This is a simple bug fix (use
rpikit:systematic-debugging) - Only research is needed without implementation
Phase 1: Research (Parallel Subagents)
Step 1: Define Research Questions
Before spawning subagents, break the feature into independent research questions. Typically 2-3 questions covering:
- Codebase context: How does the relevant code work today?
- External context: What APIs, libraries, or patterns are involved?
- Security/performance: Are there concerns to investigate?
Step 2: Spawn Research Subagents
Spawn subagents for each research question using the Agent tool. Each subagent gets its own context window. Use existing skills to ensure consistent methodology. Launch independent subagents in parallel by including multiple Agent tool calls in a single message.
Codebase researcher:
Spawn a subagent with the Agent tool:
name: "codebase-researcher"
model: "sonnet"
prompt: "Research [feature area] for the goal: [what will be implemented].
1. Invoke the Skill tool with skill: 'rpikit:researching-codebase'
and args: '[feature area]'
2. Follow the skill's full methodology (interrogation, exploration,
documentation)
3. Write your findings to docs/plans/YYYY-MM-DD-<topic>-codebase.md"Web researcher (when external context needed):
Spawn a subagent with the Agent tool:
name: "web-researcher"
model: "sonnet"
prompt: "Research [specific question about API, library, pattern, or best
practice].
Provide findings with source citations and confidence assessment.
Write your findings to docs/plans/YYYY-MM-DD-<topic>-external.md"Additional subagents (when needed):
Spawn a subagent with the Agent tool:
name: "security-researcher"
model: "sonnet"
prompt: "Investigate security and performance implications of [feature].
Write findings to docs/plans/YYYY-MM-DD-<topic>-security.md"Note: Research agents must NOT use
isolation: "worktree"— they write shared artifacts todocs/plans/that other agents and the main session need to read.
Guidelines:
- Verify questions are truly independent before parallelizing
- Each subagent gets a focused scope with clear deliverable
- Keep to 2-4 subagents for manageability
- Each subagent writes its findings to a separate file
Step 3: Synthesize Research
After research subagents complete, spawn a synthesis subagent that consolidates all findings using the synthesis skill.
Spawn a subagent with the Agent tool:
name: "synthesizer"
model: "sonnet"
prompt: "Synthesize all research findings for '<topic>'.
1. Invoke the Skill tool with skill: 'rpikit:synthesizing-research'
and args: '<topic>'
2. Follow the skill's full methodology to consolidate:
- docs/plans/YYYY-MM-DD-<topic>-codebase.md
- docs/plans/YYYY-MM-DD-<topic>-external.md
- [any additional research files]
3. Write the consolidated document to:
docs/plans/YYYY-MM-DD-<topic>-research.md"Step 4: Present Summary and Gate
Read the research document and present a brief summary to the user. Include the subagent results table:
| Agent | Task | Status | Key Findings |
Research complete for '<topic>'.
Key findings:
- [Finding 1]
- [Finding 2]
- [Finding 3]
Research document: docs/plans/YYYY-MM-DD-<topic>-research.mdUse AskUserQuestion:
- "Create plan" — proceed to Phase 2
- "More research needed" — spawn additional subagents
- "Stop here" — end with research document
Phase 2: Plan (Dedicated Subagent)
Spawn a planning subagent that reads the research document and creates the implementation plan. The subagent gets a fresh context window with only the research file as input.
Spawn a subagent with the Agent tool:
name: "planner"
model: "opus"
prompt: "You are creating an implementation plan.
1. Read the research document at
docs/plans/YYYY-MM-DD-<topic>-research.md
2. Invoke the Skill tool with skill: 'rpikit:writing-plans' and
args: '<topic>'
3. Follow the skill's full methodology to create the plan
4. Write the plan to docs/plans/YYYY-MM-DD-<topic>-plan.md
The plan must reference the research document and be self-contained.
Do NOT ask the user questions — use the research document as your
source of truth for requirements and constraints."Present Plan and Gate
When the planning subagent completes, read the plan document and present a summary to the user:
Plan created for '<topic>'.
Stakes: [level]
Phases: [count]
Steps: [count]
Plan document: docs/plans/YYYY-MM-DD-<topic>-plan.mdUse AskUserQuestion:
- "Approve and implement" — proceed to Phase 3
- "Request changes" — describe what to modify, spawn new planner
- "Stop here" — end with plan document
Do not skip this approval gate. The user must explicitly approve the plan before implementation begins.
Phase 3: Implement (Dedicated Subagent)
After plan approval, spawn an implementation subagent that reads the plan and executes it. The subagent gets a fresh context window with only the plan file as input.
Spawn a subagent with the Agent tool:
name: "implementer"
model: "opus"
isolation: "worktree"
prompt: "You are implementing an approved plan.
NOTE: You are running in an isolated worktree (isolation: worktree).
The implementing-plans skill will detect this via 'test -f .git' and
skip the worktree offer — this is expected behavior.
1. Read the plan at docs/plans/YYYY-MM-DD-<topic>-plan.md
2. Invoke the Skill tool with skill: 'rpikit:implementing-plans' and
args: 'docs/plans/YYYY-MM-DD-<topic>-plan.md'
3. Follow the skill's full methodology:
- Execute steps in order
- Run verification after each step
- Track progress
- Run code review and security review at completion
4. Update the plan document status as you complete steps
5. CRITICAL: git commit ALL changes before completing — uncommitted
work in an isolated worktree is silently destroyed on cleanup
The plan has been approved by the user. Execute it as written. If you
encounter issues that require plan changes, document them and return
the issue — do NOT deviate silently."Report Results
When the implementation subagent completes, present results:
Implementation complete for '<topic>'.
Steps completed: [N/M]
Files changed: [list]
Tests: [pass/fail]
Reviews: [code review status, security review status]If the subagent reported deviations or blockers, present them and ask the user how to proceed.
Customizing the Pipeline
Skipping Phases
If partial context already exists:
- Research exists: Read the file, skip to Phase 2 (plan)
- Plan exists: Read the file, skip to Phase 3 (implement)
- Only research needed: Stop after Phase 1
Adjusting Research Depth
Match research depth to complexity:
| Complexity | Research Subagents | Expected Duration |
| Simple | 1 (codebase) | Quick |
| Moderate | 2 (code + web) | Medium |
| Complex | 3-4 (multiple) | Thorough |
Adding Brainstorming
If requirements are unclear, prepend brainstorming:
Skill tool with skill: "rpikit:brainstorming"Then resume the pipeline at Phase 1 with clarified requirements.
Orchestrator Rules
The orchestrator MUST stay thin:
- Do: Spawn subagents, read artifacts, present summaries, gate approvals
- Do NOT: Research code, write plans, implement changes, or read source files beyond the phase artifacts
This ensures the orchestrator's context remains small, leaving maximum context for each subagent.
Model Selection
Use explicit model parameters when spawning subagents:
| Model | Use For | Rationale |
haiku | file-finder, quick lookups | Fast, cost-effective |
sonnet | research agents, synthesis, code review | Balanced capability |
opus | planning, implementation, architecture | Deep reasoning needed |
Anti-Patterns
| Do Not | Instead |
| Do research/planning/implementation as orchestrator | Delegate each phase to a subagent |
| Pass findings through conversation context | Write to files, read from files |
| Spawn 5+ research subagents | Keep to 2-4 focused subagents |
| Skip approval gates between phases | Always get explicit user approval |
| Combine dependent research questions | Only parallelize independent questions |
Quality Checklist
Before each phase transition:
- All subagents for current phase completed
- Phase artifact written to
docs/plans/ - Subagent results summary table presented
- User approved before proceeding to next phase
- Orchestrator context remains thin (no research/planning content)
At pipeline completion:
- All artifacts saved to
docs/plans/ - Final results presented to user
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.

