Repository Governance Lifecycle

This is the central nervous system for governing an agent-operated repository. It applies to apps, libraries, tools, plugins, harnesses, and meta repos; Skill Steward itself remains a structural stewardship repo, not a domain tutorial catalog. It unifies ethics, branding, architectural decision logs (ADRs), and living documentation (FAQs) into a single, cohesive loop: Decide → Document → Cleanup.

Whenever an agent proposes or executes a structural shift, claim change, durable policy change, or docs-lattice change, they must walk this loop. Routine repo repairs should keep the original goal and native gate first; use this governance loop only when the repair changes durable ownership, policy, evidence, ADR/FAQ truth, or plan hygiene.

The Governance Loop

1. Check Ethics & Boundaries (NORTH_STAR)

Before making any decision, check the repository's foundational charter and ethical baseline.

• Read Charter and Ethics to ensure your proposed changes do not violate the repository's moral boundaries (e.g. no hype; no domain tutorials inside Skill Steward; domain docs belong in the governed product repo when they are that repo's product).
• Read North Star Rules to understand the extension model.
• Classify north_star_impact for durable structural changes: none, applies, clarifies, sub_star, amends, or conflicts. Use the protocol only when ownership, policy, evidence truth, ADR/FAQ truth, or the repo's center may change.
• Ask the gate questions before editing durable governance surfaces: what pain triggered this; which North Star value path it serves; whether it is a mechanism or a new center; whether it changes what the repo owns or refuses; where the ADR is if it does; and what check prevents the mechanism becoming the mission if it does not.
• Route none and applies through the native workflow, clarifies through FAQ/skill/map/check updates, sub_star through an explicit parent/child boundary, and amends or conflicts through an ADR plus a North Star diff before implementation.

2. Log the Decision (ADRs)

If you have made an architecturally significant decision (or triggered a T1-T8 threshold), you must write it down. Decisions are not valid if they only live in an agent's context window.

• Follow the formatting rules in ADR Format to write a formal Decision Record.