菜单
Push committed changes and create a draft PR on GitHub. Use when you have staged changes ready to push and want to open a draft PR for early feedback or documentation.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Helper for release operations, compilation of changelogs between tags, version lockstep syncing, and promotion of GitHub releases from canary/pre-release to latest/production. Use when the user asks to "compile the changelog", "promote release to latest", "tag a release", or do version release operations.
Consult this skill BEFORE proposing a fix to any CLI gap or schema gap that touches evidence, trust magnitude, evidence types, evidence grades, the TM formula, or star-level promotion gates. Also read it whenever an issue mentions citations, stars, commits, contributors, views, reviewers, percentile, arxiv, github-stars-own, repo-own, social-signal, benchmark-result, peer-review, self-attestation, fusion-recipe, verifier-attestation, or proxy-containment — those are the 10 canonical evidence types and the raw inputs that feed their formulas. Also read it when asked whether a skill qualifies for a given star level (0★–6★): the Star Bar and promotion gates live in `META.md`, not in the TM methodology page. Reading both prevents proposing a calibration that satisfies the TM grade threshold but violates a Star Bar installability or link requirement.
Phase 4 of the Gaia evidence verification pipeline. Checks every URL in the evidence data lake for HTTP liveness — catches dead links (404, 403, timeout, connection errors) before evidence is ingested into the registry. Use this skill when: running the full /ev-pipeline, asked to "validate links", "check evidence URLs", "run link validation", "find dead links in the data lake", "check HTTP status of evidence sources", or "verify evidence links still work". Also useful standalone when you suspect evidence sources have gone stale after a long gap between pipeline runs. Wraps validate_sources.py, which uses Firecrawl CLI to scrape each unique URL and records pass/fail status in a markdown report. Requires Firecrawl CLI to be installed and authenticated.
Top-level orchestrator for the Gaia Registry evidence verification pipeline. Run this when you want to do a full evidence pass — collecting raw sources, verifying live GitHub star counts, adversarially auditing for quality/formatting issues, and checking that every URL is reachable — all in one coordinated sequence. Trigger phrases: "run the evidence pipeline", "full evidence pass", "verify evidence", "evidence verification pipeline", "run ev-pipeline", "check all evidence", "audit the data lake", "evidence quality sweep", "refresh evidence", "validate evidence sources". Also aliased as /evidence-verification-pipeline. Use the individual sub-skills (ev-collection, ev-star-verification, ev-adversarial-audit, ev-link-validation) only when you need to re-run one phase in isolation; for end-to-end work, always start here.
Canonical entry point for the full Gaia evidence verification pipeline. Invoke as /evidence-verification-pipeline or /ev-pipeline — both names trigger this skill. Use whenever you need to run all four evidence phases end-to-end: collecting raw evidence from the data lake, verifying live GitHub star counts, running adversarial auditing for noise and URL errors, and checking link health via Firecrawl. Also use when someone says "run the evidence pipeline", "verify the evidence lake", "audit evidence", "run ev-pipeline", "full evidence check", "pipeline run", "prepare evidence for ingestion", or "refresh the data lake". This is the pre-ingestion step — run it before importing any evidence into the registry.
Batch wrapper for /gaia-ingest. Ingests a bounded set of already-verified evidence rows through CLI-only writes, uses --no-build on every row, appraises Trust Magnitude for every affected named skill, then runs exactly one build and validation pass. Use for an L4-approved intake after /ev-pipeline.
| name | pr |
| description | Push committed changes and create a draft PR on GitHub. Use when you have staged changes ready to push and want to open a draft PR for early feedback or documentation. |
Quickly push changes and open a draft pull request on GitHub.
Check what will be committed:
git status
Ensure all changes you want are staged with:
git add <files>
Or add everything:
git add .
Write a clear, conventional commit message. Use the format:
<type>(<scope>): <description>
<optional body with details>
Types: feat, fix, chore, refactor, docs, test, etc.
Examples:
feat(registry): add new skill categoryfix(cli): resolve version mismatchchore: regenerate artifactsgit commit -m "your commit message here"
git push -u origin <branch-name>
If you're on main or pushing to an existing branch:
git push
gh pr create --draft
This will prompt you for:
For multiline descriptions, use a body file with real newlines. Do not pass literal \\n sequences or rely on shell $'...' quoting; malformed quoting can make GitHub display \\n (and sometimes a stray $).
cat > /tmp/pr-body.md <<'EOF'
## Summary
Describe the change here.
EOF
gh pr create --draft --title "Your PR Title" --body-file /tmp/pr-body.md
After creating or editing the PR, verify the stored body:
gh pr view <number> --json body --jq .body
Or specify details inline for a one-line body:
gh pr create --draft --title "Your PR Title" --body "Description here"
origin/main, apply only the intended files, verify git diff --stat origin/main...HEAD, then push and create a replacement draft PR. Close the contaminated PR and cross-reference the replacement in a comment.git rebase -i origin/main to clean up commitsgh pr ready to convert from draft to ready-for-reviewgit push, the PR updates automatically"fatal: The current branch has no upstream branch"
git push -u origin <branch-name> on first push"Permission denied" when pushing
gh auth statusgh auth loginPR creation fails
git rev-parse --show-toplevelgh version