teamcraft-glgd:init-project

What this skill does

## Goal

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

1. `.teamcraft/project.md` — the minimal project index: GitLab project ID and Drive artifact URLs. 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. `.gitlab-ci.yml` — a baseline quality-gate pipeline appropriate to the project's tech stack, with three stages: `test` (stack-appropriate test suite), `quality` (lint/format check for the detected stack), and `security` (GitLab CE secret detection template — language-agnostic). After the file is written, attempt to set merge protection via the GraphQL MCP tool — fall back to manual UI instructions if the mutation fails on this GitLab CE version.

## 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, GitLab namespace, numeric project ID, and Drive URLs for PRD, tech decisions, and conventions. Leave rows blank where documents don't exist. Nothing else — no milestone data, no sprint history, no team notes.
- `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.
- If a Drive file operation fails with a path error, read the error message to identify a valid accessible host path and retry with it.
- **Brownfield CI/CD detection:** If `.gitlab-ci.yml` already exists, do not replace it. Inspect it for the three quality-gate stages (test, quality, security). Offer to extend it with any missing stages only. Get confirmation before writing.
- **Runner prerequisite:** Without at least one registered GitLab Runner, pipelines sit as pending forever. Detect whether a runner is likely configured by checking if any pipelines have run on the project. If there is no evidence of a runner, surface this clearly: explain what the team needs to do (install and register a runner), what will happen without one (pipelines pending indefinitely), and that runner setup is outside TeamCraft's scope. Do not leave the team without direction.
- **Merge protection via GraphQL — attempt, then fall back:** Use `mcp__gitlab__execute_graphql` to call the `projectUpdate` mutation and set `onlyAllowMergeIfPipelineSucceeds: true`. This mutation is not available on all GitLab CE versions — if the call fails, do not attempt curl or REST fallbacks. Instead, tell the developer to set it manually in the GitLab UI: Settings → General → Merge requests → enable "Pipelines must succeed". Explain what it does and why it matters.
- **CI/CD is Claude Code only.** This capability reads the local filesystem to detect the tech stack and writes `.gitlab-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.

## Resolve Drive Account

Call `mcp__google-drive__list_accounts` before any other Drive operation:
- **No accounts** — Drive is not configured for this user. Tell them and skip Drive operations.
- **One account** — Use it. Pass `account_email` explicitly on every Drive tool call this session.
- **Multiple accounts** — Present the list, ask which account to use for this session. Pass that `account_email` on every Drive tool call.

If any Drive call returns a permission error, surface it: the active account may not have access to that file or folder. Offer to try another account if one is available.

## 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/`, `.gitlab-ci.yml`, 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 GitLab project.** This is the one thing the developer must answer before anything else — which project is this?

- **Empty directory:** Use `mcp__gitlab__list_projects` to surface visible projects. Ask the developer which one this directory belongs to.
- **Has `.git`:** Check `git remote -v` to identify the project. Confirm with the developer. If no remote resolves, fall back to `mcp__gitlab__list_projects`.

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

- **Drive artifacts:** Ask the developer if they have Drive artifact URLs (PRD, tech decisions, conventions) to link — if they can point at them, load them directly; if not, ask whether to search Drive. When found, read them. They reveal tech stack decisions, scaffolding approaches, and conventions already established by the team.
- **GitLab issues:** For greenfield projects (empty directory), use `mcp__gitlab__list_issues` to read the current milestone'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 Drive artifacts and GitLab issues — not in the developer's head.

**Step 4: Present what you found and confirm.** Now — with context from Drive and GitLab — 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 Drive artifacts and/or the GitLab issues. Then confirm:
  > "Based on [source — tech decisions doc / issue #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 Drive artifacts or GitLab 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 teamcraf