git:20260813.f9de8c5 to git:20260814.383d593

28 added, 7 removed. Audit A to A.

---

name: project-work

- description: Repository inspection, documentation maintenance, release preparation, and project health workflows.

+ description: Use for repository health inspection, project summaries, documentation maintenance, release-readiness evidence, or bounded run-operation reports.

---

# Project Work

- Own reusable workflows for inspecting and maintaining software projects.

+ 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.

- ## Scope

+ ## Choose the primary workflow

- - Summarize Git, package, Skill, changelog, and documentation state.

- - Compose repository health, documentation maintenance, and release-readiness evidence.

- - Keep project-level orchestration separate from lower-level artifact and actor utilities.

+ | Intended result | Recipe | Boundary |

+ | --- | --- | --- |

+ | Repository status, recent history, docs surface, validation, and risks | `project-work/repo-health` | Runs the caller-supplied trusted validation command |

+ | Documentation consistency review and maintenance plan | `project-work/docs-maintenance` | Evidence and plan only; does not edit documentation |

+ | Multi-lens release verdict with blockers and degraded-confidence evidence | `project-work/release-readiness` | Readiness only; does not publish |

+ | Evidence-only release summary and PR-body draft | `project-work/release-summary` | No commit, PR, merge, tag, publish, or external release action |

+ | Bounded report over existing actor Run state | `project-work/run-ops` | Read-only report; does not send Control or mutate Runs |

- This Skill does not own the Run kernel, publication authority, multi-agent methodology, or artifact-writing mechanics. Its Recipe identity is `project-work/<filename stem>`; Recipe files have no top-level `name`. It composes other capabilities only through exact `<skill>/<recipe>` references and keeps project-specific helper behavior under its own `scripts/` directory.

+ 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.