conductor-setup - Agent Skills

Conductor Setup

Initialize or resume Conductor project setup. This command creates foundational project documentation through interactive Q&A.

Use this skill when

Working on conductor setup tasks or workflows

Needing guidance, best practices, or checklists for conductor setup

Do not use this skill when

The task is unrelated to conductor setup

You need a different domain or tool outside this scope

Instructions

Clarify goals, constraints, and required inputs.

Apply relevant best practices and validate outcomes.

Provide actionable steps and verification.

If detailed examples are required, open resources/implementation-playbook.md.

Pre-flight Checks

Check if conductor/ directory already exists in the project root:

- If conductor/product.md exists: Ask user whether to resume setup or reinitialize
- If conductor/setup_state.json exists with incomplete status: Offer to resume from last step

Detect project type by checking for existing indicators:

- Greenfield (new project): No .git, no package.json, no requirements.txt, no go.mod, no src/ directory
- Brownfield (existing project): Any of the above exist

Load or create conductor/setup_state.json:

{
     "status": "in_progress",
     "project_type": "greenfield|brownfield",
     "current_section": "product|guidelines|tech_stack|workflow|styleguides",
     "current_question": 1,
     "completed_sections": [],
     "answers": {},
     "files_created": [],
     "started_at": "ISO_TIMESTAMP",
     "last_updated": "ISO_TIMESTAMP"
   }

Interactive Q&A Protocol

CRITICAL RULES:

Ask ONE question per turn

Wait for user response before proceeding

Offer 2-3 suggested answers plus "Type your own" option

Maximum 5 questions per section

Update setup_state.json after each successful step

Validate file writes succeeded before continuing

Section 1: Product Definition (max 5 questions)

Q1: Project Name

What is your project name?
Suggested:
[Infer from directory name]

[Infer from package.json/go.mod if brownfield]

Type your own

Q2: Project Description

Describe your project in one sentence.
Suggested:
A web application that [does X]

A CLI tool for [doing Y]

Type your own

Q3: Problem Statement

What problem does this project solve?
Suggested:
Users struggle to [pain point]

There's no good way to [need]

Type your own

Q4: Target Users

Who are the primary users?
Suggested:
Developers building [X]

End users who need [Y]

Internal teams managing [Z]

Type your own

Q5: Key Goals (optional)

What are 2-3 key goals for this project? (Press enter to skip)

Section 2: Product Guidelines (max 3 questions)

Q1: Voice and Tone

What voice/tone should documentation and UI text use?
Suggested:
Professional and technical

Friendly and approachable

Concise and direct

Type your own

Q2: Design Principles

What design principles guide this project?
Suggested:
Simplicity over features

Performance first

Developer experience focused

User safety and reliability

Type your own (comma-separated)

Section 3: Tech Stack (max 5 questions)

For brownfield projects, first analyze existing code:

Run Glob to find package.json, requirements.txt, go.mod, Cargo.toml, etc.

Parse detected files to pre-populate tech stack

Present findings and ask for confirmation/additions

Q1: Primary Language(s)

What primary language(s) does this project use?
[For brownfield: "I detected: Python 3.11, JavaScript. Is this correct?"]
Suggested:
TypeScript

Python

Go

Rust

Type your own (comma-separated)

Q2: Frontend Framework (if applicable)

What frontend framework (if any)?
Suggested:
React

Vue

Next.js

None / CLI only

Type your own

Q3: Backend Framework (if applicable)

What backend framework (if any)?
Suggested:
Express / Fastify

Django / FastAPI

Go standard library

None / Frontend only

Type your own

Q4: Database (if applicable)

What database (if any)?
Suggested:
PostgreSQL

MongoDB

SQLite

None / Stateless

Type your own

Q5: Infrastructure

Where will this be deployed?
Suggested:
AWS (Lambda, ECS, etc.)

Vercel / Netlify

Self-hosted / Docker

Not decided yet

Type your own

Section 4: Workflow Preferences (max 4 questions)

Q1: TDD Strictness

How strictly should TDD be enforced?
Suggested:
Strict - tests required before implementation

Moderate - tests encouraged, not blocked

Flexible - tests recommended for complex logic

Q2: Commit Strategy

What commit strategy should be followed?
Suggested:
Conventional Commits (feat:, fix:, etc.)

Descriptive messages, no format required

Squash commits per task

Q3: Code Review Requirements

What code review policy?
Suggested:
Required for all changes

Required for non-trivial changes

Optional / self-review OK

Q4: Verification Checkpoints

When should manual verification be required?
Suggested:
After each phase completion

After each task completion

Only at track completion

Section 5: Code Style Guides (max 2 questions)

Q1: Languages to Include

Which language style guides should be generated?
[Based on detected languages, pre-select]
Options:
TypeScript/JavaScript

Python

Go

Rust

All detected languages

Skip style guides

Q2: Existing Conventions

Do you have existing linting/formatting configs to incorporate?
[For brownfield: "I found .eslintrc, .prettierrc. Should I incorporate these?"]
Suggested:
Yes, use existing configs

No, generate fresh guides

Skip this step

Artifact Generation

After completing Q&A, generate the following files:

1. conductor/index.md

# Conductor - [Project Name] Navigation hub for project context. Quick Links Product Definition Product Guidelines Tech Stack Workflow Tracks Active Tracks  Getting Started

Run /conductor:new-track to create your first feature track.

2. conductor/product.md

Template populated with Q&A answers for:

Project name and description

Problem statement

Target users

Key goals

3. conductor/product-guidelines.md

Template populated with:

Voice and tone

Design principles

Any additional standards

4. conductor/tech-stack.md

Template populated with:

Languages (with versions if detected)

Frameworks (frontend, backend)

Database

Infrastructure

Key dependencies (for brownfield, from package files)

5. conductor/workflow.md

Template populated with:

TDD policy and strictness level

Commit strategy and conventions

Code review requirements

Verification checkpoint rules

Task lifecycle definition

6. conductor/tracks.md

# Tracks Registry
<div class="overflow-x-auto my-6"><table class="min-w-full divide-y divide-border border border-border"><thead><tr><th class="px-4 py-2 text-left text-sm font-semibold text-foreground bg-muted/50">Status</th><th class="px-4 py-2 text-left text-sm font-semibold text-foreground bg-muted/50">Track ID</th><th class="px-4 py-2 text-left text-sm font-semibold text-foreground bg-muted/50">Title</th><th class="px-4 py-2 text-left text-sm font-semibold text-foreground bg-muted/50">Created</th><th class="px-4 py-2 text-left text-sm font-semibold text-foreground bg-muted/50">Updated</th></tr></thead><tbody class="divide-y divide-border"></tbody></table></div><!-- Tracks registered by /conductor:new-track -->

7. conductor/code_styleguides/

Generate selected style guides from $CLAUDE_PLUGIN_ROOT/templates/code_styleguides/

State Management

After each successful file creation:

Update setup_state.json:

- Add filename to files_created array
- Update last_updated timestamp
- If section complete, add to completed_sections

Verify file exists with Read tool

Completion

When all files are created:

Set setup_state.json status to "complete"

Display summary:

Conductor setup complete! Created artifacts: - conductor/index.md - conductor/product.md - conductor/product-guidelines.md - conductor/tech-stack.md - conductor/workflow.md - conductor/tracks.md - conductor/code_styleguides/[languages]

Next steps: 1. Review generated files and customize as needed 2. Run /conductor:new-track to create your first track

Resume Handling

If --resume argument or resuming from state:

Load setup_state.json

Skip completed sections

Resume from current_section and current_question

Verify previously created files still exist

If files missing, offer to regenerate

Error Handling

If file write fails: Halt and report error, do not update state

If user cancels: Save current state for future resume

If state file corrupted: Offer to start fresh or attempt recovery