mcpField
P
project-tickets

project-tickets

github.com/light-chengAgent workflows521 installsUpdated 3d ago
Repository

About project-tickets

project-tickets is a user-invoked planning skill that converts an approved SPEC into numbered issues in a local Markdown tracker. It verifies the handoff, drafts dependency-aware vertical slices, and publishes tickets only after the user approves their shape.

Key features

  1. 01Verify SPEC approval and completeness
  2. 02Draft demoable vertical-slice tickets
  3. 03Track dependencies and parallel work
  4. 04Iterate on ticket shape with the user
  5. 05Publish numbered Markdown issue files

Use cases

  1. 01Turn an approved SPEC into implementation tickets
  2. 02Plan work with explicit dependencies
  3. 03Apply an approved change proposal to tickets

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/light-cheng/skills --skill project-tickets

After installing, type/project-ticketsin Claude Code to confirm it loaded.

Bundled files

References and scripts installed along with SKILL.md.

ATTRIBUTION.md
agents/
openai.yaml
references/
EXAMPLES.md
TICKET-CONTRACT.md
WORKFLOW.md

Details

From the project README

Project Tickets

project-tickets is an explicit, user-invoked planning stage. Run it only after an explicit $project-tickets request. It turns a verified SPEC into numbered, one-file-per-ticket issues on the local markdown tracker.

Resolve the tracker and working area from docs/agents/light-project.md and its docs/agents/issue-tracker.md locator when present. If the configured tracker is not the supported local-markdown contract, report BLOCKED with the missing adapter instead of silently writing .scratch files.

Core behavior

  1. Verify the SPEC handoff. Read the SPEC at the supplied path; a missing, malformed or Approval: pending SPEC is a handoff gap — report it and stop. A SPEC with no Approval: line: ask the user, and on yes record it.
  2. Draft tracer-bullet vertical slices. Each slice is a narrow, complete, demoable path through the relevant layers, with Blocked by edges, ready work, and parallelizable groups.
  3. Quiz the user. Show title, Blocked by, and what each ticket delivers; iterate until the granularity and edges are approved.
  4. Publish one file per ticket under .scratch/<feature>/issues/, numbered from 01 in dependency order with the approved shape unchanged. Then append the approval (who, when, their words) to the SPEC's ## Comments as a Tickets approved line.

Applying a change proposal. When the user passes an approved proposal from .scratch/<feature>/changes/, apply exactly its Tickets: line (add, drop, split, reorder, change Blocked by or acceptance). When its SPEC: line is none or a SPEC applied line is already under ## Comments, set **Status:** to applied with a status line; otherwise add - <date> Tickets applied — project-tickets. A proposal in any other status, or a change it does not list, goes back to the user unchanged.

Handoff

After publishing, describe the frontier and recommend explicit $light-implement on the chosen ticket, then stop.

Optional capabilities

  • .scratch/<feature>/plan.html exists → after publishing, call light-html-plan to refresh it. Missing page or capability → skip.

References

Comments

Markdown supported