Workflows AI-Driven Delivery Workflow
AI-Driven Delivery Workflow
Use when you need to move a tracker task from brief to done with a disciplined AI-assisted plan and execution process.
Spec Writer Phase Planner Task Executor Flow Advisor
Why this workflow
Most implementation failures start before any code is written — the task wasn't defined, prioritized, or verified. This workflow keeps the AI working as a process facilitator across four disciplined steps: write the spec, plan the phase, execute the task, then check the guardrails so the tracker stays honest.
What you'll walk away with
A scoped spec tied to a task or ticket
A phase plan that exposes dependencies and parallel work
A disciplined execution plan with verification
A guardrail check that keeps tracker state honest
STEP 1
Write the implementation spec
Use when you need a structured feature or engineering spec for a feature request, task, or tracker item.
Ask me these questions one at a time. Wait for my answer before moving to the next. 1. What is the feature request, task summary, or tracker id? If you have an existing spec, paste that path or id. 2. What problem does this feature solve for the user or product? 3. What is in scope for this work? 4. What is explicitly out of scope? 5. What files, components, or existing behavior will this impact? 6. What acceptance criteria or verification steps should be included? Once I've answered all six, write a spec document with the following sections: - Summary - Motivation - Scope - Affected files - Implementation steps - Edge cases & risks - Acceptance criteria The spec should be concise, task-focused, and suitable for a tracker-based engineering workflow. Do not write code or change file contents.
A scoped spec with acceptance criteria.
STEP 2
Plan the phase
Skill Build Phase Planner
Use when you need to turn a roadmap stage or tracker phase into concrete implementation steps and handoff-ready work.
This skill assumes a generic task tracker with phases and a next-action query. Substitute your own tracker's commands and stage names wherever they appear below. Ask me these questions one at a time. Wait for my answer before moving to the next. 1. What roadmap stage, tracker phase, or feature area are you planning for? 2. What are the core tasks or objectives in that stage? 3. Which tasks or work items are dependent on each other? 4. Which tasks can run in parallel because they touch different files or independent areas? 5. What verification criteria or finish conditions should each task use? Once I've answered all five, produce a concrete plan with: - A review step for the stage and task list - A dependency/parallelism analysis - A small set of next actions, including the single next task to start - A verification strategy The output should call out which task to claim first, which tasks must wait for dependencies, and which can run in parallel because they touch different file lanes. Keep the plan focused on your tracker's next-action command, task readiness, and safe execution. Do not write code.
A clear next action and a parallelization plan.
STEP 3
Execute the task
Skill Tracker Task Executor
Use when you are ready to implement a spec'd tracker task and need a disciplined, tracker-safe execution plan.
This skill assumes a generic task tracker with stages (e.g. `specced`, `building`, `validating`, `done`) and a validation command. Substitute your own tracker's commands and stage names wherever they appear below. Ask me these questions one at a time. Wait for my answer before moving to the next. 1. What is the tracker task id or spec path you are implementing? 2. What is the current stage of the task, and is it ready to build? 3. What spec steps or acceptance criteria must be followed? 4. What verification command or checks should be used? 5. Are there any branch, review, or merge rules to respect? If the task is not `specced` or has no linked spec, stop and tell me to finish the spec first. Once I've answered all five, write a step-by-step execution plan that covers: - claiming the task - reading the spec - implementing each step - verifying the result - moving the tracker toward done The plan must include a concrete next action and explicit rules for when to set `stage=building`, `validating`, and `done`. Keep the guidance tactical and disciplined. Do not write code.
A step-by-step, tracker-safe execution plan.
STEP 4
Check the process guardrails
Use when you need a rules-based workflow for planner → spec → implement → validate in a tracker-driven project.
This skill assumes a generic task tracker with stages (e.g. `specced`, `building`, `validating`, `done`) and a next-action query. Substitute your own tracker's commands and stage names wherever they appear below. Ask me these questions one at a time. Wait for my answer before moving to the next. 1. What is the current work stage or tracker state? 2. What is the outcome you want next: plan, spec, build, or validate? 3. What constraints or handoff rules should be respected? 4. Is there a specific task id, phase, or project area in focus? Once I've answered all four, give me the next action and the rule-based process for that action. Include any branch/merge discipline needed: if work is on a branch, do not mark `done` until the code is merged to `main` and verification passes. If tasks share file lanes, do not recommend parallel execution. Keep the advice explicit about tracker state, commands, and completion criteria. Do not write code.
Explicit rules for what to do next, and when it's done.
Or run all 4 steps in one session
Short on time? Paste this single prompt and your AI will walk through every step in order, pausing for your input as it goes.
You are running a 4-step chained workflow. Complete each step in order, label your output clearly, and use each output as context for the next step. ━━━ STEP 1: Implementation Spec Writer ━━━ Ask me these questions one at a time. Wait for my answer before moving to the next. 1. What is the feature request, task summary, or tracker id? If you have an existing spec, paste that path or id. 2. What problem does this feature solve for the user or product? 3. What is in scope for this work? 4. What is explicitly out of scope? 5. What files, components, or existing behavior will this impact? 6. What acceptance criteria or verification steps should be included? Once I've answered all six, write a spec document with the following sections: - Summary - Motivation - Scope - Affected files - Implementation steps - Edge cases & risks - Acceptance criteria The spec should be concise, task-focused, and suitable for a tracker-based engineering workflow. Do not write code or change file contents. ━━━ STEP 2: Build Phase Planner ━━━ This skill assumes a generic task tracker with phases and a next-action query. Substitute your own tracker's commands and stage names wherever they appear below. Ask me these questions one at a time. Wait for my answer before moving to the next. 1. What roadmap stage, tracker phase, or feature area are you planning for? 2. What are the core tasks or objectives in that stage? 3. Which tasks or work items are dependent on each other? 4. Which tasks can run in parallel because they touch different files or independent areas? 5. What verification criteria or finish conditions should each task use? Once I've answered all five, produce a concrete plan with: - A review step for the stage and task list - A dependency/parallelism analysis - A small set of next actions, including the single next task to start - A verification strategy The output should call out which task to claim first, which tasks must wait for dependencies, and which can run in parallel because they touch different file lanes. Keep the plan focused on your tracker's next-action command, task readiness, and safe execution. Do not write code. ━━━ STEP 3: Tracker Task Executor ━━━ This skill assumes a generic task tracker with stages (e.g. `specced`, `building`, `validating`, `done`) and a validation command. Substitute your own tracker's commands and stage names wherever they appear below. Ask me these questions one at a time. Wait for my answer before moving to the next. 1. What is the tracker task id or spec path you are implementing? 2. What is the current stage of the task, and is it ready to build? 3. What spec steps or acceptance criteria must be followed? 4. What verification command or checks should be used? 5. Are there any branch, review, or merge rules to respect? If the task is not `specced` or has no linked spec, stop and tell me to finish the spec first. Once I've answered all five, write a step-by-step execution plan that covers: - claiming the task - reading the spec - implementing each step - verifying the result - moving the tracker toward done The plan must include a concrete next action and explicit rules for when to set `stage=building`, `validating`, and `done`. Keep the guidance tactical and disciplined. Do not write code. ━━━ STEP 4: Deterministic Flow Advisor ━━━ This skill assumes a generic task tracker with stages (e.g. `specced`, `building`, `validating`, `done`) and a next-action query. Substitute your own tracker's commands and stage names wherever they appear below. Ask me these questions one at a time. Wait for my answer before moving to the next. 1. What is the current work stage or tracker state? 2. What is the outcome you want next: plan, spec, build, or validate? 3. What constraints or handoff rules should be respected? 4. Is there a specific task id, phase, or project area in focus? Once I've answered all four, give me the next action and the rule-based process for that action. Include any branch/merge discipline needed: if work is on a branch, do not mark `done` until the code is merged to `main` and verification passes. If tasks share file lanes, do not recommend parallel execution. Keep the advice explicit about tracker state, commands, and completion criteria. Do not write code.