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

fp-implement

Phase 3 of the feature-pipeline suite. Use this after /fp-plan has received explicit user approval and printed the M2-plan stop hook — when you need to translate an approved numbered plan into committed, pushed code. Triggers on: "implement the plan", "start coding", "commit the plan", "write the code", "fp-implement", "Phase 3", "plan is approved let's code", "next step after plan", "execute the plan", "apply the plan", "make the changes". Reads planApproved and branch from state; refuses to run if approval hasn't been recorded. Commits one atomic change per plan step, pushes after each commit, handles obstacles cleanly, and hands off to /fp-review when done. Never squashes or skips steps — the one-commit-per-step rule keeps the review history readable and rollback surgical.

インストール方法を見る

含まれるファイル(1)

  • SKILL.md5.5 KB

SKILL.md(原文)

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

fp-implement (Phase 3 — Implementation)

Translate the approved plan into commits, one step at a time. Each step is a self-contained atomic commit pushed immediately — so if this turn is interrupted, nothing is lost and the next run can pick up where it left off.


Setup

STATE=".agents/skills/feature-pipeline/scripts/state.sh"

Check preconditions before touching any code. Skipping this check is how bad state propagates — an unapproved plan being implemented defeats the whole purpose of the approval gate in /fp-plan:

approved=$($STATE get planApproved)   # must be "true"
branch=$($STATE get branch)
pr=$($STATE get prNumber)

If planApproved != true, tell the user clearly and end the turn:

⚠ Plan not yet approved. Run /fp-plan first and wait for approval.

Checkout the branch so all commits land in the right place:

git checkout "$branch"

Reading the plan

Fetch the approved plan from the PR body — this is the source of truth because the user may have edited it during the approval step in /fp-plan:

gh pr view "$pr" --json body

If the fetch fails or the ## Plan section is empty, ask the user to paste the plan. Don't guess or reconstruct from memory.


Implementation loop

Work through each numbered step in order. The one-step-one-commit discipline matters: it keeps the diff reviewable, makes rollback surgical (git revert on a single commit), and gives /fp-review clear commit messages to annotate.

For each step:

  1. Implement the change in the relevant file(s). Read the file before editing so you don't clobber unrelated content.

  2. Stage only the relevant hunks — don't sweep in unrelated changes:

    git add -p   # or git add <specific-files> when the step is clearly scoped
    
  3. Commit with a conventional message so CI and reviewers can parse intent:

    git commit -m "<type>(<scope>): <description>"
    git push
    
  4. Print one confirmation line:

      ✓ Step N committed: <short-hash>  <commit message>
    

Handling obstacles

If a step hits an unexpected blocker (import error, schema conflict, test failure that reveals a new problem not in the plan) — stop immediately. Partial work committed half-done is harder to untangle than a clean stop with a note.

  • Leave a TODO comment at the exact location explaining what's needed.
  • Commit the partial work so nothing is lost:
    git commit -m "wip(<scope>): partial step N — <obstacle summary>"
    git push
    
  • Record the blockage in state so the next run can see it:
    $STATE set ciStatus "blocked"
    
  • Print what the obstacle is, what file/line is involved, and what additional information would unblock it. Then end your turn — don't attempt the next step while this one is unresolved.

Phase completion

When all steps are committed and pushed, advance state so /fp-review knows to start the sandbox pass:

$STATE set phase 4

Update the PR labels to reflect current status. needs-plan is no longer accurate once code exists; in-progress signals the PR is ready for review:

# via GitHub MCP:
mcp__github__update_pull_request — remove "needs-plan", add "in-progress"

Print the M2 stop hook and end your turn. The stop hook is mandatory — it's what tells the user which skill to run next and gives them a moment to scan the commit list before review starts:

╔══ STOP HOOK M2 ══════════════════════════════════════════════════════════════╗
║  Implementation complete — <N> commits pushed to <branch>                    ║
║  Run /fp-review to start sandbox review.                                     ║
╚══════════════════════════════════════════════════════════════════════════════╝

Constraints

  • One commit per plan step — no squashing, no combining steps. Reviewers need to be able to understand each change in isolation.
  • Never commit secrets, generated registry artifacts (docs/graph/*, registry/gaia.json), or files unrelated to the current step.
  • Any registry mutations (registry/nodes/) must go through gaia dev add / gaia dev merge / gaia dev split — hand-edits skip timeline logging and break the audit trail.
  • No force-pushes. If a commit needs to be undone, use git revert.
  • End the turn after the stop hook. Sandbox review belongs to /fp-review.

レビュー

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

同じリポジトリのスキル

概要と使いどころ

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月11日 更新

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月11日 更新

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月11日 更新

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月11日 更新

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月11日 更新

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月11日 更新

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

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