Skip to content
cccskills
FreePublished on 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.

The English summary is being prepared. Showing the original description.

See how to install

Files included (1)

  • SKILL.md8.4 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

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.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

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.

The English summary is being prepared. Showing the original description.

gaia-research/gaia-skill-tree23Updated Oct 17, 2026

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.

The English summary is being prepared. Showing the original description.

gaia-research/gaia-skill-tree23Updated Oct 17, 2026

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".

The English summary is being prepared. Showing the original description.

gaia-research/gaia-skill-tree23Updated Oct 17, 2026

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".

The English summary is being prepared. Showing the original description.

gaia-research/gaia-skill-tree23Updated Oct 17, 2026

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.

The English summary is being prepared. Showing the original description.

gaia-research/gaia-skill-tree23Updated Oct 17, 2026

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.

The English summary is being prepared. Showing the original description.

gaia-research/gaia-skill-tree23Updated Oct 17, 2026

See all skills by gaia-research

Report a problem with this skill