Skip to main content
tk uses graph algorithms to analyze your issue dependency graph and help you prioritize work intelligently. Instead of manually sorting through issues, tk automatically surfaces what matters most.

​
Why Graph Analytics?

Your issues form a dependency graph. Some issues block others. Some are blocked by many. The structure of this graph reveals which work will have the biggest impact. tk analyzes this graph using battle-tested algorithms from computer science and applies them to project management.

​
PageRank Priority

​
How It Works

PageRank is the algorithm that powers Google Search. Here’s the key insight:

🌐 How does Google know if a website is important?

Answer: Many other websites link to it.If 1,000 websites link to your page, Google sees it as valuable. If only 5 link to it, maybe not so much.

🎟️ How does Ticket know which issue is most important?

Answer: Many other issues depend on it.If 8 issues are blocked waiting for you to finish tk-abc123, that’s high-priority work. Complete it first to unblock the most downstream work.
Issues that block the most downstream work get higher PageRank scores. Completing them first unblocks the most work, so you should prioritize them.

​
Example

# See PageRank scores for all issues
tk priority

# Limit to top 5
tk priority --limit 5

# Filter by status
tk priority --status open
Sample output: 
Top Priority Issues (by PageRank):

1. tk-abc123 (score: 0.42) - Implement database schema
   Blocks: 8 issues

2. tk-def456 (score: 0.31) - Set up CI/CD pipeline
   Blocks: 5 issues

3. tk-ghi789 (score: 0.18) - Add authentication API
   Blocks: 3 issues
Issues with no dependents have low PageRank scores. Issues that many others depend on have high scores.

​
Critical Path

​
What It Is

The critical path is the longest chain of dependencies in your project. It determines your minimum timeline. If you have issues A → B → C → D (each depends on the previous), you can’t parallelize them. The critical path shows you which sequences can’t be worked on simultaneously.

​
Why It Matters

  • Timeline estimates: Critical path length = minimum project duration
  • Bottleneck identification: Issues on the critical path are bottlenecks
  • Parallelization planning: Work NOT on critical path can be done in parallel

​
Example

# View critical path analysis
tk insights

# Show just the critical path
tk insights --critical-path
Sample output: 
Critical Path (7 issues, ~21 days):

tk-start → tk-abc123 → tk-def456 → tk-ghi789 → tk-jkl012 → tk-mno345 → tk-end

Issues on critical path:
- tk-abc123: Database schema (est: 3d)
- tk-def456: API endpoints (est: 5d)
- tk-ghi789: Frontend integration (est: 4d)
...

⚠️  Any delay in these issues delays the entire project.
Issues on the critical path deserve special attention. Delays here delay everything.

​
Betweenness Centrality

​
What It Is

Betweenness centrality measures how many dependency paths flow through an issue. Issues with high centrality are bottlenecks — they appear in many different dependency chains. Think of it like traffic flow:
  • A highway interchange has high betweenness (many routes go through it)
  • A dead-end street has low betweenness (no routes go through it)

​
Why It Matters

Issues with high betweenness centrality are project choke points. If they get delayed, they impact many different work streams.

​
Example

# Show betweenness centrality scores
tk insights --centrality

# Combined with triage
tk triage
Sample output: 
High Centrality Issues (bottlenecks):

1. tk-abc123 - Authentication system (centrality: 0.65)
   Appears in 12 dependency paths
   Blocks work in: frontend, mobile, API

2. tk-def456 - Database migrations (centrality: 0.48)
   Appears in 8 dependency paths
   Blocks work in: backend, sync, reports
Clear high-centrality issues first. They’re blocking multiple teams or work streams.

​
Ready Work

​
What It Is

Ready work is simple: issues with no open blockers. These are your green lights — work you can start right now.

​
Why It Matters

When you finish an issue, other issues may become ready. The ready command helps you:
  • Find what’s unblocked and can be worked on immediately
  • Parallelize work across multiple developers or AI agents
  • Stay productive by always knowing what’s available

​
Example

# List all ready issues
tk ready

# Filter by priority
tk ready --priority 0

# Limit results
tk ready --limit 10

# See what becomes ready after resolving an issue
tk resolve tk-abc123
Sample output: 
Ready to Work (15 issues):

tk-def456 [P1] - Add user profile page
tk-ghi789 [P2] - Write integration tests
tk-jkl012 [P1] - Update documentation
...

💡 These issues have no open blockers.
Use tk ready to find work when you’re context switching or starting a new task.

​
AI-Powered Triage

tk combines all these analytics into a single unified triage command: 
tk triage
What you get:
  1. Quick Reference — Issue counts and project health
  2. Top Recommendation — Single best next action
  3. Quick Wins — Easy issues to knock out
  4. Blockers to Clear — High-impact issues blocking the most work
  5. Health Score — Overall project health grade (A-F)
Sample output: 
═══════════════════════════════════════════════════════
                    PROJECT TRIAGE
═══════════════════════════════════════════════════════

📊 Quick Reference:
   Total: 42 | Open: 28 | Ready: 15 | Blocked: 8

🎯 Top Recommendation:
   tk-abc123 - Implement database schema

   Why: Blocks 8 other issues, on critical path
   Priority: Critical (P0)

   → tk claim tk-abc123

⚡ Quick Wins (est < 1 day):
   • tk-def456 - Update README
   • tk-ghi789 - Fix typo in error message
   • tk-jkl012 - Add logging to API endpoint

🚧 Blockers to Clear:
   1. tk-abc123 (blocks 8 issues)
   2. tk-mno345 (blocks 5 issues)
   3. tk-pqr678 (blocks 4 issues)

💚 Health Score: B+ (Good)
   - 65% of issues are unblocked
   - 3 high-priority blockers need attention
   - Critical path: 7 issues

Use AI Triage Daily

Run tk triage at the start of your work session to get AI-powered recommendations.

​
Parallel Execution Planning

tk can generate a parallel execution plan using topological sort: 
tk plan
This shows you batches of issues that can be worked on in parallel. Each batch contains issues with no dependencies on other issues in the same or later batches. Sample output: 
Parallel Execution Plan:

Batch 1 (can start immediately):
  • tk-abc123 - Database schema
  • tk-def456 - CI/CD setup
  • tk-ghi789 - Design mockups

Batch 2 (after Batch 1):
  • tk-jkl012 - API endpoints (waits for: tk-abc123)
  • tk-mno345 - UI components (waits for: tk-ghi789)

Batch 3 (after Batch 2):
  • tk-pqr678 - Integration tests (waits for: tk-jkl012, tk-mno345)

Batch 4 (after Batch 3):
  • tk-stu901 - Deploy to production (waits for: tk-pqr678)
This plan helps you:
  • Maximize parallelization — Work on multiple batches simultaneously
  • Understand dependencies — See what’s blocking what
  • Plan sprints — Assign batches to different team members
For linear dependency chains, tk also detects stacks — coordinated sequences of issues for incremental development. See Stacks for more.

​
Best Practices

Start each work session with tk triage to get AI-powered recommendations.
Review tk insights to understand project timeline and bottlenecks.
Run tk priority to identify high-impact issues for sprint planning.
Use tk ready to see what you can work on while waiting for blockers.
Use tk resolve instead of tk close to see what work becomes unblocked.

​
Next Steps

Stacks

Learn about linear dependency chains for coordinated development.

Dependencies Guide

Learn how to structure and manage issue dependencies.

CLI Reference

Full command reference for triage, priority, insights, and more.

Claude Integration

Set up automated triage in Claude Code.