Help us improve
Share bugs, ideas, or general feedback.
Share bugs, ideas, or general feedback.
Share bugs, ideas, or general feedback.
By Dowwie
Turn natural-language specs into executable task DAGs: decompose a specification into a validated, phase-ordered plan, then run isolated subagents that implement each task, verify results against acceptance criteria, and recover from crashes.
npx claudepluginhub dowwie/taskerExtract capabilities and behaviors from spec. Outputs JSON that MUST validate against schemas/capability-map.schema.json.
Phase 2 - Map behaviors to file paths. Outputs JSON to .tasker/artifacts/physical-map.json. Must validate against schema.
Phase 4 - Assign phases, identify steel thread, validate DAG. Updates task files with final phase assignments.
Phase 7 of /specify workflow - Analyze spec for weakness categories before export. Engages user to resolve critical weaknesses.
Phase 3 - Create individual task files from physical map. Each task is a separate JSON file in .tasker/tasks/. Enables parallel work and cleaner state tracking.
Uses power tools
Uses Bash, Write, or Edit tools
Share bugs, ideas, or general feedback.
Own this plugin?
Verify ownership to unlock analytics, metadata editing, and a verified badge.
Sign in to claimOwn this plugin?
Verify ownership to unlock analytics, metadata editing, and a verified badge.
Sign in to claimBased on adoption, maintenance, documentation, and repository signals. Not a security audit or endorsement.
Spec-Driven Development: specifications compiled into executable, verifiable behavior
Spec Driven Development toolkit - structured specification, planning, and implementation workflows for systematic feature development
Unified spec-to-execution workflow system. Combines spec rigor, autonomous execution, and native task orchestration with parallel agent dispatch. Swarms-ready architecture.
Spec-driven development using GitHub spec-kit methodology. Constitution-first approach with specify, plan, tasks, and implement phases.
Spec-driven development workflow - transforms ideas into structured specifications (requirements, design, tasks) before implementation.
Spec-Driven Development Workflow for Claude Code. A 6-step pipeline: Requirements → Code Analysis → Design → Implement → Verify → Self-Improve. Specifications are the source of truth, code is a verified artifact.
Spec-Driven Development: specifications compiled into executable, verifiable behavior
Tasker is a spec-driven development workflow built for Claude Code. It covers the entire pipeline: spec -> plan -> execute.
curl -fsSL https://raw.githubusercontent.com/Dowwie/tasker/main/scripts/install.sh | bash -s -- --easy-mode
This installs the tasker CLI and registers the Claude Code plugin. After installation, start a new session:
/tasker:specify — develop a specification/tasker:plan — decompose into tasks/tasker:execute — implement and verifyTasker enforces a three-stage pipeline.
Specify captures intent exhaustively. Edge cases, state transitions, and invariants are resolved before implementation begins.
Plan decomposes the specification into isolated, verifiable tasks with explicit dependencies.
Execute implements each task and verifies results against the spec.
By the time code is written, behavior is defined and implementation becomes translation.
Exhaustive discovery. Agents naturally stop asking after a few questions. Tasker uses reduce-while loops that continue until all requirement categories are covered. The loop pressure forces comprehensive specifications.
Steel thread first. Before building features, validate the architecture. The primary end-to-end flow is identified and implemented early; if the foundation is flawed, you discover it in days, not months.
Task decomposition protocol. Specifications are transformed into a directed acyclic graph through a structured six-phase process: logical decomposition, physical mapping, cross-cutting concerns, task definition, dependency analysis, and completeness audits. Every task is small enough to verify, specific enough to implement without questions.
Finite state machines as contracts. State machines serve two purposes: shaping acceptance criteria during implementation, and producing documentation for ongoing understanding. The FSM JSON is canonical; diagrams are derived.
Decision registry. Architectural decisions are captured in ADRs alongside specifications. Context is preserved, not lost to chat history.
Stop anytime with tasker stop, resume with tasker resume. Checkpoints are created before each batch; result files track every task outcome; git commits mark progress. Work survives interruptions.