@ai-is-gonna/get-tasks-done 0.2.0

package/commands/gtd/ingest-docs.md

@@ -0,0 +1,42 @@
+---
+name: gtd:ingest-docs
+description: Bootstrap or merge a .planning/ setup from existing ADRs, PRDs, SPECs, and docs in a repo.
+argument-hint: "[path] [--mode new|merge] [--manifest <file>] [--resolve auto|interactive]"
+allowed-tools:
+  - Read
+  - Write
+  - Edit
+  - Bash
+  - Glob
+  - Grep
+  - AskUserQuestion
+  - Agent
+---
+
+<objective>
+Build the full `.planning/` setup (or merge into an existing one) from multiple pre-existing planning documents — ADRs, PRDs, SPECs, DOCs — in one pass.
+
+- **Net-new bootstrap** (`--mode new`, default when `.planning/` is absent): produces PROJECT.md + REQUIREMENTS.md + ROADMAP.md + STATE.md from synthesized doc content, delegating final generation to `gtd-roadmapper`.
+- **Merge into existing** (`--mode merge`, default when `.planning/` is present): appends phases and requirements derived from the ingested docs; hard-blocks any contradiction with existing locked decisions.
+
+Auto-synthesizes most conflicts using the precedence rule `ADR > SPEC > PRD > DOC` (overridable via manifest). Surfaces unresolved cases in `.planning/INGEST-CONFLICTS.md` with three buckets: auto-resolved, competing-variants, unresolved-blockers. The BLOCKER gate from the shared conflict engine prevents any destination file from being written when unresolved contradictions exist.
+
+**Inputs:** directory-convention discovery (`docs/adr/`, `docs/prd/`, `docs/specs/`, `docs/rfc/`, root-level `{ADR,PRD,SPEC,RFC}-*.md`), or an explicit `--manifest <file>` YAML listing `{path, type, precedence?}` per doc.
+
+**v1 constraints:** hard cap of 50 docs per invocation; `--resolve interactive` is reserved for a future release.
+</objective>
+
+<execution_context>
+@~/.claude/get-tasks-done/workflows/ingest-docs.md
+@~/.claude/get-tasks-done/references/ui-brand.md
+@~/.claude/get-tasks-done/references/gate-prompts.md
+@~/.claude/get-tasks-done/references/doc-conflict-engine.md
+</execution_context>
+
+<context>
+$ARGUMENTS
+</context>
+
+<process>
+Execute the ingest-docs workflow end-to-end. Preserve all approval gates (discovery, conflict report, routing) and the BLOCKER safety rule.
+</process>

package/commands/gtd/manager.md

@@ -0,0 +1,45 @@
+---
+name: gtd:manager
+description: Interactive command center for managing multiple phases from one terminal
+argument-hint: "[--analyze-deps]"
+allowed-tools:
+  - Read
+  - Write
+  - Bash
+  - Glob
+  - Grep
+  - AskUserQuestion
+  - Skill
+  - Agent
+requires: [phase]
+---
+<objective>
+Single-terminal command center for managing a milestone. Shows a dashboard of all phases with visual status indicators, recommends optimal next actions, and dispatches work — discuss runs inline, plan/execute run as background agents.
+
+Designed for power users who want to parallelize work across phases from one terminal: discuss a phase while another plans or executes in the background.
+
+**Creates/Updates:**
+- No files created directly — dispatches to existing GTD commands via Skill() and background Task agents.
+- Reads `.planning/STATE.md`, `.planning/ROADMAP.md`, phase directories for status.
+
+**After:** User exits when done managing, or all phases complete and milestone lifecycle is suggested.
+</objective>
+
+<execution_context>
+@~/.claude/get-tasks-done/workflows/manager.md
+@~/.claude/get-tasks-done/references/ui-brand.md
+</execution_context>
+
+<context>
+No arguments required. Requires an active milestone with ROADMAP.md and STATE.md.
+
+Project context, phase list, dependencies, and recommendations are resolved inside the workflow using `gtd-sdk query init.manager`. No upfront context loading needed.
+</context>
+
+<process>
+If `--analyze-deps` is in $ARGUMENTS:
+Read and execute `~/.claude/get-tasks-done/workflows/analyze-dependencies.md` end-to-end.
+
+Execute end-to-end.
+Maintain the dashboard refresh loop until the user exits or all phases complete.
+</process>

package/commands/gtd/map-codebase.md

@@ -0,0 +1,83 @@
+---
+name: gtd:map-codebase
+description: Analyze codebase with parallel mapper agents to produce .planning/codebase/ documents
+argument-hint: "[--fast [--focus tech|arch|quality|concerns]] [--query <term>|status|diff|refresh] [area]"
+allowed-tools:
+  - Read
+  - Bash
+  - Glob
+  - Grep
+  - Write
+  - Agent
+requires: [config, new-project, plan-phase]
+---
+
+<objective>
+Analyze existing codebase using parallel gtd-codebase-mapper agents to produce structured codebase documents.
+
+Each mapper agent explores a focus area and **writes documents directly** to `.planning/codebase/`. The orchestrator only receives confirmations, keeping context usage minimal.
+
+Output: .planning/codebase/ folder with 7 structured documents about the codebase state.
+</objective>
+
+<execution_context>
+@~/.claude/get-tasks-done/workflows/map-codebase.md
+</execution_context>
+
+<flags>
+- **--fast**: Lightweight scan mode — spawns one mapper agent instead of four. Accepts an optional `--focus` value: `tech`, `arch`, `quality`, `concerns`, or `tech+arch` (default). Faster and lower-context than the full map.
+- **--query**: Codebase intelligence query mode. Sub-commands: `query <term>`, `status`, `diff`, `refresh`. Requires intel to be enabled in config (`intel.enabled: true`). Runs inline for query/status/diff; spawns an agent for refresh.
+- **(no flag)**: Full parallel map — spawns 4 mapper agents to produce all 7 codebase documents.
+</flags>
+
+<context>
+Arguments: $ARGUMENTS
+
+Parse the first token of $ARGUMENTS:
+- If it is `--fast`: strip the flag, run the scan workflow (passing remaining args including optional --focus).
+- If it is `--query`: strip the flag, run the intel workflow (passing remaining args as the subcommand).
+- Otherwise: pass all of $ARGUMENTS as focus area to the map-codebase workflow.
+
+**Load project state if exists:**
+Check for .planning/STATE.md - loads context if project already initialized
+
+**This command can run:**
+- Before /gtd:new-project (brownfield codebases) - creates codebase map first
+- After /gtd:new-project (greenfield codebases) - updates codebase map as code evolves
+- Anytime to refresh codebase understanding
+</context>
+
+<when_to_use>
+**Use map-codebase for:**
+- Brownfield projects before initialization (understand existing code first)
+- Refreshing codebase map after significant changes
+- Onboarding to an unfamiliar codebase
+- Before major refactoring (understand current state)
+- When STATE.md references outdated codebase info
+
+**Skip map-codebase for:**
+- Greenfield projects with no code yet (nothing to map)
+- Trivial codebases (<5 files)
+</when_to_use>
+
+<process>
+1. Check if .planning/codebase/ already exists (offer to refresh or skip)
+2. Create .planning/codebase/ directory structure
+3. Spawn 4 parallel gtd-codebase-mapper agents:
+   - Agent 1: tech focus → writes STACK.md, INTEGRATIONS.md
+   - Agent 2: arch focus → writes ARCHITECTURE.md, STRUCTURE.md
+   - Agent 3: quality focus → writes CONVENTIONS.md, TESTING.md
+   - Agent 4: concerns focus → writes CONCERNS.md
+4. Wait for agents to complete, collect confirmations (NOT document contents)
+5. Verify all 7 documents exist with line counts
+6. Commit codebase map
+7. Offer next steps (typically: /gtd:new-project or /gtd:plan-phase)
+</process>
+
+<success_criteria>
+- [ ] .planning/codebase/ directory created
+- [ ] All 7 codebase documents written by mapper agents
+- [ ] Documents follow template structure
+- [ ] Parallel agents completed without errors
+- [ ] User knows next steps
+</success_criteria>

package/commands/gtd/milestone-summary.md

@@ -0,0 +1,51 @@
+---
+type: prompt
+name: gtd:milestone-summary
+description: Generate a comprehensive project summary from milestone artifacts for team onboarding and review
+argument-hint: "[version]"
+allowed-tools:
+  - Read
+  - Write
+  - Bash
+  - Grep
+  - Glob
+---
+
+<objective>
+Generate a structured milestone summary for team onboarding and project review. Reads completed milestone artifacts (ROADMAP, REQUIREMENTS, CONTEXT, SUMMARY, VERIFICATION files) and produces a human-friendly overview of what was built, how, and why.
+
+Purpose: Enable new team members to understand a completed project by reading one document and asking follow-up questions.
+Output: MILESTONE_SUMMARY written to `.planning/reports/`, presented inline, optional interactive Q&A.
+</objective>
+
+<execution_context>
+@~/.claude/get-tasks-done/workflows/milestone-summary.md
+</execution_context>
+
+<context>
+**Project files:**
+- `.planning/ROADMAP.md`
+- `.planning/PROJECT.md`
+- `.planning/STATE.md`
+- `.planning/RETROSPECTIVE.md`
+- `.planning/milestones/v{version}-ROADMAP.md` (if archived)
+- `.planning/milestones/v{version}-REQUIREMENTS.md` (if archived)
+- `.planning/phases/*-*/` (SUMMARY.md, VERIFICATION.md, CONTEXT.md, RESEARCH.md)
+
+**User input:**
+- Version: $ARGUMENTS (optional — defaults to current/latest milestone)
+</context>
+
+<process>
+Execute end-to-end.
+</process>
+
+<success_criteria>
+- Milestone version resolved (from args, STATE.md, or archive scan)
+- All available artifacts read (ROADMAP, REQUIREMENTS, CONTEXT, SUMMARY, VERIFICATION, RESEARCH, RETROSPECTIVE)
+- Summary document written to `.planning/reports/MILESTONE_SUMMARY-v{version}.md`
+- All 7 sections generated (Overview, Architecture, Phases, Decisions, Requirements, Tech Debt, Getting Started)
+- Summary presented inline to user
+- Interactive Q&A offered
+- STATE.md updated
+</success_criteria>

package/commands/gtd/mvp-phase.md

@@ -0,0 +1,45 @@
+---
+name: gtd:mvp-phase
+description: Plan a phase as a vertical MVP slice — user story, SPIDR splitting, then plan-phase
+argument-hint: "<phase-number>"
+allowed-tools:
+  - Read
+  - Write
+  - Bash
+  - Glob
+  - Grep
+  - Agent
+  - AskUserQuestion
+requires: [new-project, phase, plan-phase]
+---
+<objective>
+Guide the user through MVP-mode planning for a phase. The command:
+
+1. Prompts for an "As a / I want to / So that" user story (three structured questions)
+2. Runs SPIDR splitting check — if the story is too large, walks through Spike/Paths/Interfaces/Data/Rules and offers to split into multiple phases
+3. Writes `**Mode:** mvp` and the reformatted `**Goal:**` to the phase's ROADMAP.md section
+4. Delegates to `/gtd plan-phase <N>` which auto-detects MVP mode via the roadmap field
+
+Phase 1 of the vertical-mvp-slice PRD shipped the planner-side machinery; this command is the user entry point for it.
+</objective>
+
+<execution_context>
+@~/.claude/get-tasks-done/workflows/mvp-phase.md
+@~/.claude/get-tasks-done/references/spidr-splitting.md
+@~/.claude/get-tasks-done/references/user-story-template.md
+</execution_context>
+
+<runtime_note>
+**Copilot (VS Code):** Use `vscode_askquestions` wherever this workflow calls `AskUserQuestion`. Equivalent API.
+</runtime_note>
+
+<context>
+Phase number: $ARGUMENTS (required — integer or decimal like `2.1`)
+
+The phase must already exist in ROADMAP.md (created via `/gtd new-project`, `/gtd add-phase`, or `/gtd insert-phase`). This command does not create new phases — it converts an existing phase to MVP mode.
+</context>
+
+<process>
+Execute the mvp-phase workflow from @~/.claude/get-tasks-done/workflows/mvp-phase.md end-to-end.
+Preserve all gates: phase existence, status guard (refuse in_progress/completed), user-story format validation, SPIDR splitting check, ROADMAP write confirmation, plan-phase delegation.
+</process>

package/commands/gtd/new-milestone.md

@@ -0,0 +1,45 @@
+---
+name: gtd:new-milestone
+description: Start a new milestone cycle — update PROJECT.md and route to requirements
+argument-hint: "[milestone name, e.g., 'v1.1 Notifications']"
+allowed-tools:
+  - Read
+  - Write
+  - Bash
+  - Agent
+  - AskUserQuestion
+requires: [new-project, phase, plan-phase]
+---
+<objective>
+Start a new milestone: questioning → research (optional) → requirements → roadmap.
+
+Brownfield equivalent of new-project. Project exists, PROJECT.md has history. Gathers "what's next", updates PROJECT.md, then runs requirements → roadmap cycle.
+
+**Creates/Updates:**
+- `.planning/PROJECT.md` — updated with new milestone goals
+- `.planning/research/` — domain research (optional, NEW features only)
+- `.planning/REQUIREMENTS.md` — scoped requirements for this milestone
+- `.planning/ROADMAP.md` — phase structure (continues numbering)
+- `.planning/STATE.md` — reset for new milestone
+
+**After:** `/gtd:plan-phase [N]` to start execution.
+</objective>
+
+<execution_context>
+@~/.claude/get-tasks-done/workflows/new-milestone.md
+@~/.claude/get-tasks-done/references/questioning.md
+@~/.claude/get-tasks-done/references/ui-brand.md
+@~/.claude/get-tasks-done/templates/project.md
+@~/.claude/get-tasks-done/templates/requirements.md
+</execution_context>
+
+<context>
+Milestone name: $ARGUMENTS (optional - will prompt if not provided)
+
+Project and milestone context files are resolved inside the workflow (`init new-milestone`) and delegated via `<files_to_read>` blocks where subagents are used.
+</context>
+
+<process>
+Execute end-to-end.
+Preserve all workflow gates (validation, questioning, research, requirements, roadmap approval, commits).
+</process>

package/commands/gtd/new-project.md

@@ -0,0 +1,47 @@
+---
+name: gtd:new-project
+description: Initialize a new project with deep context gathering and PROJECT.md
+argument-hint: "[--auto]"
+allowed-tools:
+  - Read
+  - Bash
+  - Write
+  - Agent
+  - AskUserQuestion
+requires: [config, phase, plan-phase]
+---
+<runtime_note>
+**Copilot (VS Code):** Use `vscode_askquestions` wherever this workflow calls `AskUserQuestion`. They are equivalent — `vscode_askquestions` is the VS Code Copilot implementation of the same interactive question API.
+</runtime_note>
+
+<context>
+**Flags:**
+- `--auto` — Automatic mode. After config questions, runs research → requirements → roadmap without further interaction. Expects idea document via @ reference.
+</context>
+
+<objective>
+Initialize a new project through unified flow: questioning → research (optional) → requirements → roadmap.
+
+**Creates:**
+- `.planning/PROJECT.md` — project context
+- `.planning/config.json` — workflow preferences
+- `.planning/research/` — domain research (optional)
+- `.planning/REQUIREMENTS.md` — scoped requirements
+- `.planning/ROADMAP.md` — phase structure
+- `.planning/STATE.md` — project memory
+
+**After this command:** Run `/gtd:plan-phase 1` to start execution.
+</objective>
+
+<execution_context>
+@~/.claude/get-tasks-done/workflows/new-project.md
+@~/.claude/get-tasks-done/references/questioning.md
+@~/.claude/get-tasks-done/references/ui-brand.md
+@~/.claude/get-tasks-done/templates/project.md
+@~/.claude/get-tasks-done/templates/requirements.md
+</execution_context>
+
+<process>
+Execute end-to-end.
+Preserve all workflow gates (validation, approvals, commits, routing).
+</process>

package/commands/gtd/ns-context.md

@@ -0,0 +1,23 @@
+---
+name: gtd-context
+description: "codebase intelligence | map graphify docs learnings"
+argument-hint: ""
+allowed-tools:
+  - Read
+  - Skill
+requires: [map-codebase, graphify, docs-update, extract-learnings]
+---
+
+Route to the appropriate codebase-intelligence skill based on the user's intent.
+`gtd-scan` and `gtd-intel` were folded into `gtd-map-codebase` flags by #2790.
+
+| User wants | Invoke |
+|---|---|
+| Map the full codebase structure | gtd-map-codebase |
+| Quick lightweight codebase scan | gtd-map-codebase --fast |
+| Query mapped intelligence files | gtd-map-codebase --query |
+| Generate a knowledge graph | gtd-graphify |
+| Update project documentation | gtd-docs-update |
+| Extract learnings from a completed phase | gtd-extract-learnings |
+
+Invoke the matched skill directly using the Skill tool.

package/commands/gtd/ns-ideate.md

@@ -0,0 +1,24 @@
+---
+name: gtd-ideate
+description: "exploration capture | explore sketch spike spec capture"
+argument-hint: ""
+allowed-tools:
+  - Read
+  - Skill
+requires: [capture, explore, sketch, spike, spec-phase]
+---
+
+Route to the appropriate exploration / capture skill based on the user's intent.
+`gtd-note`, `gtd-add-todo`, `gtd-add-backlog`, and `gtd-plant-seed` were folded
+into `gtd-capture` (with `--note`, default, `--backlog`, `--seed` modes) by
+#2790. The capture target lists pending todos via `--list`.
+
+| User wants | Invoke |
+|---|---|
+| Explore an idea or opportunity | gtd-explore |
+| Sketch out a rough design or plan | gtd-sketch |
+| Time-boxed technical spike | gtd-spike |
+| Write a spec for a phase | gtd-spec-phase |
+| Capture a thought (todo / note / backlog / seed) | gtd-capture |
+
+Invoke the matched skill directly using the Skill tool.

package/commands/gtd/ns-manage.md

@@ -0,0 +1,28 @@
+---
+name: gtd-manage
+description: "config workspace | workstreams thread update inbox"
+argument-hint: ""
+allowed-tools:
+  - Read
+  - Skill
+requires: [config, workspace, workstreams, thread, pause-work, resume-work, update, inbox, pr-branch, undo]
+---
+
+Route to the appropriate management skill based on the user's intent.
+`gtd-config` (settings + advanced + integrations + profile) and `gtd-workspace`
+(new + list + remove) are post-#2790 consolidated entries.
+
+| User wants | Invoke |
+|---|---|
+| Configure GTD settings (basic / advanced / integrations / profile) | gtd-config |
+| Manage workspaces (create / list / remove) | gtd-workspace |
+| Manage parallel workstreams | gtd-workstreams |
+| Continue work in a fresh context thread | gtd-thread |
+| Pause current work | gtd-pause-work |
+| Resume paused work | gtd-resume-work |
+| Update the GTD installation | gtd-update |
+| Process inbox items | gtd-inbox |
+| Create a clean PR branch | gtd-pr-branch |
+| Undo the last GTD action | gtd-undo |
+
+Invoke the matched skill directly using the Skill tool.

package/commands/gtd/ns-project.md

@@ -0,0 +1,22 @@
+---
+name: gtd-project
+description: "project lifecycle | milestones audits summary"
+argument-hint: ""
+allowed-tools:
+  - Read
+  - Skill
+---
+
+Route to the appropriate project / milestone skill based on the user's intent.
+`gtd-plan-milestone-gaps` was deleted by #2790 — gap planning now happens
+inline as part of `gtd-audit-milestone`'s output.
+
+| User wants | Invoke |
+|---|---|
+| Start a new project | gtd-new-project |
+| Create a new milestone | gtd-new-milestone |
+| Complete the current milestone | gtd-complete-milestone |
+| Audit a milestone for issues | gtd-audit-milestone |
+| Summarize milestone status | gtd-milestone-summary |
+
+Invoke the matched skill directly using the Skill tool.

package/commands/gtd/ns-review.md

@@ -0,0 +1,26 @@
+---
+name: gtd-quality
+description: "quality gates | code review debug audit security eval ui"
+argument-hint: ""
+allowed-tools:
+  - Read
+  - Skill
+requires: [code-review, audit-uat, secure-phase, eval-review, ui-review, validate-phase, debug, forensics]
+---
+
+Route to the appropriate quality / review skill based on the user's intent.
+`gtd-code-review-fix` was absorbed by `gtd-code-review --fix` in #2790.
+
+| User wants | Invoke |
+|---|---|
+| Review code for quality and correctness | gtd-code-review |
+| Auto-fix code review findings | gtd-code-review --fix |
+| Audit UAT / acceptance testing | gtd-audit-uat |
+| Security review of a phase | gtd-secure-phase |
+| Evaluate AI response quality | gtd-eval-review |
+| Review UI for design and accessibility | gtd-ui-review |
+| Validate phase outputs | gtd-validate-phase |
+| Debug a failing feature or error | gtd-debug |
+| Forensic investigation of a broken system | gtd-forensics |
+
+Invoke the matched skill directly using the Skill tool.

package/commands/gtd/ns-workflow.md

@@ -0,0 +1,30 @@
+---
+name: gtd-workflow
+description: "workflow | discuss plan tasks verify phase progress"
+argument-hint: ""
+allowed-tools:
+  - Read
+  - Skill
+requires: [discuss-phase, spec-phase, plan-phase, export-phase-issues, work-task-issue, orchestrate-tasks, verify-work, phase, progress, ultraplan-phase, plan-review-convergence]
+---
+
+Route to the appropriate phase-pipeline skill based on the user's intent.
+Sub-skill names below are post-#2790 consolidated targets — `gtd-phase`
+absorbs the former add/insert/remove/edit-phase commands and `gtd-progress`
+absorbs the former next/do commands.
+
+| User wants | Invoke |
+|---|---|
+| Gather context before planning | gtd-discuss-phase |
+| Clarify what a phase delivers | gtd-spec-phase |
+| Create a PLAN.md | gtd-plan-phase |
+| Export planned tasks to GitHub issues | gtd-export-phase-issues |
+| Work one exported task issue or finalize a completed phase with `--complete-phase <phase> --execute` | gtd-work-task-issue |
+| Orchestrate multiple exported task issues through a bulk branch and comprehensive PR | gtd-orchestrate-tasks |
+| Verify built features through UAT | gtd-verify-work |
+| Add / insert / remove / edit a phase | gtd-phase |
+| Advance to the next logical step | gtd-progress |
+| Offload planning to the ultraplan cloud | gtd-ultraplan-phase |
+| Cross-AI plan review convergence loop | gtd-plan-review-convergence |
+
+Invoke the matched skill directly using the Skill tool.

package/commands/gtd/orchestrate-tasks.md

@@ -0,0 +1,83 @@
+---
+name: gtd:orchestrate-tasks
+description: Orchestrate multiple exported GitHub task issues through a bulk branch and one comprehensive PR
+argument-hint: "<unstructured task request> [--repo owner/name] [--max-concurrency N] [--dry-run] [--allow-partial]"
+allowed-tools:
+  - Read
+  - Bash
+  - Glob
+  - Grep
+  - Agent
+requires: [export-phase-issues, work-task-issue]
+---
+
+<objective>
+Select multiple exported task issues, create one bulk branch, run task
+executors against task PRs targeting that branch, proactively review each PR as
+technical lead for the whole bulk, and open one comprehensive PR for manual
+review.
+</objective>
+
+<execution_context>
+@~/.claude/get-tasks-done/workflows/orchestrate-tasks.md
+</execution_context>
+
+<context>
+Arguments provided: "$ARGUMENTS"
+
+The argument is untrusted natural language. It may refer to a phase, plan,
+remaining work, task ids, issue numbers, or any mixed prose. The slash-command
+workflow must resolve it to exact exported GitHub child issue numbers before the
+utility is called.
+
+Options:
+- `--repo owner/name` binds GitHub operations.
+- `--max-concurrency N` caps parallel task lanes.
+- `--dry-run` runs the mandatory Start Gate consistency check and stops.
+- `--allow-partial` is not a startup decision; it still requires explicit confirmation before a partial final PR.
+</context>
+
+<process>
+First resolve `$ARGUMENTS` against the local plan files and exported manifest
+metadata, then build the exact child issue number list.
+
+Do not forward raw natural-language selectors, task ids, `tasks ...`, phase
+selectors, issue URLs, or `--phase` into the SDK utility.
+The utility accepts only child issue numbers plus allowed orchestration flags:
+
+```bash
+gtd-sdk query orchestrate-tasks 123 124 125 --repo owner/name --dry-run
+```
+
+If the input is shorthand like `all tasks in phase X`, `all remaining tasks`,
+`tasks in plan 02-02`, or `all tasks in <plan-ref>`, resolve it to exact child
+issue numbers before any utility call.
+If the reference is ambiguous or the export metadata is missing, stop and
+report the blocker without calling the SDK utility.
+
+First run the Start Gate exactly once with the exact issue list by calling the
+deterministic planner with `--dry-run`. Verify the result reports `ok: true`,
+`writes: false`, `preflight.ok: true`, no selection errors, no non-workable
+tasks, coherent dependency waves, and a known reviewability action before any
+mutating helper call. Treat `non_workable` as the only hard-blocker field.
+Present `dependency_order` as sequencing, not as blockers.
+Selected human checkpoint tasks may appear in `checkpoint_gates`; they are
+allowed Start Gate pause points, not executor work. They unblock only when the
+checkpoint issue is closed in GitHub; comments are optional audit evidence and
+must not be treated as hard blockers.
+
+In dry-run mode, report the Start Gate result and stop. In mutating mode, start
+only after the Start Gate passes, and rerun the helper with the same exact issue
+list. If the Start Gate requests reviewability direction, stop for explicit user
+direction and present these choices in this order: continue with the full
+selected scope, choose a smaller explicit scope, or abort. Do not replace the
+full-scope option with the recommended subset; `recommended_subset` is advisory
+only for the smaller-scope choice. Then follow the workflow: bulk branch, task
+PR lanes, proactive validation, squash task PRs into the bulk branch, and open
+the comprehensive PR.
+
+When checkpoint-paused output includes `user_next_step`, present that message to
+the user. The user-facing action is to complete and close the checkpoint issue,
+then tell the agent to continue; do not ask the user to run internal helper
+commands.
+</process>

package/commands/gtd/pause-work.md

@@ -0,0 +1,43 @@
+---
+name: gtd:pause-work
+description: Create context handoff when pausing work mid-phase
+argument-hint: "[--report]"
+allowed-tools:
+  - Read
+  - Write
+  - Bash
+requires: [phase, progress]
+---
+
+<objective>
+Create `.continue-here.md` handoff file to preserve complete work state across sessions.
+
+Routes to the pause-work workflow which handles:
+- Current phase detection from recent files
+- Complete state gathering (position, completed work, remaining work, decisions, blockers)
+- Handoff file creation with all context sections
+- Git commit as WIP
+- Resume instructions
+</objective>
+
+<execution_context>
+@~/.claude/get-tasks-done/workflows/pause-work.md
+</execution_context>
+
+<context>
+State and phase progress are gathered in-workflow with targeted reads.
+</context>
+
+<process>
+If `--report` is in $ARGUMENTS:
+Read and execute `~/.claude/get-tasks-done/workflows/session-report.md` end-to-end.
+
+**Follow the pause-work workflow**.
+
+The workflow handles all logic including:
+1. Phase directory detection
+2. State gathering with user clarifications
+3. Handoff file writing with timestamp
+4. Git commit
+5. Confirmation with resume instructions
+</process>