@leeovery/claude-technical-workflows 2.0.22 → 2.0.23

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@leeovery/claude-technical-workflows",
-  "version": "2.0.22",
+  "version": "2.0.23",
   "description": "Technical workflow skills & commands for Claude Code",
   "license": "MIT",
   "author": "Lee Overy <me@leeovery.com>",

package/skills/technical-discussion/references/template.md

@@ -15,7 +15,7 @@ This is a single file per topic.
 ```markdown
 # Discussion: {Topic}
 
-**Date**: YYYY-MM-DD
+**Date**: YYYY-MM-DD *(use today's actual date)*
 **Status**: Exploring | Deciding | Concluded
 
 ## Context

package/skills/technical-planning/references/output-backlog-md.md

@@ -59,7 +59,7 @@ project: {TOPIC_NAME}
 # Plan Reference: {Topic Name}
 
 **Specification**: `docs/workflow/specification/{topic}.md`
-**Created**: {DATE}
+**Created**: YYYY-MM-DD *(use today's actual date)*
 
 ## About This Plan
 

package/skills/technical-planning/references/output-beads.md

@@ -246,7 +246,7 @@ epic: bd-{EPIC_ID}
 # Plan Reference: {Topic Name}
 
 **Specification**: `docs/workflow/specification/{topic}.md`
-**Created**: {DATE}
+**Created**: YYYY-MM-DD *(use today's actual date)*
 
 ## About This Plan
 

package/skills/technical-planning/references/output-linear.md

@@ -156,7 +156,7 @@ team: {TEAM_NAME}
 # Plan Reference: {Topic Name}
 
 **Specification**: `docs/workflow/specification/{topic}.md`
-**Created**: {DATE}
+**Created**: YYYY-MM-DD *(use today's actual date)*
 
 ## About This Plan
 

package/skills/technical-planning/references/output-local-markdown.md

@@ -38,7 +38,7 @@ format: local-markdown
 
 # Implementation Plan: {Feature/Project Name}
 
-**Date**: YYYY-MM-DD
+**Date**: YYYY-MM-DD *(use today's actual date)*
 **Status**: Draft | Ready | In Progress | Completed
 **Specification**: `docs/workflow/specification/{topic}.md`
 
@@ -145,7 +145,7 @@ Triggers and steps
 
 | Date | Change |
 |------|--------|
-| YYYY-MM-DD | Created from specification |
+| YYYY-MM-DD *(use today's actual date)* | Created from specification |
 ```
 
 ## Cross-Topic Dependencies

package/skills/technical-specification/SKILL.md

@@ -48,6 +48,8 @@ Either way: Transform unvalidated reference material into a specification that's
 
 5. **Log**: Only when approved, write content verbatim to the specification.
 
+6. **Final review**: After all topics and dependencies are documented, perform a comprehensive review of ALL source material against the specification. Flag any potentially missed content to the user - but only from the sources, never fabricated. User confirms before any additions.
+
 The specification is the **golden document** - planning uses only this. If information doesn't make it into the specification, it won't be built. No references back to source material.
 
 ## Critical Rules

package/skills/technical-specification/references/specification-guide.md

@@ -104,7 +104,7 @@ Suggested skeleton:
 # Specification: [Topic Name]
 
 **Status**: Building specification
-**Last Updated**: [timestamp]
+**Last Updated**: YYYY-MM-DD *(use today's actual date)*
 
 ---
 
@@ -209,6 +209,91 @@ This section feeds into the planning phase, where dependencies become blocking r
 
 **Key distinction**: This is about sequencing what must come first, not mapping out what works together. A feature may integrate with many systems - only list the ones that block you from starting.
 
+## Final Specification Review
+
+After documenting dependencies, perform a **final comprehensive review** of the entire specification against all source material. This is your last chance to catch anything that was missed.
+
+**Why this matters**: The specification is the golden document. Plans are built from it. If a detail isn't in the specification, it won't be built - regardless of whether it was in the source material.
+
+### The Review Process
+
+1. **Re-read ALL source material** - Go back to every source document, discussion, research note, and reference. Don't rely on memory.
+
+2. **Compare systematically** - For each piece of source material:
+   - What topics does it cover?
+   - Are those topics fully captured in the specification?
+   - Are there details, edge cases, or decisions that didn't make it?
+
+3. **Search for the forgotten** - Look specifically for:
+   - Edge cases mentioned in passing
+   - Constraints or requirements buried in tangential discussions
+   - Technical details that seemed minor at the time
+   - Decisions made early that may have been overshadowed
+   - Error handling, validation rules, or boundary conditions
+   - Integration points or data flows mentioned but not elaborated
+
+4. **Flag what you find** - When you discover potentially missed content, present it to the user. There are two cases:
+
+   **Enhancing an existing topic** - Details that belong in an already-documented section:
+
+   > "During my final review, I found additional detail about [existing topic] that isn't captured. From [source]:
+   >
+   > [quote or summary from source material]
+   >
+   > I'd add this to the [section name] section. Would you like me to include it, or show you the full section with this addition first?"
+
+   If the user wants to see context, present the entire section with the new content clearly marked (e.g., with a comment like `<!-- NEW -->` or by calling it out before the block).
+
+   **An entirely missed topic** - Something that warrants its own section but was glossed over:
+
+   > "During my final review, I found [topic] discussed in [source] that doesn't have coverage in the specification:
+   >
+   > [quote or summary from source material]
+   >
+   > This would be a new section. Should I add it?"
+
+   In both cases, you know where the content belongs - existing topics get enhanced in place, new topics get added at the end.
+
+5. **Never fabricate** - Every item you flag must trace back to specific source material. If you can't point to where it came from, don't suggest it. The goal is to catch missed content, not invent new requirements.
+
+6. **User confirms before inclusion** - Standard workflow applies: present proposed additions, get approval, then log verbatim.
+
+7. **Surface potential gaps** - After reviewing source material, consider whether the specification has gaps that the sources simply didn't address. These might be:
+   - Edge cases that weren't discussed
+   - Error scenarios not covered
+   - Integration points that seem implicit but aren't specified
+   - Behaviors that are ambiguous without clarification
+
+   Present these as a batch for the user to triage:
+
+   > "I've identified some potential gaps that aren't covered in the source material:
+   >
+   > 1. **[Gap A]** - [brief description of what's unclear/missing]
+   > 2. **[Gap B]** - [brief description]
+   > 3. **[Gap C]** - [brief description]
+   >
+   > Are any of these areas you'd like to discuss, or are they intentionally out of scope?"
+
+   The user can then pick which gaps (if any) need addressing. For those they want to discuss, work through them and add to the specification with standard approval workflow.
+
+   This should be infrequent - most gaps will be caught from source material. But occasionally the sources themselves have blind spots worth surfacing.
+
+### What You're NOT Doing
+
+- **Not inventing requirements** - When surfacing gaps not in sources, you're asking questions, not proposing answers
+- **Not assuming gaps need filling** - If something isn't in the sources, it may have been intentionally omitted
+- **Not padding the spec** - Only add what's genuinely missing and relevant
+- **Not re-litigating decisions** - If something was discussed and rejected, it stays rejected
+
+### Completing the Review
+
+When you've:
+- Systematically reviewed all source material for missed content
+- Addressed any discovered gaps with the user
+- Surfaced any potential gaps not covered by sources (and resolved them)
+
+...then inform the user the final review is complete and proceed to getting sign-off on the specification.
+
 ## Completion
 
 Specification is complete when: