Agent skill
spec
Maintain governance artifacts without implementation work. Use when: (1) Accepting or refining ADRs, (2) Clarifying or amending RFCs without code changes, (3) Governance-only docs/check/render updates
Install this agent skill to your Project
npx add-skill https://github.com/govctl-org/govctl/tree/main/.claude/skills/spec
SKILL.md
/spec - Governance Artifact Maintenance
Maintain governance artifacts for: $ARGUMENTS
Use this workflow for spec-only governance work: refine or accept ADRs, clarify or amend RFCs, update artifact references, and validate/render governance output without implementing code.
Outputs: Updated governance artifacts, completed artifact review, and validated rendered governance state.
Artifact roles: RFCs define obligations, ADRs explain decisions, and work items track execution. /spec only maintains the first two.
Critical Rules
- Artifact-only scope. Do not write implementation code in this workflow.
- No work item by default. This workflow is for governance maintenance, not implementation tracking.
- Ask permission before lifecycle-owned verbs:
govctl adr accept,govctl adr reject,govctl adr supersede,govctl rfc finalize, andgovctl rfc bump. - Do not advance RFC phase out of
spechere. Hand off to/govwhen implementation-bearing work begins. - Clarification-only RFC updates must not silently change behavior. If behavior changes, stop and route through
/discussand/gov. - Never edit governed files directly. Use
govctlverbs only. - Validate with
govctl check, and rungovctl renderwhen rendered docs should change. - Use
/commitfor raw VCS operations. This workflow defines what to record, not how to invoke VCS directly. - Do not let RFCs absorb implementation structure or let ADRs absorb work-item execution details. Preserve artifact roles while editing.
Quick Reference
govctl status
govctl rfc list
govctl rfc show <RFC-ID>
govctl adr list
govctl adr show <ADR-ID>
govctl adr set <ADR-ID> context --stdin <<'EOF' ... EOF
govctl adr add <ADR-ID> alternatives "Option: ..."
govctl adr add <ADR-ID> alternatives "Other option: ..." --reject-reason "Why it was not chosen"
govctl adr tick <ADR-ID> alternatives --at 1 -s rejected
govctl adr tick <ADR-ID> alternatives --at 0 -s accepted
govctl adr set <ADR-ID> decision --stdin <<'EOF' ... EOF
govctl adr set <ADR-ID> consequences --stdin <<'EOF' ... EOF
govctl adr accept <ADR-ID>
govctl clause edit <RFC-ID>:C-<NAME> text --stdin <<'EOF' ... EOF
govctl rfc bump <RFC-ID> --patch -m "Clarify clause wording"
govctl rfc finalize <RFC-ID> normative
govctl check
govctl render
Workflow
1. Classify the task
Choose the narrowest fit:
- ADR maintenance: refine a proposed ADR, add alternatives/refs, or accept it
- RFC clarification: tighten wording or fill specification gaps without changing behavior
- RFC amendment: change normative requirements without implementing them yet
- Governance-only cleanup: fix artifact references, rendering output, or metadata
If the task requires implementation, testing implementation behavior, or phase advancement beyond spec, stop and use /gov.
2. Gather context
govctl status
govctl rfc list
govctl adr list
Then read the relevant artifacts:
govctl rfc show <RFC-ID>
govctl adr show <ADR-ID>
For artifact editing conventions, follow the appropriate writer skill:
- RFC changes -> rfc-writer
- ADR changes -> adr-writer
3. Edit the artifacts
Use govctl verbs only.
For ADR work:
- Refine
context,alternatives,decision,consequences, andrefs - If the ADR is ready to become authoritative, ask permission before
govctl adr accept <ADR-ID>
For RFC work:
- Edit clauses with
govctl clause edit - If the RFC is draft and ready to become normative, ask permission before
govctl rfc finalize <RFC-ID> normative - If amending an existing normative RFC, ask permission before
govctl rfc bump
Semver guidance for RFC amendments:
--patch: clarification or wording fix with no behavioral change--minor: additive requirement or newly specified behavior--major: breaking or incompatible requirement change
Every RFC bump must include a changelog summary via -m.
4. Review and validate
Run the appropriate reviewer before finalizing artifact state:
- RFC changes -> rfc-reviewer
- ADR changes -> adr-reviewer
Then validate:
govctl check
govctl render
Fix validation or reviewer issues before recording the result.
5. Record the result
Spec-only governance commits may be recorded without a work item.
Use commit types that reflect artifact maintenance:
docs(rfc): RFC drafting, clarification, or amendmentdocs(adr): ADR drafting or acceptance preparationchore(gov): governance metadata, refs, render output, or config cleanup
Use /commit to record those changes.
If the task grows into implementation work, stop here and hand off to /gov.
Handoff Rules
- Use
/discusswhen the design itself is still unresolved - Use
/govwhen code or tests must change - Use
/quickonly for standalone non-behavioral cleanup outside governance artifacts
Examples
Accept a reviewed ADR
- Read the ADR with
govctl adr show <ADR-ID> - Run adr-reviewer
- Fix issues
- Ask permission, then run
govctl adr accept <ADR-ID> - Run
govctl check
Clarify an RFC without changing behavior
- Edit the clause text with
govctl clause edit - Run rfc-reviewer
- Ask permission, then run
govctl rfc bump <RFC-ID> --patch -m "Clarify wording" - Run
govctl checkandgovctl render
Prepare a deprecation plan without implementation
- Update the RFC language to mark the behavior deprecated
- Record the rationale and migration guidance
- Review and validate the artifact changes
- Hand off to
/govfor actual implementation or removal work
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?