ptp-backlog

Defines the GitHub Projects v2 epic backlog contract, schema, read protocol, and ready set.

Updated Jun 8, 2026
One-click install
npx skills add https://github.com/AlmogMaayan/ptp --skill ptp-backlog-almogmaayan
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: ptp-backlog
Source: https://github.com/AlmogMaayan/ptp/tree/main/skills/ptp-backlog
Command: npx skills add https://github.com/AlmogMaayan/ptp --skill ptp-backlog-almogmaayan

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Teams using the PtP pipeline need one durable place to record epics before they become change folders, and every command that reads or writes that store must agree on its schema, validation rules, and ready-set definition. This Skill is the single source of truth for the epic backlog stored as a GitHub Projects v2 board, preventing schema drift across the view, editor, recovery gate, and runner commands. ## Core Features & Use Cases - Canonical schema and identity model: Defines the ten-field entry object, the board-supplied node-id identity rule, the version marker gate, and the tolerant read that keeps the board hand-editable. - Read protocol and validation vocabulary: Specifies the ordered gh CLI read sequence, totalCount reconciliation, the three-way join of roster, non-archived, and archived rows, and the problem codes every consumer reports identically. - Status transitions and recovery: Owns the guarded transition table (ready, in-progress, in-review, blocked, done, cancelled) and the reconciliation machinery for crashed runs, including claim, disown, and rerun dispositions. - Use Case: When /ptp:backlog-run picks the next epic to execute, it cites this Skill's ready-set definition (status equals ready, ordered by board position) rather than restating it, so the view and the runner never disagree about what runs next. ## Quick Start Ask the AI to read the epic backlog board and show the ready set using the ptp-backlog contract.

Frequently Asked Questions about ptp-backlog

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I manage an epic backlog on a GitHub Projects board?▼

Use the PtP backlog commands, which treat one GitHub Projects v2 board per workspace root as the epic store. Entries carry title, status, change-epic links, and a run baseline, and the board's card position defines execution order.

What statuses can a backlog epic have?▼

An entry's status is one of backlog, ready, in-progress, in-review, done, blocked, or cancelled. The first five are pipeline values; blocked and cancelled are auxiliary states, and pending is no longer a valid value.

How does the backlog decide which epic runs next?▼

The ready set is every entry whose status equals ready, ordered by the board item's position ascending with a node-id tie-break. No dependency or topological pass is performed, so the top card of the Ready column runs first.

What happens when a backlog run crashes mid-epic?▼

A stale in-progress entry with a non-null runBaseline triggers reconciliation: the current change-folder prefix set is diffed against the baseline, and the user settles it via claim, disown, or rerun dispositions. Recovery never yields done.

Can I hand-edit cards on the backlog board?▼

Yes, the read is deliberately tolerant: only id, title, and status are required, and missing optional fields get in-memory defaults. Absent required fields or wrong types are reported as malformed-entry problems and never silently coerced.

Does the backlog fall back to a local file if the board is unreachable?▼

No. There is no local backlog file, second store, or fallback of any kind; an unreachable board stops the operation with an unreachable-store outcome rather than splitting the backlog across two stores.