teamcraft:init-project

What this skill does

## Goal

Scaffold the minimum structure Teamcraft needs to operate in this repo — nothing more. That's:

- `.teamcraft/project.md` — project identity (name, repo)
- `.teamcraft/work/INDEX.md` — empty work-item registry with the table header
- `CLAUDE.md` with an `@.teamcraft/project.md` import line — a shell, not a filled-in document
- `AGENTS.md` — a short pointer so any non-Claude AI harness (Codex, etc.) reads `CLAUDE.md` and `.claude/rules/*.md` as durable instructions; a pointer, not a copy

This skill does NOT interview the team about how they work, what technologies they use, or what they're building. Those are the responsibility of dedicated capture skills (`capture-team-conventions`, `capture-technical-design`, `capture-requirements`). Keeping this skill narrow prevents the scaffolding step from bloating into a multi-hour interview, and lets teams add captured knowledge in the order that makes sense for their project.

Read `references/example-project-setup.md` first. It shows exactly what the scaffolding output looks like.

## Detect What Exists

Look for existing Teamcraft scaffolding and any `CLAUDE.md` or `.claude/rules/` already in the repo. If any of them exist, **never overwrite**. Your job shifts from "create from scratch" to "fill in what's missing, leaving existing content alone."

Specifically:
- If `.teamcraft/project.md` exists: read it, don't modify it. The team's project identity is already set.
- If `.teamcraft/work/INDEX.md` exists: read it, don't modify it. Work items are already being tracked.
- If `CLAUDE.md` exists: do NOT overwrite. If it lacks an `@.teamcraft/project.md` import line, propose adding one at the top — let the developer approve the addition.
- If `AGENTS.md` exists: do NOT overwrite — a team may already maintain one. If it doesn't point at `CLAUDE.md` / `.claude/rules/`, propose adding those pointer lines; let the developer approve.
- If `.claude/rules/` exists with content: leave it entirely alone. That's managed by the capture skills and `refresh-project-rules`, not by this skill.

If the repo is completely unscaffolded, proceed with the full creation flow below.

## Create the Scaffolding

### `.teamcraft/project.md`
Interview briefly for project identity only — name, repo. Two fields. Don't expand scope. Present the proposed content to the developer; write on approval.

### `.teamcraft/work/INDEX.md`
Create an empty work-item registry with the standard table header. No entries yet — `create-issue` populates this. If the file exists, leave it alone.

### `CLAUDE.md`
If missing, create it with just the `@.teamcraft/project.md` import line. That's the scaffold. If the team later wants non-obvious constraints captured there, the capture skills handle that. Don't interview about constraints here.

If `CLAUDE.md` exists, propose adding the import line at the top (after any existing frontmatter) unless it's already there. Let the developer approve.

### `AGENTS.md`
Claude Code auto-loads `CLAUDE.md` and `.claude/rules/*.md`. Other AI harnesses don't — Codex, for one, looks for `AGENTS.md` and never sees that always-loaded layer, so a Codex session in this repo would miss whatever catastrophe banners and guardrails live there. Create a short `AGENTS.md` at the repo root that points any AI agent at `CLAUDE.md` and `.claude/rules/*.md` as the durable source of truth. Keep it a pointer, not a copy — there's nothing to keep in sync, and it stays correct as those files evolve. See `references/example-project-setup.md` for the shape. In a Claude-Code-only repo it's harmless; say so in your closing summary ("created `AGENTS.md` as a pointer for non-Claude harnesses — safe to delete if you only use Claude Code"). If it already exists, don't overwrite.

## Present Everything Before Writing

Show the developer every file you intend to create or modify, in full, before writing. The developer approves. Nothing gets written without explicit approval.

## When You're Done

Confirm what was created. Then point to the next steps — the three capture skills that populate the knowledge this project will need:

- `/capture-team-conventions` — how the team works (branching, testing, review, merge, deploy, etc.)
- `/capture-technical-design` — architecture and technology decisions
- `/capture-requirements` — product requirements (PRD)

Each is independent. The team runs them in whichever order fits their project (greenfield teams often start with requirements and tech decisions before writing code; brownfield teams often start with conventions).

Ask the developer directly: "Scaffolding done. Want to run one of the capture skills next, or stop here?" Wait for their answer. Don't auto-invoke.