Ralphinho Rfc Pipeline
Split an oversized feature into RFC-backed work units with a DAG, per-unit quality gates, and a merge queue so multiple agent passes stay verifiable.
Overview
Ralphinho RFC Pipeline is an agent skill most often used in Build (also Ship testing and review) that splits oversized features into RFC-backed DAG work units with quality gates and a merge queue.
Install
npx skills add https://github.com/affaan-m/everything-claude-code --skill ralphinho-rfc-pipelineWhat is this skill?
- 7-stage pipeline: RFC intake → DAG decomposition → assignment → implementation → validation → merge queue → system verif
- Work-unit spec template with id, depends_on, scope, acceptance_tests, risk_level, and rollback_plan
- 3 complexity tiers from isolated edits through schema/auth/perf/security changes
- Per-unit quality pipeline: research → plan → implementation → tests → review → merge-ready report
- Merge queue rules with dependency checks, rebase, integration tests, and stall recovery via eviction and narrowed retrie
- 7 pipeline stages from RFC intake through final system verification
- 6-step quality pipeline per work unit
- 3 complexity tiers for unit risk classification
Adoption & trust: 4.2k installs on skills.sh; 210k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your feature is too big for one agent pass, so work overlaps, dependencies break, and you cannot tell which slice is actually merge-ready.
Who is it for?
Solo builders coordinating multi-file or multi-agent feature work who already use specs and want deterministic unit boundaries and merge ordering.
Skip if: One-file tweaks, spike prototypes with no acceptance tests, or teams that do not use branches and integration tests between agent runs.
When should I use this skill?
A feature is too large for a single agent pass and must be split into independently verifiable work units.
What do I get? / Deliverables
You get a logged RFC run, scored work units, a dependency graph, and merge-queue discipline so approved slices integrate with tests re-run after each merge.
- RFC execution log
- Unit scorecards
- Dependency graph snapshot
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Large features are usually scoped and decomposed during Build before coding; this skill is the canonical shelf for that orchestration step. PM-style decomposition (RFC intake, units, dependencies) maps directly to project-management subphase rather than a single integration or file edit.
Where it fits
Decompose a multi-service auth refactor into Tier 2 units with depends_on edges before any agent edits files.
Assign each DAG leaf to a separate agent session with acceptance_tests copied from the unit spec.
Re-run integration tests after each queued merge per merge-queue rules.
Require the six-step per-unit pipeline to end in a merge-ready report before queueing.
How it compares
Use instead of ad-hoc “do the whole feature in one chat” when you need DAG decomposition and merge-queue rules, not a single checklist skill.
Common Questions / FAQ
Who is ralphinho-rfc-pipeline for?
Indie and solo builders using Claude Code, Cursor, or similar agents on features that exceed one session, especially when multiple units must land in dependency order with tests and review per slice.
When should I use ralphinho-rfc-pipeline?
During Build when scoping a large RFC or epic into units; again in Ship for per-unit validation, review, and merge-queue integration before final system verification.
Is ralphinho-rfc-pipeline safe to install?
It is procedural orchestration guidance in SKILL.md—review the Security Audits panel on this Prism page and treat merge and git steps as you would any workflow that touches your repo and CI.
SKILL.md
READMESKILL.md - Ralphinho Rfc Pipeline
# Ralphinho RFC Pipeline Inspired by [humanplane](https://github.com/humanplane) style RFC decomposition patterns and multi-unit orchestration workflows. Use this skill when a feature is too large for a single agent pass and must be split into independently verifiable work units. ## 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 Each work unit should include: - `id` - `depends_on` - `scope` - `acceptance_tests` - `risk_level` - `rollback_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 If a unit stalls: - 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