Estimate
Read a Linear ticket and recommend a story point estimate.
Usage
/estimate — auto-detect ticket from branch name/estimate MAC-42 — specify ticket explicitly
Step 1: Identify the Ticket
If no ticket ID provided, extract from the current branch name:
git branch --show-current
Parse the ticket ID from common branch patterns:
gh-123-slug → GitHub issue #123 (look up linked Linear ticket)gareth/mac-42-slug → MAC-42fix/PROJ-456-slug → PROJ-456
Step 2: Fetch the Ticket
lc issue get <TICKET-ID> --json
lc comment list <TICKET-ID> --json
This returns title, description, estimate, state, assignee, priority, and labels. Comments are fetched separately.
Comments often contain clarifications, scope changes, or technical context that affect complexity. Factor these into your assessment.
If the ticket has no description or is title-only, flag this and estimate based on title alone with lower confidence.
Step 3: Assess Complexity
Evaluate the ticket on four dimensions:
| Factor |
What to assess |
| Scope |
How many files, systems, or layers are touched? Is it a single change or cross-cutting? |
| Ambiguity |
Are requirements clear? Could two engineers read this and build the same thing? |
| Dependencies |
Does this touch shared code, APIs, external services, or require coordination? |
| Risk |
How likely are unknowns, edge cases, or things that could go wrong? Is there prior art? |
Rate each factor: Low / Medium / High.
Step 4: Map to Points
Use this scale:
| Points |
Profile |
| 1 |
Trivial. Single file, no ambiguity, no risk. Copy-paste with minor edits. |
| 2 |
Small. Clear scope, 1-2 files, straightforward implementation. |
| 3 |
Moderate. Multiple files, some decisions needed, manageable risk. |
| 5 |
Significant. Cross-cutting changes, design decisions required, some unknowns. |
| 8 |
Large. High ambiguity, multiple systems, research needed, significant risk. |
If the ticket feels larger than 8, note that it should be broken down.
Output Format
## Estimate: [TICKET-ID]
**Title**: [title]
**Current estimate**: [existing points if set, or "none"]
| Factor | Rating | Notes |
|--------|--------|-------|
| Scope | Low/Med/High | [brief reason] |
| Ambiguity | Low/Med/High | [brief reason] |
| Dependencies | Low/Med/High | [brief reason] |
| Risk | Low/Med/High | [brief reason] |
**Recommended: [N] points**
[1-2 sentence justification]
Rules
- Do NOT update the Linear ticket. User does this manually.
- Do NOT read the codebase to inform the estimate. This is a ticket-level estimate, not a code review.
- If the ticket lacks a description, say so and flag lower confidence.
- Only use values 1, 2, 3, 5, or 8. No in-between values.
1---2name: estimate3description: Read a Linear ticket and estimate story points (1, 2, 3, 5, 8) based on scope, ambiguity, dependencies, and risk.4---56# Estimate78Read a Linear ticket and recommend a story point estimate.910## Usage1112- `/estimate` — auto-detect ticket from branch name13- `/estimate MAC-42` — specify ticket explicitly1415## Step 1: Identify the Ticket1617If no ticket ID provided, extract from the current branch name:1819```bash20git branch --show-current21```2223Parse the ticket ID from common branch patterns:24- `gh-123-slug` → GitHub issue #123 (look up linked Linear ticket)25- `gareth/mac-42-slug` → `MAC-42`26- `fix/PROJ-456-slug` → `PROJ-456`2728## Step 2: Fetch the Ticket2930```bash31lc issue get <TICKET-ID> --json32lc comment list <TICKET-ID> --json33```3435This returns title, description, estimate, state, assignee, priority, and labels. Comments are fetched separately.3637Comments often contain clarifications, scope changes, or technical context that affect complexity. Factor these into your assessment.3839If the ticket has no description or is title-only, flag this and estimate based on title alone with lower confidence.4041## Step 3: Assess Complexity4243Evaluate the ticket on four dimensions:4445| Factor | What to assess |46|--------|---------------|47| **Scope** | How many files, systems, or layers are touched? Is it a single change or cross-cutting? |48| **Ambiguity** | Are requirements clear? Could two engineers read this and build the same thing? |49| **Dependencies** | Does this touch shared code, APIs, external services, or require coordination? |50| **Risk** | How likely are unknowns, edge cases, or things that could go wrong? Is there prior art? |5152Rate each factor: Low / Medium / High.5354## Step 4: Map to Points5556Use this scale:5758| Points | Profile |59|--------|---------|60| **1** | Trivial. Single file, no ambiguity, no risk. Copy-paste with minor edits. |61| **2** | Small. Clear scope, 1-2 files, straightforward implementation. |62| **3** | Moderate. Multiple files, some decisions needed, manageable risk. |63| **5** | Significant. Cross-cutting changes, design decisions required, some unknowns. |64| **8** | Large. High ambiguity, multiple systems, research needed, significant risk. |6566If the ticket feels larger than 8, note that it should be broken down.6768## Output Format6970```71## Estimate: [TICKET-ID]7273**Title**: [title]74**Current estimate**: [existing points if set, or "none"]7576| Factor | Rating | Notes |77|--------|--------|-------|78| Scope | Low/Med/High | [brief reason] |79| Ambiguity | Low/Med/High | [brief reason] |80| Dependencies | Low/Med/High | [brief reason] |81| Risk | Low/Med/High | [brief reason] |8283**Recommended: [N] points**8485[1-2 sentence justification]86```8788## Rules8990- Do NOT update the Linear ticket. User does this manually.91- Do NOT read the codebase to inform the estimate. This is a ticket-level estimate, not a code review.92- If the ticket lacks a description, say so and flag lower confidence.93- Only use values 1, 2, 3, 5, or 8. No in-between values.
cerico