Skill · from spec to board

Delivery Planner

A spec is not a plan, and a plan in someone’s head is not a board. This cuts the work into slices you can build and prove one at a time, and keeps your tracker telling the truth about them — without duplicates, and without overwriting a person.

Soumya Rauth · Creator & maintainer

npx skills add soumyaRauth/skills-hub --skill delivery-planner

The problem

spec → database, then API, then UI → nothing works until everything does

Work cut into layers cannot be shown working until the last layer lands. And the board drifts: cards sit in To Do while the code ships, a retried script creates the same ticket twice, an automation overwrites the column a person just moved a card into.

When it activates

No slash command needed. Installed, it is loaded when a request needs it and stays out of the way otherwise — and when it does shape the work, one ⚡ line says so. How the skills work together →

Engages	You ask to plan the work, break a spec or feature into tickets, connect a tracker, change tickets, or what’s left — and, passively, whenever work starts or finishes in a project that keeps .delivery/.
Stays quiet	A single small task in a project without .delivery/. It never creates a tracker or tickets nobody asked for.
Depth	Shapes the work when asked to plan or change tickets. Status moves happen in the background, with one line in the reply. Never a gate.
Works with	ProofBuild, Project Compass, Architecture Engineer, Dependency Guard

What it does

the spec → milestones M1 is a walking skeleton, deployed
   → tickets vertical slices · numbered acceptance criteria · negative cases
   → decisions an undecided rule blocks its ticket, with the question
   → .delivery/ ⇄ your tracker

You:    Plan the build from the spec and put the tickets in Jira.

Agent:  PLAN     docs/spec.md → 3 milestones · 10 tickets · 2 open decisions
        M1       Walking skeleton deployed        T-001 T-002
        M2       Customers book and cancel        T-003 T-004 T-005 T-006
        M3       Owner runs the week              T-007 T-008 T-009 T-010
        BLOCKED  T-006 on D1: can a customer cancel on the day?
        TRACKER  jira · via rest · SAL · 10 created · 0 already there

Any tracker, or none

Jira (Cloud and Data Center), Trello, Nextcloud Deck, GitHub Issues and Projects, GitLab Issues, Linear, or local files only. Tickets are not tied to any of them. It reaches each through an installed MCP server, then the official CLI, then the REST API — and says which. Every endpoint it uses is checked against the vendor’s own documentation, and anything that could not be is marked unverified.

Setup that sets itself up

which tracker → connect official MCP sign-in, or a hidden prompt in your terminal
→ pick a board from your real ones, or create one on your yes
→ map columns create the missing ones on your yes → autonomy → CONNECTED

Agent:  Run this in your own terminal (not here), from the repository root:
          python3 <skill dir>/scripts/tracker.py secret deck
        It shows where to create an app password and asks for it with hidden input.

You:    done

Agent:  Your Deck boards: 1 Personal (4) · 2 Salon admin (9)
        Pick one, or: n) create a new board "salon-booking"
        …
        CONNECTED  deck via rest as Mira Okafor · board salon-booking (17) · 7 of 7 statuses mapped

The first run is a conversation that acts after each answer. Tokens never pass through the chat: they go into a git-ignored, owner-only .delivery/.env, or there is no token at all because an official MCP server signs you in through the browser. Nothing is created in the tracker until a read-only check proves who you are and what the board looks like — and when it fails, it says whether the credential, its scope or the board id is wrong.

A person’s move wins

Tracker: T-004 → Done (✓ VERIFIED · merged 3f2a91c)
T-006 not started — the owner moved it to Blocked on the board at 13:52:
  "Wait, I need to check the holiday dates with my landlord."
Local file updated. Next ready ticket is T-008. Take that instead?

Tickets move at fixed moments — picked up, PR opened, proven and merged, blocked — each with a comment carrying its evidence. The tracker item is read before every write. A change a person made there is pulled in, never overwritten. Nothing is ever deleted, and when the tracker is down the work continues locally and reconciles on the next run.

Where it fits

Each ticket’s acceptance criteria become ProofBuild’s requirements, and a ticket reaches done only on its VERIFIED and a merge. An undecided business rule is the kind of thing Project Compass notices; here it blocks the ticket instead of being guessed.