Plan

Use when you have items to execute and need to know the right order. Sequences by dependency (what blocks what), not by score. Keywords: plan, sequence, order, dependencies, execution, schedule, critical path, before, after, blocks.From its SKILL.md

Install

npx -y skills add tyevans/tackline --skill plan

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

14 stars14 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

3.8 KB, as published. Nobody here has run it

Plan: Sequence Items by Dependency

You are running the plan primitive — sequencing items into a dependency-aware execution order. Constraint: $ARGUMENTS

When to Use

After decompose or gather to sequence sub-parts into an execution plan
When the user asks to "plan", "order", "sequence", or "schedule" work
To identify what must come before what (dependency ordering vs. score-based ranking)
When you need to visualize critical path and parallel opportunities

Process

Find Items: Detect upstream pipe-format output in context. If none found, extract items directly from $ARGUMENTS.
Identify Dependencies: For each item, determine what it depends on. Use Read/Grep/Glob to understand technical dependencies in the codebase when applicable.
Sequence by Dependency: Order items so dependencies come before dependents. Apply constraint from $ARGUMENTS if present (e.g., "minimize risk" → de-risk blockers first; "fastest path" → shortest critical path).
Emit Sequenced Output: Output in pipe format with execution-order numbering, dependency metadata, ASCII dependency graph, and parallel groups with isolation hints.

Output Format

Output in pipe format. Items in EXECUTION ORDER, each with:

Title — what this step does
depends-on: [item numbers or "none"]
rationale: [why this position in the sequence]
Dependencies: ASCII diagram showing dependency graph (e.g., 1 → 2 → 4, 1 → 3 → 4)
Parallel Groups: Execution waves derived from the dependency graph, each listing concurrent items with isolation hints. Format:
```
### Parallel Groups

**Wave 1** (no dependencies)
- Item 1 — `shared` (read-only config changes)
- Item 3 — `worktree` (modifies shared model layer)

**Wave 2** (depends on Wave 1)
- Item 2 — `shared` (isolated module, no shared file writes)
- Item 4 — `worktree` (touches shared migration files)

**Wave 3** (depends on Wave 2)
- Item 5 — `worktree` (integration layer, touches multiple modules)
```
Isolation hint rules:
- worktree — item writes to files that other wave-siblings also read or write, or modifies shared infrastructure (migrations, config, interfaces)
- shared — item is safe to run concurrently in a shared workspace (isolated module, read-only, or no file overlap with siblings)
Summary: One paragraph synthesis including critical path length, parallel opportunities, and constraint application

Guidelines

Items are numbered in execution order (earliest-possible first), not score order
If multiple items have no dependencies, constraint determines their relative order
Critical path is the longest dependency chain from start to finish
Parallel opportunities are items with the same depends-on set (can run concurrently); these form a wave in the Parallel Groups section
If dependencies are unclear from input, note assumptions in rationale
Parallel Groups is the bridge to /sprint: wave items with worktree hint → dispatch with isolation: "worktree"; wave items with shared hint → dispatch normally; waves are sequential, items within a wave are parallel
Isolation hint is worktree when an item writes to files that sibling items in the same wave also touch, or when it modifies shared infrastructure (migrations, config, public interfaces); otherwise shared