Maintainer

Maintainer

Goal

Use this project-maintainer skill only after the user explicitly invokes $maintainer, asks to run Maintainer, or an explicitly invoked parent workflow routes here. This skill is manual-only. Do not auto-select it for ordinary skill, plugin, metadata, docs, or repository change requests.

Maintain existing skill and plugin packages through one routed control plane:

• A bare run, run your tasks, or equivalent imperative starts a conservative repo-wide maintenance pass.
• Named packages stay targeted; explicit metadata wording stays metadata-only.
• Health and instruction-density audits are read-only evidence passes.
• Runtime failures, package lifecycle work, and domain refreshes use their explicit routes and never expand from a bare run.
• Brand-new skills start with $skill-creator. Substantial public skill or plugin reshapes start with $skill-creator or $plugin-creator, then return here for integration, validation, and cleanup.

Runtime Dependencies

This project-local skill is Codex-dependent. Use $skill-audit read-only when health or workflow-family claims require portfolio, writing-quality, prompt-cost, or session evidence. Use $skill-creator or $plugin-creator for substantial public reshapes and native codex review for non-trivial implementation closeout. The remaining workflows rely on the local repository filesystem, shell, and git.

Routing And Progressive Disclosure

Always open references/maintenance-router.md first. It owns request routing, mixed-route order, task isolation, delegation, and common output handling. Open only the branch references whose conditions match the routed request:

Before closeout, load states.md, select every applicable lane from validation-matrix.md, and finish with release-checklist.md. Emit canonical result and change_state values and actionable findings.

Execution Boundaries

• Direct audit and instruction-density routes remain read-only. $skill-audit findings are evidence, not automatic cleanup authority.
• A bare maintenance run may apply only safe, low-ambiguity improvements with a concrete rationale. Report strategic, behavior-sensitive, or high-ambiguity candidates for approval.
• Keep refresh, workflow hardening, package lifecycle, and new-skill creation explicit.
• Resolve commit, push, PR, and other publication authority independently; do not infer Git mutations from maintenance authority.
• Keep changes scoped to the selected or discovered packages and preserve unrelated dirty worktree state.
• If no meaningful update is needed, return result=pass and change_state=no-change without persistent edits.