Урок 2.15. Conductor

Зачем это нужно

Conductor полезен как пример plugin-first SDD approach. Он не пытается заменить coding agent. Он добавляет поверх него workflow:

setup project context
-> create track
-> write spec
-> write plan
-> implement
-> review / status / revert

Для курса это важный тип инструмента. Не всегда нужна отдельная runtime-система или full methodology. Иногда достаточно plugin layer, который заставляет agent работать через specs, plans and project context внутри уже знакомой среды.

Основная идея

Conductor добавляет SDD workflow в AI coding agents через namespace commands and repository artifacts.

Он предлагает два уровня:

1. Project context.
2. Track-specific work.

Project context отвечает:

Что это за продукт?
Какой tech stack?
Какие guidelines?
Как команда работает?

Track отвечает:

Какую feature или bugfix делаем сейчас?
Какая specification?
Какой implementation plan?
Какой status?

Ключевые термины

Как это устроено

Conductor делает work track-based. Это удобно, потому что feature получает отдельное место для spec, plan and metadata.

Setup artifacts

Команда setup:

/conductor:conductor-setup

Она помогает определить:

• product context;
• product guidelines;
• tech stack;
• workflow preferences;
• code style guides;
• track registry.

Generated artifacts:

conductor/
  product.md
  product-guidelines.md
  tech-stack.md
  workflow.md
  code_styleguides/
  tracks.md

Эти files важны как project memory. Agent должен читать их до track planning.

Track lifecycle

Новая feature или bugfix:

/conductor:conductor-new-track "Add dark mode toggle to settings"

Generated artifacts:

conductor/tracks/<track_id>/
  spec.md
  plan.md
  metadata.json

Implementation:

/conductor:conductor-implement

Monitoring and control:

/conductor:conductor-status
/conductor:conductor-review
/conductor:conductor-revert

Как пользоваться

На обзорном уровне:

1. Установить Conductor plugin по official README.
2. Выполнить setup один раз.
3. Review project context files.
4. Создать track для feature or bug.
5. Review spec.md.
6. Review plan.md.
7. Запустить implementation.
8. Проверять status.
9. Использовать review command.
10. При необходимости использовать revert на уровне logical work unit.

Пример: dark mode

Prompt:

Use Conductor.

If project context is missing, run setup first.
Then create a new track:
"Add dark mode toggle to settings"

Spec must include:
- system preference detection
- manual override
- persisted user choice
- no changes to auth
- no new UI framework

Do not implement until spec.md and plan.md are reviewed.

Expected track:

conductor/tracks/add-dark-mode/
  spec.md
  plan.md
  metadata.json

Plan should include:

• storage decision;
• UI component;
• CSS variables or design tokens;
• tests;
• accessibility check;
• verification.

Когда Conductor полезен

Conductor хорошо подходит, когда:

• команда хочет SDD в existing agent environment;
• нужен project-level context;
• work удобно вести tracks;
• нужно review plans before code;
• нужен status command;
• важен git-aware revert;
• команда не хочет тяжелую external runtime.

Когда не стоит брать

Conductor может быть не лучшим выбором, если:

• нужен full lifecycle PRD/architecture/epic framework;
• нужна database-backed runtime memory;
• task слишком маленькая для track;
• project context будет никто не review;
• plugin support в вашем harness нестабилен.

Conductor vs OpenSpec

Prompt patterns

Setup

Run Conductor setup.
Create project context files.
Capture product goals, tech stack, workflow preferences, and style guides.
Stop for review after generating context.

New track

Create a new Conductor track for this feature.
Generate spec.md and plan.md.
Do not implement until both are reviewed.

Review

Review this track against:
- conductor/product.md
- conductor/tech-stack.md
- conductor/workflow.md
- track spec.md
- track plan.md

Focus on scope creep, missing tests, and guideline violations.

Типичные ошибки

Ошибка 1. Не review project context

Если product.md или tech-stack.md неправильны, все tracks будут наследовать неверный context.

Ошибка 2. Track без boundaries

Track spec должен явно сказать, что входит и что не входит. Иначе agent начнет расширять scope.

Ошибка 3. Не использовать status/review

Conductor дает control commands. Если ими не пользоваться, workflow превращается в обычный prompt-to-code.

Ошибка 4. Revert как замена review

Smart revert полезен, но лучше ловить ошибки на plan/review gate до implementation.

Практика

Создайте imaginary Conductor track:

Track:
Product context needed:
Spec:
Plan phases:
Files likely touched:
Verification:
Review questions:
Revert boundary:

Проверьте, можно ли revert feature как logical unit.

Критерии готовности

После урока студент должен уметь:

• объяснить Conductor как plugin-first SDD layer;
• описать setup artifacts;
• понять track lifecycle;
• использовать status/review/revert as control points;
• отличить Conductor от OpenSpec and BMAD.

Краткое резюме

Conductor показывает практичный middle ground: не full methodology и не bare Markdown specs, а plugin layer с project context, tracks, plans, implementation and review controls. Его сила - простота внедрения в existing agent workflow. Его риск - качество зависит от того, насколько команда review project context and tracks.

Вопросы для самопроверки

1. Что такое track в Conductor?
2. Какие project context files создает setup?
3. Почему conductor-review важен до completion?
4. Чем smart revert отличается от обычного git revert по commit hash?
5. Когда Conductor лучше lightweight manual specs?

Источники для актуализации

• Conductor repository: https://github.com/gemini-cli-extensions/conductor

Что дальше

Следующий урок разберет cc-sdd - minimal adaptable SDD harness, который воспроизводит Kiro-style spec workflow через Agent Skills for multiple coding agents.