get-shit-done-cc 1.9.3 → 1.9.6

package/get-shit-done/templates/state.md

@@ -174,33 +174,3 @@ It's a DIGEST, not an archive. If accumulated context grows too large:
 The goal is "read once, know where we are" — if it's too long, that fails.
 
 </size_constraint>
-
-<guidelines>
-
-**When created:**
-- During project initialization (after ROADMAP.md)
-- Reference PROJECT.md (extract core value and current focus)
-- Initialize empty sections
-
-**When read:**
-- Every workflow starts by reading STATE.md
-- Then read PROJECT.md for full context
-- Provides instant context restoration
-
-**When updated:**
-- After each plan execution (update position, note decisions, update issues/blockers)
-- After phase transitions (update progress bar, clear resolved blockers, refresh project reference)
-
-**Size management:**
-- Keep under 100 lines total
-- Recent decisions only in STATE.md (full log in PROJECT.md)
-- Keep only active blockers
-
-**Sections:**
-- Project Reference: Pointer to PROJECT.md with core value
-- Current Position: Where we are now (phase, plan, status)
-- Performance Metrics: Velocity tracking
-- Accumulated Context: Recent decisions, pending todos, blockers
-- Session Continuity: Resume information
-
-</guidelines>

package/get-shit-done/templates/summary.md

@@ -233,37 +233,14 @@ The one-liner should tell someone what actually shipped.
 </example>
 
 <guidelines>
-**When to create:**
-- After completing each phase plan
-- Required output from execute-plan workflow
-- Documents what actually happened vs what was planned
-
-**Frontmatter completion:**
-- MANDATORY: Complete all frontmatter fields during summary creation
-- See <frontmatter_guidance> for field purposes
-- Frontmatter enables automatic context assembly for future planning
-
-**One-liner requirements:**
-- Must be substantive (describe what shipped, not "phase complete")
-- Should tell someone what was accomplished
-- Examples: "JWT auth with refresh rotation using jose library" not "Authentication implemented"
-
-**Performance tracking:**
-- Include duration, start/end timestamps
-- Used for velocity metrics in STATE.md
-
-**Deviations section:**
-- Documents unplanned work handled via deviation rules
-- Separate from "Issues Encountered" (which is planned work problems)
-- Auto-fixed issues: What was wrong, how fixed, verification
+**Frontmatter:** MANDATORY - complete all fields. Enables automatic context assembly for future planning.
+
+**One-liner:** Must be substantive. "JWT auth with refresh rotation using jose library" not "Authentication implemented".
 
 **Decisions section:**
-- Key decisions made during execution
-- Include rationale (why this choice)
+- Key decisions made during execution with rationale
 - Extracted to STATE.md accumulated context
 - Use "None - followed plan as specified" if no deviations
 
-**After creation:**
-- STATE.md updated with position, decisions, issues
-- Next plan can reference decisions made
+**After creation:** STATE.md updated with position, decisions, issues.
 </guidelines>

package/get-shit-done/templates/user-setup.md

@@ -304,20 +304,8 @@ curl -X POST http://localhost:3000/api/test-email \
 
 ## Guidelines
 
-**Include in USER-SETUP.md:**
-- Environment variable names and where to find values
-- Account creation URLs (if new service)
-- Dashboard configuration steps
-- Verification commands to confirm setup works
-- Local development alternatives (e.g., `stripe listen`)
-
-**Do NOT include:**
-- Actual secret values (never)
-- Steps Claude can automate (package installs, code changes, file creation)
-- Generic instructions ("set up your environment")
+**Never include:** Actual secret values. Steps Claude can automate (package installs, code changes).
 
 **Naming:** `{phase}-USER-SETUP.md` matches the phase number pattern.
-
 **Status tracking:** User marks checkboxes and updates status line when complete.
-
 **Searchability:** `grep -r "USER-SETUP" .planning/` finds all phases with user requirements.

package/get-shit-done/workflows/complete-milestone.md

@@ -29,12 +29,7 @@ When a milestone completes, this workflow:
 5. Performs full PROJECT.md evolution review
 6. Offers to create next milestone inline
 
-**Context Efficiency:**
-
-- Completed milestones: One line each (~50 tokens)
-- Full details: In archive files (loaded only when needed)
-- Result: ROADMAP.md stays constant size forever
-- Result: REQUIREMENTS.md is always milestone-scoped (not cumulative)
+**Context Efficiency:** Archives keep ROADMAP.md constant-size and REQUIREMENTS.md milestone-scoped.
 
 **Archive Format:**
 

package/get-shit-done/workflows/diagnose-issues.md

@@ -201,21 +201,8 @@ Do NOT offer manual next steps - verify-work handles the rest.
 </process>
 
 <context_efficiency>
-**Orchestrator context:** ~15%
-- Parse UAT.md gaps
-- Fill template strings
-- Spawn parallel Task calls
-- Collect results
-- Update UAT.md
-
-**Each debug agent:** Fresh 200k context
-- Loads full debug workflow
-- Loads debugging references
-- Investigates with full capacity
-- Returns root cause
-
-**No symptom gathering.** Agents start with symptoms pre-filled from UAT.
-**No fix application.** Agents only diagnose - plan-phase --gaps handles fixes.
+Agents start with symptoms pre-filled from UAT (no symptom gathering).
+Agents only diagnose—plan-phase --gaps handles fixes (no fix application).
 </context_efficiency>
 
 <failure_handling>

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

@@ -550,24 +550,9 @@ All {N} phases executed.
 </process>
 
 <context_efficiency>
-**Why this works:**
-
-Orchestrator context usage: ~10-15%
-- Read plan frontmatter (small)
-- Analyze dependencies (logic, no heavy reads)
-- Fill template strings
-- Spawn Task calls
-- Collect results
-
-Each subagent: Fresh 200k context
-- Loads full execute-plan workflow
-- Loads templates, references
-- Executes plan with full capacity
-- Creates SUMMARY, commits
-
-**No polling.** Task tool blocks until completion. No TaskOutput loops.
-
-**No context bleed.** Orchestrator never reads workflow internals. Just paths and results.
+Orchestrator: ~10-15% context (frontmatter, spawning, results).
+Subagents: Fresh 200k each (full workflow + execution).
+No polling (Task blocks). No context bleed.
 </context_efficiency>
 
 <failure_handling>

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

@@ -216,19 +216,7 @@ Tasks 2-5: Main context (need decision from checkpoint 1)
 No segmentation benefit - execute entirely in main
 ```
 
-**4. Why this works:**
-
-**Segmentation benefits:**
-
-- Fresh context for each autonomous segment (0% start every time)
-- Main context only for checkpoints (~10-20% total)
-- Can handle 10+ task plans if properly segmented
-- Quality impossible to degrade in autonomous segments
-
-**When segmentation provides no benefit:**
-
-- Checkpoint is decision/human-action and following tasks depend on outcome
-- Better to execute sequentially in main than break flow
+**4. Why segment:** Fresh context per subagent preserves peak quality. Main context stays lean (~15% usage).
 
 **5. Implementation:**
 
@@ -533,18 +521,7 @@ Committing...
 
 ````
 
-**Benefits of this pattern:**
-- Main context usage: ~20% (just orchestration + checkpoints)
-- Subagent 1: Fresh 0-30% (tasks 1-3)
-- Subagent 2: Fresh 0-30% (tasks 5-6)
-- Subagent 3: Fresh 0-20% (task 8)
-- All autonomous work: Peak quality
-- Can handle large plans with many tasks if properly segmented
-
-**When NOT to use segmentation:**
-- Plan has decision/human-action checkpoints that affect following tasks
-- Following tasks depend on checkpoint outcome
-- Better to execute in main sequentially in those cases
+**Benefit:** Each subagent starts fresh (~20-30% context), enabling larger plans without quality degradation.
 </step>
 
 <step name="load_prompt">
@@ -1068,13 +1045,6 @@ Store in array or list for SUMMARY generation:
 TASK_COMMITS+=("Task ${TASK_NUM}: ${TASK_COMMIT}")
 ```
 
-**Atomic commit benefits:**
-- Each task independently revertable
-- Git bisect finds exact failing task
-- Git blame traces line to specific task context
-- Clear history for Claude in future sessions
-- Better observability for AI-automated workflow
-
 </task_commit>
 
 <step name="checkpoint_protocol">

package/get-shit-done/workflows/list-phase-assumptions.md

@@ -132,7 +132,7 @@ Wait for user response.
 Acknowledge the corrections:
 
 ```
-Got it. Key corrections:
+Key corrections:
 - [correction 1]
 - [correction 2]
 
@@ -142,7 +142,7 @@ This changes my understanding significantly. [Summarize new understanding]
 **If user confirms assumptions:**
 
 ```
-Great, assumptions validated.
+Assumptions validated.
 ```
 
 Continue to offer_next.

package/get-shit-done/workflows/resume-project.md

@@ -7,10 +7,7 @@ Use this workflow when:
 </trigger>
 
 <purpose>
-Instantly restore full project context and present clear status.
-Enables seamless session continuity for fully autonomous workflows.
-
-"Where were we?" should have an immediate, complete answer.
+Instantly restore full project context so "Where were we?" has an immediate, complete answer.
 </purpose>
 
 <required_reading>
@@ -290,17 +287,12 @@ This handles cases where:
   </reconstruction>
 
 <quick_resume>
-For users who want minimal friction:
-
-If user says just "continue" or "go":
-
+If user says "continue" or "go":
 - Load state silently
 - Determine primary action
 - Execute immediately without presenting options
 
 "Continuing from [state]... [action]"
-
-This enables fully autonomous "just keep going" workflow.
 </quick_resume>
 
 <success_criteria>

package/get-shit-done/workflows/transition.md

@@ -514,15 +514,7 @@ Exit skill and invoke SlashCommand("/gsd:complete-milestone {version}")
 </process>
 
 <implicit_tracking>
-
-Progress tracking is IMPLICIT:
-
-- "Plan phase 2" → Phase 1 must be done (or ask)
-- "Plan phase 3" → Phases 1-2 must be done (or ask)
-- Transition workflow makes it explicit in ROADMAP.md
-
-No separate "update progress" step. Forward motion IS progress.
-
+Progress tracking is IMPLICIT: planning phase N implies phases 1-(N-1) complete. No separate progress step—forward motion IS progress.
 </implicit_tracking>
 
 <partial_completion>

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "get-shit-done-cc",
-  "version": "1.9.3",
+  "version": "1.9.6",
   "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"