Agent skill
quick
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
Install this agent skill to your Project
npx add-skill https://github.com/govctl-org/govctl/tree/main/.claude/skills/quick
SKILL.md
/quick - Fast Path Workflow
Execute the lightweight workflow for: $ARGUMENTS
Use this only for trivial, non-behavioral changes such as typos, comments, docs fixes, or small internal cleanup.
Outputs: Completed trivial non-behavioral change, updated work item memory, and validation evidence.
Do not use this for new behavior, RFC-governed work, or architecture decisions. If the task stops being trivial, switch to /gov.
Critical Rules
- Keep the fast path small. Do not invent governance work the change does not need.
- Still use a work item.
govctl check --has-activeis the gate before editing. - Read the active work item with
govctl work show <WI-ID>. - Use work item fields correctly:
description: scope and whyjournal: what you did and what happenednotes: constraints or lessons future steps must remember
- If the change becomes behavioral, ambiguous, or architectural, stop using
/quickand switch to/gov. - Use
/commitfor raw VCS operations. Do not embedjjorgitprocedures here.
Workflow
1. Validate and classify
govctl status
- Confirm the change is still trivial and non-behavioral.
/commitwill choose the raw VCS workflow if recording is needed.
2. Resolve the work item
govctl work list pending
- Matching active item: use it
- Matching queued item:
govctl work move <WI-ID> active - No match:
govctl work new --active "<concise-title>"
Then:
govctl work show <WI-ID>
govctl work set <WI-ID> description "Brief scope: what and why"
govctl work add <WI-ID> acceptance_criteria "chore: govctl check passes"
govctl work add <WI-ID> acceptance_criteria "<category>: <specific observable outcome for this trivial change>"
The second criterion must be concrete and diff-specific. Examples:
docs: CLI example uses the current subcommand namechore: remove unused import from parser modulefix: typo in error message is corrected
3. Implement
Before editing:
govctl check --has-active
Make the change. If code comments reference governance artifacts, use [[artifact-id]].
Run the relevant validation:
govctl check
Update working memory as needed:
govctl work add <WI-ID> journal "Updated docs; govctl check passes"
govctl work add <WI-ID> notes "Do not use old command name in examples"
For very small changes, journal may be enough. Add notes only when there is something future steps should remember.
4. Record
Record the implementation change with /commit, typically using docs(scope), chore(scope), or fix(scope) as appropriate.
5. Complete
govctl work tick <WI-ID> acceptance_criteria "govctl check passes" -s done
govctl work tick <WI-ID> acceptance_criteria "<specific observable outcome>" -s done
govctl work move <WI-ID> done
6. Final record
If work-item closure should be recorded separately, use /commit with chore(work): complete <WI-ID>.
Switch to /gov when
- The change affects behavior
- The governing RFC is unclear or missing
- An ADR-level design choice appears
- The task stops being obviously trivial
BEGIN EXECUTION NOW.
Recommended Agent Skills
Expand your agent's capabilities with these related and highly-rated skills.
commit
Commit changes with govctl integration — check work item status, update journal or notes, and run govctl check
guard-writer
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
wi-writer
Write well-structured work items with proper acceptance criteria. Use when: (1) Creating work items, (2) Adding acceptance criteria, (3) User mentions work item, task, WI, or ticket
adr-writer
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
rfc-writer
Write well-structured RFCs with normative clauses. Use when: (1) Creating a new RFC, (2) Adding or editing RFC clauses, (3) User mentions RFC, specification, or normative requirements
decision-analysis
Stress-test a design decision with premortem/backcast analysis, then produce a risk-calibrated recommendation that maps to ADR fields. Use when: (1) Multiple competing architecture options, (2) Irreversible or high-risk design choices, (3) /discuss identifies a complex trade-off
Didn't find tool you were looking for?