init

Studio Init

Initialize studio/ directory in the current project for plugin development. This directory is git-tracked — it holds development documentation (briefs, drafts, status) that has version control value.

Inspired by OpenSpec's openspec init pattern: a spec-driven workspace initialized into the project repo.

Pre-check

1. Check if studio/ already exists at the project root
   • If yes: read studio/config.yaml, report current status, list active changes via ls studio/changes/, and exit without creating anything
   • If no: proceed with initialization
2. Confirm the current directory is a git repo (check for .git/). If not, warn: "studio/ is designed to be git-tracked. Consider running git init first." Proceed anyway if the user confirms.

Steps

1. Read the config template from ${CLAUDE_SKILL_DIR}/../../templates/config.yaml. This file contains the default config — use its content verbatim.

2. Create the directory structure and write files:

studio/
├── config.yaml          # copied from template
├── changes/             # active design workspaces (domains + plugin change workspaces)
│   └── .gitkeep
├── agents/              # custom domain expert definitions (override built-ins)
│   └── .gitkeep
└── archive/             # shipped plugin design history
    └── .gitkeep

Create .gitkeep files as empty files — they ensure git tracks the empty directories.

3. Print a summary:

Studio initialized at studio/

  studio/config.yaml   — configuration
  studio/changes/      — active domain and plugin design workspaces
  studio/agents/       — custom domain expert definitions
  studio/archive/      — shipped plugin design history

This directory is git-tracked — commit it to share with your team.

4. Suggest next steps:
   • "Run /studio-planner:plan <domain> to start planning your first plugin"
   • "Implementation files will be generated into each plugin's target_dir, not stored in studio/changes/"

Notes

• studio/ is meant to be committed to git — it contains development decisions and rationale
• studio/changes/ holds active design workspaces; studio/archive/ holds shipped design history
• Domain workspaces keep long-lived planning artifacts; plugin workspaces hold design docs such as brief.md, skill-map.md, plugin.json.draft, and status.json
• Executable implementation files live in each plugin's target_dir as the single source of truth
• The official skill-creator skill handles individual skill authoring and eval — studio handles the plugin-level orchestration around it