@jokerized/getresearchdone 0.4.1

package/commands/reapply-patches.md

@@ -0,0 +1,154 @@
+---
+description: Reapply local modifications after a GRD update
+argument-hint: ""
+allowed-tools: Read, Write, Edit, Bash, Glob, Grep, AskUserQuestion
+---
+
+<purpose>
+Restore user-modified files after a GRD update. Reads backed-up files from
+grd-local-patches/, compares with newly installed versions, and intelligently
+merges or presents conflicts for resolution.
+</purpose>
+
+<context>
+CLAUDE.md rules: @CLAUDE.md
+Plugin root: ${CLAUDE_PLUGIN_ROOT}
+</context>
+
+<process>
+
+## Step 1: CHECK FOR PATCHES
+
+```bash
+cd "${CLAUDE_PLUGIN_ROOT}" && node bin/grd-manifest.js load-patches
+```
+
+Parse JSON output. If `found` is false:
+```
+No local patches found.
+
+Patches are created automatically during /grd:update when local modifications exist.
+Nothing to reapply.
+```
+Exit.
+
+## Step 2: DISPLAY PATCH SUMMARY
+
+Read backup metadata from `grd-local-patches/backup-meta.json`.
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+ GRD PATCH RESTORE
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+  Backed up from: v{from_version}
+  Backup date:    {timestamp}
+  Files:          {count}
+```
+
+## Step 3: ANALYZE EACH PATCH
+
+For each file in the backup:
+
+1. Read the backed-up version (user's modified file) from `grd-local-patches/{file}`
+2. Read the newly installed version from `${CLAUDE_PLUGIN_ROOT}/{file}`
+3. Compare the two:
+
+**Case A — Identical:** Upstream incorporated the user's change. Mark as SKIP.
+
+**Case B — Different:** User's modification differs from new version. Needs merge.
+
+**Case C — File deleted upstream:** The file no longer exists in new version.
+
+Display analysis table:
+
+```
+  | # | File                       | Status   | Action    |
+  |---|----------------------------|----------|-----------|
+  | 1 | commands/execute-phase.md  | DIFFERS  | Merge     |
+  | 2 | agents/grd-executor.md     | SAME     | Skip      |
+  | 3 | commands/old-command.md    | DELETED  | Ask user  |
+```
+
+## Step 4: PROCESS EACH FILE
+
+For files marked **Merge**:
+
+1. Read both versions fully
+2. Identify the user's specific modifications (diff the backed-up version against the original pre-update version if available, otherwise diff against new version)
+3. Apply user's modifications to the new version using Edit tool
+4. If changes are in non-overlapping regions: apply automatically
+5. If changes overlap (conflict): present both versions to user
+
+For conflicts, use AskUserQuestion:
+- header: "{filename}"
+- question: "Conflict in {file}. Which version to keep?"
+- options:
+  - "Keep my version" — Use the backed-up (user's) version
+  - "Use new version" — Accept the upstream changes
+  - "Show diff" — Display both versions for manual resolution
+
+**If "Show diff":** Display side-by-side comparison of the conflicting section, then re-ask.
+
+For files marked **DELETED upstream**:
+- Use AskUserQuestion to ask if user wants to keep their version as a custom file
+
+## Step 5: REGENERATE MANIFEST
+
+After all patches are processed:
+```bash
+cd "${CLAUDE_PLUGIN_ROOT}" && node bin/grd-manifest.js generate
+```
+
+## Step 6: CLEANUP
+
+Use AskUserQuestion:
+- header: "Cleanup"
+- question: "Remove patch backup directory?"
+- options:
+  - "Yes, clean up (Recommended)" — Delete grd-local-patches/
+  - "Keep backups" — Preserve grd-local-patches/ for reference
+
+**If "Yes, clean up":**
+```bash
+rm -rf "${CLAUDE_PLUGIN_ROOT}/grd-local-patches"
+```
+
+## Step 7: DISPLAY RESULT
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+ PATCHES APPLIED
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+  Applied:  {N} file(s)
+  Skipped:  {M} file(s) (already incorporated upstream)
+  Conflicts resolved: {K}
+
+  Manifest regenerated with merged hashes.
+```
+
+</process>
+
+<output>
+Modified files restored. Manifest regenerated with current hashes.
+Patch directory optionally cleaned up.
+</output>
+
+<error_handling>
+- **No patches found**: Inform user, suggest running /grd:update first
+- **Backed-up file corrupted**: Skip file, report to user
+- **Cannot resolve conflict automatically**: Present to user for manual resolution
+- **Manifest generation fails**: Report error, suggest manual `node bin/grd-manifest.js generate`
+</error_handling>
+
+<success_criteria>
+- [ ] Patch backup found and loaded
+- [ ] Summary table displayed with status per file
+- [ ] Identical files skipped (upstream incorporated change)
+- [ ] Different files merged or presented for resolution
+- [ ] Conflicts resolved with user input
+- [ ] Manifest regenerated after all patches applied
+- [ ] Cleanup offered and executed if chosen
+- [ ] Final report displayed
+</success_criteria>

package/commands/remove-phase.md

@@ -0,0 +1,97 @@
+---
+description: Remove an unstarted phase from the roadmap and renumber subsequent phases
+argument-hint: <phase number>
+---
+
+<purpose>
+Remove an unstarted future phase from the project roadmap, delete its directory, renumber all subsequent phases to maintain a clean linear sequence, and commit the change.
+</purpose>
+
+<required_reading>
+Read all files referenced by the invoking prompt's execution_context before starting.
+</required_reading>
+
+<process>
+
+<step name="parse_arguments">
+Parse: phase number to remove (integer or decimal).
+If no argument: Error with usage. Exit.
+</step>
+
+<step name="init_context">
+```bash
+INIT=$(node ${CLAUDE_PLUGIN_ROOT}/bin/grd-tools.js init phase-op "${target}")
+```
+
+Extract: `phase_found`, `phase_dir`, `phase_number`, `commit_docs`, `roadmap_exists`.
+</step>
+
+<step name="validate_future_phase">
+Target must be > current phase number.
+
+If target <= current phase:
+```
+ERROR: Cannot remove Phase {target}
+Only future phases can be removed.
+To abandon current work, use /grd:pause-work instead.
+```
+Exit.
+</step>
+
+<step name="confirm_removal">
+Present removal summary and confirm:
+```
+Removing Phase {target}: {Name}
+
+This will:
+- Delete: ${phase_dir}/
+- Renumber all subsequent phases
+- Update: ROADMAP.md, STATE.md
+
+Proceed? (y/n)
+```
+</step>
+
+<step name="execute_removal">
+```bash
+RESULT=$(node ${CLAUDE_PLUGIN_ROOT}/bin/grd-tools.js phase remove "${target}")
+```
+
+If phase has executed plans, use `--force` only if user confirms.
+</step>
+
+<step name="commit">
+```bash
+node ${CLAUDE_PLUGIN_ROOT}/bin/grd-tools.js commit "chore: remove phase {target} ({original-phase-name})" --files .planning/
+```
+</step>
+
+<step name="completion">
+```
+Phase {target} ({original-name}) removed.
+
+Changes:
+- Deleted: ${phase_dir}/
+- Renumbered: {N} directories and {M} files
+- Updated: ROADMAP.md, STATE.md
+- Committed
+
+---
+
+## What's Next
+
+- `/grd:progress` — see updated roadmap status
+- Continue with current phase
+
+---
+```
+</step>
+
+</process>
+
+<success_criteria>
+- [ ] Target phase validated as future/unstarted
+- [ ] `grd-tools phase remove` executed successfully
+- [ ] Changes committed with descriptive message
+- [ ] User informed of changes
+</success_criteria>

package/commands/requirement.md

@@ -0,0 +1,96 @@
+---
+description: Look up requirements by ID, list with filters, or query traceability matrix
+argument-hint: <get REQ-ID | list [--phase N] [--status S] | traceability [--phase N] | update-status REQ-ID STATUS>
+---
+
+<purpose>
+Query and manage project requirements. Look up individual requirements by ID, list requirements with filtering by phase/priority/status/category, view the traceability matrix, or update requirement status. Wraps the requirement CLI commands from grd-tools.js.
+</purpose>
+
+<process>
+
+## Step 0: Parse Arguments
+
+Parse `$ARGUMENTS` for the subcommand:
+
+- `get <REQ-ID>` — look up a single requirement
+- `list [--phase N] [--priority P] [--status S] [--category C] [--all]` — list requirements with filters
+- `traceability [--phase N]` — show traceability matrix
+- `update-status <REQ-ID> <STATUS>` — update a requirement's status
+
+If no arguments provided, default to `list` (show all current milestone requirements).
+
+---
+
+## Get: Look Up a Requirement
+
+```bash
+RESULT=$(node ${CLAUDE_PLUGIN_ROOT}/bin/grd-tools.js requirement get <REQ-ID>)
+```
+
+Present the requirement details: ID, description, priority, status, phase mapping, and any notes.
+
+---
+
+## List: Filter Requirements
+
+```bash
+RESULT=$(node ${CLAUDE_PLUGIN_ROOT}/bin/grd-tools.js requirement list [--phase N] [--priority P] [--status S] [--category C] [--all])
+```
+
+Present as a formatted table:
+
+```
+## Requirements
+
+| ID | Description | Priority | Status | Phase |
+|----|-------------|----------|--------|-------|
+| REQ-01 | ... | P0 | Done | 3 |
+| REQ-02 | ... | P1 | In Progress | 5 |
+```
+
+If `--all` flag: include completed/deferred requirements.
+
+---
+
+## Traceability: Requirement-to-Phase Mapping
+
+```bash
+RESULT=$(node ${CLAUDE_PLUGIN_ROOT}/bin/grd-tools.js requirement traceability [--phase N])
+```
+
+Present the traceability matrix showing which requirements map to which phases, plans, and verification status.
+
+---
+
+## Update Status
+
+```bash
+node ${CLAUDE_PLUGIN_ROOT}/bin/grd-tools.js requirement update-status <REQ-ID> <STATUS>
+```
+
+Valid statuses: `Pending`, `In Progress`, `Done`, `Deferred`
+
+After updating, confirm the change:
+
+```
+Updated <REQ-ID> status to <STATUS>
+```
+
+If `commit_docs` is true in config, commit the change:
+
+```bash
+node ${CLAUDE_PLUGIN_ROOT}/bin/grd-tools.js commit "docs: update <REQ-ID> status to <STATUS>" --files .planning/REQUIREMENTS.md
+```
+
+---
+
+</process>
+
+<success_criteria>
+- [ ] Subcommand parsed from arguments
+- [ ] Correct CLI command invoked
+- [ ] Results presented in readable format
+- [ ] Status updates committed if commit_docs enabled
+</success_criteria>
+</content>

package/commands/resume-project.md

@@ -0,0 +1,113 @@
+---
+description: Restore full project context to resume work seamlessly
+---
+
+<trigger>
+Use this workflow when:
+- Starting a new session on an existing project
+- User says "continue", "what's next", "where were we", "resume"
+- Any planning operation when .planning/ already exists
+- User returns after time away from project
+</trigger>
+
+<purpose>
+Instantly restore full project context so "Where were we?" has an immediate, complete answer.
+</purpose>
+
+<required_reading>
+@${CLAUDE_PLUGIN_ROOT}/references/continuation-format.md
+</required_reading>
+
+<process>
+
+<step name="initialize">
+```bash
+INIT=$(node ${CLAUDE_PLUGIN_ROOT}/bin/grd-tools.js init resume)
+```
+
+Parse JSON for: `state_exists`, `roadmap_exists`, `project_exists`, `planning_exists`, `has_interrupted_agent`, `interrupted_agent_id`, `commit_docs`, `phases_dir`, `todos_dir`.
+
+**If `state_exists` is true:** Proceed to load_state
+**If `state_exists` is false but `roadmap_exists` or `project_exists` is true:** Offer to reconstruct STATE.md
+**If `planning_exists` is false:** This is a new project - route to /grd:init
+</step>
+
+<step name="load_state">
+Read and parse STATE.md, then PROJECT.md:
+
+```bash
+cat .planning/STATE.md
+cat .planning/PROJECT.md
+```
+
+Extract: Project Reference, Current Position, Progress, Recent Decisions, Pending Todos, Blockers/Concerns, Session Continuity, Requirements (Validated, Active, Out of Scope), Key Decisions, Constraints.
+</step>
+
+<step name="check_incomplete_work">
+```bash
+ls ${phases_dir}/*/.continue-here*.md 2>/dev/null
+
+for plan in ${phases_dir}/*/*-PLAN.md; do
+  summary="${plan/PLAN/SUMMARY}"
+  [ ! -f "$summary" ] && echo "Incomplete: $plan"
+done 2>/dev/null
+```
+
+Check for interrupted agents using `has_interrupted_agent` from init.
+</step>
+
+<step name="present_status">
+Present complete project status with progress bar, phase/plan position, last activity, incomplete work, pending todos, and blockers.
+</step>
+
+<step name="determine_next_action">
+Based on project state, determine the most logical next action:
+
+- Interrupted agent -> Resume or start fresh
+- .continue-here file -> Resume from checkpoint
+- Incomplete plan -> Complete the plan
+- Phase complete, all plans done -> Transition to next
+- Phase ready to plan -> Check for CONTEXT.md, suggest discuss-phase or plan-phase
+- Phase ready to execute -> Execute next plan
+</step>
+
+<step name="offer_options">
+Present contextual options:
+
+```
+What would you like to do?
+
+1. [Primary action based on state]
+2. Review current phase status
+3. Check pending todos ([N] pending)
+4. Something else
+```
+
+When offering phase planning, check for CONTEXT.md first. If missing, suggest discuss-phase.
+</step>
+
+<step name="route_to_workflow">
+Based on user selection, route to appropriate workflow:
+
+- **Execute plan** -> `/grd:execute-phase {phase}`
+- **Plan phase** -> `/grd:plan-phase [phase-number]`
+- **Check todos** -> Read ${todos_dir}/pending/
+- **Something else** -> Ask what they need
+
+All routes suggest `/clear` first for fresh context.
+</step>
+
+<step name="update_session">
+Update STATE.md session continuity before proceeding.
+</step>
+
+</process>
+
+<success_criteria>
+- [ ] STATE.md loaded (or reconstructed)
+- [ ] Incomplete work detected and flagged
+- [ ] Clear status presented to user
+- [ ] Contextual next actions offered
+- [ ] User knows exactly where project stands
+- [ ] Session continuity updated
+</success_criteria>