teamcraft-jcg:init-project

What this skill does

## Goal

Produce four artifacts that enable Claude Code and the project's tooling to work effectively together from any starting point:

1. `.teamcraft/project.md` — the minimal project index: GitHub repo (owner/repo), Jira site URL, Jira project key, Jira project ID, and Confluence page IDs for key artifacts. Never grows beyond this.
2. `CLAUDE.md` — a living team file committed to the repo. Starts with `@.teamcraft/project.md` to import the manifest into every session automatically. Contains only what Claude Code cannot discover from the environment and what no build skill already loads.
3. `.claude/rules/` — starter rule files for domain-specific conventions that only load when Claude Code touches relevant files.
4. `.github/workflows/ci.yml` — a baseline quality-gate pipeline appropriate to the project's tech stack, using GitHub Actions format. After the file is written, attempt to set branch protection via `gh api` — fall back to manual UI instructions if the call fails.

## Hard Constraints

- No presuppositions about project state. The repo may be empty, mid-sprint, or a 30,000-line legacy codebase with no teamcraft files. Work with what exists.
- `.teamcraft/project.md` contains exactly: project name, GitHub repo (owner/repo), Jira site URL, Jira project key, Jira project ID (numeric), and Confluence page IDs for PRD, tech decisions, and conventions. Leave rows blank where documents don't exist. Nothing else.
- `CLAUDE.md` is a team file committed to the repo. Not gitignored. Not per-developer. `CLAUDE.local.md` is the per-developer file — mention it to the developer as the place for personal additions.
- `CLAUDE.md` starts with `@.teamcraft/project.md` so the manifest loads automatically in every session. Its remaining content is only what Claude Code would get wrong that it cannot discover from the environment and that no skill already provides.
- `.claude/rules/` files with a `paths` frontmatter field load only when Claude Code reads matching files — use for domain-specific rules that should not load on every session. Rules files without `paths` load at session start alongside CLAUDE.md.
- Never overwrite an existing CLAUDE.md without showing exactly what changes and getting explicit confirmation.
- **Brownfield CI/CD detection:** If `.github/workflows/ci.yml` already exists, do not replace it. Inspect it for the three quality-gate jobs (test, quality, security). Offer to extend it with any missing jobs only. Get confirmation before writing.
- **GitHub-hosted runners:** GitHub Actions uses GitHub-hosted runners by default — there is no runner registration prerequisite like GitLab CE. Self-hosted runner setup is out of scope and not a blocking issue.
- **Branch protection via gh api — attempt, then fall back:** Use `gh api repos/{owner}/{repo}/branches/{branch}/protection -X PUT` with a JSON body that requires status checks to pass before merging. If this fails, do not attempt other approaches. Instead, tell the developer to set it manually: Settings → Branches → Branch protection rules → Require status checks to pass before merging.
- **CI/CD is Claude Code only.** This capability reads the local filesystem to detect the tech stack and writes `.github/workflows/ci.yml` locally. It cannot run in Cowork without filesystem access.
- **Stack detection covers common cases.** Node (package.json), Go (go.mod), Rust (Cargo.toml), Python (requirements.txt or pyproject.toml), Java (pom.xml or build.gradle). Monorepos and exotic setups may need manual adjustment — say so and offer guidance.

## Orient and Interview

Before touching anything — before `git init`, before creating files — look around, read what the team has already decided, and then talk to the developer.

**Step 1: Observe the local directory silently.** Check what exists: `.git/`, `.teamcraft/project.md`, `CLAUDE.md`, `.claude/rules/`, `.github/workflows/`, and any project config files (package.json, go.mod, Cargo.toml, requirements.txt, pyproject.toml, etc.). Do not run `git init` yet. Do not create anything. Just observe.

**Step 2: Identify the project.** This is the one thing the developer must answer before anything else — which project is this?

- **Empty directory:** Use `gh repo list` via Bash or ask the developer for the owner/repo directly. Also use `mcp__sooperset-mcp-atlassian__jira_get_all_projects` to surface Jira projects. Ask the developer to confirm both the GitHub repo and the Jira project.
- **Has `.git`:** Check `git remote -v` to identify the GitHub repo. Use `gh repo view` via Bash to confirm accessibility. Identify the Jira project from `.teamcraft/project.md` if present, otherwise search Jira. Confirm with the developer.

**Step 3: Read what the team has already decided.** With the project identified, gather context from existing sources before asking the developer anything else:

- **Confluence artifacts:** Ask the developer if they have Confluence artifact URLs or page IDs (PRD, tech decisions, conventions) to link. If they can point at them, use `mcp__sooperset-mcp-atlassian__confluence_get_page` to load them directly. If not, offer to search Confluence using `mcp__sooperset-mcp-atlassian__confluence_search`. When found, read them. They reveal tech stack decisions, scaffolding approaches, and conventions already established by the team.
- **Jira issues:** For greenfield projects (empty directory), use `mcp__sooperset-mcp-atlassian__jira_search` with JQL to read the current sprint's issues — especially the first issue, which typically defines the scaffolding approach. Read the issue descriptions; they often specify which tools to use, what the project structure should look like, and what the tech stack is.

This step is critical. The tech lead or PM may have already decided whether a scaffolding tool is required, which one, and how the project should be structured. Those decisions live in Confluence artifacts and Jira issues — not in the developer's head.

**Step 4: Present what you found and confirm.** Now — with context from Confluence and Jira — present your understanding to the developer. What you present depends on the directory state:

- **Empty directory (greenfield):** Summarize the tech decisions and scaffolding approach you found in Confluence artifacts and/or the Jira issues. Then confirm:
  > "Based on [source — tech decisions doc / issue KEY-N / both], this project uses [tech stack]. [If scaffolding tool identified:] The plan calls for [tool, e.g., Vite] for scaffolding, which needs an empty directory — so I'll hold off on creating any files until you've run it. [If no scaffolding tool identified:] I didn't find any scaffolding tool specified — are you building the structure by hand, or is there a scaffolding tool I should know about? [If sources were unavailable:] I wasn't able to read Confluence artifacts or Jira issues, so I need your guidance: will you be using a scaffolding tool that needs a clean directory (e.g., cookiecutter, create-react-app, Vite, cargo init)?"

  The developer confirms or overrides. They may know something has changed since the documents were written — follow their lead.

- **Has `.git` but no teamcraft files (brownfield):** This is an existing repo, first time using TeamCraft. No scaffolding question needed — there's already code here. Summarize what you found in Confluence artifacts and the codebase, then proceed.

- **Has `.teamcraft/project.md` and/or `CLAUDE.md` (audit/update):** Read what exists, assess what's current, and propose updates. Ask the developer what prompted them to re-run init-project.

**Step 5: Act on what you learned.**

For **greenfield with a scaffolding tool**: Do NOT run `git init`. Do NOT create any files. Explain that you'll wait for them to run their scaffolding tool first, then come back to you — or they can run it right now in this session and tell you when it's done. Once scaffolding is complete, proceed with git init (if the scaffolding tool didn't already create one), GitHub remote s