Agent skill

Vertical-Slice Task Planner

by owainlewis in owainlewis/blueprint

Breaks a reviewed spec into ordered, vertical-slice tasks that each fit one agent run and one pull request, grouped into milestones when useful.

MITAuto-check passedAgent Workflows

Install Vertical-Slice Task Planner

skills CLI
$ npx skills add owainlewis/blueprint --skill plan -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install owainlewis/blueprint plan --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/owainlewis/blueprint.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/plan .claude/skills/plan && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
plan
GitHub stars
412
Token cost
~1.5k tokens
SKILL.md length
781 words
Files
1
Skills in repo
11
Repo updated
First seen
Licence
MIT

At a glance

Breaks a reviewed spec into ordered, vertical-slice tasks that each fit one agent run and one pull request, grouped into milestones when useful.

  • Works in 8 steps: Read the source, repository… → Stop and return to /spec if an… → Split the work into tasks that each… → …
  • Turning a decided spec into tickets for separate agent runs
  • SKILL.md covers Process, Write for two readers, Task shape and Writing rules, plus 2 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

The agent reads the source spec, repository instructions and relevant code, then splits the work into tasks that each deliver working behavior through every layer they touch, with acceptance checks. It returns to `/spec` if an unresolved choice would change behavior, interfaces, data, security or cost. Shared contracts stay in one task, and refactoring is separated when it would hide a behavior change.

Tasks are ordered by dependency and may be grouped into milestones that each give a usable end-to-end result, never layer-named ones such as database or frontend. Each task is written for two readers: a plain-language opening a person can grasp in under a minute, then Agent notes holding decisions, interfaces and constraints. The plan comes back in chat, tracker tickets are created only on request, no plan document is written, and nothing is implemented.

When your agent uses it

  • Turning a decided spec into tickets for separate agent runs
  • Splitting a large feature into milestones with acceptance checks
  • Preparing tracker tickets that a fresh agent can pick up without further decisions

Example prompts

  • “Plan the export-to-CSV feature from the spec we just reviewed into tasks.”
  • “Break this spec into milestones, each delivering something I can try end to end.”
  • “Turn the approved notifications brief into ordered tickets for our tracker.”

Requirements

  • A reviewed spec or decided brief

Workflow steps

8 steps, taken from the first numbered list in SKILL.md.

  1. Read the source, repository instructions, and relevant code.
  2. Stop and return to /spec if an unresolved choice would change behavior, interfaces, data, security, scale, performance, compatibility…
  3. Split the work into tasks that each deliver working behavior, fit one agent run, and produce one focused pull request.
  4. Keep shared contracts in one task. Do not make two tasks answer the same question independently.
  5. Separate refactoring when it would hide a behavior change.
  6. Order tasks by dependency. Group tasks into milestones when useful. Each milestone delivers a usable end-to-end result, with acceptance…
  7. Return the plan in chat. Create tracker tickets only when the user asks. Never write a plan document.
  8. Stop after planning. Do not implement.

What it can do on your machine

Read from SKILL.md and the folder at commit 1d74745. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md (its code samples are markdown).

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Vertical-Slice Task Planner loads about 1.5k tokens when it runs. Until then it costs about 55 tokens; SKILL.md has 781 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~55
When it runs · the whole SKILL.md, loaded when a task matches
~1.5k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from owainlewis/blueprint at commit 1d74745, republished under its MIT licence (© owainlewis). 781 words, ~1,506 tokens.

Download SKILL.mdSave it as .claude/skills/plan/SKILL.md (or your agent's skills folder).
name
plan
description
Turns a reviewed spec or decided brief into ordered tasks for separate agent runs. Use for implementation tasks, tracker tickets, or useful milestones. Do not use for one coding task or its short execution outline.
user-invocable
true
argument-hint
<spec, brief, issue, or request>

Plan

Create tasks that a new agent can finish without making product or technical decisions. Every task and milestone must be a vertical slice: a usable outcome that runs through the required layers and has acceptance checks. Split by working result, not by file, layer, or team boundary.

Process

  1. Read the source, repository instructions, and relevant code.
  2. Stop and return to /spec if an unresolved choice would change behavior, interfaces, data, security, scale, performance, compatibility, operations, cost, or proof.
  3. Split the work into tasks that each deliver working behavior, fit one agent run, and produce one focused pull request.
  4. Keep shared contracts in one task. Do not make two tasks answer the same question independently.
  5. Separate refactoring when it would hide a behavior change.
  6. Order tasks by dependency. Group tasks into milestones when useful. Each milestone delivers a usable end-to-end result, with acceptance checks and dependencies. Do not use milestones such as “database”, “backend”, or “frontend”.
  7. Return the plan in chat. Create tracker tickets only when the user asks. Never write a plan document.
  8. Stop after planning. Do not implement.

For example, “add a task and see it after a restart” includes CLI input, validation, storage, output, and tests in one task. A later milestone could deliver “manage unfinished tasks” through add, list, and complete slices. Name the milestone's observable result and how to prove the whole result works.

Write for two readers

Each task is read by a human and executed by an agent.

The first sections must let a human understand the task in under a minute. State the concrete problem, the result, and why it matters in everyday words. Do not use requirement IDs, implementation details, undefined project terms, or acronyms unfamiliar to the intended readers there.

Put task-specific decisions, interfaces, failure rules, and security constraints in Agent notes. Link the spec or decided source for shared architecture and full requirement definitions. Use a repository path or URL that will resolve from the published ticket, and pin the decided version when later edits could change the contract. If no durable source exists, include the required shared decisions in Agent notes. Do not copy the whole source into every ticket.

A task stands alone when its purpose, boundary, dependencies, non-negotiable decisions, and proof are clear. It does not need to repeat background that the linked source already explains.

Task shape

Use this compact shape. Omit optional sections that add no information.

markdown
## <Plain action and result>

### What are we building?
In one to three short sentences, say what is wrong or missing and what will work after this task.

### Why?
In one or two short sentences, explain the practical value to a user, operator, or developer.

### Done when
- Three to seven observable results.

### How to check
Exact commands and required manual checks.

### Agent notes
- Depends on: <task titles, or None>
- Source: <durable spec, brief, issue, or request path/URL, pinned when needed>
- Only the definitions, decisions, constraints, and failure behavior specific to this task.

### Out of scope
- Related work this task is likely to absorb by mistake.
Show full SKILL.md (370 more words)Show less

Writing rules

  • Use a short title that names an action and result.
  • Use familiar words and specific verbs.
  • Define a necessary technical term where it first appears. Otherwise replace it with observable behavior.
  • Say sending the same event twice creates one reply, not prove idempotency.
  • Say the answer is supported by the cited document, not prove grounding.
  • Do not add user stories by default. Add one only when it clarifies product behavior that the first two sections do not.
  • Keep implementation mechanics out of the first two sections.
  • Keep task-specific implementation choices in Agent notes. Leave interchangeable local mechanics to the implementing agent.
  • Preserve applicable AC-n, REQ-n, and INV-n references in Done when or Agent notes without making a reader decode them to understand the task.
  • Aim for 250 to 500 words per ticket. Exceed 700 only when the extra text is required to prevent an unsafe or incompatible implementation. Otherwise split the task or link the shared source.
  • Do not repeat a fact in several sections.
  • Do not use slogans, metaphors, filler, or vague claims such as robust, seamless, comprehensive, and future-proof.

Boundaries

  • Do not split one working behavior into separate file or technical-layer tasks.
  • Do not create scaffolding or cleanup tasks without a checked outcome.
  • Do not hide unresolved decisions inside implementation tickets.
  • Keep each task small enough for one agent run and one focused review.
  • In Done when, state observable behavior and any internal rule that must hold.
  • In How to check, include exact commands and manual proof when automation cannot cover the behavior.
  • If the source uses requirement IDs, keep each ID attached to the same rule. Do not renumber or reuse it.

Before returning the plan, read each task twice:

  1. Human pass: can someone explain what will change and why after reading only the title and first two sections?
  2. Agent pass: can a fresh agent find the source, identify dependencies and fixed decisions, implement the task, and prove it without asking a product or architecture question?

Delete repeated background after both passes succeed.

Return

Return the ordered tasks, any useful milestones with acceptance checks, their dependencies, and any decision that still blocks implementation. Do not add a separate summary that repeats the tasks.

© owainlewis, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in skills/plan of owainlewis/blueprint.

Open the folder on GitHubat commit 1d74745

Compare with similar skills

Vertical-Slice Task Planner next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Vertical-Slice Task Planner compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Vertical-Slice Task Planner this skillowainlewis/blueprint412—~1.5kAutomated safety check: PassMIT
Implementation Plan Writerimbue-ai/bouncer400—~2.1kAutomated safety check: PassAGPL-3.0
Vibe Workflow RouterKhazP/vibe-coding-prompt-template3.1k—~544Automated safety check: NotesMIT
Technical Plan WriterEveryInc/compound-engineering-plugin25k—~1.9kAutomated safety check: PassMIT
Speckit Tasksforyourhealth111-pixel/Vibe-Skills3.6k—~1.6kAutomated safety check: PassApache-2.0
Conductor Track Managementwshobson/agents40k9 repos~420Automated safety check: PassMIT

Similar skills

  • Turns a feature's goals, requirements and architecture documents into a set of self-contained task files that a developer with no project context can follow.

    400 GitHub stars~2.1k tokensUpdated today
    Agent WorkflowsAuto-check passed
  • Vibe Workflow Router

    KhazP/vibe-coding-prompt-template

    Picks the next useful step for an app project, whether planning a new product, changing an existing app, fixing a bug or writing a handoff, loading only the context needed.

    3.1k GitHub stars~544 tokensUpdated 4 days ago
    Agent WorkflowsAuto-check: notes
  • Technical Plan Writer

    EveryInc/compound-engineering-plugin

    Writes a structured plan for multi-step software or non-software work after research, without writing production code, and pairs with ce-brainstorm and ce-work.

    25k GitHub stars~1.9k tokensUpdated today
    Agent WorkflowsAuto-check passed
  • Speckit Tasks

    foryourhealth111-pixel/Vibe-Skills

    Break down implementation plans into actionable task lists. An agent skill from foryourhealth111-pixel/Vibe-Skills.

    3.6k GitHub stars~1.6k tokensUpdated 1 mo ago
    Agent WorkflowsAuto-check passed
  • Use this skill when creating, managing, or working with Conductor tracks - the logical work units for features, bugs, and refactors. Applies to spec.md…

    40k GitHub starsUsed in 9 repos~420 tokens
    DevelopmentAuto-check passed
  • Planning Document Review

    EveryInc/compound-engineering-plugin

    Reviews requirements, plans and specs through role-based reviewer personas, applies proven corrections within its authority, and returns only the findings that need your call.

    25k GitHub stars~1.9k tokensUpdated today
    Agent WorkflowsAuto-check passed

More from owainlewis/blueprint

All 11 skills in this repo
  • Markdown PRD to HTML Renderer

    owainlewis/blueprint

    Converts a complete Markdown PRD or technical design into one verified, static HTML reading page without changing what it says.

    412 GitHub stars~1.3k tokensUpdated 2 days ago
    Auto-check passed
  • Codex Issue Coordinator

    owainlewis/blueprint

    Lets one Codex thread run a batch of GitHub issues through separate worker threads, each with its own worktree, branch, tested pull request and gated merge.

    412 GitHub stars~2.6k tokensUpdated 2 days ago
    Auto-check passed
  • Has a separate agent review a code change without editing it, checking behavior, security, regressions, complexity, tests and docs before merge.

    412 GitHub stars~1.5k tokensUpdated 2 days ago
    Auto-check passed
  • Architecture

    owainlewis/blueprint

    Designs and maintains root ARCHITECTURE.md for the intended system, including its data model and shared technical rules.

    412 GitHub stars~1.3k tokensUpdated 2 days ago
    Auto-check passed
  • Architecture Review

    owainlewis/blueprint

    Reviews a technical proposal before implementation through an independent subagent, returning findings, open questions and a verdict without rewriting it.

    412 GitHub stars~1.2k tokensUpdated 2 days ago
    Auto-check passed
  • Product Requirements Document

    owainlewis/blueprint

    Creates or updates a long-running REQUIREMENTS.md that defines a system's users, outcomes, capabilities, business rules, scope and acceptance conditions.

    412 GitHub stars~766 tokensUpdated 2 days ago
    Auto-check passed

Questions about Vertical-Slice Task Planner

What does Vertical-Slice Task Planner do?

Breaks a reviewed spec into ordered, vertical-slice tasks that each fit one agent run and one pull request, grouped into milestones when useful. The agent reads the source spec, repository instructions and relevant code, then splits the work into tasks that each deliver working behavior through every layer they touch, with acceptance checks. It returns to `/spec` if an unresolved choice would change behavior, interfaces, data, security or cost.

When should I use Vertical-Slice Task Planner?

Vertical-Slice Task Planner fits situations like: turning a decided spec into tickets for separate agent runs; splitting a large feature into milestones with acceptance checks; preparing tracker tickets that a fresh agent can pick up without further decisions.

How do I install Vertical-Slice Task Planner in Claude Code?

Run `npx skills add owainlewis/blueprint --skill plan -a claude-code`. Or copy the skill folder (skills/plan in owainlewis/blueprint) into .claude/skills/plan in your project. Claude Code loads it when a task matches its description.

How do I install Vertical-Slice Task Planner in Codex?

Run `npx skills add owainlewis/blueprint --skill plan -a codex`. Or copy the skill folder (skills/plan in owainlewis/blueprint) into .agents/skills/plan in your project. Codex loads it when a task matches its description.

Can I use Vertical-Slice Task Planner in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add owainlewis/blueprint --skill plan -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/plan, .gemini/skills/plan, .github/skills/plan and .opencode/skills/plan in your project.

What does Vertical-Slice Task Planner need to run?

SKILL.md names no scripts, command-line tools or credentials: Vertical-Slice Task Planner is instructions for the agent only. Our summary lists: A reviewed spec or decided brief.

Does Vertical-Slice Task Planner access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Vertical-Slice Task Planner safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Vertical-Slice Task Planner use?

Vertical-Slice Task Planner is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Vertical-Slice Task Planner use?

About 1.5k tokens (SKILL.md is roughly 6k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Vertical-Slice Task Planner?

Skills that share tags, products or a category with Vertical-Slice Task Planner: Implementation Plan Writer (imbue-ai/bouncer, 400 stars), Vibe Workflow Router (KhazP/vibe-coding-prompt-template, 3.1k stars), Technical Plan Writer (EveryInc/compound-engineering-plugin, 25k stars) and Speckit Tasks (foryourhealth111-pixel/Vibe-Skills, 3.6k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Vertical-Slice Task Planner?

owainlewis (a GitHub user) maintains it in owainlewis/blueprint, which has 412 GitHub stars. The repository holds 11 skills in this directory. The repository was last updated on October 6, 2026.

Source: owainlewis/blueprint on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.