Ralphinho Rfc Pipeline
- 1.4k installs
- 238k repo stars
- Updated August 5, 2026
- affaan-m/ecc
This is a copy of ralphinho-rfc-pipeline by affaan-m - installs and ranking accrue to the original listing.
ralphinho-rfc-pipeline is an ECC agent orchestration skill that breaks large features into independently verifiable work units with DAG execution, quality gates, and merge queues for developers running multi-agent RFC-dr
About
ralphinho-rfc-pipeline is an ECC-origin skill inspired by humanplane-style RFC decomposition for multi-agent software delivery. Its seven pipeline stages cover RFC intake, DAG decomposition, unit assignment, unit implementation, unit validation, merge queue integration, and final system verification. Each work unit includes id, depends_on, scope, acceptance_tests, risk_level, and rollback_plan, with three complexity tiers from isolated file edits to multi-file behavior changes. Developers reach for ralphinho-rfc-pipeline when a feature is too large for one agent path and needs independently testable units executed safely in sequence across multiple agents.
- 7-stage RFC-driven multi-agent DAG execution pattern
- Per-unit spec template with id, depends_on, scope, acceptance_tests, risk_level and rollback_plan
- Complexity tiers that classify changes from isolated edits to schema/auth/perf/security updates
- 6-step quality pipeline per unit: research → plan → implementation → tests → review → merge-ready report
- Strict merge queue rules with dependency failure blocking, rebasing, and post-merge integration re-testing
Ralphinho Rfc Pipeline by the numbers
- 1,355 all-time installs (skills.sh)
- +82 installs in the week ending Aug 5, 2026 (Skillselion tracking)
- Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/affaan-m/ecc --skill ralphinho-rfc-pipelineAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 1.4k |
|---|---|
| repo stars | ★ 238k |
| Last updated | August 5, 2026 |
| Repository | affaan-m/ecc ↗ |
How do you split large features for multi-agent builds?
Break down large features into independently verifiable work units that multiple agents can execute safely in sequence.
Who is it for?
Developers orchestrating multi-agent builds on large RFCs that need DAG-ordered units, quality gates, and merge-queue integration.
Skip if: Small single-file changes or teams running one agent without RFC decomposition or acceptance-test gates.
When should I use this skill?
The user has a large RFC or feature too big for one agent and needs DAG decomposition, work units, quality gates, or merge-queue orchestration.
What you get
RFC decomposition DAG, work unit specs with acceptance tests, validated unit outputs, merge queue integration, and final system verification results.
- Work unit DAG
- Acceptance test specs
- Merge queue integration plan
By the numbers
- Seven pipeline stages from RFC intake to final system verification
- Three complexity tiers for work unit sizing
- Each work unit spec includes six required fields including acceptance_tests and rollback_plan
Files
Ralphinho RFC Pipeline
humanplane スタイルのRFC分解パターンと複数ユニットオーケストレーションワークフローにインスパイア。
単一エージェントパスでは大きすぎる機能を独立して検証可能なワークユニットに分割する必要がある場合、このスキルを使用します。
Pipeline Stages
1. RFC intake 2. DAG decomposition 3. Unit assignment 4. Unit implementation 5. Unit validation 6. Merge queue and integration 7. Final system verification
Unit Spec Template
各ワークユニットに含める：
iddepends_onscopeacceptance_testsrisk_levelrollback_plan
Complexity Tiers
- Tier 1: isolated file edits, deterministic tests
- Tier 2: multi-file behavior changes, moderate integration risk
- Tier 3: schema/auth/perf/security changes
Quality Pipeline per Unit
1. research 2. implementation plan 3. implementation 4. tests 5. review 6. merge-ready report
Merge Queue Rules
- Never merge a unit with unresolved dependency failures.
- Always rebase unit branches on latest integration branch.
- Re-run integration tests after each queued merge.
Recovery
ユニットが stall した場合：
- evict from active queue
- snapshot findings
- regenerate narrowed unit scope
- retry with updated constraints
Outputs
- RFC execution log
- unit scorecards
- dependency graph snapshot
- integration risk summary
Related skills
Setup Matt Pocock SkillsScaffold the per-repo configuration that Matt Pocock’s engineering agent skills rely on so they understand the issue tracker, triage labels, and domain documentation la495k196k
Lark AppsConnect Claude, Cursor or custom agents directly to Lark (Feishu) for messaging, document automation, approval workflows and enterprise data access.402k
CavemanSlash token usage by roughly 75% while keeping every technical detail intact when working with Claude Code, Cursor or similar agents.391k94.7k
Lark Skill MakerQuickly turn any Lark/Feishu OpenAPI call or multi-step workflow into a reusable agent skill with its own SKILL.md.386k16k
Running Claude Code Via Litellm CopilotRun Claude Code at a fraction of the cost by routing requests through LiteLLM to the GitHub Copilot Chat API.270k72
Codex PetGenerate a complete Codex Pet spritesheet and metadata from one reference image without needing an OpenAI key or Codex Pro.246k10How it compares
Use ralphinho-rfc-pipeline for RFC-scale multi-agent DAG orchestration; use single coding agents when the change fits one verifiable unit.
FAQ
What are the ralphinho-rfc-pipeline stages?
ralphinho-rfc-pipeline has seven stages: RFC intake, DAG decomposition, unit assignment, unit implementation, unit validation, merge queue and integration, and final system verification. Each stage gates progress before the next agent unit runs.
What fields does each work unit include?
Each ralphinho-rfc-pipeline work unit includes id, depends_on, scope, acceptance_tests, risk_level, and rollback_plan. Units form a DAG so agents execute independently verifiable chunks in safe sequence.
What complexity tiers does ralphinho-rfc-pipeline define?
ralphinho-rfc-pipeline defines three complexity tiers ranging from Tier 1 isolated file edits with deterministic tests to Tier 2 multi-file behavior changes. Teams pick tiers to size agent assignments and validation strictness.