---
name: govern-project
description: Establish or continue requirement-led delivery governance for Alife or a system created from its baseline. Use for project completion, evidence reconciliation, prioritized work packages and handover; not for unrelated projects or routine narrow fixes.
---

# Govern project delivery

Respect the target repository's AGENTS.md, domain authorities and existing authorization. For Alife use docs/governance/README.md and work-register.json; elsewhere locate existing equivalents before creating them. This skill does not grant Git publication, deployment, migrations, future automation or architecture changes.

Identify the user's desired outcome, release scope and available evidence. Keep current-source behavior, target requirements and verified delivery separate. Reconcile conflicts against owning contracts and affected implementation; historical proposals are not automatically active requirements. Do not duplicate domain rules into a second authority.

Maintain a small register with stable task IDs, value/priority, dependencies, owning requirement references, observable acceptance, implementation status, verification status, evidence, blockers and next action. Each evidence record names date, exact revision/worktree, environment, check, outcome and limitations. Preserve failures and superseded evidence with their scope. Unassessed does not mean unimplemented. Never invent a percentage before requirements have a useful denominator.

When asked to continue toward completion, pick the highest-priority authorized unblocked package: demonstrated security/privacy/data-loss issues, blocked real-user journeys, remaining agreed requirements, then optional refinements. Inspect relevant source/tests, implement a bounded package, verify risks and update affected authorities/register. User steering wins. Ask only for material unknown decisions and keep independent work moving.

Completion needs reachable usable flows, real persistence where applicable, server-side authority, role negatives, isolation/invalidation, saved-contract compatibility, bilingual behavior, relevant rendering and target-environment evidence. Use existing domain QA; builds and mocks alone cannot certify a product. Project completion requires all agreed requirements verified or explicitly deferred by the user, operational handover and user product acceptance. Report unavailable provider/database/deployment checks plainly.

Creating a plan does not authorize executing all future tasks. Follow the user's authorized implementation scope; if they asked only for planning, return the plan. Continuing after a chat ends requires an explicitly requested automation; this skill does not schedule one.