# Governance

> Use when deciding which document canonically owns a topic, whether it is safe to mark documentation or an implementation plan Completed/Archived/Deprecated, whether a documentation change is acceptance-ready, or when running the structure/metadata/old-path/manifest/reindex audits before accepting a change. Also use when a state record (a target README's `## Status` block, or `process-state.yaml`) may have drifted, when deciding whether async messaging/orchestration/auth/external-provider work needs a Mermaid sequence diagram before it can be accepted, or when checking a change against the documentation stop conditions before treating it as done. Covers both canonical-ownership/lifecycle policy (`documentation-governance.md`) and the acceptance-blocking quality gates and stop conditions built on top of it (`quality-gates.md`) — the two are companion documents in this workspace's own governance/README.md and are not meant to be applied separately.

- Skill: `bhangeef16/governance` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add bhangeef16/governance`
- Raw SKILL.md: https://api.skillmd.com/api/skills/bhangeef16/governance/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: BhangeeF16 (https://skillmd.com/u/bhangeef16)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/bhangeef16/governance

---


# Governance

This is a meta-skill: a rule that applies across every stage rather than belonging to one. It covers two tightly coupled documents this workspace's own `governance/README.md` names as companions — `documentation-governance.md` is the canonical owner for ownership/lifecycle policy, `quality-gates.md` is the canonical owner for the acceptance-blocking checks built on top of that policy — read live from this plugin's own source files every time this skill runs, so there is no separate paraphrased copy anywhere for either to drift against.

## Documentation governance (live)

!`cat "${CLAUDE_PLUGIN_ROOT}/skills/governance/documentation-governance.md"`

## Documentation quality gates (live)

!`cat "${CLAUDE_PLUGIN_ROOT}/skills/governance/quality-gates.md"`

## Instructions

1. Before marking any document `Completed`, confirm acceptance evidence actually exists (Lifecycle Rules above); before marking one `Archived`, confirm active navigation no longer depends on it. Never mark either status because a plan section was merely edited — see the Delivery Gates section above.
2. When a target's state might have drifted, compare the state record against the artifacts it describes and repair both together in the same change set (see the `delivery-governance` meta-skill for the full state contract) — state records are hand-maintained; there is no mechanical writer.
3. Before accepting a documentation change, run the audits named in the Quality Gates content above (structure, metadata, active old-path search, manifest path validation, graph reindex) and the Acceptance Playbook, and check the change against every Stop Condition listed above — do not accept if any one of them applies.
4. Apply the Business Rule And Engineering Rule Split exactly: a documentation rule belongs in the `documentation-standards` meta-skill's source; a delivery or test acceptance rule belongs here. An engineering constraint (for example "no controllers," "Kafka commands are non-replayable by default") is never a business rule — flag it as miscategorized if you see one.
5. When a document is stale, follow the Stale Document Handling sequence above (identify the canonical owner, move or summarize unique content into it, replace or delete the stale content, update incoming links, rebuild the graph index) — do not preserve stale content merely because it is large, and do not delete it before its canonical owner is confirmed.
6. Never recreate a documentation `archive/` directory without an approved plan, per the No Archive Directory Policy above; product-domain status language (for example "Archived vendor") is a different concept and is not affected by this policy.
7. For the Mermaid diagram formatting rules this governance content points at (owned elsewhere, per its own Diagram Governance section), defer to the `documentation-standards` meta-skill rather than restating them here.
8. If you are re-reading this skill after `skills/governance/documentation-governance.md` or `skills/governance/quality-gates.md` changed, trust what you just read above over any memory of a previous run — that live content is always the current source of truth for documentation ownership, lifecycle, and acceptance in this knowledge base.