Conductor Linear Issue

**Purpose**: Turn a Linear issue into an autonomous, end‑to‑end implementation flow inside Conductor workspaces, with minimal chatter and strict Graphite/Linear compliance. Adapted for Conductor's pre-configured branch setup.
---
## How to Use
- Command: `/conductor-linear-issue [LinearKey|IssueID?]`
- Arguments

    - LinearKey|IssueID (optional): Linear issue key (e.g. AIC-432) or issue ID.
- Issue Resolution (priority order):

    1. **Argument**: If provided, use directly.
    2. **Context**: Issue details given in conversation (user may paste or describe the issue).
    3. **Branch name**: Extract from current branch (e.g. `lionvsx/aic-432-feature` → `AIC-432`).
    4. **Commit message**: Check latest commit for Linear key.
    5. **Prompt**: Ask user if none found.
---
## Conductor Context
- **Pre-configured branch**: Conductor already places you on the correct Linear branch (no branch creation needed).
- **No initial commits**: The branch exists but has zero commits.
- **Workflow**: Investigation → Implementation → Validation → PR on command.
---
## Single‑Run Contract
- This command executes now, within the current Cursor session.
- It follows the Two‑Phase Workflow with minimal external output (single‑line updates only).
- Deferred PR: no commit/push until the developer explicitly types PR after completion.
---
## Exact Behavior (What this command must do)
### 1. Resolve the Issue
- Resolve the identifier using priority order:

    1. Argument provided → use directly.
    2. Issue in conversation context → extract key or use provided details.
    3. Branch name → parse Linear key (e.g. `lionvsx/aic-432-xxx` → `AIC-432`).
    4. Commit message → extract Linear key.
    5. None found → prompt user.
- Call Linear MCP get_issue with the resolved identifier (unless full issue context already provided).
- Fetch from the retrieved issue: title, description, acceptance criteria, labels, priority, and any attachments/links.
- If the issue cannot be found or fetched → output: 🔴 20% – Clarification needed: issue not found for "<identifier>". Provide a valid Linear key or issue ID.
- Inject the full issue body into {issue} to scope the task.
### 2. Complexity Assessment
- Estimate Total Effort (TE).
- If TE ≤ 4h and task is straightforward → proceed.
- If TE > 4h or acceptance criteria are unclear → Stop and ask one very specific clarification question. Do not create sub‑issues unless you will execute them now.
### 3. Two‑Phase Workflow (Minimal External Output)
PhasePurposeExternal Output (exactly 1 line)Phase 1 – InvestigationUnderstand, design, plan.Phase 1: [EMOJI_CONFIDENCE] [PERCENT]%Phase 2 – ExecutionImplement, test, validate.Phase 2: [EMOJI_COMPLETION] [PERCENT]%
### 4. Scales
- Phase 1 (Confidence): 🟢 90‑100 % · 🟡 60‑89 % · 🟠 30‑59 % · 🔴 < 30 %
- Phase 2 (Completion): ⬜ 0 % · 🟥 1‑25 % · 🟧 26‑50 % · 🟨 51‑75 % · 🟩 76‑99 % · ✅ 100 %
### 5. Auto‑transition
Investigate until reaching 🟢 confidence, then switch to Phase 2.
### 6. Implementation Rules
- Keep Linear as the single source of truth.
- No narrative logs; only the mandated single‑line Phase updates and Stop‑Lines.
- No subtasks unless they will be implemented now in this session.
### 7. Validation
- Run all project tests, linters, CI, and type checks applicable to the repo. Fix failures until Phase 2 shows ✅ 100 %.
---
## Stop Rule (exactly one stop‑line)
### Situations & Formats
- Clarification needed (Phase 1 < 30 %) → 🔴 [X]% – Clarification needed: <very specific question>
- Feature complete, awaiting PR instruction → 🟦 100% – Feature ready. Reply "PR" (or give feedback) to continue.
---
## Conductor Graphite Workflow — Simplified PR Flow
### Context
- You are already on the correct branch (created by Conductor).
- No branch creation is needed.
- Always ensure tracking before publishing.
### When User Says "PR"
Execute this decision tree:
`1. Check if current branch has commits:
   git log dev..HEAD --oneline

2. IF no commits exist:
   a. Stage files selectively (git add <file>; never -a or -A)
   b. Create initial commit: git commit -m "<Linear-Key>: <concise commit title>"
   c. Ensure tracking: gt track --parent dev
   d. Publish: gt ss --no-edit --publish

3. IF commits exist:
   a. Stage new/modified files selectively
   b. Amend: gt modify
   c. Ensure tracking: gt track --parent dev
   d. Publish: gt ss --no-edit --publish

4. Post the PR link/identifier
`
### Compliance Checklist
- Stage only the files permitted by project rules.
- Never use `git add -A` or `git add -a`.
- If graphite-linear-workflow directives are unclear → output:

    - 🔴 15% – Clarification needed: graphite-linear-workflow compliance unclear
    - Then wait for guidance.
### Failure Handling
- If `gt ss` fails → check branch tracking with `gt info` and fix.
- If conflicts arise → resolve, stage, then `gt modify && gt ss --no-edit --publish`.
---
## User‑Triggered Pull Request (after 🟦 100%)
On `PR` (or similar):
1. Check for existing commits on branch: `git log dev..HEAD --oneline`
2. Stage relevant file changes (selective `git add <paths>`).
3. Ensure tracking: `gt track --parent dev`
4. **No commits yet**: `git commit -m "<Linear-Key>: <concise title>"` → `gt ss --no-edit --publish`
5. **Commits exist**: `gt modify && gt ss --no-edit --publish`
6. Post the PR link/identifier.
If feedback is provided instead of PR → address it, rerun validations, return to 🟦 100% stop‑line.
---
## Stop‑Line Recap
- Never emit more than one stop‑line per pause.
- Formats are exactly:

    - 🔴 [X]% – Clarification needed: <question>
    - 🟦 100% – Feature ready. Reply "PR" (or give feedback) to continue.
---
## Safety & Scope Guards
- Never run `gt ss` before the explicit PR instruction.
- Never stage all (`git add -A` or `-a`). Stage only allowed paths.
- Never create Linear subtasks unless they will be executed now.
- Never create a new branch — Conductor has already set it up.
- If rule compliance is uncertain → stop with the failure stop‑line.
---
## One‑Screen Summary (for Cursor/Conductor)
`Fetch Linear → assess complexity → Phase 1 → Phase 2 → validate → 🟦 100%
→ on "PR": check commits → gt track --parent dev → (no commits: commit + gt ss) OR (commits: gt modify + gt ss)
→ post PR link
`
---
metadata:
priority: high
version: 1.0
context: conductor