project-kickstarter

Automatically consume open GitHub issues, in parallel where dependencies allow. The main agent acts as Project Manager: it builds a dependency-aware work plan, dispatches issue-implementer agents (Tech Specialists) concurrently, reviews each PR with a panel of specialist reviewers, consolidates findings, iterates on fixes, and merges. Repeats until no open issues remain. Invoke with `/auto-issue-worker`.

Run the auto-issue-worker flow against a single GitHub issue: implement it via the issue-implementer agent (Tech Specialist), review the PR once with a panel of specialist reviewers, consolidate the findings, apply one round of fixes, then stop with the PR left open (no merge). Use when you want a single issue taken from open to a ready-for-review PR without merging. Invoke with `/issue-worker <issue-number>`.

Run the full kickstarter workflow — setup, spec, issues — in one command.

Fill in the template placeholders across the `.claude/` agents and skills based on an interview about the target project. Use right after copying this kickstarter template into a project, or when project details change and the placeholders need refreshing. Invoke with `/template-setup`.

Pull updates from the kickstarter template into a working repository created from it, using a per-file 3-way merge so project-specific placeholder values are preserved and only the template's own changes are applied. Use when the upstream template has been updated and you want those changes reflected here. Invoke with `/template-update`.

Interview the user to gather project requirements and consolidate them into a structured `spec.md` at the repository root. Use when starting a new project or feature and the requirements are not yet written down. Invoke with `/spec-builder`. Produces the input consumed by the `spec-to-issues` skill.

Harden the project against software supply-chain attacks across two layers: project dependencies (lockfile pinning, audits, install-time script controls) and the CI/build pipeline (SHA-pinned actions, least-privilege tokens, Dependabot/Renovate). Sets up the guardrails with the user's approval, then audits existing dependencies and files a GitHub issue per remaining risk. Use during environment setup, or whenever dependencies or CI change. Invoke with `/supply-chain-guard`. The created issues are consumed by `/auto-issue-worker`.

Interview the user about a single ad-hoc task, then register it as one GitHub issue in the project repository. Use when an individual task comes up (a bug, a small feature, a chore) and the requirements are not yet written down — without going through `spec.md`. Invoke with `/task-to-issue`. The created issue is consumed by `/auto-issue-worker`.

Run an authorized penetration test against the project after some implementation exists: combine static code analysis and dynamic testing against the running app to detect vulnerabilities, then register each confirmed finding as a GitHub issue. Use once enough of the project is implemented to be worth probing for security flaws. Invoke with `/pentest`. The created issues are consumed by `/auto-issue-worker`.

Read `spec.md`, break it down into discrete implementation tasks, and register them as GitHub issues in the project repository. Use after a spec exists (e.g. produced by the `spec-builder` skill) and the user wants to turn it into actionable issues. Invoke with `/spec-to-issues`. The created issues are consumed by `/auto-issue-worker`.