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
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
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
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
설치 방법 보기설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.
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.
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.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 set <ADR-ID> decision --stdin <<'EOF' ... EOF
govctl adr set <ADR-ID> consequences --stdin <<'EOF' ... EOF
govctl adr add <ADR-ID> alternatives "Option: ..."
govctl adr accept <ADR-ID>
govctl clause edit <RFC-ID>:C-<NAME> --stdin <<'EOF' ... EOF
govctl rfc bump <RFC-ID> --patch -m "Clarify clause wording"
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>
For artifact editing conventions, follow the appropriate writer skill:
Use govctl verbs only.
For ADR work:
context, decision, consequences, alternatives, and refsgovctl adr accept <ADR-ID>For RFC work:
govctl clause editgovctl rfc finalize <RFC-ID> normativegovctl rfc bumpSemver 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 RFC bump must include a changelog summary via -m.
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 clause editgovctl rfc bump <RFC-ID> --patch -m "Clarify wording"govctl check and govctl render/gov for actual implementation or removal work아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.
로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.
아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.
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, update journal or notes, and run govctl check
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
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
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
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
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.