Skip to content

Instantly share code, notes, and snippets.

@yitzwillroth
Created March 12, 2026 13:47
Show Gist options
  • Select an option

  • Save yitzwillroth/74784f360588d647e7f8a9bb175f76c2 to your computer and use it in GitHub Desktop.

Select an option

Save yitzwillroth/74784f360588d647e7f8a9bb175f76c2 to your computer and use it in GitHub Desktop.
Linear-Driven Development Workflow for Claude Code

Linear-Driven Development Workflow for Claude Code

A complete skill-based workflow for Claude Code that integrates with Linear for issue tracking, planning, implementation, and review. Includes session-scoped edit locking during planning mode.

Skills

Skill Purpose Status Transition
/plan Explore codebase, write plan document to Linear — (creates document)
/approve Finalize artifacts, create parent issue, attach plan → Scheduling
/release Release planned work for implementation Scheduling → Queueing
/implement Break down into subtasks/checklists, start coding Queueing → Working
/handoff End-of-session: enrich artifacts, save progress — (stays Working)
/remediate Post organized review feedback, route back for fixes Reviewing → Queueing
/complete Mark as Running after human review Reviewing → Running

Board Columns (Linear)

Planning → Scheduling → Queueing → Working → Reviewing → Running
  • Planning: Idea dump, unrefined
  • Scheduling: Planned & approved, not released for implementation
  • Queueing: Released — agent can pick these up
  • Working: Actively being implemented
  • Reviewing: Complete, awaiting human review
  • Running: Human reviewed and approved

Labels

  • Feature — issue with subtasks (phases) + checklists on subtasks (steps)
  • Task — issue with checklists directly (no subtasks)
  • Remediation — needs fixes from review; prioritized over fresh work

Installation

1. Create skill directories

mkdir -p ~/.claude/skills/{plan,approve,implement,handoff,remediate,complete,release}

2. Copy skill files

Place each *-SKILL.md file as SKILL.md in its corresponding directory:

# Example for plan:
cp plan-SKILL.md ~/.claude/skills/plan/SKILL.md
cp approve-SKILL.md ~/.claude/skills/approve/SKILL.md
cp implement-SKILL.md ~/.claude/skills/implement/SKILL.md
cp handoff-SKILL.md ~/.claude/skills/handoff/SKILL.md
cp remediate-SKILL.md ~/.claude/skills/remediate/SKILL.md
cp complete-SKILL.md ~/.claude/skills/complete/SKILL.md
cp release-SKILL.md ~/.claude/skills/release/SKILL.md

3. Install the planning mode hooks

mkdir -p ~/.claude/hooks
cp planning-mode-toggle.sh ~/.claude/hooks/
cp planning-mode-gate.sh ~/.claude/hooks/
chmod +x ~/.claude/hooks/planning-mode-toggle.sh
chmod +x ~/.claude/hooks/planning-mode-gate.sh

4. Register the gate hook

Add to your .claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Edit|Write|NotebookEdit",
        "hooks": [
          {
            "type": "command",
            "command": "~/.claude/hooks/planning-mode-gate.sh"
          }
        ]
      }
    ]
  }
}

5. Linear setup

  • Create Feature, Task, and Remediation labels
  • Create custom statuses: Planning (backlog), Scheduling (unstarted), Queueing (unstarted), Working (started), Reviewing (started), Running (completed), Canceled (canceled)
  • The workflow assumes a team named "Technologentsia" — update skill files to match your team name

Key Design Decisions

  • Planning and implementation are separate sessions by default. /approve finalizes artifacts but does NOT start coding. /implement starts a fresh session with full context window.
  • TodoWrite and Linear checklists are the same information — composed once, posted to both. Near-zero marginal cost.
  • Use haiku subagents for all Linear write operations to save tokens. Opus reads and composes, haiku executes CRUD.
  • Agent never moves issues to Running — human in the loop required.
  • Remediation items are prioritized over fresh work when agent picks from the board.
  • Cross-session continuity via Linear: /implement TEC-xxx in a new session reads plan + checklists to reconstruct state.

Dependencies

  • Linear MCP server for Linear integration
  • jq for the planning mode hooks
  • Claude Code with skills support
name approve
description Approve a plan and finalize Linear artifacts. Unlocks editing tools, creates parent issue if needed, attaches plan document, and moves to Scheduling status. Does NOT start implementation — use /implement for that.

Approve Plan

The user has reviewed and approved the plan. Finalize the artifacts and unlock editing tools — but do NOT begin implementation. The user will invoke /implement when ready to start building.

Step 1: Remove Session from Planning File

Run this command to deactivate planning mode:

~/.claude/hooks/planning-mode-toggle.sh deactivate

After unlocking, confirm: "Planning mode is off. Editing tools are unlocked."

Step 2: Identify the Plan Context

Determine what was planned and where the plan document lives:

  • If the plan was attached to an existing issue → you already have the issue ID and document
  • If the plan created a new issue (task plan) → you already have both from /plan
  • If the plan is a project-level document (feature exploration) → check whether it's now ready to become actionable (see Step 3)

Step 3: Create or Update Linear Artifacts

For task plans (plan attached to an issue):

The issue already exists with the plan document attached. Ensure it has the Task label:

save_issue(id: "<issue-id>", labels: ["Task"], state: "Scheduling")

For feature plans becoming actionable:

If the exploration has matured into an actionable feature:

  1. Create a parent issue labeled Feature for the feature:
save_issue(title: "<feature title>", team: "Technologentsia", project: "<project>", labels: ["Feature"], state: "Scheduling")
  1. Create a new implementation plan document attached to that issue (distinct from the exploratory project document):
create_document(issue: "<new issue identifier>", title: "Implementation Plan: <brief description>", content: <tactical plan>)
  1. Add a reference link to the original exploratory document on the issue:
save_issue(id: "<issue-id>", links: [{"url": "<exploratory doc URL>", "title": "Exploratory Plan"}])

For feature explorations that are NOT yet actionable:

If the plan is purely exploratory and not ready for implementation, skip issue creation. Just confirm: "Exploration plan is finalized on the project. When you're ready to move this toward implementation, we can create an actionable plan and feature issue."

Step 4: Promote Parent Issue if Needed

If the issue being approved is a subtask (has a parent issue), check the parent's status. If the parent is in Planning or Queueing, move it to Working:

get_issue(id: "<issue-id>")  → check for parentId
# If parentId exists:
get_issue(id: "<parent-id>")  → check state
# If state is Planning or Queueing:
save_issue(id: "<parent-id>", state: "Working")

Use a haiku subagent for these status updates.

Step 5: Confirm to User

Summarize what was done:

  • What artifacts were created or updated
  • Current status of the issue(s)
  • Where the plan document lives

Close with: "Plan is approved and artifacts are finalized. Use /implement (or /implement TEC-xxx) when you're ready to start building."

Important Rules

  1. Do NOT begin implementation. This skill finalizes artifacts only. /implement starts the work.
  2. Do NOT create subtasks or checklists. Those are created at implementation time by /implement.
  3. Use haiku subagents for Linear write operations (status updates, label changes, link additions).
  4. Use the correct status names: Scheduling (planned/approved), Queueing (released for work), Working (in progress), Reviewing (awaiting review), Running (complete).
name complete
description Mark a Linear issue as Running after user review. Usage: /complete TEC-123. Dispatches via haiku subagent.

Complete

The user has reviewed the implementation and is satisfied. Mark the issue as Running.

Step 1: Parse Arguments

The first token should be an issue identifier (TEC-123). If not provided, infer from conversation context. If ambiguous, ask.

Step 2: Mark Complete

Use a haiku subagent to:

  1. Move the issue to Running status
  2. If the issue is a subtask, check: are ALL sibling subtasks also Running?
    • If yes → move the parent issue to Running as well
    • If no → leave the parent as-is and inform the user which subtasks remain

Step 3: Confirm

"TEC-123 marked as Running."

If the parent was also completed: "TEC-123 and parent TEC-100 both marked as Running — all subtasks are complete."

If siblings remain: "TEC-123 marked as Running. Parent TEC-100 still has open subtasks: TEC-124, TEC-125."

name handoff
description End-of-session review. Enriches Linear artifacts with insights, updates checklist progress, and saves durable learnings to memory. Use when wrapping up a session before context gets stale.

Handoff

The session is winding down. Review what happened and make sure everything valuable is captured in the right places before the conversation ends.

Step 1: Review the Session

Scan the conversation for:

  • Decisions made — approach choices, design decisions, constraints established
  • Work completed — code written, tests added, files changed
  • Work in progress — tasks started but not finished
  • Insights discovered — things learned about the codebase, patterns, gotchas
  • Open questions — unresolved items that need attention in the next session

Step 2: Update Linear Artifacts

Use a haiku subagent for all Linear writes.

If implementation was in flight:

  • Update checklist progress (check off completed items)
  • If a subtask is partially complete, add a comment noting where work stopped and what remains
  • Do NOT move issues to Reviewing unless the work is actually complete

For all sessions:

  • Post a session summary comment on the primary issue being worked on. Format:
## Session Summary — [date]

### Completed
- [bullet list of what was done]

### In Progress
- [what was started but not finished, and where it stands]

### Decisions
- [any decisions made during this session]

### Next Steps
- [what the next session should pick up]

Enrich related issues:

If insights or decisions apply to other issues (parent, sibling subtasks, related issues), post brief comments on those too.

Step 3: Save Durable Learnings to Memory

If the session revealed anything that would be valuable in future conversations:

  • Codebase insights that aren't obvious from the code → project memory
  • User preferences or workflow corrections → feedback memory
  • External references discovered → reference memory

Only save what's genuinely durable. Don't save ephemeral task state — that lives in Linear.

Step 4: Confirm to User

Summarize what was captured and where:

  • Which Linear issues were updated
  • What was saved to memory (if anything)
  • What the next session should start with

"Session handoff complete. [Issue TEC-xxx] has been updated with progress and a session summary. Next session can pick up with /implement TEC-xxx."

name implement
description Start implementation of a planned issue. Creates subtasks (features) or checklists (tasks), builds a TodoWrite list, and begins coding. Invoke with /implement TEC-123 or just /implement if the target is clear from context.

Implement

Begin implementation of a planned and approved issue. This skill reads the plan, creates the execution scaffolding (subtasks/checklists + TodoWrite), and starts coding.

Step 1: Identify the Target Issue

With an argument (/implement TEC-123):

Fetch the issue with get_issue(id: "TEC-123").

Without an argument (/implement):

Infer the target from conversation context — typically the issue just created or discussed via /plan and /approve. If the target is ambiguous, ask: "Which issue should I implement? I see we've been discussing [X] and [Y]."

Validate readiness:

  • The issue should be in Scheduling or Queueing status. If it's in Planning, ask: "This issue is still in Planning. Should I proceed, or did you want to plan it first with /plan?"
  • The issue should have a plan document attached. If it doesn't, ask: "I don't see a plan document on this issue. Should I proceed without one, or create a plan first?"

Step 2: Move to Working

Move the target issue to Working:

save_issue(id: "<issue-id>", state: "Working")

Promote parent issue if needed:

If the issue is a subtask (has a parent issue), check the parent's status. If the parent is in Planning or Queueing, move it to Working as well.

Use a haiku subagent for these status updates.

Step 3: Read the Plan

Read the plan document attached to the issue. Understand:

  • The objective and approach
  • The implementation steps (and phases, if any)
  • The test strategy
  • Any open questions (raise these with the user before proceeding)

If there's a referenced exploratory document (linked from the issue), read that too for broader context.

Step 4: Build the Execution Scaffolding

Re-read the plan's Implementation Steps. Determine the issue type from its labels.

For issues labeled Task:

Tasks get checklists directly on the issue. No subtasks.

  1. Compose a checklist from the implementation steps. Each item should be concrete and independently verifiable.
  2. Use a haiku subagent to post the checklist as a comment on the issue in this format:
## Implementation Checklist
- [ ] Step 1 description
- [ ] Step 2 description
- [ ] Step 3 description
...

For issues labeled Feature:

Features get subtasks for phases, with checklists on each subtask.

  1. Create a subtask for each phase/major deliverable in the plan:
save_issue(title: "<phase title>", team: "Technologentsia", parentId: "<parent-issue-id>", state: "Queueing")
  1. For the first subtask you're about to work on, read the relevant code and compose a checklist of concrete implementation steps. Post it as a comment on that subtask.

  2. Move the first subtask to Working.

Use a haiku subagent for creating subtasks and posting checklists.

Don't create checklists for future subtasks yet — create them when you pick each one up. This keeps them grounded in code you've actually read.

Create the TodoWrite list:

Build a TodoWrite list from the checklist you just created. This is your session-scoped execution tracker. Include:

  • Every step from the checklist, in execution order
  • A final task: "Verify implementation against plan"

Mark the first task as in_progress.

Step 5: Implement

Begin coding, following the TodoWrite list. As you work:

Progress tracking:

  • Mark TodoWrite tasks complete immediately as you finish each one (don't batch)
  • Periodically dispatch a haiku subagent to check off completed checklist items in Linear (every 2-3 completed items, not after every single one)
  • If you discover the task list needs to change: pause coding, update both the TodoWrite list and the Linear checklist, then continue

Scope discipline:

The plan is scope-locked. You may perform localized code hygiene (formatting, fixing an adjacent typo) but nothing beyond that. If you feel tempted to introduce refactoring that isn't in the plan:

  1. Stop coding
  2. Describe the refactoring, its justification, and its implications
  3. Wait for user approval before continuing

When uncertain:

If you encounter ambiguity or a decision the plan doesn't cover:

  1. Stop coding
  2. Describe the uncertainty concisely
  3. Wait for clarification before continuing

When stuck:

If you hit a blocker:

  1. Use the counselors CLI to explore options that align with the plan
  2. If counselors yields a path forward — take it, but note what happened
  3. If no path aligns with the plan — stop coding, describe the difficulty, and wait for guidance

When deviating:

If you discover the task list must change to successfully implement the plan:

  1. Stop coding
  2. Update your TodoWrite list and the Linear checklist
  3. You may then continue without waiting for confirmation — the updated list is your authorization

Tool selection:

Before each task, briefly consider which tools are highest leverage:

  • Serena LSP for structural navigation and symbol-level edits
  • ColGrep for behavioral/intent queries
  • ast-grep for structural pattern matching
  • Grep for exact text matches

Step 6: Completion

When you believe implementation is complete:

6a. Plan-diff check:

Re-read the original plan document. Compare it against what was implemented. Look for:

  • Gaps — planned steps that weren't executed
  • Deviations — implementation that diverged from the plan
  • Scope creep — work that wasn't in the plan

Remediate any issues before declaring completion.

6b. Finalize Linear artifacts:

Use a haiku subagent to:

  • Check off any remaining checklist items
  • Move the issue (or current subtask) to Reviewing
  • If all subtasks of a feature are complete, move the parent to Reviewing

6c. Post completion summary:

Compose a summary and present it in the conversation AND post it as a comment on the Linear issue (via haiku subagent). The summary should include:

  • What was done — concrete list of changes, files touched
  • Assumptions made — decisions you made without asking
  • Challenges and resolutions — anything that didn't go smoothly, including any use of counselors CLI
  • Insights — anything learned that would be valuable for future work on this codebase, especially guidance that would help other agents working on the project

6d. Confirm to user:

"Implementation is complete and moved to Reviewing. Summary posted above and on the Linear issue. Please review when ready — use /complete TEC-xxx to mark it Running, or /remediate TEC-xxx if there are issues to address."

name plan
description Enter custom planning mode. Locks editing tools, guides thorough codebase exploration, and writes the plan to a Linear document. Invoke with /plan TEC-12, /plan hubble, or just /plan. Supports an optional prompt after the target.

Custom Planning Mode

You are entering planning mode. Your job is to explore thoroughly and think deeply before proposing any implementation. You are NOT allowed to write code until the user explicitly approves your plan.

Step 1: Lock Editing Tools

Run this command immediately to activate the planning gate:

~/.claude/hooks/planning-mode-toggle.sh activate

After running this, confirm to the user: "Planning mode is active. I can explore and read but cannot edit code until you approve the plan."

Step 2: Parse Arguments

Parsing is positional. Use these rules in order — stop at the first match.

Parsing rules:

  1. No arguments (/plan) → ask what to plan.

  2. First token matches issue identifier (XXX-123 — letters, dash, numbers) → issue mode. Fetch the issue with get_issue. Everything after the identifier is the prompt.

  3. First token matches a Linear project name → call list_projects to confirm the match. Everything after the project name is the prompt.

  4. First token matches neither an issue ID nor a known project → treat the entire argument string as a prompt. Call list_projects to check for close matches (typos, slugs). Then ask the user: "Which project does this belong to?"

Examples:

Input Target Prompt
/plan TEC-12 refactor the buffer to use Redis Issue TEC-12 "refactor the buffer to use Redis"
/plan hubble add rate limiting Project hubble "add rate limiting"
/plan hubble Project hubble (none — explore and ask)
/plan add rate limiting to the buffer ask project "add rate limiting to the buffer"
/plan (none) (none — ask everything)

Determining plan placement:

The user tells you where the plan goes and what kind of work this is. Don't assume. If context makes it obvious (e.g., /plan TEC-12 is clearly an issue-level plan), proceed. Otherwise, ask:

  • "Should this be an exploratory document on the project, or a tactical implementation plan on an issue?"

Exploratory plans (project-level documents): Broader explorations, architecture decisions, feature-level thinking that may spawn tasks later. These attach to the Linear project.

Implementation plans (issue-level documents): Tactical plans for specific work. These attach to a Linear issue. If no issue exists yet, you'll create one.

What to do with the prompt:

The prompt is the user's initial direction. It replaces the "ask what to plan" step — you already know what they want. Use it as your starting context alongside any relevant conversation history. You still explore thoroughly; the prompt just gives you a head start.

You are still responsible for the title. The prompt informs your understanding but isn't used verbatim as a title. The title emerges from conversation and exploration.

Resolving projects:

Always call list_projects on Linear to confirm project names. Do not guess or infer from the working directory. Project matching is case-insensitive.

For existing issues (TEC-12):

Fetch the issue with get_issue to understand the task. The issue description plus any prompt is your starting context.

For new implementation plans (create issue + plan):

Use the prompt and conversation to understand what's being planned. Explore the codebase. When writing the plan, also create the issue with save_issue using a title that captures what you learned. Attach the plan doc to that issue.

For exploratory plans (project-level):

Use the prompt and conversation to understand the scope. Explore the codebase. Before creating the document, check for existing documents (see Step 5). Create a plan doc attached to the project.

Step 3: Gather Context

Before exploring the codebase, assess what context you already have. This step is critical — the user may invoke /plan after a long conversation, and relevant discussion should carry forward into the plan.

Context assessment:

  1. Scan the conversation history for content relevant to the plan target. Relevance is determined by the plan target, not by recency — something from an hour ago may be critical, something from 2 minutes ago may be irrelevant.

  2. Look for decisions already made — statements like "let's use Redis for this", "I don't want a new migration", "keep it simple" are constraints that must carry into the plan. Don't re-ask questions the user already answered.

  3. Look for exploration already done — if you already read through files, discussed architecture, or identified patterns during the conversation, reference what you learned rather than re-reading everything.

  4. Look for rejected approaches — if the user said "I don't want to do it that way", don't propose it in the plan.

  5. Ignore unrelated work — if the first half of the conversation was fixing CSS and now the user is planning a new recorder, the CSS discussion isn't context.

  6. When uncertain, briefly state what you're carrying forward — "I'm incorporating our earlier discussion about X and Y. Anything else I should factor in, or anything I should set aside?" Keep this short — don't recite the entire conversation back.

Cold start (no prior conversation context):

If /plan is invoked with minimal context (fresh session, or the conversation so far was about unrelated things):

  • Issue with good description → the issue description is your context, explore from there
  • Plan with no prior discussion → ask 2-3 focused clarifying questions before exploring: What's the scope? What triggered this? Any known constraints?
  • No arguments at all → ask what they want to plan

Step 4: Explore Thoroughly

This is the most important step. Do not rush to write a plan. Your goal is to deeply understand the codebase before proposing anything. However, don't re-explore things you already understand from the conversation context.

Exploration checklist:

  1. Understand the request — What exactly needs to happen? What are the acceptance criteria?
  2. Find existing patterns — How does the codebase handle similar things today? Use Serena LSP (find_symbol, get_symbols_overview, find_referencing_symbols) for structural navigation. Use ColGrep for behavioral/intent queries when you don't know what to search for.
  3. Identify all touchpoints — Which files, classes, methods, configs, tests, and migrations will be affected?
  4. Check for constraints — Are there architectural rules (check ArchTest.php)? Database limitations (SQLite in tests)? Convention requirements?
  5. Look for prior art — Has something similar been attempted before? Are there related TODOs, comments, or partial implementations?
  6. Consider the test strategy — How will this be tested? What fixtures or factories are needed?

Tools you SHOULD use heavily:

  • find_symbol / get_symbols_overview / find_referencing_symbols (Serena LSP)
  • colgrep via Bash (semantic code search)
  • Read (read files thoroughly)
  • Grep / Glob (exact matches, file patterns)
  • Agent with explore subagent (for deep dives)
  • Linear tools (read issues, check related tasks)

Tools you CANNOT use (the hook will block them):

  • Edit — blocked
  • Write — blocked
  • NotebookEdit — blocked

If you try to use them, you'll get a block message. This is intentional.

Step 5: Write the Plan to Linear

Once you've explored enough to have a clear picture, create or update a Linear document with the plan.

Check for existing documents first:

For exploratory plans (project-attached): Before creating a new document, call list_documents(project: "<project>") and scan the titles for anything relevant to what you're planning. If a document looks like it covers the same topic:

  • Ask: "I found [title] on this project. Should I update that document, or create a new one?"
  • If the user says update → use update_document with the existing document's ID
  • If the user says create new → proceed with create_document
  • If nothing matches → create a new document without asking

For implementation plans (issue-attached): Check if the issue already has a plan document. If it does, update it with update_document rather than creating a duplicate. If it doesn't, create a new one.

Creating new plans:

For implementation plans (create issue + plan):

save_issue(title: "<title from conversation>", team: "Technologentsia", project: "<project>", labels: ["Task"])
create_document(issue: "<new issue identifier>", title: "Plan: <brief description>", content: <plan>)

For features, use the Feature label instead of Task.

For exploratory plans (project-attached):

create_document(project: "<project>", title: "Exploration: <brief description>", content: <plan>)

For existing issue plans:

create_document(issue: "TEC-12", title: "Plan: <brief description>", content: <plan>)

Plan document structure:

## Objective
What we're trying to accomplish and why.

## Background
What exists today that's relevant. Key findings from exploration.
Include relevant context from the conversation if applicable.

## Approach
The proposed implementation strategy. Be specific about:
- Which files to create or modify
- Which patterns to follow (reference existing code)
- Key design decisions and why

## Implementation Steps
Numbered steps in the order they should be executed.
Each step should be concrete enough to act on.
Group steps into phases if the work is complex enough to warrant it.

## Test Strategy
How this will be tested. Which test files, what scenarios.

## Open Questions
Anything unresolved that needs input before starting.

After creating or updating the document, share the URL with the user and say:

"Plan is ready for review: [link]. Let me know when you'd like to approve it, suggest changes, or discuss any part of it. Use /approve when you're ready to finalize the artifacts."

Important Behavioral Rules

  1. Do not ask to exit planning mode yourself. Only the user can approve.
  2. Do not try to work around the edit block. The constraint exists to keep you in exploration mode.
  3. Spend more time exploring than you think you need. The whole point of planning mode is to prevent premature coding.
  4. If the user gives feedback on the plan, update the Linear document — you can do this because update_document is not blocked, only code editing tools are.
  5. If you realize the plan is wrong while writing it, go back and explore more. Don't commit to a bad plan just because you started writing.
  6. Honor decisions from the conversation. If the user already expressed preferences, constraints, or rejected approaches during the conversation, respect those in the plan without re-litigating them.
  7. You own the titles. The user doesn't provide issue or document titles — you craft them based on what you learned from the conversation and exploration. Make them clear and specific.
  8. Always resolve projects live. Call list_projects to confirm project names — never guess or infer from the working directory.
#!/bin/bash
# Planning Mode Gate — PreToolUse hook (tested and working)
# Blocks Edit, Write, and NotebookEdit when the current session is in planning mode.
# Planning sessions are tracked in ~/.claude/planning-sessions.json
# Format: ["session-id-1", "session-id-2"]
PLANNING_FILE="$HOME/.claude/planning-sessions.json"
# Read hook input from stdin
input=$(cat)
session_id=$(echo "$input" | jq -r '.session_id')
tool_name=$(echo "$input" | jq -r '.tool_name')
# If no planning file exists, allow everything
if [[ ! -f "$PLANNING_FILE" ]]; then
exit 0
fi
# Check if this session is in planning mode
in_planning=$(jq -r --arg sid "$session_id" 'if type == "array" then map(select(. == $sid)) | length else 0 end' "$PLANNING_FILE" 2>/dev/null)
if [[ "$in_planning" -gt 0 ]]; then
# Session is in planning mode — block editing tools
case "$tool_name" in
Edit|Write|NotebookEdit)
# Output JSON to block the tool with a reason
cat <<'BLOCK'
{"decision":"block","reason":"Planning mode is active. Finish your plan and get approval before editing code. Use /approve to exit planning mode."}
BLOCK
exit 0
;;
esac
fi
# Allow everything else
exit 0
#!/bin/bash
# Planning Mode Toggle — used by /plan and /plan-approve skills
# Usage: planning-mode-toggle.sh activate
# planning-mode-toggle.sh deactivate
ACTION="$1"
PLANNING_FILE="$HOME/.claude/planning-sessions.json"
PROJECT_DIR="$HOME/.claude/projects"
# Find the most recently modified transcript to get session ID
TRANSCRIPT=$(ls -t "$PROJECT_DIR"/*/*.jsonl 2>/dev/null | head -1)
SESSION_ID=$(basename "$TRANSCRIPT" .jsonl)
if [[ -z "$SESSION_ID" ]]; then
echo "ERROR: Could not determine session ID"
exit 1
fi
case "$ACTION" in
activate)
if [[ -f "$PLANNING_FILE" ]]; then
jq --arg sid "$SESSION_ID" 'if index($sid) then . else . + [$sid] end' "$PLANNING_FILE" > /tmp/planning-tmp.json
mv /tmp/planning-tmp.json "$PLANNING_FILE"
else
jq -n --arg sid "$SESSION_ID" '[$sid]' > "$PLANNING_FILE"
fi
echo "✅ Planning mode activated for session $SESSION_ID"
echo "Edit/Write/NotebookEdit tools are now blocked."
;;
deactivate)
if [[ -f "$PLANNING_FILE" ]]; then
jq --arg sid "$SESSION_ID" 'map(select(. != $sid))' "$PLANNING_FILE" > /tmp/planning-tmp.json
mv /tmp/planning-tmp.json "$PLANNING_FILE"
echo "✅ Planning mode deactivated for session $SESSION_ID"
echo "Edit/Write/NotebookEdit tools are now unlocked."
else
echo "⚠️ No planning sessions file found — editing was already unlocked."
fi
;;
*)
echo "Usage: planning-mode-toggle.sh [activate|deactivate]"
exit 1
;;
esac
name release
description Move a planned issue from Scheduling to Queueing, releasing it for implementation. Usage: /release TEC-123. Dispatches via haiku subagent.

Release

Move an approved issue from Scheduling to Queueing, signaling it's released for implementation.

Step 1: Parse Arguments

The first token should be an issue identifier (TEC-123). If not provided, infer from conversation context. If ambiguous, ask.

Step 2: Validate and Move

Use a haiku subagent to:

  1. Fetch the issue and verify it's in Scheduling status
    • If it's in Planning → warn: "TEC-123 is still in Planning. Did you want to plan it first with /plan TEC-123?"
    • If it's already in Queueing or later → inform: "TEC-123 is already in Queueing/Working."
  2. Move the issue to Queueing status

Step 3: Confirm

"TEC-123 released to Queueing and available for implementation. Use /implement TEC-123 to start building."

name remediate
description Send review feedback to a Linear issue. Organizes your brain dump into a structured comment, adds the Remediation label, and moves the issue back to Queueing. Usage: /remediate TEC-123 followed by your feedback.

Remediate

The user has review feedback for an issue. Organize it, post it, and route the issue back for work.

Step 1: Parse Arguments

The first token should be an issue identifier (TEC-123). Everything after it is the user's feedback — a brain dump that may be informal, unstructured, or stream-of-consciousness.

If no issue identifier is provided, check conversation context for the most recently discussed issue. If still ambiguous, ask.

Step 2: Organize the Feedback

Take the user's raw feedback and structure it into a clear, actionable comment. Don't change the meaning — just organize it.

Format:

## Remediation Feedback

### Issues Found
- [each distinct issue as a bullet, with enough context to act on]

### Expected Behavior
- [what the user expects, if stated or implied]

### Additional Context
- [any other details from the feedback that don't fit above]

Omit sections that don't apply (e.g., if there's no "additional context," skip that section).

Step 3: Post and Route

Use a haiku subagent to do all three in one dispatch:

  1. Post the organized comment on the issue
  2. Add the Remediation label to the issue
  3. Move the issue to Queueing status

Step 4: Confirm

Show the user the organized comment you posted (so they can verify it captures their intent), and confirm:

"Feedback posted to TEC-123 and moved to Queueing with Remediation label. This will be prioritized in the next implementation session."

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment