القائمة
Commit changes with govctl integration — check work item status, update journal or notes, and run govctl check
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | commit |
| description | Commit changes with govctl integration — check work item status, update journal or notes, and run govctl check |
| allowed-tools | Read, Write, Edit, Bash, Glob, Grep, TodoWrite |
| argument-hint | ["optional commit message hint"] |
Commit changes using the project's version control system, with govctl-aware checks.
Outputs: Recorded VCS commit, updated work-item memory when applicable, and a clean post-commit working copy.
CRITICAL: Steps MUST be executed in exact order. Do NOT skip ahead.
jj or git commit commands.Run jj root first. If succeeds, use Jujutsu. If fails, run git rev-parse --git-dir. If succeeds, use Git. If both fail, stop and inform user.
Before committing, run govctl checks:
govctl check
If check fails, stop. Show the diagnostics, fix the issue, and rerun govctl check before committing.
Check for active work items:
govctl work list pending
If active work item exists:
journal entry documenting what was done and what happenednotes should be recordedgovctl work show <WI-ID>
govctl work tick <WI-ID> acceptance_criteria "<pattern>" -s done
If no active work item:
gov/** artifact filesdocs/rfc/** or docs/adr/**.claude/**CLAUDE.md, build.rs, or src/cmd/new.rs that only wire governance assetsIf Jujutsu:
jj status
jj diff --stat
If Git:
git status
git diff --stat
Format (mandatory):
<type>(<area>): <short summary>
<body (optional)>
| Type | When to use |
|---|---|
feat | New feature |
fix | Bug fix |
refactor | Code restructuring |
docs | Documentation |
test | Tests |
chore | Maintenance |
If $ARGUMENTS provided, use as basis. Otherwise derive from diff.
Single-line:
jj describe -m "<type>(<area>): <summary>"
jj new
Multi-line:
jj describe --stdin <<'EOF'
<type>(<area>): <short summary>
<body>
EOF
jj new
git add -A
git commit -m "<type>(<area>): <summary>"
After successful commit, if work item exists:
Add journal entry (if user confirmed in Step 3):
govctl work add <WI-ID> journal "Committed <summary>; govctl check passes"
govctl work add <WI-ID> journal --scope <scope> --stdin <<'EOF'
<multi-line progress summary>
EOF
Add notes only when there is a durable constraint, retry rule, or learning to preserve:
govctl work add <WI-ID> notes "Do not retry X; it fails because Y"
Tick acceptance criteria (if applicable)
Check if work item should be marked done:
govctl work move <WI-ID> done# Govctl checks
govctl check # Validate all artifacts
govctl work list pending # List active work items
govctl work show <WI-ID> # Show work item details
govctl work add <WI-ID> journal "Progress update"
govctl work tick <WI-ID> acceptance_criteria "<pattern>" -s done
# VCS commands
jj status # Jujutsu
jj diff --stat
git status # Git
git diff --stat
1. Detect active WI-XXXX
2. govctl check → passes
3. Confirm the active WI actually matches this diff
4. If yes: ask about journal entry and criterion ticks
5. If no, but diff is spec-only: proceed without attaching the commit to that WI
6. If no and diff is implementation-bearing: switch/create the correct WI first
7. Commit changes
8. Ask: "Mark work item as done?" (if all criteria ticked)
1. No pending work items
2. govctl check → passes
3. Check whether the diff is spec-only governance maintenance
- If yes: proceed with a spec-only commit and mention no WI was used
- Otherwise: ask "Which work item should this commit belong to?"
4. If implementation work applies:
- If existing work applies: activate or use it
- Otherwise: create WI with `govctl work new --active`
5. Commit changes
1. govctl check → fails
2. Show diagnostics
3. Fix the issue
4. Rerun `govctl check`
5. Commit only after it passes
Report:
BEGIN EXECUTION NOW.
Write effective Architecture Decision Records. Use when: (1) Creating a new ADR, (2) Recording a design decision, (3) User mentions ADR, decision, trade-off, or alternatives
Facilitate design discussion — research context, clarify requirements, draft RFC/ADR
Execute governed implementation workflow with work items, RFC/ADR checks, phase gates, testing, and closure. Use when: (1) User invokes /gov, (2) A non-trivial change needs work item tracking, (3) Implementation may require RFC/ADR handling
Write well-structured Verification Guards. Use when: (1) Creating a new guard, (2) Editing guard check commands or patterns, (3) User mentions guard, verification, or check
Adopt govctl in an existing project. Discovers undocumented decisions, backfills ADRs/RFCs, annotates source code. Use when: (1) Project has no governance yet, (2) User mentions migrate, adopt, onboard, or brownfield
Execute the fast path for trivial changes with minimal governance ceremony. Use when: (1) User invokes /quick, (2) Change is doc-only or non-behavioral, (3) No RFC or ADR work is needed