codingthefuturewithai/teamcraft:init-project

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.