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

gaia-issue-resolver

End-to-end plan → implement → review pipeline that takes one triaged Gaia issue to a merged-ready PR, with Kill Criteria on the issue and zero follow-up debt. Use when someone says: "resolve this issue", "take #N end-to-end", "work the P0 queue", "fix and ship this issue", "run the resolver", "close out this issue properly", or /gaia-issue-resolver. Works any gaia-research org repo — gaia-skill-tree, gaia-research, gaia-skill-heaven — while the issue itself lives on the headquarters tracker, gaia-research/gaia-skill-tree. Assumes the issue is already triaged and carries a P0–P4 label; if it does not, run /gaia-triage first.

インストール方法を見る

含まれるファイル(1)

  • SKILL.md9.6 KB

SKILL.md(原文)

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

gaia-issue-resolver

Execute the complete resolution pipeline on one already-triaged Gaia issue, selected by priority (P0–P4) or assignee. Adapted from favorchurch/rock-steward's rock-issue-resolver; the six-phase shape and the Kill Criteria discipline are its contribution, the Gaia mechanics below are this repo's.

Prerequisite: the issue is triaged — it has a priority label, a size, and a stated problem. If it doesn't, stop and run /gaia-triage on it first. This skill resolves; it does not decide what is worth resolving.


1. Non-negotiables

  1. Zero follow-up debt. Do not close an issue by filing a trailing "clean up" issue that carries its own unfinished work. Everything a reasonable reviewer would call a direct consequence of this change belongs in this change. This is gaia-skill-tree's sprint-completeness rule applied at issue granularity: genuinely new, out-of-scope work discovered along the way may still be filed; the issue's own remainder may not.
  2. Kill Criteria before code. Every acceptance requirement is written as an explicit KC-1 … KC-N list, posted as a comment on the issue before implementation starts, and checked off from evidence before closing. An issue with no Kill Criteria has no definition of done.
  3. Draft PR first, push often. Branch, then open a draft PR as the first git operation after the first commit — before the work is finished. Push after each phase. Draft PRs stay draft until a human marks them ready.
  4. Programmatic-first. Registry mutations go through gaia dev verbs, never hand-edits to registry/nodes/ or registry/named/ frontmatter. If the right verb does not exist, file it as a CLI + tech-debt issue and say so in the PR — do not work around it.
  5. Read-only during audit. Phase 2 observes and never mutates. No gaia dev write verb, no git push, no site regeneration, until the plan is posted.
  6. Class A / Class B dual delivery, where it applies. If the issue describes a recurring drift rather than a one-off defect, ship a detector alongside the fix:
    • Class A — a read-only, deterministic check that observes the condition (founder/steward/POLICY.yaml declares the Class A repairs Gaia Steward runs unattended; scripts/verify_evidence.py and scripts/verify_lockstep.py are the shape to copy).
    • Class B — an operational routine, --dry-run by default with an explicit --apply gate, living in founder/steward/routines/. A one-off typo fix does not need either. A fourth recurrence of the same drift does.

2. The six phases

Phase 1 — Intake & scope

export GAIA_HQ=gaia-research/gaia-skill-tree
gh issue list --repo "$GAIA_HQ" --label P0 --state open        # or --assignee @me
gh issue view <n> --repo "$GAIA_HQ" --comments

Read the whole thread, not the title. Note which repo the fix lands in — the issue is in HQ, the code may not be (see /wayfinder §1 for the target-repo convention). Confirm the issue is still real before spending a session on it; a stale issue is a /gaia-triage close, not a resolution.

Phase 2 — Baseline audit (read-only)

Establish what is actually true now, from the artifact, not from the issue text. Pick the probes that match the domain:

DomainBaseline probe
Registry data / evidencegaia dev list --generic --named, gaia dev audit, python3 scripts/verify_evidence.py
Trust Magnitudegaia dev calibrate-trust-magnitude --skill <id> --dry-run, /trust-appraise
Docs / Class S driftpython scripts/build_docs.py --check (must exit 0)
CLI behaviourrun the actual command; read src/gaia_cli/commands/
Versioningpython scripts/verify_lockstep.py
Site rendering/design-gate, or node scripts/visual-audit.mjs in gaia-research
Nomenclaturenpx tsx scripts/lexicon/check-lexicon.ts (in gaia-research)

Capture the baseline output. It is what proves the fix later, and a number you did not capture before the change cannot be claimed after it.

Phase 3 — Plan, Kill Criteria, draft PR

Write the plan, then formalize it as Kill Criteria covering, as applicable:

  • the defect actually fixed, with the failing probe from Phase 2 named
  • Class A detection (if the issue is recurring drift)
  • Class B remediation routine, --dry-run default (same condition)
  • generated-artifact cohesion — Class S committed alongside the source change
  • automated tests passing
  • idempotency: a second run plans zero actions
  • CI green

Post them:

gh issue comment <n> --repo "$GAIA_HQ" --body-file kill-criteria.md

Branch and open the draft PR against the correct base — an integration branch if the effort spans multiple PRs, main otherwise:

git checkout -b fix/<topic>-<issue-number>      # or feat/<workstream>-<slug>
gh pr create --draft --body-file pr-body.md

Branch prefix must satisfy the target repo's scope rules — in gaia-skill-tree, .github/workflows/branch-scope.yml enforces which directories each prefix may touch (schema/, cli/, docs/, design/, review/meta/, infra/, dev/, claude/).

Phase 4 — Implement & test

One logical change per commit; push after each. Registry mutations through gaia dev. Tests are surgical during the loop and full once before review — CI runs on every push, so read results rather than re-running locally.

When the issue warrants dual delivery:

  • Class A check — deterministic, read-only, structured output, non-zero exit on detection.
  • Class B routine in founder/steward/routines/ — --dry-run by default, --apply gate, a receipt of what it changed.

Cover in tests: the computation and its edge cases, the CLI flags and exit codes, and an idempotency proof (second run ⇒ zero planned actions).

Phase 5 — Verify against the baseline

  • Re-run the Phase 2 probe. It must now pass, and you must show both readings.
  • Run the Class B routine --dry-run, inspect the plan, --apply, then dry-run again and show 0 planned actions.
  • Re-run the Class A check → clean.
  • Registry changes: gaia dev docs, then commit the deterministic Class S set only — docs/graph/*, docs/api/v1/**, docs/u/<handle>/index.html, docs/tree.md, registry/registry.md, docs/graph/ledger/data.json — and not docs/og/*.svg, docs/api/v1/trending/, layouts_3d.json, or docs/okf/. Confirm with python scripts/build_docs.py --check exiting 0.
  • Skills changed: python scripts/sync_agent_skill_mirror.py --check must pass.

Phase 6 — Review, ready, closeout

  1. Independent review of the diff — /code-review, or a subagent with a fresh context. Confirm no secrets, tokens, or PII in the diff.
  2. Mark ready only if the change is not human-gated. Frontend changes are founder-gated in gaia-skill-tree: agents may open, iterate, and mark ready, but may not merge. Attach the evidence page from /design-gate.
    gh pr ready <pr>
    
  3. Post the closeout comment: every Kill Criterion checked off with the evidence that satisfied it (a command output, a file path, a commit sha), then close.
    gh issue close <n> --repo "$GAIA_HQ" --reason completed --comment "$(cat closeout.md)"
    
  4. Merge verb is per repo, not per project — check before merging:
    gh api repos/<owner>/<repo> --jq '{squash:.allow_squash_merge,merge:.allow_merge_commit,rebase:.allow_rebase_merge}'
    
    gaia-skill-tree and gaia-research take merge commits (squash to main is disallowed); gaia-skill-heaven squashes — a merge commit there is blocked by a ruleset on main regardless of what the API reports. Rulesets can be stricter than repo settings; treat the API answer as a floor.
  5. Report token spend for the session (/pi-cost) as a comment on the PR, or on the issue when there is no PR.

3. Priority behaviour

The P0–P4 ladder is the one /gaia-triage, /gaia-meta-audit, and /gaia-meta-sweep already use — do not import a second one. What changes per priority is how much pipeline the issue earns:

PriorityPipeline
P0Full six phases. Interrupt other work. Dual delivery expected — a P0 that recurred once will recur again.
P1Full six phases. Class A detection expected; Class B if the remediation is repeatable.
P2Full six phases, dual delivery optional.
P3Phases 1, 3, 4, 6. Baseline probe only where a number is claimed.
P4Phases 1, 4, 6. Kill Criteria may be a single line. Do not over-ceremony a typo.

4. Output

Close every run with:

  • the issue and PR, by title and number
  • each Kill Criterion, checked off with its evidence
  • before/after readings of the Phase 2 probe
  • what shipped as Class A vs Class B, or an explicit "one-off — neither warranted"
  • anything genuinely out of scope that was filed separately, and why it was not this issue's remainder
  • session token spend and estimated cost

レビュー

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

同じリポジトリのスキル

概要と使いどころ

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 のスキルをすべて見る

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