/writing-plans
Use when you have a spec or requirements for a multi-step task, before touching code
$ npx -y skills add Ibrahim-3d/orchestrator-supaconductor --skill writing-plans --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/writing-plans
Context preview
The summary Claude sees to decide when to auto-load this skill.
Use when you have a spec or requirements for a multi-step task, before touching code
SKILL.md
writing-plans.SKILL.mdname: writing-plans
description: Use when you have a spec or requirements for a multi-step task, before touching code
Writing Plans
Overview
Write comprehensive implementation plans assuming the engineer has zero context for our codebase and questionable taste. Document everything they need to know: which files to touch for each task, code, testing, docs they might need to check, how to test it. Give them the whole plan as bite-sized tasks. DRY. YAGNI. TDD. Frequent commits.
Assume they are a skilled developer, but know almost nothing about our toolset or problem domain. Assume they don't know good test design very well.
**Announce at start:** "I'm using the writing-plans skill to create the implementation plan."
**Save plans to:** The active conductor track directory: `conductor/tracks/{track_id}/plan.md` If no conductor track exists, create one first using the `/orchestrator-supaconductor:new-track` flow.
Bite-Sized Task Granularity
**Each step is one action (2-5 minutes):**
- "Write the failing test" - step
- "Run it to make sure it fails" - step
- "Implement the minimal code to make the test pass" - step
- "Run the tests and make sure they pass" - step
- "Commit" - step
Plan Document Header
**Every plan MUST start with this header:**
# [Feature Name] Implementation Plan
> **For Claude:** REQUIRED SUB-SKILL: Use orchestrator-supaconductor:executing-plans to implement this plan task-by-task.
**Goal:** [One sentence describing what this builds]
**Architecture:** [2-3 sentences about approach]
**Tech Stack:** [Key technologies/libraries]
---
Task Structure
### Task N: [Component Name]
**Files:**
- Create: `exact/path/to/file.py`
- Modify: `exact/path/to/existing.py:123-145`
- Test: `tests/exact/path/to/test.py`
**Step 1: Write the failing test**
```python
def test_specific_behavior():
result = function(input)
assert result == expected**Step 2: Run test to verify it fails**
Run: `pytest tests/path/test.py::test_name -v` Expected: FAIL with "function not defined"
**Step 3: Write minimal implementation**
def function(input):
return expected**Step 4: Run test to verify it passes**
Run: `pytest tests/path/test.py::test_name -v` Expected: PASS
**Step 5: Commit**
git add tests/path/test.py src/path/file.py
git commit -m "feat: add specific feature"
## Remember
- Exact file paths always
- Complete code in plan (not "add validation")
- Exact commands with expected output
- Reference relevant skills with @ syntax
- DRY, YAGNI, TDD, frequent commits
## Conductor Integration
This skill is part of the Conductor workflow. All plans are saved to the active track directory.
**When invoked by the Conductor orchestrator** (with `--track-dir` and `--spec` parameters):
- Read spec from `--spec` path
- Read project context from `conductor/product.md`, `conductor/tech-stack.md`
- Save plan to `{--track-dir}/plan.md`
- Include DAG section for parallel execution
- Update track's `metadata.json` checkpoint to `PLAN: PASSED`
- Return control to orchestrator — do NOT start execution
**When invoked standalone** (no parameters):
- Look for the active track in `conductor/tracks.md`
- Read its `spec.md` for requirements
- Save plan to `conductor/tracks/{track_id}/plan.md`
- Update track's `metadata.json` checkpoint to `PLAN: PASSED`
- After saving, announce the plan summary and HALT — do NOT start execution
- The user should run `/orchestrator-supaconductor:implement` or `/orchestrator-supaconductor:go` to executeRead more
name: writing-plans description: Use when you have a spec or requirements for a multi-step task, before touching code
Writing Plans
Overview
Write comprehensive implementation plans assuming the engineer has zero context for our codebase and questionable taste. Document everything they need to know: which files to touch for each task, code, testing, docs they might need to check, how to test it. Give them the whole plan as bite-sized tasks. DRY. YAGNI. TDD. Frequent commits.
Assume they are a skilled developer, but know almost nothing about our toolset or problem domain. Assume they don't know good test design very well.
**Announce at start:** "I'm using the writing-plans skill to create the implementation plan."
**Save plans to:** The active conductor track directory: `conductor/tracks/{track_id}/plan.md` If no conductor track exists, create one first using the `/orchestrator-supaconductor:new-track` flow.
Bite-Sized Task Granularity
**Each step is one action (2-5 minutes):**
- "Write the failing test" - step
- "Run it to make sure it fails" - step
- "Implement the minimal code to make the test pass" - step
- "Run the tests and make sure they pass" - step
- "Commit" - step
Plan Document Header
**Every plan MUST start with this header:**
# [Feature Name] Implementation Plan > **For Claude:** REQUIRED SUB-SKILL: Use orchestrator-supaconductor:executing-plans to implement this plan task-by-task. **Goal:** [One sentence describing what this builds] **Architecture:** [2-3 sentences about approach] **Tech Stack:** [Key technologies/libraries] ---
Task Structure
### Task N: [Component Name]
**Files:**
- Create: `exact/path/to/file.py`
- Modify: `exact/path/to/existing.py:123-145`
- Test: `tests/exact/path/to/test.py`
**Step 1: Write the failing test**
```python
def test_specific_behavior():
result = function(input)
assert result == expected**Step 2: Run test to verify it fails**
Run: `pytest tests/path/test.py::test_name -v` Expected: FAIL with "function not defined"
**Step 3: Write minimal implementation**
def function(input):
return expected**Step 4: Run test to verify it passes**
Run: `pytest tests/path/test.py::test_name -v` Expected: PASS
**Step 5: Commit**
git add tests/path/test.py src/path/file.py git commit -m "feat: add specific feature"
## Remember
- Exact file paths always
- Complete code in plan (not "add validation")
- Exact commands with expected output
- Reference relevant skills with @ syntax
- DRY, YAGNI, TDD, frequent commits
## Conductor Integration
This skill is part of the Conductor workflow. All plans are saved to the active track directory.
**When invoked by the Conductor orchestrator** (with `--track-dir` and `--spec` parameters):
- Read spec from `--spec` path
- Read project context from `conductor/product.md`, `conductor/tech-stack.md`
- Save plan to `{--track-dir}/plan.md`
- Include DAG section for parallel execution
- Update track's `metadata.json` checkpoint to `PLAN: PASSED`
- Return control to orchestrator — do NOT start execution
**When invoked standalone** (no parameters):
- Look for the active track in `conductor/tracks.md`
- Read its `spec.md` for requirements
- Save plan to `conductor/tracks/{track_id}/plan.md`
- Update track's `metadata.json` checkpoint to `PLAN: PASSED`
- After saving, announce the plan summary and HALT — do NOT start execution
- The user should run `/orchestrator-supaconductor:implement` or `/orchestrator-supaconductor:go` to executeMulti-agent orchestration system for Claude Code with parallel execution, automated quality gates, Board of Directors, and bundled Superpowers skills
Repo: Ibrahim-3d/orchestrator-supaconductor
Other skills on orchestrator-supaconductor.
- /agent-factory
Creates specialized worker agents dynamically from templates. Use when orchestrator needs to spawn task-specific workers for parallel execution. Handles agent lifecycle: create -> execute -> cleanup.
Open skill - /board-of-directors
Simulate a 5-member expert board deliberation for major decisions. Use when evaluating plans, architecture choices, feature designs, or any decision requiring multi-perspective expert analysis. Triggers: 'board review', 'get expert opinions', 'board meeting', 'director
Open skill - /brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
Open skill - /business-docs-sync
Ensures all business strategy, pricing, and product documents stay synchronized when product decisions change during any track execution or evaluation.
Open skill - /conductor-orchestrator
Master coordinator for the Evaluate-Loop workflow v3. Supports GOAL-DRIVEN entry, PARALLEL execution via worker agents, BOARD OF DIRECTORS deliberation, and message bus coordination. Dispatches specialized workers dynamically, monitors via message bus, aggregates results. Uses
Open skill - /context-driven-development
Use this skill when working with Conductor's context-driven development methodology, managing project context artifacts, or understanding the relationship between product.md, tech-stack.md, and workflow.md files.
Open skill

