/do
This skill should be used for structured feature development with codebase understanding. Triggers on /do command. Provides a 5-phase workflow (Understand, Clarify, Design, Implement, Complete) using codeagent-wrapper to orchestrate code-explorer, code-architect, code-reviewer,
$ npx -y skills add cexll/myclaude --skill do --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
/do
Context preview
The summary Claude sees to decide when to auto-load this skill.
This skill should be used for structured feature development with codebase understanding. Triggers on /do command. Provides a 5-phase workflow (Understand, Clarify, Design, Implement, Complete) using codeagent-wrapper to orchestrate code-explorer, code-architect, code-reviewer,
SKILL.md
do.SKILL.mdname: do
description: This skill should be used for structured feature development with codebase understanding. Triggers on /do command. Provides a 5-phase workflow (Understand, Clarify, Design, Implement, Complete) using codeagent-wrapper to orchestrate code-explorer, code-architect, code-reviewer, and develop agents in parallel.
allowed-tools: ["Bash(python3:*/.claude/skills/do/scripts/setup-do.py*)", "Bash(python3:*/.claude/skills/do/scripts/task.py*)"]
do - Feature Development Orchestrator
An orchestrator for systematic feature development. Invoke agents via `codeagent-wrapper`, never write code directly.
Loop Initialization (REQUIRED)
When triggered via `/do <task>`, initialize the task directory immediately without asking about worktree:
python3 "$HOME/.claude/skills/do/scripts/setup-do.py" "<task description>"
This creates a task directory under `.claude/do-tasks/` with:
- `task.md`: Single file containing YAML frontmatter (metadata) + Markdown body (requirements/context)
**Worktree decision is deferred until Phase 4 (Implement).** Phases 1-3 are read-only and do not require worktree isolation.
Task Directory Management
Use `task.py` to manage task state:
# Update phase
python3 "$HOME/.claude/skills/do/scripts/task.py" update-phase 2
# Check status
python3 "$HOME/.claude/skills/do/scripts/task.py" status
# List all tasks
python3 "$HOME/.claude/skills/do/scripts/task.py" list
Worktree Mode
The worktree is created **only when needed** (right before Phase 4: Implement). If the user chooses worktree mode:
1. Run setup with `--worktree` flag to create the worktree:
python3 "$HOME/.claude/skills/do/scripts/setup-do.py" --worktree "<task description>"
2. Use the `DO_WORKTREE_DIR` environment variable to direct `codeagent-wrapper` develop agent into the worktree. **Do NOT pass `--worktree` to subsequent calls** — that creates a new worktree each time.
# Save the worktree path from setup output, then prefix all develop calls:
DO_WORKTREE_DIR=<worktree_dir> codeagent-wrapper --agent develop - . <<'EOF'
...
EOF
Read-only agents (code-explorer, code-architect, code-reviewer) do NOT need `DO_WORKTREE_DIR`.
Hard Constraints
1. **Never write code directly.** Delegate all code changes to `codeagent-wrapper` agents. 2. **Parallel-first.** Run independent tasks via `codeagent-wrapper --parallel`. 3. **Update phase after each phase.** Use `task.py update-phase <N>`. 4. **Expect long-running `codeagent-wrapper` calls.** High-reasoning modes can take a long time. 5. **Timeouts are not an escape hatch.** If a call times out, retry with narrower scope. 6. **Defer worktree decision until Phase 4.** Only ask about worktree mode right before implementation. If enabled, prefix develop agent calls with `DO_WORKTREE_DIR=<path>`. Never pass `--worktree` after initialization.
Agents
| Agent | Purpose | Needs --worktree | |-------|---------|------------------| | `code-explorer` | Trace code, map architecture, find patterns | No (read-only) | | `code-architect` | Design approaches, file plans, build sequences | No (read-only) | | `code-reviewer` | Review for bugs, simplicity, conventions | No (read-only) | | `develop` | Implement code, run tests | **Yes** — use `DO_WORKTREE_DIR` env prefix |
Issue Severity Definitions
**Blocking issues** (require user input):
- Impacts core functionality or correctness
- Security vulnerabilities
- Architectural conflicts with existing patterns
- Ambiguous requirements with multiple valid interpretations
**Minor issues** (auto-fix without asking):
- Code style inconsistencies
- Naming improvements
- Missing documentation
- Non-critical test coverage gaps
5-Phase Workflow
Phase 1: Understand (Parallel, No Interaction)
**Goal:** Understand requirements and map codebase simultaneously.
**Actions:** Run `code-architect` and 2-3 `code-explorer` tasks in parallel.
codeagent-wrapper --parallel <<'EOF'
---TASK---
id: p1_requirements
agent: code-architect
workdir: .
---CONTENT---
Analyze requirements completeness (score 1-10):
1. Extract explicit requirements, constraints, acceptance criteria
2. Identify blocking questions (issues that prevent implementation)
3. Identify minor clarifications (nice-to-have but can proceed without)
Output format:
- Completeness score: X/10
- Requirements: [list]
- Non-goals: [list]
- Blocking questions: [list, if any]
---TASK---
id: p1_similar_features
agent: code-explorer
workdir: .
---CONTENT---
Find 1-3 similar features, trace end-to-end. Return: key files with line numbers, call flow, extension points.
---TASK---
id: p1_architecture
agent: code-explorer
workdir: .
---CONTENT---
Map architecture for relevant subsystem. Return: module map + 5-10 key files.
---TASK---
id: p1_conventions
agent: code-explorer
workdir: .
---CONTENT---
Identify testing patterns, conventions, config. Return: test commands + file locations.
EOF
Phase 2: Clarify (Conditional)
**Goal:** Resolve blocking ambiguities only.
**Actions:** 1. Review `p1_requirements` output for blocking questions 2. **IF blocking questions exist** → Use AskUserQuestion 3. **IF no blocking questions (completeness >= 8)** → Skip to Phase 3
Phase 3: Design (No Interaction)
**Goal:** Produce minimal-change implementation plan.
codeagent-wrapper --agent code-architect - . <<'EOF'
Design minimal-change implementation:
- Reuse existing abstractions
- Minimize new files
- Follow established patterns from Phase 1 exploration
Output:
- File touch list with specific changes
- Build sequence
- Test plan
- Risks and mitigations
EOF
Phase 4: Implement + Review
**Goal:** Build feature and review in one phase.
**Step 1: Decide on worktree mode (ONLY NOW)**
Use AskUserQuestion to ask:
Develop in a separate worktree? (Isolates changes from main branch)
- Yes (Recommended for larger changes)
- No (Work directly in current directory)
If user ch
Read more
name: do description: This skill should be used for structured feature development with codebase understanding. Triggers on /do command. Provides a 5-phase workflow (Understand, Clarify, Design, Implement, Complete) using codeagent-wrapper to orchestrate code-explorer, code-architect, code-reviewer, and develop agents in parallel. allowed-tools: ["Bash(python3:*/.claude/skills/do/scripts/setup-do.py*)", "Bash(python3:*/.claude/skills/do/scripts/task.py*)"]
do - Feature Development Orchestrator
An orchestrator for systematic feature development. Invoke agents via `codeagent-wrapper`, never write code directly.
Loop Initialization (REQUIRED)
When triggered via `/do <task>`, initialize the task directory immediately without asking about worktree:
python3 "$HOME/.claude/skills/do/scripts/setup-do.py" "<task description>"
This creates a task directory under `.claude/do-tasks/` with:
- `task.md`: Single file containing YAML frontmatter (metadata) + Markdown body (requirements/context)
**Worktree decision is deferred until Phase 4 (Implement).** Phases 1-3 are read-only and do not require worktree isolation.
Task Directory Management
Use `task.py` to manage task state:
# Update phase python3 "$HOME/.claude/skills/do/scripts/task.py" update-phase 2 # Check status python3 "$HOME/.claude/skills/do/scripts/task.py" status # List all tasks python3 "$HOME/.claude/skills/do/scripts/task.py" list
Worktree Mode
The worktree is created **only when needed** (right before Phase 4: Implement). If the user chooses worktree mode:
1. Run setup with `--worktree` flag to create the worktree:
python3 "$HOME/.claude/skills/do/scripts/setup-do.py" --worktree "<task description>"
2. Use the `DO_WORKTREE_DIR` environment variable to direct `codeagent-wrapper` develop agent into the worktree. **Do NOT pass `--worktree` to subsequent calls** — that creates a new worktree each time.
# Save the worktree path from setup output, then prefix all develop calls: DO_WORKTREE_DIR=<worktree_dir> codeagent-wrapper --agent develop - . <<'EOF' ... EOF
Read-only agents (code-explorer, code-architect, code-reviewer) do NOT need `DO_WORKTREE_DIR`.
Hard Constraints
1. **Never write code directly.** Delegate all code changes to `codeagent-wrapper` agents. 2. **Parallel-first.** Run independent tasks via `codeagent-wrapper --parallel`. 3. **Update phase after each phase.** Use `task.py update-phase <N>`. 4. **Expect long-running `codeagent-wrapper` calls.** High-reasoning modes can take a long time. 5. **Timeouts are not an escape hatch.** If a call times out, retry with narrower scope. 6. **Defer worktree decision until Phase 4.** Only ask about worktree mode right before implementation. If enabled, prefix develop agent calls with `DO_WORKTREE_DIR=<path>`. Never pass `--worktree` after initialization.
Agents
| Agent | Purpose | Needs --worktree | |-------|---------|------------------| | `code-explorer` | Trace code, map architecture, find patterns | No (read-only) | | `code-architect` | Design approaches, file plans, build sequences | No (read-only) | | `code-reviewer` | Review for bugs, simplicity, conventions | No (read-only) | | `develop` | Implement code, run tests | **Yes** — use `DO_WORKTREE_DIR` env prefix |
Issue Severity Definitions
**Blocking issues** (require user input):
- Impacts core functionality or correctness
- Security vulnerabilities
- Architectural conflicts with existing patterns
- Ambiguous requirements with multiple valid interpretations
**Minor issues** (auto-fix without asking):
- Code style inconsistencies
- Naming improvements
- Missing documentation
- Non-critical test coverage gaps
5-Phase Workflow
Phase 1: Understand (Parallel, No Interaction)
**Goal:** Understand requirements and map codebase simultaneously.
**Actions:** Run `code-architect` and 2-3 `code-explorer` tasks in parallel.
codeagent-wrapper --parallel <<'EOF' ---TASK--- id: p1_requirements agent: code-architect workdir: . ---CONTENT--- Analyze requirements completeness (score 1-10): 1. Extract explicit requirements, constraints, acceptance criteria 2. Identify blocking questions (issues that prevent implementation) 3. Identify minor clarifications (nice-to-have but can proceed without) Output format: - Completeness score: X/10 - Requirements: [list] - Non-goals: [list] - Blocking questions: [list, if any] ---TASK--- id: p1_similar_features agent: code-explorer workdir: . ---CONTENT--- Find 1-3 similar features, trace end-to-end. Return: key files with line numbers, call flow, extension points. ---TASK--- id: p1_architecture agent: code-explorer workdir: . ---CONTENT--- Map architecture for relevant subsystem. Return: module map + 5-10 key files. ---TASK--- id: p1_conventions agent: code-explorer workdir: . ---CONTENT--- Identify testing patterns, conventions, config. Return: test commands + file locations. EOF
Phase 2: Clarify (Conditional)
**Goal:** Resolve blocking ambiguities only.
**Actions:** 1. Review `p1_requirements` output for blocking questions 2. **IF blocking questions exist** → Use AskUserQuestion 3. **IF no blocking questions (completeness >= 8)** → Skip to Phase 3
Phase 3: Design (No Interaction)
**Goal:** Produce minimal-change implementation plan.
codeagent-wrapper --agent code-architect - . <<'EOF' Design minimal-change implementation: - Reuse existing abstractions - Minimize new files - Follow established patterns from Phase 1 exploration Output: - File touch list with specific changes - Build sequence - Test plan - Risks and mitigations EOF
Phase 4: Implement + Review
**Goal:** Build feature and review in one phase.
**Step 1: Decide on worktree mode (ONLY NOW)**
Use AskUserQuestion to ask:
Develop in a separate worktree? (Isolates changes from main branch) - Yes (Recommended for larger changes) - No (Work directly in current directory)
If user ch
AI-powered development automation with multi-backend execution (Codex/Claude/Gemini/OpenCode)
Repo: cexll/myclaude
Other skills on myclaude.
- /browser
This skill should be used for browser automation tasks using Chrome DevTools Protocol (CDP). Triggers when users need to launch Chrome with remote debugging, navigate pages, execute JavaScript in browser context, capture screenshots, or interactively select DOM elements. No MCP
Open skill - /codeagent
Execute codeagent-wrapper for multi-backend AI code tasks. Supports Codex, Claude, Gemini, and OpenCode backends with agent presets, skill injection, file references (@syntax), worktree isolation, parallel execution, and structured output.
Open skill - /dev
Extreme lightweight end-to-end development workflow with requirements clarification, intelligent backend selection, parallel codeagent execution, and mandatory 90% test coverage
Open skill - /harness
This skill should be used for multi-session autonomous agent work requiring progress checkpointing, failure recovery, and task dependency management. Triggers on '/harness' command, or when a task involves many subtasks needing progress persistence, sleep/resume cycles across
Open skill - /omo
Use this skill when you see `/omo`. Multi-agent orchestration for "code analysis / bug investigation / fix planning / implementation". Choose the minimal agent set and order based on task type + risk; recipes below show common patterns.
Open skill - /product-requirements
Interactive Product Owner skill for requirements gathering, analysis, and PRD generation. Triggers when users request product requirements, feature specification, PRD creation, or need help understanding and documenting project requirements. Uses quality scoring and iterative
Open skill

