<!-- Generated by mstack from Misbah's Build Like This workflow. Regenerate instead of editing. -->

ticket-graph

This skill is part of Misbah Khursheed's Build Like This workflow. Thinking, evidence, and explicit trade-offs come before generated output.

Project identity and sources of truth

The repository where this skill is installed is the host project being built. Build Like This is the method used to build it; mstack only installs and reconciles method resources. Do not assume mstack or Build Like This is the product unless project-owned sources explicitly identify this repository as mstack itself.

Use project-owned docs/, decisions, executable code, and tests as sources of truth. .mstack/templates/ are reference scaffolds to copy and adapt into project-owned documents, not product requirements and not a replacement for docs/.

Purpose

Produce a dependency DAG of vertical delivery slices so implement-task-graph can run the unblocked frontier safely in parallel.

Required inputs

• A publishable spec or feature document with acceptance criteria.
• planning-setup tracker configuration (GitHub, GitLab, or local markdown).
• Constraints on slice size, expand-and-contract needs, and owners.

If a missing input would materially change the result, state the gap and obtain or discover it before proceeding. Otherwise label the assumption and continue.

Process

1. If planning-setup is missing, run it or stop with that gap.
2. Propose tracer-bullet vertical slices that each prove user-visible or contract-level behavior; quiz the user on granularity and edges before publishing.
3. For wide refactors, prefer expand-and-contract tickets over forced vertical fiction.
4. Publish blockers first so edges can cite real IDs; record Blocked by links using native tracker dependencies when available, otherwise a body field.
5. Local tracker layout: <configured-path>/<feature>/issues/NN-slug.md with status, acceptance criteria, and Blocked by.
6. Hand the frontier (open and unblocked) to implement-task-graph.

Output contract

• Published tickets with stable IDs, acceptance criteria, and blocking edges.
• A frontier list and a visual or textual DAG summary.
• Tracker-specific sync notes (gh/glab/local paths).

Guardrails

• Do not create horizontal layer tickets (all-DB-then-all-API) when a vertical slice is possible.
• Do not start implementation inside this skill.
• Do not leave blocking edges as prose only when the tracker supports native dependencies.

Delegation and parallel safety

• Material lifecycle work must delegate at least one bounded specialist lane when subagents are available. Prefer two or more concurrent lanes only for independent evidence gathering, analysis, or non-overlapping file ownership.
• The active lead owns integration and acceptance. Supporting agents do not recursively delegate unless explicitly promoted to lead a named lane.
• Assign distinct outputs and ownership. Serialize shared docs, contracts, schemas, migrations, deployments, external writes, and overlapping file edits.
• When subagents are unavailable, perform the same named specialist passes sequentially and state that constraint instead of implying parallel verification.
• Delegation never grants permission for outreach, consequential external actions, destructive changes, paid resources, or production operations.

End with the evidence gathered, verification performed, and any residual risk or unresolved decision.