do — Feature Development Orchestrator
Turns feature work into a five-phase workflow where parallel sub-agents handle code understanding, design, implementation and review — the orchestrator never writes code itself.
Positives: allowed-tools whitelist limits execution to two python3 scripts; data flow (task dirs, worktree, env vars) is disclosed; read-only/write agents separated; uninstall supports rollback. Deductions: install.py silently injects Stop/SubagentStop hooks into the user's global ~/.claude/settings. without explicit confirmation, and the stop hook blocks session exit until 5 phases finish; verify-loop.py runs verify_commands from task. via shell=True with no allowlist, creating a broad command-execution surface; it depends on a codeagent-wrapper binary not bundled here, whose integrity cannot be verified statically.
Positives: hook scripts are structurally complete with timeouts and a MAX_ITERATIONS=5 anti-deadlock valve and readable failure messages. Deductions: README contradicts SKILL.md (Phase 2 mandatory vs conditional; task./Context Pack vs task.md-only; hooks. references verify-loop.py while SKILL.md never mentions it); the skill has no tests of its own (CI only covers the Go wrapper); setup-do.py and task.py sources are absent from the provided files, so key paths cannot be statically reproduced.
Positives: clear scenario (structured feature development), explicit /do trigger, defined phase boundaries and output formats. Deductions: no declared non-fit ranges (overhead for small changes, behavior without git); core function depends entirely on codeagent-wrapper plus overseas backend CLIs (Codex/Claude/Gemini/OpenCode), a real mainland-China reachability risk not disclosed; no Chinese-language support notes.
Positives: well-layered docs (progressive-disclosure SKILL.md, detailed README, separate agent prompts), repo-level AGPL-3.0 license and versioning, FAQ and uninstall path. Deductions: no skill-level version/changelog; cross-document inconsistencies on phase mandatory-ness and state files mislead users; maintenance responsibility is only implied at repo level with unverified publisher; missing setup-do.py makes install documentation incomplete.
Positives: multi-agent parallel orchestration offers theoretical marginal value, and output formats (task dir, completion promise, verify commands) are concretely specified. Deductions: zero execution evidence that the 5-phase flow yields directly usable results; heavy dependence on external wrapper and multi-backend config creates many failure points; long-running calls and retry policies shift debugging cost to the user.
Positives: all sources auditable; repo has genuine CI/Release workflows. Deductions: CI covers only the Go wrapper, not this skill's key paths; the skills/harness tests belong to another skill and do not corroborate do; no third-party execution evidence, so README behavior claims remain author assertions.
- install.py auto-modifies the global ~/.claude/settings. to inject hooks, and the Stop hook blocks session exit until all 5 phases complete — review and accept this before installing; early exit requires manually editing the task state file.
- verify-loop.py runs verify_commands from task. via shell=True; never let untrusted task state files define these commands.
- Core function depends on codeagent-wrapper and overseas backend CLIs (Codex/Claude/Gemini/OpenCode), which may be unreachable from mainland-China networks; this limitation is not disclosed in the docs.
- Documentation is internally inconsistent (Phase 2 mandatory vs conditional, task.md vs task., hook behavior); treat SKILL.md as authoritative and verify yourself — the skill has no tests of its own and this review is static only.
- Publisher is unverified by the FollowSkills registry; identity is unknown, not evidence of malice.
What does this skill do, and when should you use it?
do is a skill in the myclaude repository, triggered by the /do command, for structured feature development. It runs a 5-phase workflow — Understand, Clarify, Design, Implement, Complete — orchestrating code-explorer, code-architect, code-reviewer and develop agents through codeagent-wrapper, with Phase 1 exploration tasks running in parallel. Task state is managed by two Python scripts, setup-do.py and task.py, and implementation can optionally be isolated in a git worktree. The skill is part of the AGPL-3.0 licensed myclaude collection and requires codeagent-wrapper plus at least one backend CLI (Codex, Claude, Gemini or OpenCode) to function.
When you run /do <task>, the skill first runs setup-do.py to create a task directory under .claude/do-tasks/ (a task.md with YAML frontmatter); Phase 1 dispatches code-architect (requirements completeness scoring) and several code-explorer tasks in parallel (similar-feature tracing, architecture mapping, testing conventions); Phase 2 asks the user only if blocking questions exist; Phase 3 has code-architect produce a minimal-change implementation plan; Phase 4 asks whether to use a worktree, then invokes the develop agent to write code and run tests (full-stack work can be split into parallel backend/frontend tasks), followed by two parallel code-reviewer passes for correctness and simplicity — blocking issues require user confirmation, minor issues are auto-fixed; Phase 5 has code-reviewer write a completion summary and emits the <promise>DO_COMPLETE</promise> signal. Phase transitions are recorded via task.py update-phase.
- Developers adding a feature to an existing codebase who want architecture and similar implementations mapped automatically before any code is written
- Teams on large full-stack projects who need backend and frontend changes split into parallel sub-tasks
- Users who want experimental changes isolated in a separate git worktree to keep the main branch clean
- Engineering teams that want every change double-reviewed for correctness and simplicity, with issues classified as blocking vs. minor
- Claude Code users running Codex, Claude, Gemini or OpenCode backends who want a single orchestration entry point
What are this skill's strengths and limitations?
- Clear structure: five phases covering understanding, clarification, design, implementation, review and documentation reduce guesswork-driven coding
- Phases 1–3 are read-only and parallel, making early exploration fast with zero code changes
- Explicit issue severity: blocking issues require user confirmation, style-level minor issues are fixed automatically, minimizing interruptions
- Worktree decision is deferred to Phase 4, so read-only phases carry no isolation overhead
- Enforced separation of duties — the orchestrator delegates all code changes to codeagent-wrapper agents
- Hard dependency on codeagent-wrapper plus at least one backend CLI; without them the skill cannot run at all
- SKILL.md uses Claude Code-specific mechanisms (/do slash command, AskUserQuestion, allowed-tools Bash permission syntax), so porting to other platforms requires rewriting
- Injected skills mentioned in SKILL.md (e.g. golang-base-practices, frontend-design) must be installed separately and the docs don't explain how to obtain them
- No test suite or benchmark data in the README — effectiveness claims lack quantitative evidence
- High-reasoning mode calls can run long; the skill itself acknowledges timeouts require retrying with a narrower scope
How do you install this skill?
Run the interactive installer with npx github:stellarlinkco/myclaude (installs to ~/.claude by default), or edit config. to set the "do" module to enabled: true. Already-installed modules can be updated from GitHub with npx github:stellarlinkco/myclaude --update. After installation the skill lives at ~/.claude/skills/do/. Note: the installer docs do not state whether codeagent-wrapper is installed automatically; if /do fails to run, install the wrapper separately per the README troubleshooting section.
How do you use this skill?
In a Claude Code session, type /do <task description>, e.g. /do add email login to the user module. The skill creates the task directory and enters Phase 1 automatically, asking you questions only in Phase 2 (if blocking issues exist) and Phase 4 (worktree choice). Track progress with python3 ~/.claude/skills/do/scripts/task.py status or list. The SKILL.md does not document how to switch backend CLIs; see the repository's codeagent-wrapper documentation for that configuration.
How does this skill compare with similar options?
Within the same repository, the omo skill targets bug investigation and fixes with intelligent routing; the README's selection guide routes feature development (the default scenario) to do and bug fixing to omo. The repo also ships a lightweight dev workflow and the essentials module (/code, /debug, etc.) for simple tasks. For end-to-end development orchestration rather than quick fixes, do is the recommended entry point.