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

package/get-tasks-done/workflows/new-workspace.md

@@ -0,0 +1,239 @@
+<purpose>
+Create an isolated workspace directory with git repo copies (worktrees or clones) and an independent `.planning/` directory. Supports multi-repo orchestration and single-repo feature branch isolation.
+</purpose>
+
+<required_reading>
+Read all files referenced by the invoking prompt's execution_context before starting.
+</required_reading>
+
+<process>
+
+## 1. Setup
+
+**MANDATORY FIRST STEP — Execute init command:**
+
+```bash
+INIT=$(gtd-sdk query init.new-workspace)
+if [[ "$INIT" == @file:* ]]; then INIT=$(cat "${INIT#@file:}"); fi
+```
+
+Parse JSON for: `default_workspace_base`, `child_repos`, `child_repo_count`, `worktree_available`, `is_git_repo`, `cwd_repo_name`, `project_root`.
+
+## 2. Parse Arguments
+
+Extract from $ARGUMENTS:
+- `--name` → `WORKSPACE_NAME` (required)
+- `--repos` → `REPO_LIST` (comma-separated paths or names)
+- `--path` → `TARGET_PATH` (defaults to `$default_workspace_base/$WORKSPACE_NAME`)
+- `--strategy` → `STRATEGY` (defaults to `worktree`)
+- `--branch` → `BRANCH_NAME` (defaults to `workspace/$WORKSPACE_NAME`)
+- `--auto` → skip interactive questions
+
+**If `--name` is missing and not `--auto`:**
+
+
+**Text mode (`workflow.text_mode: true` in config or `--text` flag):** Set `TEXT_MODE=true` if `--text` is present in `$ARGUMENTS` OR `text_mode` from init JSON is `true`. When TEXT_MODE is active, replace every `AskUserQuestion` call with a plain-text numbered list and ask the user to type their choice number. This is required for non-Claude runtimes (OpenAI Codex, Gemini CLI, etc.) where `AskUserQuestion` is not available.
+Use AskUserQuestion:
+- header: "Workspace Name"
+- question: "What should this workspace be called?"
+- requireAnswer: true
+
+## 3. Select Repos
+
+**If `--repos` is provided:** Parse comma-separated values. For each value:
+- If it's an absolute path, use it directly
+- If it's a relative path or name, resolve against `$project_root`
+- Special case: `.` means current repo (use `$project_root`, name it `$cwd_repo_name`)
+
+**If `--repos` is NOT provided and not `--auto`:**
+
+**If `child_repo_count` > 0:**
+
+Present child repos for selection:
+
+Use AskUserQuestion:
+- header: "Select Repos"
+- question: "Which repos should be included in the workspace?"
+- options: List each child repo from `child_repos` array by name
+- multiSelect: true
+
+**If `child_repo_count` is 0 and `is_git_repo` is true:**
+
+Use AskUserQuestion:
+- header: "Current Repo"
+- question: "No child repos found. Create a workspace with the current repo?"
+- options:
+  - "Yes — create workspace with current repo" → use current repo
+  - "Cancel" → exit
+
+**If `child_repo_count` is 0 and `is_git_repo` is false:**
+
+Error:
+```
+No git repos found in the current directory and this is not a git repo.
+
+Run this command from a directory containing git repos, or specify repos explicitly:
+  /gtd:workspace --new --name my-workspace --repos /path/to/repo1,/path/to/repo2
+```
+Exit.
+
+**If `--auto` and `--repos` is NOT provided:**
+
+Error:
+```
+Error: --auto requires --repos to specify which repos to include.
+
+Usage:
+  /gtd:workspace --new --name my-workspace --repos repo1,repo2 --auto
+```
+Exit.
+
+## 4. Select Strategy
+
+**If `--strategy` is provided:** Use it (validate: must be `worktree` or `clone`).
+
+**If `--strategy` is NOT provided and not `--auto`:**
+
+Use AskUserQuestion:
+- header: "Strategy"
+- question: "How should repos be copied into the workspace?"
+- options:
+  - "Worktree (recommended) — lightweight, shares .git objects with source repo" → `worktree`
+  - "Clone — fully independent copy, no connection to source repo" → `clone`
+
+**If `--auto`:** Default to `worktree`.
+
+## 5. Validate
+
+Before creating anything, validate:
+
+1. **Target path** — must not exist or must be empty:
+```bash
+if [ -d "$TARGET_PATH" ] && [ "$(ls -A "$TARGET_PATH" 2>/dev/null)" ]; then
+  echo "Error: Target path already exists and is not empty: $TARGET_PATH"
+  echo "Choose a different --name or --path."
+  exit 1
+fi
+```
+
+2. **Source repos exist and are git repos** — for each repo path:
+```bash
+if [ ! -d "$REPO_PATH/.git" ]; then
+  echo "Error: Not a git repo: $REPO_PATH"
+  exit 1
+fi
+```
+
+3. **Worktree availability** — if strategy is `worktree` and `worktree_available` is false:
+```
+Error: git is not available. Install git or use --strategy clone.
+```
+
+Report all validation errors at once, not one at a time.
+
+## 6. Create Workspace
+
+```bash
+mkdir -p "$TARGET_PATH"
+```
+
+### For each repo:
+
+**Worktree strategy:**
+```bash
+cd "$SOURCE_REPO_PATH"
+git worktree add "$TARGET_PATH/$REPO_NAME" -b "$BRANCH_NAME" 2>&1
+```
+
+If `git worktree add` fails because the branch already exists, try with a timestamped branch:
+```bash
+TIMESTAMP=$(date +%Y%m%d%H%M%S)
+git worktree add "$TARGET_PATH/$REPO_NAME" -b "${BRANCH_NAME}-${TIMESTAMP}" 2>&1
+```
+
+If that also fails, report the error and continue with remaining repos.
+
+**Clone strategy:**
+```bash
+git clone "$SOURCE_REPO_PATH" "$TARGET_PATH/$REPO_NAME" 2>&1
+cd "$TARGET_PATH/$REPO_NAME"
+git checkout -b "$BRANCH_NAME" 2>&1
+```
+
+Track results: which repos succeeded, which failed, what branch was used.
+
+## 7. Write WORKSPACE.md
+
+Write the workspace manifest at `$TARGET_PATH/WORKSPACE.md`:
+
+```markdown
+# Workspace: $WORKSPACE_NAME
+
+Created: $DATE
+Strategy: $STRATEGY
+
+## Member Repos
+
+| Repo | Source | Branch | Strategy |
+|------|--------|--------|----------|
+| $REPO_NAME | $SOURCE_PATH | $BRANCH | $STRATEGY |
+...for each repo...
+
+## Notes
+
+[Add context about what this workspace is for]
+```
+
+## 8. Initialize .planning/
+
+```bash
+mkdir -p "$TARGET_PATH/.planning"
+```
+
+## 9. Report and Next Steps
+
+**If all repos succeeded:**
+
+```
+Workspace created: $TARGET_PATH
+
+  Repos: $REPO_COUNT
+  Strategy: $STRATEGY
+  Branch: $BRANCH_NAME
+
+Next steps:
+  cd "$TARGET_PATH"
+  /gtd:new-project    # Initialize GTD in the workspace
+```
+
+**If some repos failed:**
+
+```
+Workspace created with $SUCCESS_COUNT of $TOTAL_COUNT repos: $TARGET_PATH
+
+  Succeeded: repo1, repo2
+  Failed: repo3 (branch already exists), repo4 (not a git repo)
+
+Next steps:
+  cd "$TARGET_PATH"
+  /gtd:new-project    # Initialize GTD in the workspace
+```
+
+**Offer to initialize GTD (if not `--auto`):**
+
+Use AskUserQuestion:
+- header: "Initialize GTD"
+- question: "Would you like to initialize a GTD project in the new workspace?"
+- options:
+  - "Yes — run /gtd:new-project" → tell user to `cd "$TARGET_PATH"` first, then run `/gtd:new-project`
+  - "No — I'll set it up later" → done
+
+</process>
+
+<success_criteria>
+- [ ] Workspace directory created at target path
+- [ ] All specified repos copied (worktree or clone) into workspace
+- [ ] WORKSPACE.md manifest written with correct repo table
+- [ ] `.planning/` directory initialized at workspace root
+- [ ] User informed of workspace path and next steps
+</success_criteria>

package/get-tasks-done/workflows/next.md

@@ -0,0 +1,220 @@
+<purpose>
+Detect current project state and automatically advance to the next logical GTD workflow step.
+Reads project state to determine: discuss → plan → execute → verify → complete progression.
+</purpose>
+
+<required_reading>
+Read all files referenced by the invoking prompt's execution_context before starting.
+</required_reading>
+
+<process>
+
+<step name="detect_state">
+Read project state to determine current position:
+
+```bash
+# Get state snapshot
+gtd-sdk query state.json 2>/dev/null || echo "{}"
+```
+
+Also read:
+- `.planning/STATE.md` — current phase, progress, plan counts
+- `.planning/ROADMAP.md` — milestone structure and phase list
+
+Extract:
+- `current_phase` — which phase is active
+- `plan_of` / `plans_total` — plan execution progress
+- `progress` — overall percentage
+- `status` — active, paused, etc.
+
+If no `.planning/` directory exists:
+```
+No GTD project detected. Run `/gtd:new-project` to get started.
+```
+Exit.
+</step>
+
+<step name="safety_gates">
+Run hard-stop checks before routing. Exit on first hit unless `--force` was passed.
+
+If `--force` flag was passed, skip all gates and the consecutive guard.
+Print a one-line warning: `⚠ --force: skipping safety gates`
+Then proceed directly to `determine_next_action`.
+
+**Gate 1: Unresolved checkpoint**
+Check if `.planning/.continue-here.md` exists:
+```bash
+[ -f .planning/.continue-here.md ]
+```
+If found:
+```
+⛔ Hard stop: Unresolved checkpoint
+
+`.planning/.continue-here.md` exists — a previous session left
+unfinished work that needs manual review before advancing.
+
+Read the file, resolve the issue, then delete it to continue.
+Use `--force` to bypass this check.
+```
+Exit (do not route).
+
+**Gate 2: Error state**
+Check if STATE.md contains `status: error` or `status: failed`:
+If found:
+```
+⛔ Hard stop: Project in error state
+
+STATE.md shows status: {status}. Resolve the error before advancing.
+Run `/gtd:health` to diagnose, or manually fix STATE.md.
+Use `--force` to bypass this check.
+```
+Exit.
+
+**Gate 3: Unchecked verification**
+Check if the current phase has a VERIFICATION.md with any `FAIL` items that don't have overrides:
+If found:
+```
+⛔ Hard stop: Unchecked verification failures
+
+VERIFICATION.md for phase {N} has {count} unresolved FAIL items.
+Address the failures or add overrides before advancing to the next phase.
+Use `--force` to bypass this check.
+```
+Exit.
+
+**Prior-phase completeness scan:**
+After passing all three hard-stop gates, scan all phases that precede the current phase in ROADMAP.md order for incomplete work. For each prior phase number `N`, use `gtd-sdk query find-phase <N>` JSON (plans, summaries, incomplete_plans, etc.) to inspect that phase.
+
+Detect three categories of incomplete work:
+1. **Plans without summaries** — a PLAN.md exists in a prior phase directory but no matching SUMMARY.md exists (execution started but not completed).
+2. **Verification failures not overridden** — a prior phase has a VERIFICATION.md with `FAIL` items that have no override annotation.
+3. **CONTEXT.md without plans** — a prior phase directory has a CONTEXT.md but no PLAN.md files (discussion happened, planning never ran).
+
+If no incomplete prior work is found, continue to `determine_next_action` silently with no interruption.
+
+If incomplete prior work is found, show a structured completeness report:
+```
+⚠ Prior phase has incomplete work
+
+Phase {N} — "{name}" has unresolved items:
+  • Plan {N}-{M} ({slug}): executed but no SUMMARY.md
+  [... additional items ...]
+
+Advancing before resolving these may cause:
+  • Verification gaps — future phase verification won't have visibility into what prior phases shipped
+  • Context loss — plans that ran without summaries leave no record for future agents
+
+Options:
+  [C] Continue and defer these items to backlog
+  [S] Stop and resolve manually (recommended)
+  [F] Force advance without recording deferral
+
+Choice [S]:
+```
+
+**If the user chooses "Stop" (S or Enter/default):** Exit without routing.
+
+**If the user chooses "Continue and defer" (C):**
+1. For each incomplete item, create a backlog entry in `ROADMAP.md` under `## Backlog` using the existing `999.x` numbering scheme:
+```markdown
+### Phase 999.{N}: Follow-up — Phase {src} incomplete plans (BACKLOG)
+
+**Goal:** Resolve plans that ran without producing summaries during Phase {src} execution
+**Source phase:** {src}
+**Deferred at:** {date} during /gtd:progress --next advancement to Phase {dest}
+**Plans:**
+- [ ] {N}-{M}: {slug} (ran, no SUMMARY.md)
+```
+2. Commit the deferral record:
+```bash
+gtd-sdk query commit "docs: defer incomplete Phase {src} items to backlog"
+```
+3. Continue routing to `determine_next_action` immediately — no second prompt.
+
+**If the user chooses "Force" (F):** Continue to `determine_next_action` without recording deferral.
+</step>
+
+<step name="spike_sketch_notice">
+Check for pending spike/sketch work and surface a notice (does not change routing):
+
+```bash
+# Check for pending spikes (verdict: PENDING in any README)
+PENDING_SPIKES=$(grep -rl 'verdict: PENDING' .planning/spikes/*/README.md 2>/dev/null | wc -l | tr -d ' ')
+
+# Check for pending sketches (winner: null in any README)
+PENDING_SKETCHES=$(grep -rl 'winner: null' .planning/sketches/*/README.md 2>/dev/null | wc -l | tr -d ' ')
+```
+
+If either count is > 0, display before routing:
+```
+⚠ Pending exploratory work:
+  {PENDING_SPIKES} spike(s) with unresolved verdicts in .planning/spikes/
+  {PENDING_SKETCHES} sketch(es) without a winning variant in .planning/sketches/
+
+  Resume with `/gtd:spike` or `/gtd:sketch`, or continue with phase work below.
+```
+
+Only show lines for non-zero counts. If both are 0, skip this notice entirely.
+</step>
+
+<step name="determine_next_action">
+Apply routing rules based on state:
+
+**Route 1: No phases exist yet → discuss**
+If ROADMAP has phases but no phase directories exist on disk:
+→ Next action: `/gtd:discuss-phase <first-phase>`
+
+**Route 2: Phase exists but has no CONTEXT.md or RESEARCH.md → discuss**
+If the current phase directory exists but has neither CONTEXT.md nor RESEARCH.md:
+→ Next action: `/gtd:discuss-phase <current-phase>`
+
+**Route 3: Phase has context but no plans → plan**
+If the current phase has CONTEXT.md (or RESEARCH.md) but no PLAN.md files:
+→ Next action: `/gtd:plan-phase <current-phase>`
+
+**Route 4: Phase has plans but incomplete summaries → execute**
+If plans exist but not all have matching summaries:
+→ Next action: `/gtd:work-task-issue --phase <current-phase>`
+
+**Route 5: All plans have summaries → verify and complete**
+If all plans in the current phase have summaries:
+→ Next action: `/gtd:verify-work`
+
+**Route 6: Phase complete, next phase exists → advance**
+If the current phase is complete and the next phase exists in ROADMAP:
+→ Next action: `/gtd:discuss-phase <next-phase>`
+
+**Route 7: All phases complete → complete milestone**
+If all phases are complete:
+→ Next action: `/gtd:complete-milestone`
+
+**Route 8: Paused → resume**
+If STATE.md shows paused_at:
+→ Next action: `/gtd:resume-work`
+</step>
+
+<step name="show_and_execute">
+Display the determination:
+
+```
+## GTD Next
+
+**Current:** Phase [N] — [name] | [progress]%
+**Status:** [status description]
+
+▶ **Next step:** `/gtd-[command] [args]`
+  [One-line explanation of why this is the next step]
+```
+
+Then immediately invoke the determined command via SlashCommand.
+Do not ask for confirmation — the whole point of `/gtd:progress --next` is zero-friction advancement.
+</step>
+
+</process>
+
+<success_criteria>
+- [ ] Project state correctly detected
+- [ ] Next action correctly determined from routing rules
+- [ ] Command invoked immediately without user confirmation
+- [ ] Clear status shown before invoking
+</success_criteria>

package/get-tasks-done/workflows/node-repair.md

@@ -0,0 +1,92 @@
+<purpose>
+Autonomous repair operator for failed task verification. Invoked by task execution when a task fails its done-criteria. Proposes and attempts structured fixes before escalating to the user.
+</purpose>
+
+<inputs>
+- FAILED_TASK: Task number, name, and done-criteria from the plan
+- ERROR: What verification produced — actual result vs expected
+- PLAN_CONTEXT: Adjacent tasks and phase goal (for constraint awareness)
+- REPAIR_BUDGET: Max repair attempts remaining (default: 2)
+</inputs>
+
+<repair_directive>
+Analyze the failure and choose exactly one repair strategy:
+
+**RETRY** — The approach was right but execution failed. Try again with a concrete adjustment.
+- Use when: command error, missing dependency, wrong path, env issue, transient failure
+- Output: `RETRY: [specific adjustment to make before retrying]`
+
+**DECOMPOSE** — The task is too coarse. Break it into smaller verifiable sub-steps.
+- Use when: done-criteria covers multiple concerns, implementation gaps are structural
+- Output: `DECOMPOSE: [sub-task 1] | [sub-task 2] | ...` (max 3 sub-tasks)
+- Sub-tasks must each have a single verifiable outcome
+
+**PRUNE** — The task is infeasible given current constraints. Skip with justification.
+- Use when: prerequisite missing and not fixable here, out of scope, contradicts an earlier decision
+- Output: `PRUNE: [one-sentence justification]`
+
+**ESCALATE** — Repair budget exhausted, or this is an architectural decision (Rule 4).
+- Use when: RETRY failed more than once with different approaches, or fix requires structural change
+- Output: `ESCALATE: [what was tried] | [what decision is needed]`
+</repair_directive>
+
+<process>
+
+<step name="diagnose">
+Read the error and done-criteria carefully. Ask:
+1. Is this a transient/environmental issue? → RETRY
+2. Is the task verifiably too broad? → DECOMPOSE
+3. Is a prerequisite genuinely missing and unfixable in scope? → PRUNE
+4. Has RETRY already been attempted with this task? Check REPAIR_BUDGET. If 0 → ESCALATE
+</step>
+
+<step name="execute_retry">
+If RETRY:
+1. Apply the specific adjustment stated in the directive
+2. Re-run the task implementation
+3. Re-run verification
+4. If passes → continue normally, log `[Node Repair - RETRY] Task [X]: [adjustment made]`
+5. If fails again → decrement REPAIR_BUDGET, re-invoke node-repair with updated context
+</step>
+
+<step name="execute_decompose">
+If DECOMPOSE:
+1. Replace the failed task inline with the sub-tasks (do not modify PLAN.md on disk)
+2. Execute sub-tasks sequentially, each with its own verification
+3. If all sub-tasks pass → treat original task as succeeded, log `[Node Repair - DECOMPOSE] Task [X] → [N] sub-tasks`
+4. If a sub-task fails → re-invoke node-repair for that sub-task (REPAIR_BUDGET applies per sub-task)
+</step>
+
+<step name="execute_prune">
+If PRUNE:
+1. Mark task as skipped with justification
+2. Log to SUMMARY "Issues Encountered": `[Node Repair - PRUNE] Task [X]: [justification]`
+3. Continue to next task
+</step>
+
+<step name="execute_escalate">
+If ESCALATE:
+1. Surface to user via verification_failure_gate with full repair history
+2. Present: what was tried (each RETRY/DECOMPOSE attempt), what the blocker is, options available
+3. Wait for user direction before continuing
+</step>
+
+</process>
+
+<logging>
+All repair actions must appear in SUMMARY.md under "## Deviations from Plan":
+
+| Type | Format |
+|------|--------|
+| RETRY success | `[Node Repair - RETRY] Task X: [adjustment] — resolved` |
+| RETRY fail → ESCALATE | `[Node Repair - RETRY] Task X: [N] attempts exhausted — escalated to user` |
+| DECOMPOSE | `[Node Repair - DECOMPOSE] Task X split into [N] sub-tasks — all passed` |
+| PRUNE | `[Node Repair - PRUNE] Task X skipped: [justification]` |
+</logging>
+
+<constraints>
+- REPAIR_BUDGET defaults to 2 per task. Configurable via config.json `workflow.node_repair_budget`.
+- Never modify PLAN.md on disk — decomposed sub-tasks are in-memory only.
+- DECOMPOSE sub-tasks must be more specific than the original, not synonymous rewrites.
+- If config.json `workflow.node_repair` is `false`, skip directly to verification_failure_gate (user retains original behavior).
+</constraints>