Project Work

Use this Skill to produce bounded project evidence and plans. For generic Recipe execution, Run lifecycle, persistence, or multi-actor methodology, follow actors and, when applicable, swarm; this Skill only selects project workflows.

Choose the primary workflow

Choose release-readiness when independent review and a release verdict are needed. Choose release-summary when the evidence is already sufficient and only a concise operator-gated summary is wanted. If one primary workflow should become a recurring named tool, use the persistent-capability workflow in actors; do not copy its composition.

Inputs and evidence

• Scope every workflow to the caller-selected repository, docs directory, or Run state.
• Treat validation_command as trusted executable input. Do not invent or broaden it.
• Select current model policy explicitly for workflows that request a model; release-readiness reviewer roles inherit only the values supplied by the caller.
• Artifact paths identify intended report targets. Confirm actual declared artifact evidence before claiming a durable file.
• Preserve degraded or insufficient review status. Never turn partial reviewer output into consensus.
• Release outputs are evidence, not publication authority.

Supporting Recipes

git-status, git-log, changelog-head, changelog-section, markdown-index, package-summary, and skill-summary support the primary workflows. Use one directly only when its narrow deterministic output is the requested result; otherwise start from a primary workflow and avoid rebuilding its composition manually.

Stop rules

Stop when repository scope, version, validation command, model policy, or write target is ambiguous. Do not edit docs from a docs-maintenance plan, publish from release evidence, or send Run Controls from run-ops. Hand those operations to their owning protocol after explicit authorization.