本文へ移動
cccskills
無料GitHub で公開

feature-pipeline

Multi-agent exploration-to-PR pipeline for safely exploring, fixing, and shipping a feature or CLI. Use when the user says: "explore X", "test and ship X", "run the pipeline on X", "run /feature-pipeline on X", "let's properly investigate X", "stress-test X and file issues", or "take X through the full pipeline." Also triggers on: "find what's broken in X", "test X end-to-end", "do a sandbox review of X", "file issues for X and fix them." Do NOT use for single-file bug fixes or one-off edits — the overhead is only justified when exploration, planning approval, and CI watching all matter. Manages state via scripts/state.sh (jq required). Five phases: LIGHTER explores → ORCHESTRATOR drafts PR → HEAVIER plans (user approves first) → ORCHESTRATOR commits → HEAVIER sandbox review → LIGHTER iterates CI → LIGHTER drift check + summary. Four mandatory stop hooks (M1–M4) gate each phase transition.

インストール方法を見る

含まれるファイル(3)

  • SKILL.md12.5 KB
  • evals/evals.json1.4 KB
  • scripts/state.sh2.7 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

feature-pipeline

A five-phase exploration-to-PR pipeline. The currently active agent acts as ORCHESTRATOR — it coordinates two sub-agents (LIGHTER and HEAVIER) and holds pipeline state. Sub-agents do all the work; the ORCHESTRATOR should produce no more than 50% of total pipeline output.

Phase 1 ── LIGHTER explores → files GitHub issues           [STOP M1]
Phase 2 ── ORCHESTRATOR drafts PR + HEAVIER plans
           → user approves → ORCHESTRATOR commits           [STOP M2]
Phase 3 ── HEAVIER RED/GREEN sandbox review → PR comment    [STOP M3]
Phase 4 ── LIGHTER iterates on comment + watches CI         [STOP M4]
Phase 5 ── LIGHTER drift check → user summary

When sub-agent spawning is unavailable, write a Handover and pause. The pipeline is only valuable if the right model tier does the right work.


Setup — State File

Before Phase 1, initialise pipeline state (requires jq):

bash .claude/skills/feature-pipeline/scripts/state.sh init "{{feature}}"

This writes .fp-state.json with all fields at their defaults. Use state.sh set <key> <value> and state.sh push <key> <value> throughout phases to track progress. state.sh show at any point gives the full snapshot.


Terminology

LabelMeaning
ORCHESTRATORThe currently active agent. Coordinates, drafts the PR, gates approval, commits, and holds state. Never explores, plans, implements, or reviews directly.
LIGHTEROne capability tier below ORCHESTRATOR. Faster and cheaper — suited to exploration and CI watch. If ORCHESTRATOR is already at base tier, LIGHTER = same tier.
HEAVIEROne capability tier above ORCHESTRATOR. Deeper reasoning — suited to planning and adversarial review. If ORCHESTRATOR is at apex, HEAVIER = same tier.

Harness compatibility

HarnessSpawn mechanism
Claude CodeAgent tool (subagent_type, model)
CursorBackground agents / @agent — pass brief as system prompt
Codex CLIcodex run --agent --instructions "..."
Windsurf CascadeCascade sub-tasks — delegate via task handoff
Other / unknownTrigger Handover Protocol (see below)

Phase 1 — Feature Exploration (LIGHTER)

The goal is a complete picture of what's broken before anyone writes a fix. LIGHTER approaches {{feature}} as a first-time user, exercising every interesting edge so issues get filed while observations are fresh.

Spawn LIGHTER with this brief:

You are a developer sandbox-testing {{feature}} for the first time. Invoke it in at least five distinct ways: happy path, edge cases, invalid inputs, flag combos, piped output. Note every footgun, unintuitive behaviour, unclear error, or doc gap. File one GitHub issue per distinct finding:

  • Title: [{{feature}}] <short description>
  • Labels: exploration, needs-triage
  • Body: steps to reproduce / expected / actual / severity (low | medium | high)

End with a severity table of all issues filed.

After LIGHTER reports: state.sh push issueNumbers <N> for each issue, state.sh set phase 2.

If spawning fails, write a Handover with role: LIGHTER, task: Phase 1 exploration, context: {{feature}} — do not explore yourself.

→ STOP HOOK M1 — print the banner, wait for user input before Phase 2.


Phase 2 — Plan & Draft PR (ORCHESTRATOR + HEAVIER)

ORCHESTRATOR does these steps directly — this is its core authoring work:

  1. Read Phase 1 issues → write a one-paragraph Problem Statement.
  2. Create branch fix/{{feature}}-findings-<slug>.
  3. Open a draft PR:
    • Title: fix({{feature}}): address exploration findings
    • Labels: draft, needs-plan
    • Body: Problem Statement + Closes #N links + ## Plan placeholder.
  4. state.sh set branch <name> and state.sh set prUrl <url>.

Then spawn HEAVIER with the issue bodies, PR URL, and relevant source excerpts. HEAVIER produces a numbered implementation plan:

1. <file/area>  —  <change>  —  <rationale>  [⚠ breaking | ⚠ test-only | ⚠ schema]
2. …

Present the plan to the user. Zero implementation commits until explicit approval — because an unreviewed plan means unreviewed code, and that defeats the purpose of the HEAVIER planning tier. Accept corrections ("change step 3 to …", "skip step 2"). Update PR body ## Plan with the approved plan. state.sh set planApproved true.

After approval, ORCHESTRATOR implements step by step:

  • One atomic commit per plan step: <type>(<scope>): <desc>
  • Remove needs-plan, add in-progress
  • Push

Programmatic-First rule applies: registry mutations via gaia dev commands — never hand-edit registry/nodes/.

If HEAVIER spawning fails, write a Handover with role: HEAVIER, task: Phase 2 planning — do not plan yourself.

→ STOP HOOK M2 — print the banner, wait for user input before Phase 3.


Phase 3 — Sandbox Review (HEAVIER)

Spawn a fresh HEAVIER in isolation: worktree with the PR branch checked out. Worktree isolation prevents a broken review from dirtying the working branch.

Brief:

Read the full diff (git diff origin/main...HEAD). For each changed public surface or behaviour: write a RED test (must fail before the fix — verify by temporarily reverting, running, re-applying) and a GREEN test (must pass with fix). Run gaia dev validate for schema changes; gaia dev docs --check for doc changes. Post this review comment to the PR:

## Sandbox Review

### RED tests
| Description | Result | Notes |
|-------------|--------|-------|

### GREEN tests
| Description | Result | Notes |
|-------------|--------|-------|

### Issues found
- [ ] <description> — `<file>:<line>`

### Verdict: APPROVE / REQUEST CHANGES

After comment is posted: state.sh set reviewCommentUrl <url>.

If spawning fails, write a Handover with role: HEAVIER, task: Phase 3 sandbox review — do not review yourself.

→ STOP HOOK M3 — print the banner, wait for user input before Phase 4.


Phase 4 — Iterate & Watch CI (LIGHTER)

Spawn LIGHTER (same agent as Phase 1 if context is intact, else fresh) with the PR context and the Phase 3 review comment URL. Reusing the Phase 1 agent when possible avoids re-establishing feature context.

Brief:

Read the review comment. For each [ ] issue: fix, commit (fix(<scope>): <desc> (per review)), push. Subscribe to CI events. On each failure: read logs, diagnose root cause, push targeted fix. Do not exit until all required checks pass. On CI green: remove draft status, swap in-progress → ready-for-review. If the same check fails 3× with no new diagnosis, escalate to ORCHESTRATOR with the exact log excerpt.

ciRound in state tracks CI attempts — LIGHTER should increment it via state.sh set ciRound <N> before each push. This makes the 3× escalation threshold auditable.

If spawning fails, write a Handover with role: LIGHTER, task: Phase 4 CI watch — do not watch CI yourself.

→ STOP HOOK M4 — print the banner, wait for user input before Phase 5.


Phase 5 — Drift Check & Summary (LIGHTER)

Spawn LIGHTER for the final hygiene pass.

Brief:

git fetch origin main → gaia dev diff. If unexpected drift: print a warning table (skill ID / field / main value / branch value) and pause — do not auto-fix drift, because silent registry mutations are the main source of hard-to-audit regressions. If clean: send the user the final summary (feature explored, issues filed with links, PR URL + title, CI status, commit list, what was fixed). All agents exit.

Exception: if spawning is unavailable here, ORCHESTRATOR may run the drift check and summary itself — Phase 5 is lightweight and terminal.


Stop Hooks

Stop hooks are mandatory pauses. They exist because each phase handoff is a natural review point where the user may want to change course before work compounds. ORCHESTRATOR prints the banner and ends the turn — it does not auto-advance.

HookAfterReviewUser options
M1LIGHTER files last issue + severity tableIssue list, severitycontinue → Phase 2 · stop · add: <notes>
M2ORCHESTRATOR pushes implementation commitsPR diff, commit listcontinue → Phase 3 · stop · amend: <notes>
M3HEAVIER posts review commentVerdict, [ ] itemscontinue → Phase 4 · stop · override: <notes>
M4LIGHTER reports CI green + PR readyFinal PR statecontinue → Phase 5 · stop

Banner format:

╔══ STOP HOOK M<N> ════════════════════════════════════════════════════════════╗
║  <one-line summary of what just completed>                                   ║
║  Review above, then reply: continue · stop · <feedback>                      ║
╚══════════════════════════════════════════════════════════════════════════════╝

Handover Protocol

When sub-agent spawning is unavailable, write a handover and pause — never do the sub-agent's work yourself. Handing off preserves model-tier separation, which is the whole point of the pipeline.

Storage: ./feature-pipeline-handover-{{feature}}.md on disk; PR comment if filesystem is unavailable.

## Feature Pipeline Handover — Phase <N>

**Feature**: {{feature}}
**Timestamp**: <ISO 8601>
**PR**: <URL or "not yet created">
**Branch**: <name or "not yet created">

### Role needed
LIGHTER | HEAVIER

### Task
<paste the exact Phase brief from this skill — do not paraphrase>

### State snapshot
<contents of .fp-state.json — or paste from state.sh show>

### Resume steps
1. Read this document.
2. Complete the Task above as the specified role.
3. Update .fp-state.json (or the PR comment) when done.
4. Write a Phase <N+1> handover or post a completion note and notify ORCHESTRATOR.

After writing, print:

⚠  Sub-agent spawning unavailable.
   Handover written → <path or "PR comment">
   Assign task to a <LIGHTER | HEAVIER> agent, then reply 'continue'.

Then end the turn.


Key Rules (condensed)

  • One PR per run — all Phase 1 issues close in a single PR.
  • No commits before plan approval — HEAVIER's plan gates all implementation.
  • No force-pushes — commits append only; rebase only on explicit user request.
  • Drift → warn, never auto-fix — Phase 5 surfaces drift as a table and pauses.
  • CI loop has no exit until green — or 3× same failure triggers escalation.
  • Phase order is strict — Phase N+1 does not start until Phase N stop hook is cleared.

Invocation

/feature-pipeline <feature>

If <feature> is omitted, ask: "Which feature or CLI should I explore?"

Examples: gaia scan · packages/cli-npm · the --canon flag · gaia skills install


Phase banner (sub-agents)

Sub-agents print at phase end:

── Phase <N> complete ─────────────────────────────────────────────────────────

ORCHESTRATOR prints stop-hook banners separately. Neither should be suppressed.

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

ci-churn

無料

Measure CI churn cost for a pull request: how many commits and how many CI-compute seconds were burned on avoidable "fix the CI" push rounds. Use when you want to understand the efficiency cost of a PR's iteration cycle, get actionable pre-push check suggestions, or include a churn summary in a pipeline report. Triggers: "ci churn", "how much CI did we burn", "avoidable commits", "ci efficiency", "wasted CI time", "churn report", "/ci-churn". Called automatically by /fp-drift at pipeline close.

日本語の概要は準備中です。原文の説明を表示しています。

gaia-research/gaia-skill-tree232026年10月13日 更新

Produce the rendered evidence a human-gated frontend PR owes its reviewer: capture each changed surface (plus the before state for anything modified, plus mobile width), then generate one self-contained local HTML page the founder can open and review without checking anything out. Use when a PR is gated by the "Frontend changes are HUMAN-GATED" section of CLAUDE.md, or when the user says "/design-gate", "screenshot evidence for this PR", "prep this for founder review", "build the design evidence page", "what does this look like before and after". The page comes from a template script, not hand-written markup. Output is session-local and never committed. Do NOT use for non-gated changes: typo/grammar/factual fixes in an unchanged block, dead link targets, alt/ARIA fixes with no visual change, cache-bust bumps, or refactors with no rendered diff.

日本語の概要は準備中です。原文の説明を表示しています。

gaia-research/gaia-skill-tree232026年10月13日 更新

One-fix-at-a-time, approval-gated design fix recovery. Given a checklist of fixes (handover doc, CHECKLIST.md, or inline list), applies each individually, presents a diff, and waits for an explicit APPROVE / REJECT / NO CHANGES decision before committing. Trigger phrases: /design-iteration, "go through the checklist one by one", "fix these one at a time", "bucket recovery", "design fix pass".

日本語の概要は準備中です。原文の説明を表示しています。

gaia-research/gaia-skill-tree232026年10月13日 更新

Playbook for correcting a named skill's star level to match its computed Trust Magnitude grade, with an independent post-calibration verification pass and a CLI-logged timeline event (never hand-written). Use when: recalibrating a skill's level, fixing a stale or drifted star rating, running a batch of `gaia dev calibrate` corrections, or confirming a past calibration actually landed. Triggers: "calibrate <skill>", "recalibrate the trust magnitude backlog", "promote/demote <skill> to N stars", "why is <skill> still N stars", "verify a calibration actually landed", "Hall of Heroes ranking is wrong".

日本語の概要は準備中です。原文の説明を表示しています。

gaia-research/gaia-skill-tree232026年10月13日 更新

Close out a completed EPIC / sprint end-to-end: author a fact-verified meta-post announcing what shipped, archive the EPIC's handovers, snapshot orchestrator memory, gate the integration→main merge on CI-green + explicit human go, drive the version bump (merge-commit conventions that auto-sync classifies), and verify the release reached the registry/PyPI. Use when the user says "close out EPIC <n>", "wrap up the sprint", "ship the meta shift", "/epic-close", or asks to finalize an integration branch that is ready to merge to main. Generalizes the EPIC 1002 (Yggdrasil II) close-out. This skill orchestrates — it authors founder docs directly (superadmin) and delegates code/regen to workers; it NEVER merges to main without the human gate.

日本語の概要は準備中です。原文の説明を表示しています。

gaia-research/gaia-skill-tree232026年10月13日 更新

Run this skill for Phase 3 of the evidence verification pipeline — the adversarial audit step. Use when you need to check the evidence data lake for bad data before ingestion: dead links, wrong URL formats (tree/ vs blob/), subjective wording ("elite", "high-quality"), stale migration notes, benchmark catalog misuse/vendor-claim leakage, or skills whose star evidence conflicts with classified evidence level. Triggers on phrases like: "audit the data lake", "adversarial check", "ev-adversarial-audit", "check for noise in evidence", "flag bad evidence", "run the audit phase", "quality check the by-type files", or any reference to Phase 3 of the pipeline.

日本語の概要は準備中です。原文の説明を表示しています。

gaia-research/gaia-skill-tree232026年10月13日 更新

gaia-research のスキルをすべて見る

このスキルの問題を報告する