workflow-agent
Give your AI coding agent a memory for real project work.
A single wf skill that manages the full ticket lifecycle — context, tickets, phased plans, reviews, and progress — stored as plain files in your repo so work survives across sessions.
Create change workspace, context file, status summary, and ticket lifecycle folders.
Turn raw notes into structured goals, scope, constraints, risks, and rollout context.
Propose independently deployable tickets with goals, risk, and dependencies. Nothing is created until you confirm.
Explore actual code and create detailed, independently verifiable implementation phases.
Optional gate: wf plan-reviewExecute one phase at a time, verify results, and record progress and deviations.
Optional gate: wf impl-reviewVerify readiness, archive ticket in done, update progress, and recommend next action.
Why
AI agents are great at writing code and bad at running projects. They forget context between sessions, skip steps, lose track of multi-ticket work, and can't resume where they left off.
Persistent by design
Everything lives in .workflow/ inside your repo — markdown files and folders. Close the session, come back tomorrow, the agent picks up exactly where it stopped.
Structured, not rigid
A clear path from idea to shipped code: context → tickets → phased plan → implementation → done. Reviews are optional. Single-PR fixes and multi-ticket epics both fit.
No hosted tools
No Jira, no database, no server. Ticket directories moving between numbered folders are the source of truth. Optional isolated worktrees use local Git.
Why Not Just Ask the Agent for a PLAN.md?
You can — once. The problem is everything after that: the second session, the fifth ticket, the phase you left half-finished on Friday.
| Situation | Ad-hoc prompting | workflow-agent |
|---|---|---|
| New session | You re-explain the goal, constraints, and what's already done. | wf status PYE-1123 reconstructs it from files in seconds. |
| Context window fills up | Compaction silently drops decisions; the agent re-litigates them. | Decisions live in CONTEXT.md and PLAN.md, re-read on demand. |
| Multi-ticket work | One giant plan that drifts from reality after ticket two. | Ticket directories move draft → todo → in-progress → done. |
| Half-finished work | "Where did we stop?" is a guess. | wf implement PYE-1123 001 phase 3 resumes exactly there. |
| Status truth | A status field in a doc that nobody updates. | Folder location is the status; summaries auto-repair on drift. |
| Setup cost | None, but repeated every session. | One npx install. No server, database, or hosted service. |
Swipe the table sideways to compare all three columns.
Resume Without Reconstructing Everything
Return after an hour, a week, or a fresh agent session. One command tells you where work stopped and what to do next.
Your project handoff, available instantly.
No rereading every diff, ticket, plan, or conversation. wf status PYE-1123 inspects persisted workflow state and gives you a concise, trustworthy view of the selected change.
STATUS.md against ticket folders when summaries drift.wf command to run next.PYE-1123-auth-refactor — 2/5 done
In Progress
→ 003 Replace auth middleware
Phase 2/3 complete
Todo
○ 004 Add integration tests planned
○ 005 Remove legacy paths needs plan
Done
✓ 001 Extract auth service
✓ 002 Add token validation
Next: run wf implement PYE-1123 003 phase 3
Quickstart
Install once, then drive everything through wf commands — or just describe what you want in natural language.
Install the skill
Requires Node.js 18+ (for npx) and an agent that supports Agent Skills.
Prefer a local checkout? Clone the repo and run ./install.sh — it symlinks skills/wf into ~/.agents/skills/, so your edits apply immediately. Override the destination with AGENTS_SKILLS_DIR.
Start a change — wf new
Creates the change folder with CONTEXT.md, STATUS.md, and the four status folders. Then run wf discover — a short interview that turns your raw notes into structured context.
Don't want to memorise commands? Run bare wf for an interactive menu, or just describe what you want — “break this epic into tickets” routes to the right command.
Need isolation? Add --worktree to any command or ask naturally. Choose a new branch, available branch, or detached snapshot. The agent validates refs and collisions, confirms reuse, then runs every operation in the selected sibling worktree.
Break it into tickets — wf breakdown
Proposes independently deployable tickets (1–3 days each) with goals, risk, and dependencies. Nothing is created until you confirm.
Plan a ticket — wf plan
The agent explores your actual codebase, validates assumptions, and writes a detailed phased PLAN.md plus a concise PLAN-BRIEF.md for human review.
Implement, phase by phase — wf implement
Executes one verifiable phase at a time, runs tests, and records results in PROGRESS.md. Resume any phase later.
Finish and track — wf complete / wf status
Complete verifies readiness before moving the ticket to done. Status shows scoped progress and always recommends the exact next command.
The Lifecycle
One entry point, nine commands. Reviews are optional gates — use them for risky work, skip them for small fixes.
wf new
Open a persistent change workspace.
CONTEXT.md · STATUS.mdwf discover
Clarify goals, scope, risks, and rollout.
CONTEXT.md updatedwf breakdown
Create confirmed, deployable tickets.
TICKET.mdwf plan
Explore code and design verifiable phases.
PLAN.md · PLAN-BRIEF.mdwf implement
Execute, test, and record each phase.
PROGRESS.mdwf complete
Verify readiness and archive in done.
4.done/ · STATUS.mdwf plan-reviewValidate feasibility, coverage, and risk before coding.wf impl-reviewCheck diffs, tests, plan adherence, and acceptance criteria.wf status
Available at every stage: reconcile persisted state, show progress, and recommend the exact next command.
What Gets Created
workflow-agent stores everything as readable Markdown inside your repository. Files appear only when needed, and ticket folders move to represent real lifecycle state.
- .workflow/
- changes/
- PYE-1123-auth-refactor/
- CONTEXT.md change definition
- STATUS.md progress summary
- 1.draft/
- 2.todo/
- 001-token-validation/
- TICKET.md
- PLAN.md
- PLAN-BRIEF.md
- 001-token-validation/
- 3.in-progress/
- 4.done/
- PYE-1123-auth-refactor/
- changes/
wf new
CONTEXT.md, and STATUS.md.wf discover
CONTEXT.md with structured goals, scope, constraints, risks, and rollout.wf breakdown
NNN-ticket/ directory in 1.draft/ with its stable TICKET.md.wf plan
PLAN.md and human-readable PLAN-BRIEF.md, then moves ticket to 2.todo/.wf implement
3.in-progress/ and creates PROGRESS.md when first recording phase results.wf reviews
plan-review or impl-review creates and appends dated findings to REVIEWS.md.wf complete
4.done/, and updates STATUS.md.wf status
STATUS.md when reconciling detected drift.Digging Deeper
How workflow-agent stores and reasons about your work.
Storage model — folders are the source of truth
Each ticket is a directory that moves between numbered status folders. No status field can drift from reality — the location is the status. STATUS.md is a derived summary and gets auto-repaired if it drifts.
Ticket files — created only when needed
Breakdown creates only TICKET.md. Planning adds PLAN.md and PLAN-BRIEF.md. Progress and review files appear lazily. Empty placeholder files are never created.
TICKET.mdGoal, scope, acceptance criteria, risk, dependencies, technical contextPLAN.mdDetailed, phased implementation plan — the implementation source of truthPLAN-BRIEF.mdConcise human summary: main changes, data flow, decisions, risks, review questionsPROGRESS.mdPhase results, verification, deviations, PR-feedback workREVIEWS.mdDated plan and implementation reviews
Phased implementation — verify as you go
Plans are split into coherent, independently verifiable phases. Implementation runs one phase at a time, each verified before moving on. You can execute or resume any single phase:
If the codebase contradicts the plan, the agent stops and tells you instead of improvising.
Addressing — change first, then ticket
Ticket-scoped commands take <change> <ticket>. A unique ID prefix like PYE-1123 resolves to PYE-1123-auth-refactor. When anything is ambiguous or omitted, the agent asks instead of guessing.
Done isn't frozen — PR feedback and reopening
done means implementation completed — the PR may still be in review, merging, or receiving feedback. PR-feedback changes can update code and notes while the ticket stays in 4.done/. Explicit reopening moves it back to in-progress with a recorded reason. Follow-up work beyond the original scope becomes a new ticket.
All commands
wf newCreate a change and its workflow structurewf discoverInterview to turn raw context into a structured change definitionwf breakdownPropose and create independently deployable ticketswf planExplore code, write phased PLAN.md + PLAN-BRIEF.mdwf plan-reviewoptional Review a plan before codingwf implementExecute and verify one implementation phase at a timewf impl-reviewoptional Review code against plan and acceptance criteriawf completeVerify readiness, move ticket to donewf statusScoped progress and exact next action
FAQ
The questions developers ask before installing.
Should I commit .workflow/?
Your call, and both work. Commit it when you want teammates and CI-adjacent reviewers to see the plan and progress alongside the diff. Add it to .gitignore when you treat it as a personal scratchpad. Nothing in the skill depends on it being tracked.
Will it bloat my repo?
It's plain Markdown — typically a few KB per ticket. No binaries, no lockfiles, no generated artifacts. A large epic with a dozen planned tickets is still smaller than a single screenshot.
Does it burn extra tokens?
Files are read on demand, not preloaded. A command loads its own reference plus the specific ticket it touches. Overall it usually costs fewer tokens than re-explaining a project from scratch each session.
Do I need Jira or a ticket tracker?
No. Tickets are directories. If you already use an external tracker, reuse its IDs as change prefixes — PYE-1123 addresses PYE-1123-auth-refactor — so the two stay readable side by side.
What about multiple developers?
Ticket directories are separate files, so parallel work rarely collides. STATUS.md is derived, not authoritative — if it conflicts or drifts, wf status reconciles it from the folder layout.
Can I use it for a one-line fix?
Yes, and you should skip most of it. Use wf new plus a single ticket, skip both review gates, and go straight to wf implement. The reviews and breakdown exist for work that actually warrants them.
How do I remove it?
Delete the skill and .workflow/. If you opted into worktree mode, remove any created worktrees or branches separately with normal Git commands; workflow-agent never deletes them automatically.
What if the plan is wrong?
When the codebase contradicts the plan, the agent stops and reports the mismatch instead of improvising. Deviations that you accept are recorded in PROGRESS.md, so the trail stays honest.
Compatibility
Agents need Agent Skills, filesystem tools, question/choice prompts, Git execution, and explicit command working directories. Optional package installation also needs selected package-manager executable.
Built and exercised on OpenCode and Claude Code. Other skills-capable agents should work; if yours doesn't, open an issue.