Back to Skills

conductor-setup

majiayu000
Updated Yesterday
58
9
58
View on GitHub
Designautomationdesign

About

The conductor-setup skill initializes projects by generating Conductor artifacts like product definitions and tech stacks through interactive Q&A. Use it when starting conductor setup tasks to get guided best practices and foundational documentation. It includes pre-flight checks for existing configurations and provides actionable implementation steps.

Quick Install

Claude Code

Recommended
Plugin CommandRecommended
/plugin add https://github.com/majiayu000/claude-skill-registry
Git CloneAlternative
git clone https://github.com/majiayu000/claude-skill-registry.git ~/.claude/skills/conductor-setup

Copy and paste this command in Claude Code to install this skill

Documentation

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

  1. 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
  2. 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
  3. 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:
1. [Infer from directory name]
2. [Infer from package.json/go.mod if brownfield]
3. Type your own

Q2: Project Description

Describe your project in one sentence.

Suggested:
1. A web application that [does X]
2. A CLI tool for [doing Y]
3. Type your own

Q3: Problem Statement

What problem does this project solve?

Suggested:
1. Users struggle to [pain point]
2. There's no good way to [need]
3. Type your own

Q4: Target Users

Who are the primary users?

Suggested:
1. Developers building [X]
2. End users who need [Y]
3. Internal teams managing [Z]
4. 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:
1. Professional and technical
2. Friendly and approachable
3. Concise and direct
4. Type your own

Q2: Design Principles

What design principles guide this project?

Suggested:
1. Simplicity over features
2. Performance first
3. Developer experience focused
4. User safety and reliability
5. 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:
1. TypeScript
2. Python
3. Go
4. Rust
5. Type your own (comma-separated)

Q2: Frontend Framework (if applicable)

What frontend framework (if any)?

Suggested:
1. React
2. Vue
3. Next.js
4. None / CLI only
5. Type your own

Q3: Backend Framework (if applicable)

What backend framework (if any)?

Suggested:
1. Express / Fastify
2. Django / FastAPI
3. Go standard library
4. None / Frontend only
5. Type your own

Q4: Database (if applicable)

What database (if any)?

Suggested:
1. PostgreSQL
2. MongoDB
3. SQLite
4. None / Stateless
5. Type your own

Q5: Infrastructure

Where will this be deployed?

Suggested:
1. AWS (Lambda, ECS, etc.)
2. Vercel / Netlify
3. Self-hosted / Docker
4. Not decided yet
5. Type your own

Section 4: Workflow Preferences (max 4 questions)

Q1: TDD Strictness

How strictly should TDD be enforced?

Suggested:
1. Strict - tests required before implementation
2. Moderate - tests encouraged, not blocked
3. Flexible - tests recommended for complex logic

Q2: Commit Strategy

What commit strategy should be followed?

Suggested:
1. Conventional Commits (feat:, fix:, etc.)
2. Descriptive messages, no format required
3. Squash commits per task

Q3: Code Review Requirements

What code review policy?

Suggested:
1. Required for all changes
2. Required for non-trivial changes
3. Optional / self-review OK

Q4: Verification Checkpoints

When should manual verification be required?

Suggested:
1. After each phase completion
2. After each task completion
3. 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:
1. TypeScript/JavaScript
2. Python
3. Go
4. Rust
5. All detected languages
6. 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:
1. Yes, use existing configs
2. No, generate fresh guides
3. 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.md)
- [Product Guidelines](./product-guidelines.md)
- [Tech Stack](./tech-stack.md)
- [Workflow](./workflow.md)
- [Tracks](./tracks.md)

## Active Tracks

<!-- Auto-populated by /conductor:new-track -->

## 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

| Status | Track ID | Title | Created | Updated |
| ------ | -------- | ----- | ------- | ------- |

<!-- 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:

  1. Update setup_state.json:
    • Add filename to files_created array
    • Update last_updated timestamp
    • If section complete, add to completed_sections
  2. Verify file exists with Read tool

Completion

When all files are created:

  1. Set setup_state.json status to "complete"

  2. 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:

  1. Load setup_state.json
  2. Skip completed sections
  3. Resume from current_section and current_question
  4. Verify previously created files still exist
  5. 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

GitHub Repository

majiayu000/claude-skill-registry
Path: skills/conductor-setup

Related Skills

content-collections

Meta

This skill provides a production-tested setup for Content Collections, a TypeScript-first tool that transforms Markdown/MDX files into type-safe data collections with Zod validation. Use it when building blogs, documentation sites, or content-heavy Vite + React applications to ensure type safety and automatic content validation. It covers everything from Vite plugin configuration and MDX compilation to deployment optimization and schema validation.

View skill

creating-opencode-plugins

Meta

This skill provides the structure and API specifications for creating OpenCode plugins that hook into 25+ event types like commands, files, and LSP operations. It offers implementation patterns for JavaScript/TypeScript modules that intercept and extend the AI assistant's lifecycle. Use it when you need to build event-driven plugins for monitoring, custom handling, or extending OpenCode's capabilities.

View skill

sglang

Meta

SGLang is a high-performance LLM serving framework that specializes in fast, structured generation for JSON, regex, and agentic workflows using its RadixAttention prefix caching. It delivers significantly faster inference, especially for tasks with repeated prefixes, making it ideal for complex, structured outputs and multi-turn conversations. Choose SGLang over alternatives like vLLM when you need constrained decoding or are building applications with extensive prefix sharing.

View skill

langchain

Meta

LangChain is a framework for building LLM applications using agents, chains, and RAG pipelines. It supports multiple LLM providers, offers 500+ integrations, and includes features like tool calling and memory management. Use it for rapid prototyping and deploying production systems like chatbots, autonomous agents, and question-answering services.

View skill