Project Management

Problem with this skill? Run kendex report — it files to the owning repo automatically. Do not hand-file.

Wrappers run in the primary session: they own the user dialog and every tracker mutation. TPM workflows analyze and return JSON inline; they never mutate the tracker and never write the artifact.

Disposition

The backlog is a queue of work someone will do, not a record of everything anyone noticed.

• Creation bar. File an issue only when all three hold: it changes what a user or operator experiences, or blocks work that does; no open issue, active branch, or one-line fix already covers it; and someone could pick it up and finish it without a new investigation. A reproducible anomaly with evidence in hand passes all three as an investigation issue — the diagnosis is its deliverable. Everything else is declined with one line in the report — no issue, no placeholder, no tracking artifact. A severe-sounding edge case that no real input reaches fails the first test.
• Burn down more than you create. Any audit that proposes creations also sweeps its comparison set for issues the codebase has already satisfied, duplicated, or superseded, and proposes those for cancellation in the same pass. Report created N / closed M; an audit reporting only creations has not finished its sweep.
• Ask about work, never about mechanics. The user decides what gets created, cancelled, and activated. Labels, priorities, relations, hierarchy, sort order, and project moves are corrections the workflow applies on its own authority.

Commands

audit-issues is primary-session only: its § 6 approval gate needs the session's interactive question tool, and § 7 mutates only against approvals collected there. Delegate the tpm-audit.md analysis it spawns, never the wrapper.

TPM analysis workflows, each returning JSON per its schema: tpm-cycle-plan, tpm-audit (project / issue / project-order modes), tpm-roadmap-plan.

Execution Rules

• Run workflow sections in order. Skip only on an explicit Skip if condition, never on your own scope assessment.
• <delegation_format> and <output_format> are literal templates: fill [PLACEHOLDERS], drop lines whose placeholders are empty, add nothing.
• Send a user-visible <output_format> report as a normal assistant message first, then invoke the question tool separately with only the question and short option labels. Pasting the report into question text or options buries the choice in the Pi popup.
• Resolve tracker context once per run (audit-issues § 1.2) and route every preflight, fetch, and mutation through it. A GitHub-tracked run must not require Linear installation, sync, or authentication; where GitHub lacks a Linear concept the workflow degrades in a documented note, never silently.
• Before any issue create or label update, run the label preflight in references/labels.md against the live inventory and project taxonomy. Unknown labels, parent/group labels, missing required categories, and exclusivity violations halt before mutation.
• In multi-issue analysis, keep verification context per issue. One issue's PR, branch, or resolved path set never scopes another's checks.

Hierarchy

Initiative → Project → Milestone → Issue → Sub-Issue. Parent and child must share a project; blocking relations may cross projects freely. See references/dependencies.md.

Contracts

Dependencies

linear skill (Linear-tracked work), github skill + gh (GitHub-tracked issue audits), git and jq (audit verification scope).