/skill

Ralphinho RFC Pipeline

Credit

This skill is based on the RFC work style from humanplane. Full credit goes to the original authors and the ECC project.

When to Use

Use this skill when one agent cannot safely build a large feature alone.

Use it when work can be split into small units that can be built and tested on their own.

Do not use it for one small edit. A simple task should stay simple.

Pipeline

1. Read the RFC.
2. List goals, limits, and open questions.
3. Split the work into units.
4. Link each unit to the units it needs.
5. Check that the links form a valid DAG.
6. Give ready units to agents.
7. Build and test each unit.
8. Review each unit.
9. Add approved units to the merge queue.
10. Merge one unit at a time.
11. Run system tests after each merge.
12. Run a final check of the full feature.

A DAG is a list of work links with no loop. A unit must not depend on itself, even through other units.

Unit Spec

Write this for every unit:

id: unit-id
depends_on:
  - other-unit-id
scope:
  in:
    - work this unit must do
  out:
    - work this unit must not do
acceptance_tests:
  - clear test with a pass or fail result
risk_level: 1
rollback_plan:
  - safe steps to undo this unit
owner: agent-name
status: blocked

Use one of these states:

• blocked: A needed unit is not done.
• ready: All needed units are done.
• active: An agent is working on it.
• review: The work is done and needs review.
• merge-ready: All checks passed.
• merged: The unit is in the main work branch.
• failed: The unit needs a new plan.

Each unit must have one owner. Two agents must not edit the same lines at the same time.

Risk Levels

• Level 1: One small area changes. Tests are clear.
• Level 2: Many files or parts change. Parts must work together.
• Level 3: Data shape, login, speed, safety, or access rules change.

For Level 3 work:

• Ask for a second review.
• Test the rollback plan.
• Check old data and old clients.
• Write down any safety or access risk.
• Do not merge if the risk is not clear.

Quality Checks for Each Unit

Each unit must complete these steps:

1. Learn how the current code works.
2. Write a short build plan.
3. Make only the changes in scope.
4. Run the acceptance tests.
5. Run nearby tests that may break.
6. Review the code and test results.
7. Write a merge-ready report.

The report must list:

• Files changed
• Tests run
• Test results
• Known limits
• New risks
• Rollback steps
• Needed follow-up work

Do not mark a unit as merge-ready if a test was skipped. If a test cannot run, state why and keep the unit out of the merge queue.

Merge Queue Rules

• Merge only units marked merge-ready.
• Never merge a unit while one of its needs has failed.
• Update the unit branch from the latest work branch before merge.
• Fix all merge conflicts before merge.
• Run the unit tests again after the update.
• Merge one unit at a time.
• Run system tests after each merge.
• Stop the queue when a system test fails.
• Undo the last merge if it caused the failure and a quick fix is not safe.
• Do not hide test failures with weaker tests or removed checks.

Edge Cases

• If the DAG has a loop, stop and split or reorder the units.
• If two units edit the same code, merge them into one unit or set a clear order.
• If the RFC is not clear, write down the open question before work starts.
• If a unit grows too large, split it into smaller units.
• If a unit finds hidden work, add a new unit. Do not grow the old scope without review.
• If a needed unit changes its public shape, update all units that use it.
• If an agent stops, save its notes, code state, tests, and open issues.
• If a test is flaky, run it again and record each result. Do not call it a pass until the cause is known.
• If rollback could lose data, stop and ask for a safer plan.
• If the main branch changes during review, update and test the unit again.
• If two ready units do not touch the same code or state, they may run at the same time.

Recovery

When a unit stalls:

1. Remove it from the active queue.
2. Save its findings and current state.
3. Write the exact cause of the stall.
4. Make the scope smaller.
5. Add new limits or facts to the unit spec.
6. Give it a new owner if needed.
7. Try again.

Do not retry the same plan without a clear change.

Example

RFC goal: Add email alerts when an order ships.

units:
  - id: alert-data
    depends_on: []
    scope:
      in:
        - add an alert record
        - add data tests
      out:
        - send email
    acceptance_tests:
      - an alert record can be saved and read
      - old data still loads
    risk_level: 3
    rollback_plan:
      - remove the new table if it is empty
    owner: agent-a
    status: ready

  - id: alert-email
    depends_on:
      - alert-data
    scope:
      in:
        - make the shipping email
        - mark sent alerts
      out:
        - change order rules
    acceptance_tests:
      - one shipping event sends one email
      - a retry does not send a second email
    risk_level: 2
    rollback_plan:
      - turn off the alert sender
    owner: agent-b
    status: blocked

  - id: alert-settings
    depends_on:
      - alert-data
    scope:
      in:
        - add an email alert setting
      out:
        - send email
    acceptance_tests:
      - a user can turn shipping alerts on and off
    risk_level: 2
    rollback_plan:
      - hide the setting and use the old default
    owner: agent-c
    status: blocked

alert-email and alert-settings may start after alert-data is merged. They may run at the same time if they do not edit the same code.

Final Outputs

Create these files or report parts:

• RFC work log
• Unit scorecards
• DAG snapshot
• Merge queue record
• Test results
• Risk summary
• Final system check
• Open follow-up list