setup

name	setup
description	The entry point. Ground an AI coding agent in a repository in one command — explore the repo, run one frontier interview covering every decision (harness, docs layout, tracker conventions, design direction if a frontend is detected), write the per-repo config doc, then dispatch to the bootstrap-agents-md and design-md engines and verify their output. Run this once per repo; re-run it to revise decisions.
license	MIT
disable-model-invocation	true
metadata	{"version":"0.1.0","invocation":"user"}

Setup

You are grounding an AI coding agent in this repository: its behavior (AGENTS.md), its language (CONTEXT.md), and its appearance (DESIGN.md, when there is a frontend). This skill is a thin orchestrator — it makes every user-owned decision exactly once, records the answers, and dispatches the writing to the engine skills. Do not duplicate the engines' work here.

Reference templates

File	Used for
references/skills-config-template.md	docs/agents/skills-config.md

Process

1. Explore (facts only — ask nothing yet)

Gather what the engines will need and what the interview depends on:

• Package manager, scripts, CI config, language/lint/test setup (the bootstrap engine's Phase 0 checklist is the authority — skim, don't duplicate its depth)
• Existing agent docs: AGENTS.md, CLAUDE.md, .cursor/rules, CONTEXT.md, design docs — anything setup must merge with rather than overwrite
• Frontend detection: react/next/vue/svelte/tailwind verified in package.json — this decides whether design questions enter the interview at all
• Domain-term candidates: schema and module names, README prose, existing docs (seed material for CONTEXT.md)
• Issue-tracker traces: .github/ templates, linear/jira references in docs or commit messages

2. Interview (one frontier interview, all decisions)

Run the frontier-interview skill over the full decision tree. Typical tree — prune what the evidence already settles:

• Harness: which agent harness(es) to target; skills directory (.agents/skills/ vs harness-specific); CLAUDE.md as symlink vs stub file
• Docs layout: docs root, plans location, whether release notes are wanted
• Tracker: which issue tracker, branch/PR conventions worth encoding
• Design (only if a frontend was detected): which design-md mode the evidence supports; if greenfield, the aesthetic-direction subtree from design-md Mode C joins this same interview
• Domain: one round confirming extracted term definitions and capturing head-only terms the code doesn't show (greenfield repos: this round IS the domain-modeling session)

Facts never enter the interview — anything you can read from the repo is already settled evidence.

3. Write the config doc

Write docs/agents/skills-config.md from references/skills-config-template.md, recording every settled decision. This file is the contract: engines read it and never re-ask what it records. Stamp it with this skill's version.

4. Dispatch to the engines

1. Follow the bootstrap-agents-md skill in full. It reads the config doc and skips every question answered there.
2. If a frontend was detected, follow the design-md skill. Same contract: config first.

The engines stay independently invocable — dispatch means follow their SKILL.md, not reimplement it here.

5. Verify

• docs/agents/skills-config.md exists and records every decision the interview settled
• Each dispatched engine's own verification pass is clean
• No decision was asked twice across the interview and the engines
• Report: decisions settled, files created by each engine, anything deferred (e.g. a Mode C proposal awaiting approval)

Re-runs and stamps

docs/agents/skills-config.md is the only file this skill emits, stamped <!-- generated by setup v<version> --> (version from this skill's frontmatter). On re-run, update the recorded decisions in place — the interview starts from the existing answers, asking only what the user wants to revise plus any decisions new evidence has opened. Everything else the run produces belongs to the engines and follows their own re-run rules.

Constraints

• One interview. If a decision surfaces later (an engine hits an unforeseen conflict), that is a single follow-up question, not a second interview
• Never overwrite existing user docs — the engines' merge rules apply, and setup must not pre-empt them
• If the user declines a whole area (e.g. "no design doc"), record the refusal in the config doc so re-runs and engines don't re-open it