From ac-artifact-workflow
Creates or updates todo.md task list artifact from requirements, organizing tasks hierarchically into Planning, Implementation, and Verification phases for development workflows.
npx claudepluginhub alteredcraft/claude-code-plugins --plugin ac-artifact-workflowThis skill uses the workspace's default tool permissions.
You are creating the **Task List artifact** (`todo.md`) for an artifact-driven development workflow.
Creates implementation-plan.md artifact from approved todo.md tasks, structuring project summary, user review decisions, proposed file changes by layer, and testing strategy.
Generates structured Markdown task lists from specs, plans, or PRDs with parent tasks, granular sub-tasks, relevant files including tests, and git branches. Activates after specs or on request.
Creates structured task plans with small verifiable steps, dependencies, and project-specific details. Use for implementing features, refactoring, or multi-step work.
Share bugs, ideas, or general feedback.
You are creating the Task List artifact (todo.md) for an artifact-driven development workflow.
You have access to the interrogation context from the conversation—requirements, scope, constraints, and success criteria gathered from the user.
Create .artifacts/bld-<project-slug>/todo.md (create the directory if it doesn't exist).
Organize tasks into three phases with hierarchical nesting:
Research, design decisions, and technical approach tasks that happen before coding.
The actual build work. Group related tasks under parent items with subtasks:
Testing, validation, and documentation tasks.
Phase-first thinking — What research/design must happen before building? What verification happens after?
Hierarchical grouping — Group related implementation work under parent tasks. Subtasks should be completable independently but contribute to the parent goal.
Atomic subtasks — Each subtask is a single, verifiable unit. Parent tasks complete when all subtasks complete.
Include the unsexy work — Error handling, edge cases, fallbacks deserve explicit tasks.
Verification is a phase — Not an afterthought. Testing, edge case validation, and documentation are first-class tasks.
If working within an existing codebase:
---
status: in-progress
created: <timestamp> (ex: 2025-12-09 08:47:19 -0800)
updated: <timestamp> (ex: 2025-12-09 08:49:30 -0800)
project: <project-slug>
description: "<one-line summary>"
---
# <Project Name>
## Planning Phase
- [x] Research X and their capabilities
- [x] Design system architecture and data flow
- [ ] Create implementation plan document
- [ ] Get user approval on technical approach
## Implementation Phase
- [ ] Set up project structure and dependencies
- [ ] Implement backend service
- [ ] Subtask one
- [ ] Subtask two
- [ ] Subtask three
- [ ] Build frontend interface
- [ ] Subtask one
- [ ] Subtask two
- [ ] Add error handling and fallbacks
## Verification Phase
- [ ] Test with multiple scenarios
- [ ] Verify core functionality
- [ ] Test edge cases and error scenarios
- [ ] Create walkthrough documentation
As work progresses, update checkboxes:
- [ ] → pending- [~] → in-progress (optional, for visibility)- [x] → completeIMPORTANT: Every time you modify todo.md, update the updated: field in the frontmatter with the current timestamp.
Present the artifact to the user for review before proceeding.
When presenting, always:
📄 .artifacts/bld-<project-slug>/todo.md[x] Completed task
[ ] Pending task
[ ] Nested subtask
[x] Completed subtask
This format makes progress immediately visible to the user.