{
  "_comment": "Pool of pre-defined issues for ignaciolagosruiz/releasekit. The maintenance cronjob files these one at a time on a schedule, then resolves them after a delay. Each entry has enough detail (scope, files, tests) that a future agent session can pick it up cold and ship a clean PR.",
  "schema_version": 1,
  "issues": [
    {
      "id": "doctor-cmd",
      "title": "feat(cli): add `releasekit doctor` command to validate project setup",
      "labels": ["enhancement", "good first issue"],
      "body_markdown": "### Problem\n\nThere's no quick way to tell whether a project is ready for a `releasekit` release. New users hit confusing errors like `git tag failed (exit 128)` or `gh: not authenticated` deep in the pipeline and have to guess what's wrong.\n\n### Proposal\n\nAdd a `releasekit doctor` subcommand that runs read-only checks and prints a clear pass/fail report. Suggested checks:\n\n- `git` is on PATH and version >= 2.30\n- `gh` is on PATH, authenticated, and the auth has `repo` scope on the current remote\n- `package.json` exists, is valid JSON, and has a `name` and `version` field\n- A `releasekit.config.{json,js,cjs,mjs}` is present (warn if missing — defaults still work)\n- Working tree is clean\n- The remote URL is reachable\n- The latest tag (if any) parses as semver\n\n### Acceptance criteria\n\n- `releasekit doctor` exits 0 if all checks pass, 1 if any check fails, 2 if warnings only\n- Each check prints one line with a status icon and a short message; full report at the end\n- Add `src/doctor.ts` with a `runDoctor()` function and unit-testable check functions\n- Add a `doctor` command in `src/cli.ts`\n- Add at least 6 unit tests covering pass/fail paths for each check\n- Update README with a \"Verify your setup\" section\n\n### Suggested files\n\n- `src/doctor.ts` (new)\n- `src/cli.ts` (wire up command)\n- `src/doctor.test.ts` (new)\n- `README.md` (docs)\n- `CHANGELOG.md` (entry under \"Unreleased\")\n\n### Test plan\n\n- `npx vitest run src/doctor.test.ts` — all green\n- `npx vitest run` — full suite still green (21 existing tests unaffected)\n- Manual: `node ./dist/cli.js doctor` in a clean checkout of releasekit — exits 0, all checks pass",
      "estimate_minutes": 45
    },
    {
      "id": "prerelease-support",
      "title": "feat(version): add pre-release (alpha/beta/rc) bump support",
      "labels": ["enhancement"],
      "body_markdown": "### Problem\n\n`bumpVersion` in `src/version.ts` only handles `major`/`minor`/`patch`/`none`. The semver spec defines three more: `premajor`, `preminor`, `prepatch`, plus a way to bump an existing pre-release identifier (e.g. `1.2.3-rc.1` → `1.2.3-rc.2`). Right now `releasekit` strips any pre-release tag on bump, so a project at `1.0.0-rc.4` would jump straight to `1.0.0` and lose the pre-release history.\n\n### Proposal\n\nExtend `BumpType` to include `'premajor' | 'preminor' | 'prepatch' | 'prerelease'`. Update `bumpVersion` to:\n\n- `premajor` from `1.2.3` → `2.0.0-rc.0`\n- `preminor` from `1.2.3` → `1.3.0-rc.0`\n- `prepatch` from `1.2.3` → `1.2.4-rc.0`\n- `prerelease` from `1.2.3-rc.4` → `1.2.3-rc.5`\n- `prerelease` from `1.2.3` → `1.2.4-rc.0` (no existing pre-release)\n\nThe pre-release identifier should be configurable (default `rc`). Add a `prereleaseId` field to `ReleasekitConfig` (default `'rc'`). Update `determineBumpType` so commits with `!` (breaking) don't auto-bump to `premajor` — keep `major` as the default unless the user explicitly opts in via CLI flag.\n\n### Acceptance criteria\n\n- `parseVersion` already accepts pre-release versions (it does); no change there\n- `bumpVersion` handles all 7 bump types correctly per semver 2.0.0 §11\n- `releasekit release --bump prerelease --prerelease-id beta` works end-to-end\n- New config field `prereleaseId` defaults to `'rc'`\n- Add at least 10 new unit tests in `src/version.test.ts` covering all bump types and pre-release transitions\n- README: add a \"Pre-release versions\" section with examples\n\n### Suggested files\n\n- `src/version.ts`\n- `src/version.test.ts`\n- `src/config.ts`\n- `src/release.ts` (wire config into bump logic)\n- `src/cli.ts` (add `--prerelease-id` flag)\n- `README.md`\n- `CHANGELOG.md`\n\n### Test plan\n\n- `npx vitest run src/version.test.ts` — all green, including the 10 new tests\n- `npx vitest run` — full suite still green\n- `releasekit plan` after a `feat!:` commit should still suggest `major` (not auto-premajor) — backward compatibility check",
      "estimate_minutes": 60
    },
    {
      "id": "yes-flag",
      "title": "feat(cli): add `--yes`/`-y` flag to skip interactive confirmations in `release`",
      "labels": ["enhancement"],
      "body_markdown": "### Problem\n\n`releasekit release` will eventually prompt for confirmation in interactive mode (e.g. when the working tree is dirty, or when an override version doesn't match the computed bump). CI pipelines have no way to auto-accept, and adding a `yes` flag in the CLI is the standard pattern (e.g. `apt-get -y`, `npm i -y`).\n\n### Proposal\n\nAdd `--yes` / `-y` to the `release` command. When set:\n\n- Skip the dirty-working-tree confirmation\n- Skip the \"version override doesn't match bump type\" confirmation\n- Skip any future interactive prompts (forward-compatible)\n\nThe flag is a no-op for fully non-interactive runs.\n\n### Acceptance criteria\n\n- `releasekit release --yes` runs end-to-end without prompting, even with a dirty tree\n- Default behavior (no flag) is unchanged\n- Flag is documented in `--help` and in the README\n- One unit test that asserts the option is wired through to `runRelease`\n\n### Suggested files\n\n- `src/cli.ts` (add flag, pass to `runRelease`)\n- `src/release.ts` (accept `yes` in `ReleaseOptions`)\n- `src/release.test.ts` (new test)\n- `README.md`\n- `CHANGELOG.md`\n\n### Test plan\n\n- `npx vitest run` — all green\n- Manual: `releasekit release --yes` from a dirty tree should not prompt",
      "estimate_minutes": 20
    },
    {
      "id": "shell-completion",
      "title": "feat(cli): generate shell completion scripts (bash, zsh, fish)",
      "labels": ["enhancement", "good first issue"],
      "body_markdown": "### Problem\n\n`commander` supports shell completion out of the box via `program.complete`. `releasekit` doesn't expose it. Users on long-running terminals miss tab-completion for the subcommands and flags.\n\n### Proposal\n\nAdd a `releasekit completion <shell>` command that prints a completion script to stdout. Support `bash`, `zsh`, and `fish`. Document the one-liner install in the README.\n\n### Acceptance criteria\n\n- `releasekit completion bash` prints a valid bash completion script\n- `releasekit completion zsh` prints a valid zsh completion script\n- `releasekit completion fish` prints a valid fish completion script\n- `releasekit completion --help` shows usage\n- Documented in README: `releasekit completion bash > ~/.local/share/bash-completion/completions/releasekit`\n\n### Suggested files\n\n- `src/cli.ts` (add command; use `program.complete` from commander or build manually)\n- `README.md`\n- `CHANGELOG.md`\n\n### Test plan\n\n- `node ./dist/cli.js completion bash | head -5` produces non-empty output\n- No new unit tests required (it's a thin wrapper around commander), but add a smoke test if it's easy",
      "estimate_minutes": 20
    },
    {
      "id": "commit-msg-hook",
      "title": "feat(cli): add `releasekit install-hook` to install a Conventional Commits commit-msg validator",
      "labels": ["enhancement"],
      "body_markdown": "### Problem\n\n`releasekit` parses Conventional Commits, but it doesn't help users write them. A `commit-msg` git hook that rejects malformed messages before they land in the log would catch typos early and keep the changelog clean.\n\n### Proposal\n\nAdd a `releasekit install-hook` subcommand that:\n\n- Copies a small bash script (bundled in `src/hooks/commit-msg.sh`) to `.git/hooks/commit-msg`\n- `chmod +x`'s it\n- Prints a one-liner uninstall hint\n\nThe hook should reject any commit message that doesn't match `^(feat|fix|perf|refactor|docs|test|build|ci|chore|style|revert)(\\(.+\\))?!?:\\s.+` (i.e. the same regex `parseCommitLine` uses, with a fallback for merge commits and revert lines).\n\nAdd a `releasekit uninstall-hook` for symmetry.\n\n### Acceptance criteria\n\n- `releasekit install-hook` creates `.git/hooks/commit-msg` and marks it executable\n- A commit with a bad message (e.g. `wip stuff`) is rejected by the hook\n- A commit with a good message (`feat: add foo`) is accepted\n- `releasekit uninstall-hook` removes the file\n- README has a \"Commit conventions\" section explaining the hook and the regex\n\n### Suggested files\n\n- `src/cli.ts` (two new commands)\n- `src/hooks/commit-msg.sh` (new, committed to repo)\n- `README.md`\n- `CHANGELOG.md`\n\n### Test plan\n\n- Manual: install hook in a scratch repo, try a bad commit (rejected), then a good commit (accepted)\n- Unit test: a function that returns the hook script body as a string, so we know it exists and is non-empty",
      "estimate_minutes": 30
    },
    {
      "id": "readme-badges",
      "title": "docs: add CI status, npm version, and license badges to README",
      "labels": ["documentation"],
      "body_markdown": "### Problem\n\nThe README has a CI badge for the GitHub Actions workflow, but the npm version and license badges are linked to placeholder paths (`npmjs.com/package/releasekit` and `opensource.org/licenses/MIT`). The CI badge also points to a workflow file that may not exist yet under that exact name.\n\n### Proposal\n\nAudit the badges in `README.md` and confirm:\n\n- CI badge URL matches the actual workflow file (`.github/workflows/ci.yml`)\n- npm badge points to the real package once published (for now, leave a TODO comment in the badge alt text)\n- License badge is correct (MIT)\n\nReorder them so the most relevant badges are first. Add a `[![TypeScript]](https://www.typescriptlang.org/)` and a `[![Node 20+]](https://nodejs.org)` badge to advertise the supported runtime.\n\n### Acceptance criteria\n\n- All badge URLs in the README resolve to live, valid endpoints\n- README renders correctly on github.com (no broken images)\n- No code changes; docs only\n\n### Suggested files\n\n- `README.md`\n\n### Test plan\n\n- Visual inspection on github.com/ignaciolagosruiz/releasekit after the PR merges",
      "estimate_minutes": 10
    }
  ]
}