repository-governance-lifecycle

Orchestrates repository governance through ADRs, FAQs, North Star checks, and plan cleanup.

2|Updated Aug 15, 2026
One-click install
npx skills add https://github.com/Arenukvern/shortly --skill repository-governance-lifecycle-arenukvern
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: repository-governance-lifecycle
Source: https://github.com/Arenukvern/shortly/tree/main/.agents/skills/repository-governance-lifecycle
Command: npx skills add https://github.com/Arenukvern/shortly --skill repository-governance-lifecycle-arenukvern

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Structural changes in agent-operated repositories often go undocumented, leaving decisions trapped in chat context, stale plan files polluting the repo, and documentation drifting away from the project's charter. This Skill enforces a complete Decide → Document → Cleanup governance loop so every architectural decision is recorded, living docs stay current, and scratch artifacts are removed. ## Core Features & Use Cases - Governance Loop Orchestration: Walks agents through ethics checks, North Star impact classification (none, applies, clarifies, sub_star, amends, conflicts), ADR authoring, FAQ updates, brand tone enforcement, and plan hygiene. - Decision & Documentation Standards: Bundled references define MADR/Nygard ADR formats with T1-T8 decision checkpoints, DESIGN_FAQ/DX_FAQ structuring rules, brand guidelines with banned marketing words, and evidence routing rules. - Drift & Claim Verification: Routes claim upgrades through steward claim check evidence gates and dispositions stale docs into keep, merge, ADR, FAQ, skill, check, evidence, or delete outcomes. - Use Case: An agent proposes making repair-first the new center of a repository. The Skill classifies this as an amends North Star impact, requires an ADR plus a North Star diff before implementation, updates the DESIGN_FAQ, and deletes the temporary planning files once knowledge is durable. ## Quick Start Ask the agent to write an ADR and update the DESIGN_FAQ for a proposed architectural change using the repository-governance-lifecycle skill.

Frequently Asked Questions about repository-governance-lifecycle

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write an ADR for an architecture decision?▼

Use the MADR format with YAML frontmatter for status, date, and decision-makers, followed by context, considered options, decision outcome, and consequences. Number files as NNNN-kebab-case-title.md under docs/decisions/ and add a row to the decision log index.

What is the difference between DESIGN_FAQ and DX_FAQ?▼

DESIGN_FAQ answers why questions covering rationale and trade-offs for maintainers changing architecture, while DX_FAQ answers how questions covering API usage patterns for developers writing client code. Never duplicate facts between them; link instead.

When should a repository change trigger the governance loop?▼

Trigger the loop for structural shifts, claim changes, durable policy changes, or docs-lattice changes. Routine repairs like fixing a formatter failure should keep the native validation gate first unless they alter ownership, policy, evidence, or ADR/FAQ truth.

How do I classify North Star impact for a structural change?▼

Classify impact as none, applies, clarifies, sub_star, amends, or conflicts. Route none and applies through the native workflow, clarifies through FAQ updates, sub_star through an explicit parent/child boundary, and amends or conflicts through an ADR plus a North Star diff.

What should I do with stale plan files after completing work?▼

Extract durable knowledge into ADRs, FAQs, code, or skills, then delete the scratch plan files. Never leave completed checklists or stale implementation plans as permanent documentation, and enforce this mechanically through CI validation.

Which words are banned in repository documentation tone?▼

Marketing jargon such as unlock, supercharge, revolutionary, powerful, and ultimate is banned. Documentation should state capabilities, constraints, and failures plainly using restrained, precise, ritual-oriented language.