template-setup

name	template-setup
description	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`.
allowed-tools	["Read","Edit","Bash","AskUserQuestion"]

Template Setup

You configure this kickstarter template for a concrete project by replacing every {{...}} placeholder in the .claude/ agents and skills with real values gathered from the user. After this skill runs, /spec-builder, /spec-to-issues, and /auto-issue-worker are ready to use against the user's repository.

Workflow

Step 1 — Discover the placeholders and files

Scan the .claude/ directory for remaining placeholders, excluding this skill's own directory so its instructions are never rewritten:

grep -rno '{{[A-Z_]*}}' .claude --include='*.md' \
  | grep -v '.claude/skills/template-setup/' \
  | sort -u

• List which files contain which placeholders.
• If no placeholders remain, tell the user setup is already complete and ask whether they want to re-run anyway (e.g. project details changed). Stop if not.

Step 2 — Gather facts automatically

Before asking the user, infer what you can and use it as defaults to confirm.

Prefer spec.md if it exists. If /spec-builder has already produced a spec.md at the repository root, read it first — it is the richest source of project facts:

• PROJECT_NAME, PROJECT_DESCRIPTION, PROJECT_SHORT_DESCRIPTION ← Overview section.
• PROJECT_STRUCTURE, KEY_DEPENDENCIES, LANGUAGE_VERSION_NOTE, TECH_STACK, QA_COMMANDS ← Constraints section (tech stack, platforms, dependencies, tooling).
• Use these as pre-filled defaults; only ask the user to confirm or fill what spec.md does not cover. If there is no spec.md, suggest running /spec-builder first, but proceed with the interview if the user prefers.

Also inspect the repository directly:

git remote get-url origin 2>/dev/null   # derive GITHUB_OWNER / GITHUB_REPO
basename "$(git rev-parse --show-toplevel)"  # candidate PROJECT_NAME

• Parse the remote URL ([e-mail]:owner/repo.git or https://github.com/owner/repo) into GITHUB_OWNER and GITHUB_REPO.
• Inspect the repo for stack hints (e.g. package.json, Cargo.toml, pyproject.toml, go.mod, build.gradle) to fill gaps in TECH_STACK, KEY_DEPENDENCIES, QA_COMMANDS.

Step 3 — Interview the user

Use AskUserQuestion to confirm the inferred values (from spec.md and the repo) and fill whatever remains. Group questions so the user is not overwhelmed, and skip anything already confidently derived from spec.md. Collect a value for every placeholder found in Step 1:

Placeholder	What to ask / infer
PROJECT_NAME	Project name (default: repo directory name)
PROJECT_DESCRIPTION	One-sentence description of what the project is
PROJECT_SHORT_DESCRIPTION	One-line project summary used by auto-issue-worker
GITHUB_OWNER	GitHub owner/org (default: from origin remote)
GITHUB_REPO	GitHub repo name (default: from origin remote)
PROJECT_STRUCTURE	Directory/module layout of the project
KEY_DEPENDENCIES	Main libraries/frameworks
LANGUAGE_VERSION_NOTE	Language version and notable language features
TECH_STACK	Tech stack bullet list (language, framework, DB, testing, package manager)
LANGUAGE_SPECIFIC_REVIEW_CRITERIA	Language-specific review focus (for code-reviewer)
LANGUAGE_SPECIFIC_REVIEW_RULES	Language-specific review rules (for code-reviewer)
LANGUAGE_SPECIFIC_IMPLEMENTATION_GUIDELINES	Implementation guidelines (for issue-implementer)
QA_COMMANDS	QA commands run before a PR (build, lint, format, test)

Rules:

• Propose concrete defaults (especially for the inferred and language-specific values) and let the user accept or override. The kickstarter README contains worked examples for the multi-line placeholders — offer those as a starting point matching the user's language.
• For multi-line placeholders (TECH_STACK, QA_COMMANDS, etc.), confirm the full markdown block with the user before applying.
• Do not leave any placeholder unanswered. If the user is unsure, suggest a sensible value and confirm rather than inventing silently.

Step 4 — Apply the replacements

For each placeholder, replace all occurrences across the matching files using Edit with replace_all: true (one Edit per file per placeholder). Never edit any file under .claude/skills/template-setup/.

• Replace the entire token including the braces (e.g. the PROJECT_NAME token) with the confirmed value.
• For multi-line values, ensure the surrounding markdown (list indentation, code fences) stays valid.

Step 5 — Verify and report

Re-run the Step 1 scan to confirm no placeholders remain (outside this skill):

grep -rno '{{[A-Z_]*}}' .claude --include='*.md' \
  | grep -v '.claude/skills/template-setup/'

• If any remain, go back and fill them.
• Report a summary of placeholder → value mappings and the files changed.
• Tell the user the next step: run /spec-builder to start gathering requirements.

Step 6 — Record the template sync point

So that /template-update can later pull upstream template changes with a 3-way merge, record the commit this repo currently matches in .claude/.template-version. Fetch the template HEAD (this repo was just created from it, so HEAD is the correct base):

TEMPLATE_REPO=https://github.com/Kurogoma4D/claude-code-kickstarter.git
git fetch --no-tags "$TEMPLATE_REPO" main && git rev-parse FETCH_HEAD

Write .claude/.template-version (skip silently if the fetch fails — /template-update can bootstrap it later):

TEMPLATE_REPO=https://github.com/Kurogoma4D/claude-code-kickstarter.git
TEMPLATE_REF=main
TEMPLATE_BASE_SHA=<the sha printed above>

Rules

• Never modify files under .claude/skills/template-setup/ — that would corrupt this skill for future runs.
• Confirm every value with the user before writing; this skill edits multiple files at once.
• Do not commit changes unless the user explicitly asks.
• If the repository has no origin remote, ask the user for GITHUB_OWNER/GITHUB_REPO directly instead of failing.