get-shit-done-cc 1.5.2 → 1.5.3

package/README.md

@@ -340,7 +340,6 @@ You're never locked in. The system adapts.
 | `/gsd:plan-phase [N]` | Generate task plans for phase |
 | `/gsd:execute-plan` | Run single plan via subagent |
 | `/gsd:execute-phase <N>` | Execute all plans in phase N with parallel agents |
-| `/gsd:status [--wait]` | Check background agent status from parallel execution |
 | `/gsd:progress` | Where am I? What's next? |
 | `/gsd:verify-work [N]` | User acceptance test of phase or plan ¹ |
 | `/gsd:plan-fix [plan]` | Plan fixes for UAT issues from verify-work |

package/commands/gsd/define-requirements.md

@@ -10,14 +10,13 @@ allowed-tools:
 ---
 
 <objective>
-Define concrete, checkable requirements from research findings.
+Define concrete, checkable requirements for v1.
 
-Research answers "what do products like this have?"
-Requirements answers "what are WE building?"
+Two modes:
+1. **With research** — Transform FEATURES.md into scoped requirements
+2. **Without research** — Gather requirements through questioning
 
-Transforms research features into scoped v1/v2 requirements that roadmap phases map to.
-
-Run after `/gsd:research-project`, before `/gsd:create-roadmap`.
+Run before `/gsd:create-roadmap`.
 
 Output: `.planning/REQUIREMENTS.md`
 </objective>
@@ -30,8 +29,8 @@ Output: `.planning/REQUIREMENTS.md`
 
 <context>
 @.planning/PROJECT.md
-@.planning/research/FEATURES.md (required)
-@.planning/research/SUMMARY.md
+@.planning/research/FEATURES.md (if exists)
+@.planning/research/SUMMARY.md (if exists)
 </context>
 
 <process>
@@ -41,8 +40,8 @@ Output: `.planning/REQUIREMENTS.md`
 # Verify project exists
 [ -f .planning/PROJECT.md ] || { echo "ERROR: No PROJECT.md found. Run /gsd:new-project first."; exit 1; }
 
-# Verify research exists
-[ -f .planning/research/FEATURES.md ] || { echo "ERROR: No research found. Run /gsd:research-project first."; exit 1; }
+# Check for research
+[ -f .planning/research/FEATURES.md ] && echo "HAS_RESEARCH" || echo "NO_RESEARCH"
 
 # Check if requirements already exist
 [ -f .planning/REQUIREMENTS.md ] && echo "REQUIREMENTS_EXISTS" || echo "NO_REQUIREMENTS"
@@ -66,12 +65,24 @@ If "Replace": Continue with workflow
 </step>
 
 <step name="execute">
+**If HAS_RESEARCH:**
 Follow the define-requirements.md workflow:
-- Load research features
+- Load research features from FEATURES.md
 - Present features by category
 - Ask user to scope each category (v1 / v2 / out of scope)
 - Capture any additions research missed
 - Generate REQUIREMENTS.md with checkable list
+
+**If NO_RESEARCH:**
+Gather requirements through questioning:
+- Read PROJECT.md for core value and context
+- Ask: "What are the main things users need to be able to do?"
+- For each capability mentioned, probe for specifics
+- Group into categories (Authentication, Content, etc.)
+- For each category, ask what's v1 vs v2 vs out of scope
+- Generate REQUIREMENTS.md with checkable list
+
+Same output format either way — the difference is source (research vs conversation).
 </step>
 
 <step name="done">
@@ -101,8 +112,7 @@ Requirements defined:
 
 <success_criteria>
 - [ ] PROJECT.md validated
-- [ ] Research FEATURES.md loaded
-- [ ] Features presented by category
+- [ ] Features gathered (from research OR questioning)
 - [ ] User scoped each category (v1/v2/out of scope)
 - [ ] User had opportunity to add missing requirements
 - [ ] REQUIREMENTS.md created with checkable list

package/commands/gsd/help.md

@@ -144,15 +144,6 @@ Options (via `.planning/config.json` parallelization section):
 - `skip_checkpoints`: Skip human checkpoints in background (default: true)
 - `min_plans_for_parallel`: Minimum plans to trigger parallelization (default: 2)
 
-**`/gsd:status [--wait]`**
-Check status of background agents from parallel execution.
-
-- Shows running/completed agents from agent-history.json
-- Uses TaskOutput to poll agent status
-- With `--wait`: blocks until all agents complete
-
-Usage: `/gsd:status` or `/gsd:status --wait`
-
 ### Roadmap Management
 
 **`/gsd:add-phase <description>`**

package/commands/gsd/new-project.md

@@ -300,15 +300,15 @@ Project initialized:
 
 Choose your path:
 
-**Option A: Research first** (recommended for new domains)
-Research the ecosystem before creating roadmap. Discovers standard stacks, expected features, architecture patterns, and common pitfalls.
+**Option A: Research first** (recommended)
+Research ecosystem → define requirements → create roadmap. Discovers standard stacks, expected features, architecture patterns.
 
 `/gsd:research-project`
 
-**Option B: Create roadmap directly** (for familiar domains)
-Skip research if you know this domain well or have a clear spec.
+**Option B: Define requirements directly** (familiar domains)
+Skip research, define requirements from what you know, then create roadmap.
 
-`/gsd:create-roadmap`
+`/gsd:define-requirements`
 
 <sub>`/clear` first → fresh context window</sub>
 

package/get-shit-done/workflows/define-requirements.md

@@ -1,10 +1,11 @@
 <purpose>
-Transform research findings into scoped, checkable requirements.
+Define concrete, checkable requirements for v1.
 
-Research tells you what products in this domain typically have.
-Requirements tell you what YOU are building for v1.
+Two modes:
+1. **With research** — Transform FEATURES.md into scoped requirements
+2. **Without research** — Gather requirements through questioning
 
-This is the bridge between "what's possible" and "what we're committing to."
+This is the bridge between "what's possible/wanted" and "what we're committing to."
 </purpose>
 
 <required_reading>
@@ -12,13 +13,23 @@ This is the bridge between "what's possible" and "what we're committing to."
 
 1. ~/.claude/get-shit-done/templates/requirements.md
 2. .planning/PROJECT.md
-3. .planning/research/FEATURES.md
-4. .planning/research/SUMMARY.md
+3. .planning/research/FEATURES.md (if exists)
+4. .planning/research/SUMMARY.md (if exists)
 </required_reading>
 
 <process>
 
-<step name="load_context">
+<step name="detect_mode">
+Check for research:
+```bash
+[ -f .planning/research/FEATURES.md ] && echo "HAS_RESEARCH" || echo "NO_RESEARCH"
+```
+
+**If HAS_RESEARCH:** Follow steps load_context → present_features → scope_categories
+**If NO_RESEARCH:** Follow steps load_project → gather_requirements → scope_categories
+</step>
+
+<step name="load_context" mode="with_research">
 Read PROJECT.md and extract:
 - Core value (the ONE thing that must work)
 - Stated constraints (budget, timeline, tech limitations)
@@ -37,11 +48,52 @@ Read research/SUMMARY.md for:
 - Suggested phase structure (informational only)
 </step>
 
+<step name="load_project" mode="without_research">
+Read PROJECT.md and extract:
+- Core value (the ONE thing that must work)
+- Stated constraints (budget, timeline, tech limitations)
+- Any explicit scope boundaries from project definition
+- Any requirements already mentioned in PROJECT.md
+</step>
+
+<step name="gather_requirements" mode="without_research">
+Since no research exists, gather requirements through conversation.
+
+**Start with core value:**
+```
+Based on PROJECT.md, the core value is: "[core value]"
+
+What are the main things users need to be able to do?
+```
+
+Wait for response. For each capability mentioned:
+- Ask clarifying questions to make it specific
+- Probe for related capabilities they might need
+- Group naturally emerging categories
+
+**Example flow:**
+```
+User: "Users need to create and share posts"
+
+You: "For posts, what should users be able to include?
+- Text only?
+- Images?
+- Links with previews?
+
+And for sharing — to a feed, or also direct to other users?"
+```
+
+Build up a mental feature list organized by category.
+
+**When you have enough:**
+Present gathered features in same format as present_features step, then proceed to scope_categories.
+</step>
+
 <step name="present_features">
-Present researched features grouped by category:
+Present features grouped by category (from research or gathered through questioning):
 
 ```
-Based on research, here are the features for [domain]:
+Here are the features for [domain]:
 
 ## Authentication
 **Table stakes:**
@@ -267,7 +319,7 @@ Requirements defined:
 
 <success_criteria>
 - [ ] PROJECT.md core value extracted
-- [ ] Research FEATURES.md loaded and parsed
+- [ ] Features gathered (from research OR conversation)
 - [ ] All categories presented to user
 - [ ] User scoped each category (v1/v2/out of scope)
 - [ ] User had opportunity to add requirements

package/get-shit-done/workflows/execute-phase.md

@@ -103,15 +103,21 @@ waves = {
 
 **No dependency analysis needed.** Wave numbers are pre-computed during `/gsd:plan-phase`.
 
-Report wave structure to user:
+Report wave structure with context:
 ```
-Execution Plan:
-  Wave 1 (parallel): 03-01, 03-02
-  Wave 2 (parallel): 03-03 [checkpoint], 03-04
-  Wave 3: 03-05
+## Execution Plan
+
+**Phase {X}: {Name}** — {total_plans} plans across {wave_count} waves
+
+| Wave | Plans | What it builds |
+|------|-------|----------------|
+| 1 | 01-01, 01-02 | {from plan objectives} |
+| 2 | 01-03 | {from plan objectives} |
+| 3 | 01-04 [checkpoint] | {from plan objectives} |
 
-Total: 5 plans in 3 waves
 ```
+
+The "What it builds" column comes from skimming plan names/objectives. Keep it brief (3-8 words).
 </step>
 
 <step name="execute_waves">
@@ -119,7 +125,32 @@ Execute each wave in sequence. Autonomous plans within a wave run in parallel.
 
 **For each wave:**
 
-1. **Spawn all autonomous agents in wave simultaneously:**
+1. **Describe what's being built (BEFORE spawning):**
+
+   Read each plan's `<objective>` section. Extract what's being built and why it matters.
+
+   **Output:**
+   ```
+   ---
+
+   ## Wave {N}
+
+   **{Plan ID}: {Plan Name}**
+   {2-3 sentences: what this builds, key technical approach, why it matters in context}
+
+   **{Plan ID}: {Plan Name}** (if parallel)
+   {same format}
+
+   Spawning {count} agent(s)...
+
+   ---
+   ```
+
+   **Examples:**
+   - Bad: "Executing terrain generation plan"
+   - Good: "Procedural terrain generator using Perlin noise — creates height maps, biome zones, and collision meshes. Required before vehicle physics can interact with ground."
+
+2. **Spawn all autonomous agents in wave simultaneously:**
 
    Use Task tool with multiple parallel calls. Each agent gets prompt from subagent-task-prompt template:
 
@@ -155,12 +186,34 @@ Execute each wave in sequence. Autonomous plans within a wave run in parallel.
 
    Task tool blocks until each agent finishes. All parallel agents return together.
 
-3. **Collect results from wave:**
+3. **Report completion and what was built:**
 
    For each completed agent:
    - Verify SUMMARY.md exists at expected path
-   - Note any issues reported
-   - Record completion
+   - Read SUMMARY.md to extract what was built
+   - Note any issues or deviations
+
+   **Output:**
+   ```
+   ---
+
+   ## Wave {N} Complete
+
+   **{Plan ID}: {Plan Name}**
+   {What was built — from SUMMARY.md deliverables}
+   {Notable deviations or discoveries, if any}
+
+   **{Plan ID}: {Plan Name}** (if parallel)
+   {same format}
+
+   {If more waves: brief note on what this enables for next wave}
+
+   ---
+   ```
+
+   **Examples:**
+   - Bad: "Wave 2 complete. Proceeding to Wave 3."
+   - Good: "Terrain system complete — 3 biome types, height-based texturing, physics collision meshes. Vehicle physics (Wave 3) can now reference ground surfaces."
 
 4. **Handle failures:**
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "get-shit-done-cc",
-  "version": "1.5.2",
+  "version": "1.5.3",
   "description": "A meta-prompting, context engineering and spec-driven development system for Claude Code by TÂCHES.",
   "bin": {
     "get-shit-done-cc": "bin/install.js"

package/get-shit-done/templates/agent-history.md

@@ -1,263 +0,0 @@
-# Agent History Template
-
-Template for `.planning/agent-history.json` - tracks subagent spawns during plan execution for resume capability.
-
----
-
-## File Template
-
-```json
-{
-  "version": "1.2",
-  "max_entries": 50,
-  "entries": []
-}
-```
-
-## Entry Schema
-
-Each entry tracks a subagent spawn or status change:
-
-```json
-{
-  "agent_id": "agent_01HXXXX...",
-  "task_description": "Execute tasks 1-3 from plan 02-01",
-  "phase": "02",
-  "plan": "01",
-  "segment": 1,
-  "timestamp": "2026-01-15T14:22:10Z",
-  "status": "spawned",
-  "completion_timestamp": null,
-  "execution_mode": "sequential",
-  "parallel_group": null,
-  "granularity": "plan",
-  "depends_on": null,
-  "files_modified": null,
-  "checkpoints_skipped": null,
-  "task_results": null
-}
-```
-
-### Field Definitions
-
-| Field | Type | Description |
-|-------|------|-------------|
-| agent_id | string | Unique ID returned by Task tool |
-| task_description | string | Brief description of what agent is executing |
-| phase | string | Phase number (e.g., "02", "02.1") |
-| plan | string | Plan number within phase |
-| segment | number/null | Segment number for segmented plans, null for full plan |
-| timestamp | string | ISO 8601 timestamp when agent was spawned |
-| status | string | spawned, completed, interrupted, resumed, queued, failed |
-| completion_timestamp | string/null | ISO timestamp when completed |
-| execution_mode | string | "sequential" or "parallel" |
-| parallel_group | string/null | Batch ID linking agents in same parallel execution |
-| granularity | string | "plan" or "task_group" |
-| depends_on | array/null | Agent IDs or plan refs this depends on |
-| files_modified | array/null | Files this agent created/modified |
-| checkpoints_skipped | number/null | Count of checkpoints skipped in background |
-| task_results | object/null | Per-task outcomes for task-level parallelization |
-
-### Status Lifecycle
-
-```
-queued ──> spawned ──────────────────> completed
-               │                           ^
-               │                           │
-               ├──> interrupted ──> resumed┘
-               │
-               └──> failed
-```
-
-- **queued**: Waiting for dependency (parallel execution only)
-- **spawned**: Agent created via Task tool, execution in progress
-- **completed**: Agent finished successfully, results received
-- **interrupted**: Session ended before agent completed (detected on resume)
-- **resumed**: Previously interrupted agent resumed via resume parameter
-- **failed**: Agent execution failed (error during execution)
-
-## Usage
-
-### When to Create File
-
-Create `.planning/agent-history.json` from this template when:
-- First subagent spawn in execute-plan workflow
-- File doesn't exist yet
-
-### When to Add Entry
-
-Add new entry immediately after Task tool returns with agent_id:
-
-```
-1. Task tool spawns subagent
-2. Response includes agent_id
-3. Write agent_id to .planning/current-agent-id.txt
-4. Append entry to agent-history.json with status "spawned"
-```
-
-### When to Update Entry
-
-Update existing entry when:
-
-**On successful completion:**
-```json
-{
-  "status": "completed",
-  "completion_timestamp": "2026-01-15T14:45:33Z"
-}
-```
-
-**On resume detection (interrupted agent found):**
-```json
-{
-  "status": "interrupted"
-}
-```
-
-Then add new entry with resumed status:
-```json
-{
-  "agent_id": "agent_01HXXXX...",
-  "status": "resumed",
-  "timestamp": "2026-01-15T15:00:00Z"
-}
-```
-
-### Entry Retention
-
-- Keep maximum 50 entries (configurable via max_entries)
-- On exceeding limit, remove oldest completed entries first
-- Never remove entries with status "spawned" (may need resume)
-- Prune during init_agent_tracking step
-
-## Example Entries
-
-### Sequential Execution (Default)
-
-```json
-{
-  "agent_id": "agent_01HXY123ABC",
-  "task_description": "Execute full plan 02-01 (autonomous)",
-  "phase": "02",
-  "plan": "01",
-  "segment": null,
-  "timestamp": "2026-01-15T14:22:10Z",
-  "status": "completed",
-  "completion_timestamp": "2026-01-15T14:45:33Z",
-  "execution_mode": "sequential",
-  "parallel_group": null,
-  "granularity": "plan",
-  "depends_on": null,
-  "files_modified": ["src/api/auth.ts", "src/types/user.ts"],
-  "checkpoints_skipped": null,
-  "task_results": null
-}
-```
-
-### Parallel Execution (Plan-Level)
-
-Independent plans in a phase running in parallel:
-
-```json
-{
-  "agent_id": "agent_01HXYZ123",
-  "task_description": "Execute plan 05-01 (parallel)",
-  "phase": "05",
-  "plan": "01",
-  "segment": null,
-  "timestamp": "2026-01-12T10:00:00Z",
-  "status": "completed",
-  "completion_timestamp": "2026-01-12T10:15:00Z",
-  "execution_mode": "parallel",
-  "parallel_group": "phase-05-batch-1736676000",
-  "granularity": "plan",
-  "depends_on": null,
-  "files_modified": ["src/auth/login.ts", "src/auth/types.ts"],
-  "checkpoints_skipped": 1,
-  "task_results": null
-}
-```
-
-### Queued with Dependency
-
-Agent waiting for another to complete:
-
-```json
-{
-  "agent_id": "agent_01HXYZ456",
-  "task_description": "Execute plan 05-03 (depends on 05-01)",
-  "phase": "05",
-  "plan": "03",
-  "segment": null,
-  "timestamp": "2026-01-12T10:15:00Z",
-  "status": "spawned",
-  "completion_timestamp": null,
-  "execution_mode": "parallel",
-  "parallel_group": "phase-05-batch-1736676000",
-  "granularity": "plan",
-  "depends_on": ["agent_01HXYZ123"],
-  "files_modified": null,
-  "checkpoints_skipped": null,
-  "task_results": null
-}
-```
-
-### Parallel Group Format
-
-- **Plan-level parallel:** `phase-{phase}-batch-{timestamp}`
-- **Task-level parallel:** `plan-{phase}-{plan}-tasks-batch-{timestamp}`
-
-Example: `phase-05-batch-1736676000` groups all agents executing Phase 5 plans in parallel.
-
-## Parallel Execution Resume
-
-When a session is interrupted during parallel execution:
-
-### Detection
-
-Check for entries with `status: "spawned"` and `parallel_group` set. These are agents that were running when session ended.
-
-```bash
-# Find interrupted parallel agents
-jq '.entries[] | select(.status == "spawned" and .parallel_group != null)' .planning/agent-history.json
-```
-
-### Resume Options
-
-1. **Resume batch:** Resume all interrupted agents in the parallel group
-2. **Resume single:** Resume a specific agent by ID
-3. **Start fresh:** Abandon interrupted batch, start new execution
-
-### Resume Command
-
-`/gsd:resume-task` accepts:
-- No argument: Resume most recent interrupted agent
-- Agent ID: Resume specific agent
-- `--batch`: Resume entire parallel group
-
-### Conflict Detection
-
-Before resuming, check for file modifications since spawn:
-
-```bash
-git diff --name-only ${SPAWN_COMMIT}..HEAD
-```
-
-If files modified by another agent conflict with files this agent modifies, warn user before proceeding. This prevents overwriting work done by other parallel agents that completed after the interruption.
-
-## Related Files
-
-- `.planning/current-agent-id.txt`: Single line with currently active agent ID (for quick resume lookup)
-- `.planning/STATE.md`: Project state including session continuity info
-
----
-
-## Template Notes
-
-**When to create:** First subagent spawn during execute-plan workflow.
-
-**Location:** `.planning/agent-history.json`
-
-**Companion file:** `.planning/current-agent-id.txt` (single agent ID, overwritten on each spawn)
-
-**Purpose:** Enable resume capability for interrupted subagent executions via Task tool's resume parameter.