Skip to content

vycari/repo-ops

v0.6.4MIT

Baseline maintainer dev flow as config-driven skills: create-pr (opens PRs only after running the repo's format/lint/build/test pre-flight), address-review (drive the iterative response loop on bot + human PR feedback to approval — fix, push, reply to every inline thread and a PR-level summary), release (cut a versioned release: gather changes since the last tag, update notes, run the gate, bump, tag, publish), daily-changelog (one markdown file per day from merged PRs), and daily-update (runs the repo's per-day housekeeping skills and bundles their output into one PR). Also ships two PreToolUse Bash hooks: pr-template-guard (denies a gh pr create/edit whose body is missing a heading the repo's own PR template requires) and skip-label-race-guard (warns when gh pr create applies the repo's review-skip label without --draft). Reads .claude/maintainerd.json.

address-review

Drive the iterative response loop on a PR you own — fetch every piece of review feedback (automated reviewers like CodeRabbit / gemini-code-assist AND human reviewers), triage it, fix the real issues with one focused commit each, run the repo's pre-flight, push, then post a reply to every thread (inline file:line replies plus a PR-level round summary) — because silence makes bots re-raise the same items and leaves humans unsure you saw them. Wait for the next round and repeat until the PR clears the repo's approval threshold — an approving review, or a score like 5/5 from a scoring bot, read from the PR description block first and then from bot comments and review bodies, and never assumed met when no score is found — halting and escalating instead of churning when the repo's impasse or same-file round caps trip. Reads the repo config for repo slug, default branch, pre-flight commands, and the review.* policy. Where the repo sets createPr.requireIssueForDeferredWork, a reply that defers work must name the issue tracking it. Use whenever the user wants to address, respond to, handle, work through, or iterate on review comments on their PR — "address the review feedback", "respond to the review on PR

create-pr

Create a pull request for the current repository the right way — enforce the repo's PR template, run every CI gate (format, lint, build, typecheck, tests) locally before pushing, require docs updates for user-facing changes, and write an honest, non-marketing PR body. Where the repo sets createPr.requireIssueForDeferredWork, it also refuses to open a PR whose body promises follow-up work without naming an issue. Use whenever the user wants to "create a PR", "open a pull request", "submit changes", "prepare changes for review", or "push this for review". Never bypasses verification, never auto-merges.

daily-changelog

Generate a daily changelog / release-notes document from the PRs that merged on a given date and write it to config.paths.changelogDir as YYYY-MM-DD.md. Use when the user asks for "the daily changelog", "daily release notes", "release notes", "what shipped today/yesterday", "what landed on <date>", "write up today's changes", "summarize the day's PRs", or any variant of "what merged on <date>". Defaults to yesterday when no date is given. Always writes one markdown file per day.

daily-update

Run the repo's per-day housekeeping skills and bundle their output into one PR. Each sub-skill writes to the working tree (or mutates GitHub directly); this skill runs the configured roster in sequence, collects what they wrote, and packages the combined diff into a single PR. Use when the user asks to "do the daily update", "run the daily skills", "morning sweep", "end-of-day cleanup", or when invoked by a scheduled remote agent doing the daily run. The roster is configured per-repo in config.dailyUpdate.subSkills. In an umbrella repo whose config carries a workspace block, --workspace runs the whole routine once per cloned repo in the list — one PR per repo, one combined report. Bundles the per-day skills behind one entry point so a single schedule slot covers the whole routine. Safe to invoke manually at any time.

release

Cut a versioned release of the repo — gather every change since the last tag (not just this session), update the repo's release notes / changelog, run the pre-flight checks and the repo's final release gate, bump the version via the repo's configured mechanism, push the tag, create/publish the GitHub release, and verify. Reads config.release for the version-bump mechanism + notes file and config.guidelines.release for repo-specific gates and caveats. Use when the user asks to "cut a release", "ship a release", "bump the version", "publish a new version", or "do the release". For repos that ship continuously (no versioned releases) it confirms before doing anything.