AutoGineer summary
Written by AutoGineer from the skill’s own files, not by the author
The RPI (Research, Design, and Implement) skill provides a systematic workflow for managing software development tasks. It guides users through a series of defined phases—from initial research and design discussions to PRD creation, technical design, and final implementation. By enforcing a consistent directory structure and documentation standard, it ensures that project context, design decisions, and implementation plans are clearly tracked and easily accessible throughout the development lifecycle.
What it does
- Facilitates structured research to define project requirements and technical constraints.
- Manages design discussions by presenting options, tradeoffs, and recommendations to the user.
- Generates standardized documentation for PRDs, TDDs, and implementation outlines.
- Maintains a task-specific directory for all workflow artifacts and supporting diagrams.
- Provides a clear path for iterative updates to existing design and requirement documents.
- Coordinates the transition between development phases with clear handoff instructions.
When to use it
- When starting a new software feature or complex technical change.
- When you need to document design decisions and architectural choices clearly.
- When you want to follow a repeatable, step-by-step process for software development.
- When you need to track the evolution of a task from research to implementation.
Advantages
- Ensures consistent documentation and project structure across different tasks.
- Promotes informed decision-making by presenting clear tradeoffs and recommendations.
- Keeps design and implementation plans synchronized with the codebase.
- Reduces ambiguity by requiring explicit user confirmation for design choices.
Usage examples
- “rpi”
- The agent initiates the RPI workflow, asks for the task description, and prompts the user to choose between research, design, or implementation phases.
- “rpi create-design-discussion”
- The agent begins the design discussion phase, analyzing existing research and codebase context to draft a design document with proposed architectural choices.
Install
Download the skill as a ZIP:
https://autogineer.com/agent-skills/humanlayer/rpi/downloadUnzip it into the cross-client skills folder of your project:
mkdir -p .agents/skills && unzip rpi.zip -d .agents/skills
Documentation by HumanLayer
Research, Design, and Implement
Help the user research a change, work through its design, and implement it. Follow their requested step, using the phase instructions below.
$SKILLBASE means the directory containing this SKILL.md.
<rpi-invocation> in templates means the host's skill command: $rpi in Codex, /rpi in Claude Code, or its plugin-qualified name when the host exposes one. Render next commands with that native invocation.
Choose the Step
Follow the user's requested step. Read $SKILLBASE/references/workflow.md when choosing or explaining a flow or what comes next.
For a task description with no requested step, start with research questions. Ask which flow the user wants: research followed by design discussion, PRD, or TDD, or research only. Wait for their choice before starting the phase, then carry it into suggested next commands.
When asking the user to choose a flow, read $SKILLBASE/references/workflow-choice.md and show its box-and-line chart with the question.
Create writes a new document; iterate updates an existing document in place using the user's feedback or resumes the workflow for a partially finished document.
Load the matching process from $SKILLBASE/references/<step>/process.md:
| Request | Step |
|---|---|
| Research questions | create-research-questions or iterate-research-questions |
| Research | create-research or iterate-research |
| Design discussion | create-design-discussion or iterate-design-discussion |
| Product requirements / PRD | create-prd or iterate-prd |
| Technical design / TDD | create-tdd or iterate-tdd |
| Implementation outline | create-structure-outline or iterate-structure-outline |
| Implement | implement-outline |
| Implementation feedback or fixes | iterate-implementation |
Update an existing document by default; create one when needed or requested. When several match, use the newest and name the chosen file.
Use the Task Directory
Use the directory supplied by the user.
Otherwise, look for existing task directories in .agents/artifacts/ whose names and workflow filenames match the request or current task branch. Reuse an obvious match without asking. If a directory looks close but could belong to a different task, or several directories look plausible, ask the user which to use before writing. Read only documents allowed by the selected phase when checking a match.
When no existing directory fits, use .agents/artifacts/<branch-name> with / replaced by - if the branch identifies the task. On main, or when no branch identifies the task, choose a short kebab-case slug from the request and use .agents/artifacts/<task-slug> without asking for approval. State the selected path and reuse or create the directory as needed.
Save at the selected path. If the sandbox blocks writes there, ask for scoped write access or a writable task directory and wait for the user's choice.
The RPI framework authors recommend not committing the artifacts.
Number new workflow documents using the next available NN- prefix in the task directory. Keep the existing path when updating a document. Save supporting mockups and diagrams beside the documents and link them as ordinary local files.
Workflow document frontmatter includes repos, a list of zero or more repositories with identifier and sha for each entry. Use repos: [] when none apply. Quote string values as needed for valid YAML.
Review the Document
After writing or updating a workflow document, read $SKILLBASE/references/prose.md and $SKILLBASE/references/show-me.md, then review the document against both. Make it shorter, more visual, and easier for a person to digest: cut words and sections that do not earn their place, replace dense prose with the smallest view that makes the point, and keep each visual beside the short text it supports.
Suggest the Next Step
Use the phase's handoff instructions and $SKILLBASE/references/workflow.md to choose what comes next. Users run each phase in a separate context window by default. When suggesting a next command, include the task directory and chosen flow. Say they can run it here, after compaction, or in a new session.
Use artifact filenames to locate the current phase when asked what's next, then read its document for unfinished work and settled choices. Recognize prd or product-requirements, tdd or tech-design, and structure-outline or outline.
Use Subagents
Use the bundled agent instructions for codebase-locator, codebase-analyzer, codebase-pattern-finder, web-search-researcher, and outline-implementer-agent as directed by each phase.
<important if="you do not have an Agent() or Task() or other tool for running subagents"> read the subagent instructions from $SKILLBASE/references/subagents/SUBAGENT_NAME.md </important>
<important if="you have a tool for running subagents or delegated sessions, but the named subagents are not available"> read the subagent instructions from $SKILLBASE/references/subagents/SUBAGENT_NAME.md and pass them into the subagent with your main prompt, with <instructions> REFERENCE_CONTENTS </instructions> <message> YOUR_MESSAGE ON WHAT TO LOOK FOR OR BUILD </message> </important>
Files
- ATTRIBUTION.mdAdded by AutoGineer847 B
- LICENSELicence file added by AutoGineer1.0 KiB
- SKILL.md5.2 KiB
- references/create-design-discussion/process.md4.0 KiB
- references/create-design-discussion/references/design_discussion_final_answer.md258 B
- references/create-design-discussion/references/design_discussion_final_answer_resolved.md461 B
- references/create-design-discussion/references/design_discussion_template.md1.0 KiB
- references/create-prd/process.md3.5 KiB
- references/create-prd/references/prd_final_answer_resolved.md438 B
- references/create-prd/references/prd_template.md853 B
- references/create-research-questions/process.md3.3 KiB
- references/create-research-questions/references/request_template.md312 B
- references/create-research-questions/references/research_questions_final_answer.md471 B
- references/create-research-questions/references/research_questions_template.md462 B
- references/create-research/process.md5.4 KiB
- references/create-research/references/research_final_answer.md651 B
- references/create-research/references/research_template.md1.6 KiB
- references/create-structure-outline/process.md3.2 KiB
- references/create-structure-outline/references/structure_outline_final_answer.md342 B
- references/create-structure-outline/references/structure_outline_template.md1.0 KiB
- references/create-tdd/process.md3.6 KiB
- references/create-tdd/references/tdd_final_answer_resolved.md451 B
- references/create-tdd/references/tdd_template.md776 B
- references/implement-outline/process.md2.9 KiB
- references/implement-outline/references/implement_outline_final_answer.md504 B
- references/iterate-design-discussion/process.md2.6 KiB
- references/iterate-design-discussion/references/design_discussion_final_answer.md258 B
- references/iterate-design-discussion/references/design_discussion_final_answer_resolved.md461 B
- references/iterate-design-discussion/references/design_discussion_template.md915 B
- references/iterate-implementation/process.md1.5 KiB
- references/iterate-implementation/references/iterate_implementation_final_answer.md382 B
- references/iterate-prd/process.md2.4 KiB
- references/iterate-prd/references/prd_final_answer_resolved.md438 B
- references/iterate-prd/references/prd_template.md853 B
- references/iterate-research-questions/process.md2.5 KiB
- references/iterate-research-questions/references/research_questions_final_answer.md473 B
- references/iterate-research-questions/references/research_questions_template.md462 B
- references/iterate-research/process.md4.4 KiB
- references/iterate-research/references/research_final_answer.md710 B
- references/iterate-research/references/research_template.md1.4 KiB
- references/iterate-structure-outline/process.md2.2 KiB
- references/iterate-structure-outline/references/structure_outline_final_answer.md344 B
- references/iterate-structure-outline/references/structure_outline_template.md1.0 KiB
- references/iterate-tdd/process.md2.7 KiB
- references/iterate-tdd/references/tdd_final_answer_resolved.md451 B
- references/iterate-tdd/references/tdd_template.md776 B
- references/prose.md1.5 KiB
- references/show-me.md3.2 KiB
- references/subagents/codebase-analyzer.md5.5 KiB
- references/subagents/codebase-locator.md4.7 KiB
- references/subagents/codebase-pattern-finder.md6.8 KiB
- references/subagents/outline-implementer-agent.md4.3 KiB
- references/subagents/web-search-researcher.md5.8 KiB
- references/workflow-choice.md2.5 KiB
- references/workflow.md3.7 KiB
references/iterate-research/process.md
Iterate Research
Correct or extend an existing research document using the user's feedback, or resume a partially finished investigation. Explain the system as it exists today, with evidence from code, tests, and available documentation.
Follow these steps in order.
1. Read the Research and Feedback
Read the selected research document in full in the main context before delegating. Use the research document and the user's feedback as the whole task context. Read the current-system source files or documentation they name in full. Load the original request and desired-state design documents in design and implementation sessions. Select an actual research report when locating the document; research questions are a separate document type.
For a complete document with no feedback, ask what the user wants to investigate or change. For unfinished research, continue from the recorded scope and open questions.
2. Identify What Needs Another Look
Check which findings the feedback affects, which questions remain unanswered, and what evidence is needed. Group related investigations into focused areas. Keep questions about current behavior and interactions, with future design choices in the design phase.
3. Conduct Additional Research
Use the appropriate agents for each investigation:
codebase-locatorfinds relevant source files, configuration, and tests.codebase-analyzertraces behavior, data flow, and component interactions.codebase-pattern-finderfinds existing examples and conventions.web-search-researcherchecks external sources when the user requests web research and returns links with its findings.
Use an Explore agent when useful. Locate code first where needed, then analyze the relevant implementations. Run independent investigations in parallel. Give each agent a focused, read-only task and ask for paths, line references, testing patterns, and supporting evidence.
Use available web or library-documentation tools for external questions. When web access is unavailable, note that limit and continue with code and local documentation.
4. Wait for Results and Verify the Findings
Wait for every investigation to finish. Check the evidence against live code, resolve conflicting results, and connect findings across components. Include external links when used. Keep remaining uncertainty explicit.
5. Read the Document Template and Visual Guidance
Read $SKILLBASE/references/iterate-research/references/research_template.md for the document structure, then read $SKILLBASE/references/show-me.md for visual explanations. Use current-state views to show how the system works today.
6. Update the Document in Place
Weave verified findings into the affected sections at the existing path. Rework those sections so the document reads as one coherent technical explanation. Preserve its frontmatter and update repository entries or status as needed. Record repositories as zero or more repos entries with identifier and sha, using repos: [] when none apply.
Give each findings section a header that states what is true. A reader should understand the main findings by skimming the headers alone. For example, use "Sessions persist before the daemon acknowledges the write" rather than "Session storage" or "How are sessions persisted?" Refresh affected headers in this style.
Explain each concept before citing where it lives. Support claims with file and line references, and keep the technical depth needed to answer the research scope. Place diagrams, tables, signatures, contracts, trees, and pseudocode beside the prose they explain.
For each affected component, update its testing patterns: test locations, approaches, fixtures, mocks, and utilities. State when no tests were found. Keep the summary, code-reference list, architecture documentation, and open questions in step with the findings.
Distinguish tests read from checks run. Support claims that a check passed with its command and observed result.
7. Read the Final-Answer Template and Respond
Read $SKILLBASE/references/iterate-research/references/research_final_answer.md and respond using that template. For a chosen workflow, use $SKILLBASE/references/workflow.md to suggest the next step with the task directory and flow. For standalone research, use the saved-document and review portions as the complete response.
Offer to open the document for review in VS Code, Cursor, or the user's preferred editor or browser.
Requirements and compatibility
Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta
“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.
Security
No issues found by our static scan· No issues found
A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.
Attribution and licence
- Published by
- HumanLayer
- Publisher
- HumanLayer (Official)
- Source
- humanlayer/skills · plugins/rpi/skills/rpi · commit 4d69d20
- Licence
- MIT License (redistribution allowed)
- LICENSE (added by AutoGineer from LICENSE)
- ATTRIBUTION.md (written by AutoGineer)
- Synced
AutoGineer is not affiliated with or endorsed by HumanLayer or HumanLayer.
Related skills
Setup TS Deep Modules
Matt Pocock· Community
Configures dependency-cruiser to enforce deep module boundaries in TypeScript repositories.
Software developmentClaude CodeClaude appsOpenAI Codex+14 moreMITLow riskHas scriptsGitHub stars of the source repository317.5k
To Spec
Matt Pocock· Community
Synthesizes conversation context into a structured technical specification and publishes it to a project issue tracker.
Software developmentClaude CodeClaude appsOpenAI Codex+14 moreMITGitHub stars of the source repository317.5k
Improve Codebase Architecture
Matt Pocock· Community
A systematic process to identify, visualize, and refine architectural deepening opportunities in a codebase.
Software developmentClaude CodeClaude appsOpenAI Codex+14 moreMITGitHub stars of the source repository317.5k
Domain Modeling
Matt Pocock· Community
An expert assistant for defining project terminology, maintaining a glossary, and documenting architectural decisions.
Software developmentClaude CodeClaude appsOpenAI Codex+14 moreMITGitHub stars of the source repository317.5k
Codebase Design
Matt Pocock· Community
A shared vocabulary and set of principles for designing deep, testable, and maintainable software modules.
Software developmentClaude CodeClaude appsOpenAI Codex+14 moreMITGitHub stars of the source repository317.5k
Prototype
Matt Pocock· Community
Build a throwaway prototype to answer a design question. Use when the user wants to sanity-check whether a state model or logic feels right, or explore what a UI should look like.
Software developmentClaude CodeClaude appsOpenAI Codex+14 moreMITGitHub stars of the source repository317.5k
Download ZIP
The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download rpi.zip