# Goal Issues And Release

Clear the open issue backlog and then cut a release, in one autonomous run: use the...

- Repository: https://github.com/dyoshikawa/rulesync (1577 stars)
- Category: Engineering
- License: MIT
- Last updated: 2026-11-01
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add dyoshikawa/rulesync --skill goal-issues-and-release -g -a claude-code -y`
Codex: `npx skills add dyoshikawa/rulesync --skill goal-issues-and-release -g -a codex -y`
Cursor: `npx skills add dyoshikawa/rulesync --skill goal-issues-and-release -g -a cursor -y`
Gemini CLI: `npx skills add dyoshikawa/rulesync --skill goal-issues-and-release -g -a gemini-cli -y`

## Description

Clear the open issue backlog and then cut a release, in one autonomous run: use the `batch-all-issues` skill to resolve every open issue, then the `goal-release` skill to draft, merge, and see the release through publication. Never asks the user anything, every decision is made autonomously, and blockers are reported at the end instead of interrupting the run.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# Goal Issues and Release

Run the project's two long-form maintenance skills back to back, without
stopping to ask the user anything:

1. the `batch-all-issues` skill, resolve every open issue, one at a time.
2. the `goal-release` skill, cut the release that ships whatever those fixes merged.

Use this skill when the user wants the whole backlog cleared and a release cut
in a single unattended run.

## Autonomy Rule

**Do not ask the user any questions during this run.** Both underlying skills
have steps that say to stop and ask the user; in this skill those steps become
"decide autonomously, record the decision, and keep going", with the single
exception of the safety stops listed under **Safety Boundaries** below, which
remain hard stops.

Concretely, when an underlying step would ask the user:

- Choose the option that moves the work forward, implement the fix, merge the
  PR, close the issue, cut the release, unless it hits one of the **Safety
  Boundaries** below. Leaving an issue open or a PR unmerged is reserved for
  those boundaries, not for design questions that merely lack a maintainer's
  sign-off.
- For an open design point, pick the option that best fits the project's
  existing conventions and the tool's documented behavior, and state the
  choice in the PR body so it can be revisited later.
- Record every such decision, so it lands in the final report.

Acting decisively never means guessing at facts, bypassing CI, or widening a
fix beyond the issue it resolves.

## Safety Boundaries

The autonomy rule above relaxes _convenience_ questions only. The conditions
below keep exactly the triggers the underlying skills give them; the only
difference is that instead of asking, the run halts that step and reports at
the end. No decision made here may override them:

The rest: https://github.com/dyoshikawa/rulesync/blob/HEAD/.rulesync/skills/goal-issues-and-release/SKILL.md
