release-governance

Name: release-governance
Author: yha9806

24stars3forks

How to install release-governance?

yha9806/academic-writing-toolkit/release-governance

$npx -y skills add yha9806/academic-writing-toolkit --skill release-governance

Installs into the current project.

Summary

Use when preparing, auditing, releasing, or rebuttal-hardening academic manuscripts, datasets, artifacts, reviewer packets, or claim registers involving multiple refs, local assets, human labels, or agent-assisted drafts.

Files · 1

View on GitHub

SKILL.md

1	# /release-governance - Release Evidence Governance
2
3	## Purpose
4
5	Prepare release-facing academic artifacts with explicit evidence control. The core rule is:
6
7	```text
8	release truth = ref + artifact + gate
9	```
10
11	Do not infer release truth from memory, a branch name, a pull request title, a local file cache, or an agent draft.
12
13	## Trigger Words
14
15	This skill activates on: `release governance`, `release evidence`, `camera-ready`, `rebuttal packet`, `artifact packet`, `claim ledger`, `human evidence gate`, `release packet`, `/release-governance`.
16
17	## Core Rules
18
19	1. Name the exact ref, artifact, and gate behind every release-facing claim.
20	2. Keep draft advisory evidence, verified artifacts, and final human evidence separate.
21	3. Do not promote agent or Gemini review output into final evidence.
22	4. Do not treat ignored, untracked, cached, or local-only assets as submitted artifacts.
23	5. Do not treat a repository check as venue, submission-system, or scientific compliance.
24	6. If two refs diverge, name both and scope which one is canonical for each artifact.
25	7. If a worktree is dirty, list the dirty paths and mark the packet as draft until changes are committed or explicitly scoped.
26
27	## Evidence States
28
29	Use `references/evidence_state_schema.md` for the shared states:
30
31	- `draft_advisory`
32	- `verified_artifact`
33	- `human_final`
34
35	`human_final` requires an explicit human confirmation gate when the project schema provides one. Agent drafts, reviewer suggestions, generated summaries, simulations, and prefilled labels stay `draft_advisory`.
36
37	## Workflow
38
39	### 1. Declare Scope
40
41	Create `release/release_scope.md` with scope date, artifact name, intended use, included refs, excluded refs, and the highest-risk open question.
42
43	### 2. Map Repository Truth
44
45	Run narrow ref checks before reading a checkout as final state:
46
47	```bash
48	git fetch --all --prune
49	git status --short --branch
50	git worktree list --porcelain
51	git branch --all --verbose --no-abbrev
52	```
53
54	Create `release/canonical_refs.csv`. Detached HEADs are acceptable only when the exact SHA is recorded.
55
56	### 3. Inventory Assets
57
58	Create `release/local_asset_inventory.csv` to separate tracked, ignored, untracked, external-store, and generated assets. Local assets may support review, but release claims require an artifact anchor or explicit exclusion.
59
60	### 4. Anchor Artifacts And Claims
61
62	Create:
63
64	- `release/artifact_anchors.csv`
65	- `release/claim_ledger.csv`
66	- `release/evidence_gates.csv`
67
68	Every paper-facing number, qualitative conclusion, table value, figure, dataset count, and human-label claim should point to the artifact and gate that support it.
69
70	### 5. Review Advisory Evidence
71
72	Gemini or another agent may review the scope, packet, or diff, but its result is advisory. Record advisory review in the verification report without changing any evidence state to `human_final`.
73
74	### 6. Verify Packet
75
76	Use `references/release_workflow_templates.md` for columns and report structure. If Python is available, run:
77
78	```bash
79	python {skill_dir}/scripts/check_release_packet.py <project_root>
80	```
81
82	The helper checks required packet files, CSV/JSON/YAML readability, evidence-state values, required columns, local absolute paths, and obvious template markers. YAML files use PyYAML when installed; otherwise the helper applies a basic local syntax check for simple mappings and lists. It does not run experiments, access networks, push branches, or judge scientific validity.
83
84	## Stop Conditions
85
86	Stop and report a blocker if:
87
88	- a final claim depends on a dirty or ambiguous ref
89	- a human-label claim lacks a human confirmation gate
90	- a release artifact exists only as an ignored, untracked, cache, or local-only file
91	- a count comes from a pointer, stub, generated preview, or non-canonical ref
92	- a draft pull request, closed-unmerged pull request, or advisory review is being treated as final release state
93	- the packet validator reports issues that affect release-facing claims

People who liked this also viewed

6 picks

Type

release-governance

24stars3forks

View on GitHub

How to install release-governance?

yha9806/academic-writing-toolkit/release-governance

$npx -y skills add yha9806/academic-writing-toolkit --skill release-governance

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# /release-governance - Release Evidence Governance
2
3	## Purpose
4
5	Prepare release-facing academic artifacts with explicit evidence control. The core rule is:
6
7	```text
8	release truth = ref + artifact + gate
9	```
10
11	Do not infer release truth from memory, a branch name, a pull request title, a local file cache, or an agent draft.
12
13	## Trigger Words
14
15	This skill activates on: `release governance`, `release evidence`, `camera-ready`, `rebuttal packet`, `artifact packet`, `claim ledger`, `human evidence gate`, `release packet`, `/release-governance`.
16
17	## Core Rules
18
19	1. Name the exact ref, artifact, and gate behind every release-facing claim.
20	2. Keep draft advisory evidence, verified artifacts, and final human evidence separate.
21	3. Do not promote agent or Gemini review output into final evidence.
22	4. Do not treat ignored, untracked, cached, or local-only assets as submitted artifacts.
23	5. Do not treat a repository check as venue, submission-system, or scientific compliance.
24	6. If two refs diverge, name both and scope which one is canonical for each artifact.
25	7. If a worktree is dirty, list the dirty paths and mark the packet as draft until changes are committed or explicitly scoped.
26
27	## Evidence States
28
29	Use `references/evidence_state_schema.md` for the shared states:
30
31	- `draft_advisory`
32	- `verified_artifact`
33	- `human_final`
34
35	`human_final` requires an explicit human confirmation gate when the project schema provides one. Agent drafts, reviewer suggestions, generated summaries, simulations, and prefilled labels stay `draft_advisory`.
36
37	## Workflow
38
39	### 1. Declare Scope
40
41	Create `release/release_scope.md` with scope date, artifact name, intended use, included refs, excluded refs, and the highest-risk open question.
42
43	### 2. Map Repository Truth
44
45	Run narrow ref checks before reading a checkout as final state:
46
47	```bash
48	git fetch --all --prune
49	git status --short --branch
50	git worktree list --porcelain
51	git branch --all --verbose --no-abbrev
52	```
53
54	Create `release/canonical_refs.csv`. Detached HEADs are acceptable only when the exact SHA is recorded.
55
56	### 3. Inventory Assets
57
58	Create `release/local_asset_inventory.csv` to separate tracked, ignored, untracked, external-store, and generated assets. Local assets may support review, but release claims require an artifact anchor or explicit exclusion.
59
60	### 4. Anchor Artifacts And Claims
61
62	Create:
63
64	- `release/artifact_anchors.csv`
65	- `release/claim_ledger.csv`
66	- `release/evidence_gates.csv`
67
68	Every paper-facing number, qualitative conclusion, table value, figure, dataset count, and human-label claim should point to the artifact and gate that support it.
69
70	### 5. Review Advisory Evidence
71
72	Gemini or another agent may review the scope, packet, or diff, but its result is advisory. Record advisory review in the verification report without changing any evidence state to `human_final`.
73
74	### 6. Verify Packet
75
76	Use `references/release_workflow_templates.md` for columns and report structure. If Python is available, run:
77
78	```bash
79	python {skill_dir}/scripts/check_release_packet.py <project_root>
80	```
81
82	The helper checks required packet files, CSV/JSON/YAML readability, evidence-state values, required columns, local absolute paths, and obvious template markers. YAML files use PyYAML when installed; otherwise the helper applies a basic local syntax check for simple mappings and lists. It does not run experiments, access networks, push branches, or judge scientific validity.
83
84	## Stop Conditions
85
86	Stop and report a blocker if:
87
88	- a final claim depends on a dirty or ambiguous ref
89	- a human-label claim lacks a human confirmation gate
90	- a release artifact exists only as an ignored, untracked, cache, or local-only file
91	- a count comes from a pointer, stub, generated preview, or non-canonical ref
92	- a draft pull request, closed-unmerged pull request, or advisory review is being treated as final release state
93	- the packet validator reports issues that affect release-facing claims

People who liked this also viewed

6 picks

Type