메뉴
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
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | spec |
| description | 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 |
| allowed-tools | Read, Write, Edit, Bash, Glob, Grep, TodoWrite |
| argument-hint | <artifact-maintenance-task> |
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.
govctl adr accept, govctl adr reject, govctl adr supersede, govctl rfc finalize, and govctl rfc bump.spec here. Hand off to /gov when implementation-bearing work begins./discuss and /gov.govctl verbs only.govctl check, and run govctl render when rendered docs should change./commit for raw VCS operations. This workflow defines what to record, not how to invoke VCS directly.spec; edits there belong to that version candidate.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 get <RFC-ID> changelog
govctl rfc edit <RFC-ID> changelog.summary --set "Clarify current version"
govctl rfc finalize <RFC-ID> normative
govctl check
govctl render
Choose the narrowest fit:
If the task requires implementation, testing implementation behavior, or phase advancement beyond spec, stop and use /gov.
govctl status
govctl rfc list
govctl adr list
Then read the relevant artifacts:
govctl rfc show <RFC-ID>
govctl adr show <ADR-ID>
Before editing a normative RFC, inspect its current phase. The phase determines whether the edit remains in the current version candidate or must be released as a new version.
For artifact editing conventions, follow the appropriate writer skill:
Use govctl verbs only.
For ADR work:
context, alternatives, decision, consequences, and refsgovctl adr accept <ADR-ID>For RFC work:
govctl clause editgovctl rfc finalize <RFC-ID> normativespec, edit the current version candidate directly; do not bump it again for those editsimpl, test, or stable, an RFC or Clause edit creates an unversioned amendment; after review, ask permission before using govctl rfc bump to release it as the next version in specgovctl rfc edit <RFC-ID> changelog.* for current-version changelog corrections; these do not change version, phase, or the sealed content signatureSemver 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 changeEvery version-changing RFC bump must include a changelog summary via -m.
--change without a bump level is changelog-only and cannot release an RFC or
Clause content amendment.
Run the appropriate reviewer before finalizing artifact state:
Then validate:
govctl check
govctl render
Fix validation or reviewer issues before recording 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 cleanupUse /commit to record those changes.
If the task grows into implementation work, stop here and hand off to /gov.
/discuss when the design itself is still unresolved/gov when code or tests must change/quick only for standalone non-behavioral cleanup outside governance artifactsgovctl adr show <ADR-ID>govctl adr accept <ADR-ID>govctl checkgovctl rfc show <RFC-ID>govctl clause editspec, keep the current version; for a normative RFC in impl, test, or stable, ask permission, then run govctl rfc bump <RFC-ID> --patch -m "Clarify wording"govctl check and govctl render/gov for actual implementation or removal workExecute 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 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
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
Commit changes with govctl integration — check work item status, preserve durable notes only when needed, and run govctl check
Remove govctl governance from a project. Archives artifacts, removes skills/agents, strips code references. Use when: (1) User wants to stop using govctl, (2) User mentions detach, opt-out, remove governance, or uninstall
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