スキル一覧に戻る
dariuszparys

ralph-method

by dariuszparys

0🍴 0📅 2026年1月12日
GitHubで見るManusで実行

SKILL.md


name: ralph-method description: Apply Ralph Wiggum Method patterns for decomposing tasks into atomic user stories user-invocable: false when_to_use: | Use this skill when:

  • Breaking down a feature or task into implementable user stories
  • Planning work for autonomous AI-assisted coding loops
  • Creating prd.json or story breakdown artifacts
  • Evaluating if a story is atomic enough for single-iteration completion
  • Generating Ralph Wiggum Method artifacts

Ralph Wiggum Method

The Ralph Wiggum Method is an autonomous AI coding loop that ships features while you sleep. It breaks complex tasks into atomic user stories that can each be completed in a single AI iteration.

Core Principles

  1. One iteration = One story = One commit
  2. Each story must be completable in a single AI iteration (5-30 minutes of work)
  3. Stories are ordered by dependency (infrastructure first, consumers last)
  4. Every story ends with build/test verification
  5. The loop runs autonomously until all stories pass

Story Atomicity Rules

A story is atomic when:

  • It can be committed independently without breaking the build
  • It leaves the codebase in a working state
  • It has clear, verifiable "done" criteria
  • It doesn't require human intervention mid-way
  • It can be code-reviewed as a single logical change

Story Decomposition Patterns

API Endpoint

PriorityStoryPurpose
1Create schema/typesDefine data structures
2Create service layerBusiness logic
3Create route handlerHTTP interface
4Add integration testVerification

Database Change

PriorityStoryPurpose
1Create migration fileSchema change
2Update model/entityCode representation
3Update seed dataTest data
4Update consuming codeIntegration

React Component

PriorityStoryPurpose
1Create component skeletonStructure
2Add state/logicBehavior
3Add stylingAppearance
4Add testsQuality

Refactoring

PriorityStoryPurpose
1Add new implementation alongside oldParallel path
2Migrate consumers one by oneGradual switch
3Remove old implementationCleanup

Configuration Change

PriorityStoryPurpose
1Add environment variablesDefine config
2Create/update config fileStructure config
3Update consuming codeUse config

prd.json Schema

{
  "branchName": "ralph/feature-name",
  "taskDescription": "One-line summary of the task",
  "projectContext": {
    "framework": "e.g., Next.js, .NET",
    "testCommand": "e.g., npm test, dotnet test",
    "buildCommand": "e.g., npm run build, dotnet build"
  },
  "userStories": [
    {
      "id": "US-001",
      "title": "Short descriptive title",
      "description": "What to implement in detail",
      "acceptanceCriteria": [
        "Specific, verifiable criterion 1",
        "Specific, verifiable criterion 2",
        "Build/test passes"
      ],
      "priority": 1,
      "passes": false,
      "notes": "Hints, gotchas, references to existing code"
    }
  ]
}

Field Descriptions

  • branchName: Git branch for all work (format: ralph/<feature-name>)
  • taskDescription: One-line summary for quick context
  • projectContext: Build/test commands and framework info
  • userStories: Array of atomic stories in dependency order
    • id: Unique identifier (US-001, US-002, etc.)
    • title: Short title for commit messages
    • description: Full implementation details
    • acceptanceCriteria: Verifiable conditions for "done"
    • priority: Execution order (1 = first)
    • passes: Set to true when story is complete
    • notes: Additional context, gotchas, file references

Anti-Patterns to Avoid

Vague Stories

  • BAD: "Update all files"
  • GOOD: "Update UserController to use new AuthService"

Unbounded Scope

  • BAD: "Fix bugs as found"
  • GOOD: "Fix null reference in UserService.GetById"

Circular Dependencies

  • BAD: Story 3 depends on Story 5 which depends on Story 3
  • GOOD: Linear dependency chain

Too Large

  • BAD: "Implement entire authentication system"
  • GOOD: Split into: schema, service, middleware, routes, tests

Missing Verification

  • BAD: Story with no acceptance criteria
  • GOOD: Every story ends with "Build succeeds" or "Tests pass"

Story Sizing Guidelines

SizeTimeExamples
XS5-10 minAdd config value, create empty file, update import
S10-20 minCreate simple function, add basic test, update route
M20-30 minCreate service class, add migration, implement handler
L30+ minTOO BIG - split into smaller stories

Verification Commands

Every story should end with verification. Common patterns:

# JavaScript/TypeScript
npm run build && npm test

# .NET
dotnet build && dotnet test

# Python
pytest && python -m py_compile src/*.py

# Go
go build ./... && go test ./...

Progress Tracking

The progress.txt file tracks completed stories:

# Progress: feature-name
# Total stories: 5

Current story: 3
Completed: 2

---
# Story log
[2025-01-10 10:00] US-001: Create user entity - PASSED
[2025-01-10 10:15] US-002: Add user repository - PASSED

Commit Message Format

story US-XXX: <title>

<description of what was done>

Example:

story US-001: Create user entity

Added UserEntity with id, email, and created_at fields.
Configured EF Core mapping in ApplicationDbContext.

スコア

総合スコア

60/100

リポジトリの品質指標に基づく評価

SKILL.md

SKILL.mdファイルが含まれている

+20
LICENSE

ライセンスが設定されている

+10
説明文

100文字以上の説明がある

0/10
人気

GitHub Stars 100以上

0/15
最近の活動

3ヶ月以内に更新がある

0/10
フォーク

10回以上フォークされている

0/5
Issue管理

オープンIssueが50未満

+5
言語

プログラミング言語が設定されている

+5
タグ

1つ以上のタグが設定されている

0/5

レビュー

💬

レビュー機能は近日公開予定です