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

epic-close

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.

インストール方法を見る

含まれるファイル(1)

  • SKILL.md8.4 KB

SKILL.md(原文)

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

epic-close

Deterministic close-out procedure for a completed EPIC or sprint. It turns "the work is done on the integration branch" into "released on main, announced, archived, and snapshotted" — with the one mandated human gate (the merge to main) preserved.

This skill is orchestrator-facing. It assumes the /gaia-orchestrator persona: founder docs (root *.md, founder/) are authored directly under superadmin mode; code, schema, and regen (src/, scripts/, registry/, docs/js/, docs/**/*.html, .github/) are delegated to workers. It never pushes to main directly and never merges the integration PR without an explicit founder go on CI-green.

Preconditions (verify before starting)

  1. The EPIC's feature work is fully merged into the integration branch (dev/<sprint>). No open child PRs targeting it that belong to this EPIC (sprint-completeness: no follow-ups carrying the sprint's own remainder — see CLAUDE.md § Sprint Completeness).
  2. The integration PR (dev/<sprint> → main) exists and is MERGEABLE. If ancestry is severed (e.g. after a history rewrite), repair it by merging origin/main into the integration branch first (never rebase — see ORCHESTRATOR.md branch-strategy invariant).
  3. The live source of truth (META.md / CONTEXT.md) already reflects the ratified change — the meta-post documents what shipped, it does not decide it.

The six steps (run in order)

1 — Author the announcement meta-post (show, don't tell)

Announce what the EPIC shipped as a fact-verified meta report. Every claim must be checked against live data, not asserted from memory or a handover.

  • Prefer a verification workflow for anything with numbers. A fan-out → synthesize → verify pipeline with an opus synthesizer produces publishable stats without hand-rework: parallel readers pull the live counts (registry/gaia.json skills key; TM grade distribution; named-skill totals), a synthesizer drafts the report, and a verify pass re-derives every number against the registry before it lands. Author the workflow inline (do not require the user to opt into ultracode for a routine close-out unless they ask for that scale).
  • Show, don't tell. Work at least one concrete example end-to-end (a real skill the change reclassifies; a real skill an old gate would have blocked). Before/after tables beat prose assertions.
  • Publish via the contract, never hand-edit HTML:
    PYTHONUTF8=1 PYTHONIOENCODING=utf-8 python scripts/add_post.py report \
      "<Title>" "<Queue summary.>" \
      --source docs/meta/YYYY-MM-<slug>.md \
      --author "<byline>" --label "<Label>" --date YYYY-MM-DD
    
    The renderer writes docs/meta/reports/YYYY-MM-DD-<slug>.html, prepends posts.json, and patches docs/index.html (queue + hero) and docs/meta.html (cards).
  • Verify after publish: scan the source for banned vocabulary (CONTEXT.md); the report HTML's embedded LaTeX <style> carries hex colors but the hex CI guard (check_hex_colors.py) scans only docs/**/*.js + docs/**/*.css — HTML <style> is out of scope, so report HTML is safe (all prior reports share the template hex and pass CI). Confirm the title renders in the generated HTML.
  • Byline: default author is Gaia Research unless the user requests a founder byline. Never invent a byline; if the EPIC is founder-authored, use the founder's stated name + role and preserve the approved commit/author identity.

2 — Archive the EPIC's handovers

  • Move completed handovers/specs/roadmaps into founder/handovers/archive/ (keep any explicitly-exempt forward-looking docs live — e.g. a vision doc for the next EPIC).
  • Write/extend the archive README.md with a dated sprint-done marker cataloging what was archived and what stayed live.
  • Reconcile founder/CLAUDE.md's Key References table so no row points at a moved file.
  • Write a standalone EPIC<n>_CLOSEOUT_YYYY-MM-DD.md in the archive: what shipped, the close-out actions, the release version, and pointers back to the MEMORY snapshot.

3 — Snapshot orchestrator memory

Invoke /memory-snapshot (or write directly, additive-only) to prepend a dated ## State Snapshot block to founder/MEMORY.md: headline, TLDR, what changed, branch SHAs, issues/PRs, routing, lessons, open questions, token cost. Preserve every prior snapshot verbatim.

4 — CI green + HUMAN GATE (hard stop)

  • Push the integration branch; wait for checks. Distinguish regressions from pre-existing baseline reds (a red that predates the EPIC and is untouched by it is not a merge blocker — document it, don't chase it, unless asked). Merge on the green gate that the EPIC's changes actually exercise (Test / Build / Smoke).
  • STOP. The integration→main merge is the ONLY mandated hard human gate. Do NOT merge without the founder's explicit go on CI-green. This is non-negotiable and survives every "all auto" instruction.

5 — Version bump via the merge commit

  • The merge-to-main IS the release trigger; auto-sync classifies the bump from the HEAD merge-commit message. The merge commit message MUST carry the right conventional token: feat!: or a BREAKING CHANGE: footer → major; feat: → minor; fix: / chore: → patch. A meta shift is breaking → major. A plain merge commit ships the wrong version.
  • Never squash an EPIC integration PR (destroys child-commit topology — founder/ CLAUDE.md § EPIC branching). Use a merge commit.
  • Author the CHANGELOG.md entry for the release version.
  • The three manifests (pyproject.toml, packages/cli-npm/package.json, registry/gaia.json) stay in lockstep via the pre-commit hook; registry/gaia.json is Class P (gitignored) — do NOT hand-commit it. Class-S regen (docs/graph/*) belongs in CI or a clean Linux worktree, not a Windows hand-curation (regen there flips CRLF EOL as noise).

6 — Post-merge verify

  • Release CD reached the target version.
  • PyPI received the new CLI wheel. For vX.Y.0 (minor/major) the "Bundle fresh registry snapshot" step injects the fresh registry into the wheel; verify unzip -l dist/*.whl | grep data/registry.
  • The EPIC's issues are closed; main is healthy.
  • Proof-of-work: post one comment on the governing EPIC issue — what shipped, key decisions (especially registry-semantics/policy changes), merged PR/commit refs.
  • Token spend: log input/output by model + date to the EPIC comment and founder/COST.md per the token-spend-logging directive.

Hard boundaries (survive any "all auto" instruction)

  • Never push to main. All work lands via the integration PR through the human gate.
  • Never merge the integration PR without the explicit human go on CI-green (step 4).
  • Never hand-edit generated HTML (add_post.py owns it) or timeline arrays (CLI only) or registry/gaia.json (Class P, gitignored).
  • Author founder docs directly (superadmin); delegate code/regen to workers.
  • Respect branch-scope, redaction exemptions, Class P/S, and the Programmatic-First policy throughout.

Why this skill exists

The EPIC 1002 (Yggdrasil II) close-out ran this exact sequence — verified meta-post, founder archive, memory snapshot, CI-green human gate, feat!: major bump, post-merge verify. Capturing it as a skill removes the variance the next EPIC would otherwise rediscover: the merge-commit token that drives the version, the human gate that must not be automated away, the "show don't tell" bar on the announcement, and the hex-guard / Class-P / regen footguns that make the mechanical steps safe.

レビュー

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

同じリポジトリのスキル

概要と使いどころ

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

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

Phase 2B of the Gaia evidence verification pipeline. Verifies benchmark-result rows and benchmark-source candidates against registry/benchmark-sources.json before adversarial audit, link validation, catalog promotion, or ingestion. Use when running /ev-pipeline, checking benchmark-result evidence, reviewing benchmark-source candidates, or preparing benchmark rows for /gaia-ingest-batch.

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

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

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

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