get-shit-done-cc 1.3.16 → 1.3.18

package/commands/gsd/new-project.md

@@ -245,7 +245,7 @@ Use AskUserQuestion:
   - "Standard" — Balanced scope and speed (5-8 phases, 3-5 plans each)
   - "Comprehensive" — Thorough coverage, more phases/plans (8-12 phases, 5-10 plans each)
 
-**Depth controls quantity, not quality.** All depths use 2-3 tasks per plan. Depth determines how many plans get created—more depth means more plans, not bigger plans.
+**Depth controls compression tolerance, not artificial inflation.** All depths use 2-3 tasks per plan. Comprehensive means "don't compress complex work"—it doesn't mean "pad simple work to hit a number."
 
 Create `.planning/config.json` with chosen mode and depth using `templates/config.json` structure.
 

package/get-shit-done/references/scope-estimation.md

@@ -103,17 +103,22 @@ Each: 30-40% context, peak quality, focused commits
 </estimating_context>
 
 <depth_calibration>
-**Depth controls plan count, not plan size.**
+**Depth controls compression tolerance, not artificial inflation.**
 
-| Depth | Phases | Plans/Phase | Tasks/Plan |
-|-------|--------|-------------|------------|
+| Depth | Typical Phases | Typical Plans/Phase | Tasks/Plan |
+|-------|----------------|---------------------|------------|
 | Quick | 3-5 | 1-3 | 2-3 |
 | Standard | 5-8 | 3-5 | 2-3 |
 | Comprehensive | 8-12 | 5-10 | 2-3 |
 
 Tasks/plan is CONSTANT at 2-3. The 50% context rule applies universally.
 
-Depth determines thoroughness by creating more phases and more plans—never by cramming more into each plan.
+**Key principle:** Derive from actual work. Depth determines how aggressively you combine things, not a target to hit.
+
+- Comprehensive auth = 8 plans (because auth genuinely has 8 concerns)
+- Comprehensive "add favicon" = 1 plan (because that's all it is)
+
+Don't pad small work to hit a number. Don't compress complex work to look efficient.
 
 **Comprehensive depth example:**
 Auth system at comprehensive depth = 8 plans (not 3 big ones):

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

@@ -7,6 +7,44 @@ Template for `.planning/phases/XX-name/{phase}-{plan}-SUMMARY.md` - phase comple
 ## File Template
 
 ```markdown
+---
+phase: XX-name
+plan: YY
+subsystem: [primary category: auth, payments, ui, api, database, infra, testing, etc.]
+tags: [searchable tech: jwt, stripe, react, postgres, prisma]
+
+# Dependency graph
+requires:
+  - phase: [prior phase this depends on]
+    provides: [what that phase built that this uses]
+provides:
+  - [bullet list of what this phase built/delivered]
+affects: [list of phase names or keywords that will need this context]
+
+# Tech tracking
+tech-stack:
+  added: [libraries/tools added in this phase]
+  patterns: [architectural/code patterns established]
+
+key-files:
+  created: [important files created]
+  modified: [important files modified]
+
+key-decisions:
+  - "Decision 1"
+  - "Decision 2"
+
+patterns-established:
+  - "Pattern 1: description"
+  - "Pattern 2: description"
+
+issues-created: [ISS-XXX, ISS-YYY] # From ISSUES.md if any
+
+# Metrics
+duration: Xmin
+completed: YYYY-MM-DD
+---
+
 # Phase [X]: [Name] Summary
 
 **[Substantive one-liner describing outcome - NOT "phase complete" or "implementation finished"]**
@@ -74,6 +112,24 @@ Logged to .planning/ISSUES.md for future consideration:
 *Completed: [date]*
 ```
 
+<frontmatter_guidance>
+**Purpose:** Enable automatic context assembly via dependency graph. Frontmatter makes summary metadata machine-readable so plan-phase can scan all summaries quickly and select relevant ones based on dependencies.
+
+**Fast scanning:** Frontmatter is first ~25 lines, cheap to scan across all summaries without reading full content.
+
+**Dependency graph:** `requires`/`provides`/`affects` create explicit links between phases, enabling transitive closure for context selection.
+
+**Subsystem:** Primary categorization (auth, payments, ui, api, database, infra, testing) for detecting related phases.
+
+**Tags:** Searchable technical keywords (libraries, frameworks, tools) for tech stack awareness.
+
+**Key-files:** Important files for @context references in PLAN.md.
+
+**Patterns:** Established conventions future phases should maintain.
+
+**Population:** Frontmatter is populated during summary creation in execute-phase.md. See `<step name="create_summary">` for field-by-field guidance.
+</frontmatter_guidance>
+
 <one_liner_rules>
 The one-liner MUST be substantive:
 
@@ -173,6 +229,11 @@ Logged to .planning/ISSUES.md for future consideration:
 - Required output from execute-phase 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

package/get-shit-done/workflows/create-roadmap.md

@@ -89,20 +89,23 @@ cat .planning/config.json 2>/dev/null | grep depth
 ```
 
 <depth_guidance>
-**Phase count targets by depth:**
+**Depth controls compression tolerance, not artificial inflation.**
 
-| Depth | Target Phases | Plans/Phase | Tasks/Plan |
-|-------|---------------|-------------|------------|
+| Depth | Typical Phases | Typical Plans/Phase | Tasks/Plan |
+|-------|----------------|---------------------|------------|
 | Quick | 3-5 | 1-3 | 2-3 |
 | Standard | 5-8 | 3-5 | 2-3 |
 | Comprehensive | 8-12 | 5-10 | 2-3 |
 
-**Tasks/plan is constant (2-3). Depth scales phases and plans, not task density.**
+**Key principle:** Derive phases from actual work. Depth determines how aggressively you combine things, not a target to hit.
+
+- Comprehensive auth system = 8 phases (because auth genuinely has 8 concerns)
+- Comprehensive "add favicon" = 1 phase (because that's all it is)
 
 For comprehensive depth:
 - Don't compress multiple features into single phases
 - Each major capability gets its own phase
-- "Too many phases" is NOT a concern—thoroughness is the goal
+- Let small things stay small—don't pad to hit a number
 - If you're tempted to combine two things, make them separate phases instead
 
 For quick depth:

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

@@ -990,6 +990,41 @@ Use ~/.claude/get-shit-done/templates/summary.md for structure.
 
 **File location:** `.planning/phases/XX-name/{phase}-{plan}-SUMMARY.md`
 
+**Frontmatter population:**
+
+Before writing summary content, populate frontmatter fields from execution context:
+
+1. **Basic identification:**
+   - phase: From PLAN.md frontmatter
+   - plan: From PLAN.md frontmatter
+   - subsystem: Categorize based on phase focus (auth, payments, ui, api, database, infra, testing, etc.)
+   - tags: Extract tech keywords (libraries, frameworks, tools used)
+
+2. **Dependency graph:**
+   - requires: List prior phases this built upon (check PLAN.md context section for referenced prior summaries)
+   - provides: Extract from accomplishments - what was delivered
+   - affects: Infer from phase description/goal what future phases might need this
+
+3. **Tech tracking:**
+   - tech-stack.added: New libraries from package.json changes or requirements
+   - tech-stack.patterns: Architectural patterns established (from decisions/accomplishments)
+
+4. **File tracking:**
+   - key-files.created: From "Files Created/Modified" section
+   - key-files.modified: From "Files Created/Modified" section
+
+5. **Decisions:**
+   - key-decisions: Extract from "Decisions Made" section
+
+6. **Issues:**
+   - issues-created: Check if ISSUES.md was updated during execution
+
+7. **Metrics:**
+   - duration: From $DURATION variable
+   - completed: From $PLAN_END_TIME (date only, format YYYY-MM-DD)
+
+Note: If subsystem/affects are unclear, use best judgment based on phase name and accomplishments. Can be refined later.
+
 **Title format:** `# Phase [X] Plan [Y]: [Name] Summary`
 
 The one-liner must be SUBSTANTIVE:

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

@@ -124,15 +124,53 @@ For niche domains (3D, games, audio, shaders, ML), suggest `/gsd:research-phase`
 </step>
 
 <step name="read_project_history">
-**From STATE.md:** Decisions → constrain approach. Deferred issues → candidates. Blockers → may need to address.
+**Intelligent context assembly from frontmatter dependency graph:**
 
-**From prior summaries:**
+**1. Scan all summary frontmatter (cheap - first ~25 lines):**
 
 ```bash
-ls .planning/phases/*/*-SUMMARY.md 2>/dev/null | sort
+for f in .planning/phases/*/*-SUMMARY.md; do
+  # Extract frontmatter only (between first two --- markers)
+  sed -n '1,/^---$/p; /^---$/q' "$f" | head -30
+done
 ```
 
-Scan for decisions constraining this phase, issues flagged for "later", warnings in "Next Phase Readiness", patterns to maintain.
+Parse YAML to extract: phase, subsystem, requires, provides, affects, tags, key-decisions, key-files
+
+**2. Build dependency graph for current phase:**
+
+- **Check affects field:** Which prior phases have current phase in their `affects` list? → Direct dependencies
+- **Check subsystem:** Which prior phases share same subsystem? → Related work
+- **Check requires chains:** If phase X requires phase Y, and we need X, we also need Y → Transitive dependencies
+- **Check roadmap:** Any phases marked as dependencies in ROADMAP.md phase description?
+
+**3. Select relevant summaries:**
+
+Auto-select phases that match ANY of:
+- Current phase name/number appears in prior phase's `affects` field
+- Same `subsystem` value
+- In `requires` chain (transitive closure)
+- Explicitly mentioned in STATE.md decisions as affecting current phase
+
+Typical selection: 2-4 prior phases (immediately prior + related subsystem work)
+
+**4. Extract context from frontmatter (WITHOUT opening full summaries yet):**
+
+From selected phases' frontmatter, extract:
+- **Tech available:** Union of all tech-stack.added lists
+- **Patterns established:** Union of all tech-stack.patterns and patterns-established
+- **Key files:** Union of all key-files (for @context references)
+- **Decisions:** Extract key-decisions from frontmatter
+
+**5. Now read FULL summaries for selected phases:**
+
+Only now open and read complete SUMMARY.md files for the selected relevant phases. Extract:
+- Detailed "Accomplishments" section
+- "Next Phase Readiness" warnings/blockers
+- "Issues Encountered" that might affect current phase
+- "Deviations from Plan" for patterns
+
+**From STATE.md:** Decisions → constrain approach. Deferred issues → candidates. Blockers → may need to address.
 
 **From ISSUES.md:**
 
@@ -148,7 +186,14 @@ Assess each open issue - relevant to this phase? Waiting long enough? Natural to
 - Q3: Are there concerns from "Next Phase Readiness" that apply?
 - Q4: Given all context, does the roadmap's description still make sense?
 
-Track for PLAN.md context section: relevant summaries, applicable decisions, issues being addressed, concerns being verified.
+**Track for PLAN.md context section:**
+- Which summaries were selected (for @context references)
+- Tech stack available (from frontmatter)
+- Established patterns (from frontmatter)
+- Key files to reference (from frontmatter)
+- Applicable decisions (from frontmatter + full summary)
+- Issues being addressed (from ISSUES.md)
+- Concerns being verified (from "Next Phase Readiness")
 </step>
 
 <step name="gather_phase_context">
@@ -232,20 +277,24 @@ cat .planning/config.json 2>/dev/null | grep depth
 ```
 
 <depth_aware_splitting>
-**Plan count targets by depth:**
+**Depth controls compression tolerance, not artificial inflation.**
 
-| Depth | Plans/Phase | Tasks/Plan |
-|-------|-------------|------------|
+| Depth | Typical Plans/Phase | Tasks/Plan |
+|-------|---------------------|------------|
 | Quick | 1-3 | 2-3 |
 | Standard | 3-5 | 2-3 |
 | Comprehensive | 5-10 | 2-3 |
 
-**Tasks/plan is ALWAYS 2-3. Depth determines how many plans you create, not how big each plan is.**
+**Key principle:** Derive plans from actual work. Depth determines how aggressively you combine things, not a target to hit.
+
+- Comprehensive auth phase = 8 plans (because auth genuinely has 8 concerns)
+- Comprehensive "add config file" phase = 1 plan (because that's all it is)
 
 For comprehensive depth:
-- Create MORE plans, not bigger ones
+- Create MORE plans when the work warrants it, not bigger ones
 - If a phase has 15 tasks, that's 5-8 plans (not 3 plans with 5 tasks each)
 - Don't compress to look efficient—thoroughness is the goal
+- Let small phases stay small—don't pad to hit a number
 - Each plan stays focused: 2-3 tasks, single concern
 
 For quick depth:
@@ -308,7 +357,37 @@ Each plan follows template structure with:
 - Tasks (XML format with types)
 - Verification, Success criteria, Output specification
 
-For multi-plan phases: each plan has focused scope, references previous plan summaries, last plan's success criteria includes "Phase X complete".
+**Context section population from frontmatter analysis:**
+
+Inject automatically-assembled context package from read_project_history step:
+
+```markdown
+<context>
+@.planning/PROJECT.md
+@.planning/ROADMAP.md
+@.planning/STATE.md
+
+# Auto-selected based on dependency graph (from frontmatter):
+@.planning/phases/XX-name/YY-ZZ-SUMMARY.md
+@.planning/phases/AA-name/BB-CC-SUMMARY.md
+
+# Key files from frontmatter (relevant to this phase):
+@path/to/important/file.ts
+@path/to/another/file.ts
+
+**Tech stack available:** [extracted from frontmatter tech-stack.added]
+**Established patterns:** [extracted from frontmatter patterns-established]
+**Constraining decisions:**
+- [Phase X]: [decision from frontmatter]
+- [Phase Y]: [decision from frontmatter]
+
+**Issues being addressed:** [If any from ISSUES.md]
+</context>
+```
+
+This ensures every PLAN.md gets optimal context automatically assembled via dependency graph, making execution as informed as possible.
+
+For multi-plan phases: each plan has focused scope, references previous plan summaries (via frontmatter selection), last plan's success criteria includes "Phase X complete".
 </step>
 
 <step name="offer_next">

package/package.json

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