From ac-artifact-workflow
Initiates or continues artifact-driven development workflow, managing per-build task lists, implementation plans, walkthroughs, and shared ADRs in .artifacts/.
npx claudepluginhub alteredcraft/claude-code-plugins --plugin ac-artifact-workflowYou are executing an artifact-driven development workflow inspired by Google's Antigravity. This workflow produces three living artifacts that scope work and track progress. ## Artifacts Location **Per-build artifacts** live in `./.artifacts/bld-<project-slug>/`: - `todo.md` — Task list (scope and progress) - `implementation-plan.md` — Technical approach (architecture) - `walkthrough.md` — Verification record (proof of completion) **Shared artifact** at `./.artifacts/ADR.md`: - Architecture Decision Records — significant decisions across all builds, each entry links to its related build ...
/buildGuides feature implementation via phased workflow with approval gates: understand requirements, design options, load skills, build, verify, test, and track progress in tasks/todo.md.
/bmad-pilotOrchestrates AI development team to build project from description, with repo scanning, architecture, planning, coding, and QA phases plus user confirmations. Options: --skip-tests, --direct-dev, --skip-scan.
/buildingExecutes implementation plans through gated phases: Load plan, setup tracking, execute sections, verify tests, report status. Uses git worktrees for isolation.
/buildImplements next planned task incrementally via TDD: write failing test, minimal implementation, full tests/build verification, commit changes.
/buildBuilds, compiles, and packages projects with error handling, optimization for dev/prod/test, and detailed reporting. Supports optional target and flags like --type, --clean, --optimize.
/buildScaffolds a VitePress site from existing wiki markdown files, adding dark theme, dark-mode Mermaid diagrams, and click-to-zoom for images and diagrams.
Share bugs, ideas, or general feedback.
You are executing an artifact-driven development workflow inspired by Google's Antigravity. This workflow produces three living artifacts that scope work and track progress.
Per-build artifacts live in ./.artifacts/bld-<project-slug>/:
todo.md — Task list (scope and progress)implementation-plan.md — Technical approach (architecture)walkthrough.md — Verification record (proof of completion)Shared artifact at ./.artifacts/ADR.md:
First, check if .artifacts/ directory exists and contains any bld-* folders (Search(pattern: ".artifacts/bld-*/**/*")).
bld-* folders to the userRead the artifacts in that folder to determine current phase:
If .artifacts/ directory does not exist, create it and add:
README.md that explains:
/build command)todo.md, implementation-plan.md, walkthrough.md)ADR.md file for architecture decisions across all builds/build commandADR.md file with this template:
# Architecture Decision Records
This file captures significant architectural decisions made during builds in this project.
---
Write the README as if explaining the build tool to someone discovering this directory for the first time.
IMPORTANT: Do NOT write any code yet. A new build MUST follow the full workflow:
Never skip directly to writing code. The artifacts must be created and approved first.
The user's initial prompt $ARGUMENTS is a starting point, not sufficient context. You must gather:
Ask ONE focused question at a time. Provide your reasoning and offer suggested answers when appropriate. Continue until you have sufficient context to create a meaningful task list.
When ready:
.artifacts/bld-<project-slug>/ directory (and .artifacts/ with README.md and ADR.md if it doesn't exist)task-list-creator skill to create todo.mdAfter creating todo.md with the task-list-creator skill:
todo.md to the userAfter creating implementation-plan.md with the implementation-plan-creator skill:
implementation-plan.md to the userWork through tasks sequentially:
todo.md checkboxes as tasks completewalkthrough.md with what was built (invoke walkthrough-creator skill)If you encounter blockers or ambiguity, stop and ask the user rather than making assumptions.
CRITICAL: Before marking the build complete, systematically review for architectural decisions that should be documented.
When all implementation tasks are complete BUT BEFORE updating walkthrough to status: complete:
Read the completed artifacts to understand what was built:
.artifacts/bld-<project-slug>/implementation-plan.md — What was planned?.artifacts/bld-<project-slug>/walkthrough.md — What was actually built?.artifacts/ADR.md — What decisions have already been recorded?Review for architectural decisions — Compare what was planned vs what was built and identify any significant architectural decisions made during implementation. Refer to the adr-manager skill for detailed criteria and examples of what qualifies.
Determine if ADR entries are needed:
If YES — Architectural decisions with lasting impact were made:
adr-manager skill with appropriate details**Build:** [bld-<project-slug>](./.artifacts/bld-<project-slug>/)If NO — No significant architectural decisions (routine implementation):
Once ADR review is complete, proceed to Phase 4.
After completing Phase 3.5 ADR Review Gate:
walkthrough.md status to complete (invoke walkthrough-creator skill)walkthrough.md to the user.artifacts/ADR.md"Tests must be persisted as actual test files, not just ad-hoc verification.
tests/ directorytest_*.py)pytest"__tests__/ directory or *.test.ts filesnpm test"Ad-hoc verification is NOT sufficient. Every testable component must have a corresponding test file that the user can run themselves.