release-governance

Solid

Use when preparing, auditing, releasing, PDF-hardening, or rebuttal-hardening academic manuscripts, datasets, artifacts, reviewer packets, or claim registers involving multiple refs, local assets, human labels, agent-assisted drafts, wide tables, figure provenance, submission PDFs, or evidence-boundary checks.

AI & Automation 38 stars 7 forks Updated 3 days ago MIT

Install

View on GitHub

Quality Score: 83/100

Stars 20%
53
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

# /release-governance - Release Evidence Governance ## Purpose Prepare release-facing academic artifacts with explicit evidence control. The core rule is: ```text release truth = ref + artifact + gate ``` Do not infer release truth from memory, a branch name, a pull request title, a local file cache, or an agent draft. ## Trigger Words This skill activates on: `release governance`, `release evidence`, `camera-ready`, `rebuttal packet`, `artifact packet`, `claim ledger`, `human evidence gate`, `release packet`, `/release-governance`. ## Core Rules 1. Name the exact ref, artifact, and gate behind every release-facing claim. 2. Keep draft advisory evidence, verified artifacts, and final human evidence separate. 3. Do not promote agent or Gemini review output into final evidence. 4. Do not treat ignored, untracked, cached, or local-only assets as submitted artifacts. 5. Do not treat a repository check as venue, submission-system, or scientific compliance. 6. If two refs diverge, name both and scope which one is canonical for each artifact. 7. If a worktree is dirty, list the dirty paths and mark the packet as draft until changes are committed or explicitly scoped. 8. Freeze evidence and argument separately. An evidence ref or result snapshot does not authorise an unapproved narrative, and an approved manuscript spine does not validate changed numbers. ## Evidence States Use `references/evidence_state_schema.md` for the shared states: - `draft_advisory` - `verified_arti...

Details

Author
yha9806
Repository
yha9806/academic-writing-toolkit
Created
5 months ago
Last Updated
3 days ago
Language
Python
License
MIT

Integrates with

Similar Skills

Semantically similar based on skill content — not just same category

AI & Automation Listed

release

Use when preparing, validating, publishing, promoting, or recovering claude-code-router releases, including CI readiness, live E2E evidence, changelog/release-note updates, draft GitHub releases, GHCR browser images, and Homebrew promotion.

4 Updated today
hishamkaram
AI & Automation Listed

release

Use for user-authorised promotion of an accepted artifact: deploy, publish, send, roll out, or observe. Not for implementation or drafting; use implement or the domain owner.

1 Updated yesterday
mblauberg
AI & Automation Listed

release-readiness

Assess whether a specific release candidate, build, artifact, application, service, mobile/desktop build, or API is ready for production in a named environment and issue an evidence-backed GO / GO_WITH_CONTROLS / NO_GO / DEFER verdict across product acceptance, QA, security, operations/reliability, documentation, billing/entitlements, and support/incident readiness. Use when the user names or implies a concrete candidate (version, build ID, branch/tag, artifact digest, deploy target) for launch/release gates, pre-deploy audits, "is this build ready to ship?", hotfix readiness, post-incident releases, and repeated delta/revalidation reviews. Do not use for first-time whole-project roadmap baselines or "analyze the entire repo" — use Repo to Roadmap. Do not use for ongoing weekly prioritization on an existing roadmap — use Product Operator. Orchestrate specialist evidence without pretending to replace security scans, live-app QA, legal/privacy review, or deployment authorization.

1 Updated 2 days ago
MaciejZet