bootstrap-project

bootstrap-project

The on-ramp. Drops a new Bout Labs repo into the cornerman pattern in ~3 minutes. Run this once per repo, then never again (re-running asks before touching anything).

Always do first: locate the plugin

This skill is shipped from the cornerman plugin. Its templates live at <plugin-root>/templates/ — typically .claude/plugins/cornerman/templates/ in the project that's installing. If templates can't be found, surface clearly — the plugin install is incomplete.

Steps

1. Detect repo + branch model

• Read git remote -v to find origin; confirm with the user
• Read git branch -l to find branches; ask which is the default (default guess: develop if it exists else main)
• Ask about a release branch (e.g., master for App Store-tagged releases on iOS)

2. Detect stack

Scan the working tree for tells:

• *.xcodeproj or *.xcworkspace → ios-xcode
• next.config.{js,ts,mjs,cjs} → nextjs
• pyproject.toml with a [tool.poetry] section → python-poetry
  • Note: bare pyproject.toml could be Hatch, PDM, Rye, or Flit — grep for the section before selecting this preset
• package.json without Next → nodejs-generic (TODO)
• go.mod → go-modules (TODO)

Print the detection result, ask to confirm or override. If the right preset isn't shipped yet, surface and offer the custom block in the manifest so commands can be filled in manually.

3. Discover GitHub Issue Types

If the org uses native Issue Types (BoutLabs does), query GraphQL to fetch the type node IDs:

query {
  organization(login: "<org>") {
    issueTypes(first: 10) { nodes { id name } }
  }
}

Map them: Feature → feature, Task → task, Bug → bug.

If the org doesn't have Issue Types configured, leave the manifest fields empty and call out in the bootstrap report that issues will be filed without type metadata — flagged as a manual follow-up.

4. Discover project board (optional)

Ask: "Is there a GitHub Projects v2 board for this repo? Paste the URL or say no." If yes:

• Parse the project number from the URL
• Query GraphQL for the project's ID, the Status single-select field's ID, and each option's ID (Backlog / Ready / In progress / In review / Done)
• Write all into the manifest under github.project_board

5. Confirm milestones

Read open milestones from GET /repos/<owner>/<repo>/milestones?state=open. Show the list, ask which to allowlist (default: all open ones).

6. Token strategy

Ask: "Which env var holds the GitHub token for agent writes? (default: GITHUB_PERSONAL_ACCESS_TOKEN)" Write the chosen name into the manifest under github.token_env_var.

Optionally ask: "Is there a script that mints/refreshes that token? (path or empty)" If given, write it into github.token_mint_script. The skill does not install or copy the mint script itself — that's a one-time per-machine setup, not part of bootstrap.

6.5. Tracker backend

Ask: "Which tracker manages this project's issue state?"

Options:

• github-projects-v2 (default when a Projects board exists)
• text-files (no external tracker; writes project-management/STATUS.md)
• linear — if chosen, follow up with:
  • "Linear team key? (e.g., ENG)" → tracker.linear.team_key
  • "Linear API key env var? (default LINEAR_API_KEY)" → tracker.linear.token_env_var
  • "Use Linear's default workflow state names (Backlog/Todo/In Progress/In Review/Done), or override?" — defaults work for most teams; only fill tracker.linear.workflow_state_map when the project uses custom workflow state names

Write the chosen backend into tracker.backend in the manifest. Leave empty to let state.sh auto-detect at runtime (github-projects-v2 if a board is configured, text-files otherwise).

7. Write files

From <plugin-root>/templates/, render each .tmpl against the answers and write into the project. Note: as of plugin v0.3, all four project directories are lowercase: docs/, jtbd/, scripts/, and the standard .claude/. Projects bootstrapped with earlier versions that used Docs/, JTBD/, or Scripts/ should rename with a two-step git mv to work around case-insensitive macOS filesystems:

git mv Docs _docs_tmp && git mv _docs_tmp docs
git mv JTBD _jtbd_tmp && git mv _jtbd_tmp jtbd
git mv Scripts _scripts_tmp && git mv _scripts_tmp scripts

• .claude/project.yaml ← the manifest
• CLAUDE.md ← managed-section markers + project gaps
• CONTRIBUTING.md ← Bout Labs template, filled in
• AGENT_COMMS.log ← empty
• docs/ARCHITECTURE.md ← skeleton; the architect agent owns this
• docs/WORKFLOW.md ← skeleton
• docs/GLOSSARY.md ← empty (project-owned)
• docs/DECISION_LOG.md ← empty (project-owned)
• docs/LESSONS.md ← empty + header explaining purpose
• jtbd/README.md ← how to write JTBD entries
• scripts/README.md ← scripts/ purpose
• .gitignore additions ← append AGENT_COMMS.log + .claude/worktrees/ if not present

Each existing file gets a diff preview + confirm-before-overwrite prompt; the manifest writer is the only non-prompted overwrite (assumed: re-running bootstrap means refreshing the manifest).

8. Report

• The manifest path + values populated
• Which files were created, skipped, or overwritten
• Any gaps the user must fill manually (PRD path, JTBD entries, the mint-script if the configured one isn't pre-installed)
• Suggested next step: git add . && git commit -m "chore: bootstrap cornerman"

Idempotency

• If .claude/project.yaml already exists, ask whether to refresh it or keep the existing values + just refresh template files
• If managed CLAUDE.md sections already exist, refresh them in place (mark by markers like <!-- cornerman:agent-pipeline:start -->)
• Project-owned content (PRD path, LESSONS.md, jtbd/, DECISION_LOG.md entries) is never touched

What this skill doesn't do

• Install the mint-token script (per-machine setup)
• Install other Claude Code plugins beyond cornerman itself
• Migrate an existing CLAUDE.md from scratch — there's a separate v0.2 skill (/cornerman migrate) planned for that

v0.1.0 limitations

• Stack presets shipped: ios-xcode, nextjs, python-poetry. Others (nodejs-generic, go-modules, etc.) fall back to custom.
• The plugin doesn't yet write a .claude/plugins/cornerman/install.json pointer file — for now the install is "clone the plugin into .claude/plugins/cornerman/"
• The Issue Types and project board discovery use the token from the env var named in github.token_env_var (falling back to $GITHUB_PERSONAL_ACCESS_TOKEN if unset); if neither is present, the discovery steps gracefully degrade to "ask the user to paste the IDs"