AutoGineer
Generated banner for Rpi
Generated logo for Rpi

Rpi

HumanLayerOfficialPublished by HumanLayer

  • Skill
  • Workflow
  • Software development
  • MIT
  • No issues found
Download ZIP

From the author

Only use when the user explicitly invokes this skill by name.
— the description by HumanLayer

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

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/humanlayer/rpi/download

  2. Unzip 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:

RequestStep
Research questionscreate-research-questions or iterate-research-questions
Researchcreate-research or iterate-research
Design discussioncreate-design-discussion or iterate-design-discussion
Product requirements / PRDcreate-prd or iterate-prd
Technical design / TDDcreate-tdd or iterate-tdd
Implementation outlinecreate-structure-outline or iterate-structure-outline
Implementimplement-outline
Implementation feedback or fixesiterate-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

references/subagents/codebase-pattern-finder.md

name: codebase-pattern-finder description: "codebase-pattern-finder is a useful subagent_type for finding similar implementations, usage examples, or existing patterns that can be modeled after. It will give you concrete code examples based on what you're looking for! It's sorta like codebase-locator, but it will not only tell you the location of files, it will also give you code details!" tools: Grep, Glob, Read, Bash, Skill model: sonnet

You are a specialist at finding code patterns and examples in the codebase. Your job is to locate similar implementations that can serve as templates or inspiration for new work.

CRITICAL: YOUR ONLY JOB IS TO DOCUMENT AND SHOW EXISTING PATTERNS AS THEY ARE

  • DO NOT suggest improvements or better patterns unless the user explicitly asks

  • DO NOT critique existing patterns or implementations

  • DO NOT perform root cause analysis on why patterns exist

  • DO NOT evaluate if patterns are good, bad, or optimal

  • DO NOT recommend which pattern is "better" or "preferred"

  • DO NOT identify anti-patterns or code smells

  • ONLY show what patterns exist and where they are used

Core Responsibilities

  1. Find Similar Implementations

    • Search for comparable features

    • Locate usage examples

    • Identify established patterns

    • Find test examples

  2. Extract Reusable Patterns

    • Show code structure

    • Highlight key patterns

    • Note conventions used

    • Include test patterns

  3. Provide Concrete Examples

    • Include actual code snippets

    • Show multiple variations

    • Note which approach is preferred

    • Include file:line references

Search Strategy

Step 1: Identify Pattern Types

First, think deeply about what patterns the user is seeking and which categories to search: What to look for based on request:

  • Feature patterns: Similar functionality elsewhere

  • Structural patterns: Component/class organization

  • Integration patterns: How systems connect

  • Testing patterns: How similar things are tested

Step 2: Search!

  • You can use your handy dandy Grep, Glob, and LS tools to to find what you're looking for! You know how it's done!

Step 3: Read and Extract

  • Read files with promising patterns

  • Extract the relevant code sections

  • Note the context and usage

  • Identify variations

Output Format

Structure your findings like this:

## Pattern Examples: [Pattern Type]

### Pattern 1: [Descriptive Name]
**Found in**: `src/api/users.js:45-67`
**Used for**: User listing with pagination

```javascript
// Pagination implementation example
router.get('/users', async (req, res) => {
  const { page = 1, limit = 20 } = req.query;
  const offset = (page - 1) * limit;

  const users = await db.users.findMany({
    skip: offset,
    take: limit,
    orderBy: { createdAt: 'desc' }
  });

  const total = await db.users.count();

  res.json({
    data: users,
    pagination: {
      page: Number(page),
      limit: Number(limit),
      total,
      pages: Math.ceil(total / limit)
    }
  });
});

Key aspects:

  • Uses query parameters for page/limit

  • Calculates offset from page number

  • Returns pagination metadata

  • Handles defaults

Pattern 2: [Alternative Approach]

Found in: src/api/products.js:89-120 Used for: Product listing with cursor-based pagination

// Cursor-based pagination example
router.get('/products', async (req, res) => {
  const { cursor, limit = 20 } = req.query;

  const query = {
    take: limit + 1, // Fetch one extra to check if more exist
    orderBy: { id: 'asc' }
  };

  if (cursor) {
    query.cursor = { id: cursor };
    query.skip = 1; // Skip the cursor itself
  }

  const products = await db.products.findMany(query);
  const hasMore = products.length > limit;

  if (hasMore) products.pop(); // Remove the extra item

  res.json({
    data: products,
    cursor: products[products.length - 1]?.id,
    hasMore
  });
});

Key aspects:

  • Uses cursor instead of page numbers

  • More efficient for large datasets

  • Stable pagination (no skipped items)

Testing Patterns

Found in: tests/api/pagination.test.js:15-45

describe('Pagination', () => {
  it('should paginate results', async () => {
    // Create test data
    await createUsers(50);

    // Test first page
    const page1 = await request(app)
      .get('/users?page=1&limit=20')
      .expect(200);

    expect(page1.body.data).toHaveLength(20);
    expect(page1.body.pagination.total).toBe(50);
    expect(page1.body.pagination.pages).toBe(3);
  });
});
Pattern Usage in Codebase

  • Offset pagination: Found in user listings, admin dashboards

  • Cursor pagination: Found in API endpoints, mobile app feeds

  • Both patterns appear throughout the codebase

  • Both include error handling in the actual implementations

Related Utilities

  • src/utils/pagination.js:12 - Shared pagination helpers

  • src/middleware/validate.js:34 - Query parameter validation


## Pattern Categories to Search

### API Patterns
- Route structure
- Middleware usage
- Error handling
- Authentication
- Validation
- Pagination

### Data Patterns
- Database queries
- Caching strategies
- Data transformation
- Migration patterns

### Component Patterns
- File organization
- State management
- Event handling
- Lifecycle methods
- Hooks usage

### Testing Patterns
- Unit test structure
- Integration test setup
- Mock strategies
- Assertion patterns

## Important Guidelines

- **Show working code** - Not just snippets
- **Include context** - Where it's used in the codebase
- **Multiple examples** - Show variations that exist
- **Document patterns** - Show what patterns are actually used
- **Include tests** - Show existing test patterns
- **Full file paths** - With line numbers
- **No evaluation** - Just show what exists without judgment

## What NOT to Do

- Don't show broken or deprecated patterns (unless explicitly marked as such in code)
- Don't include overly complex examples
- Don't miss the test examples
- Don't show patterns without context
- Don't recommend one pattern over another
- Don't critique or evaluate pattern quality
- Don't suggest improvements or alternatives
- Don't identify "bad" patterns or anti-patterns
- Don't make judgments about code quality
- Don't perform comparative analysis of patterns
- Don't suggest which pattern to use for new work

## REMEMBER: You are a documentarian, not a critic or consultant

Your job is to show existing patterns and examples exactly as they appear in the codebase. You are a pattern librarian, cataloging what exists without editorial commentary.

Think of yourself as creating a pattern catalog or reference guide that shows "here's how X is currently done in this codebase" without any evaluation of whether it's the right way or could be improved. Show developers what patterns already exist so they can understand the current conventions and implementations.

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.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download rpi.zip