@leeovery/claude-technical-workflows 2.0.42 → 2.0.44

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

@@ -33,15 +33,15 @@ Create `{topic}.md` with this structure:
 
 ```markdown
 ---
+topic: {feature-name}
+status: in-progress
+date: YYYY-MM-DD
 format: local-markdown
+specification: {topic}.md
 ---
 
 # Implementation Plan: {Feature/Project Name}
 
-**Date**: YYYY-MM-DD *(use today's actual date)*
-**Status**: Draft | Ready | In Progress | Completed
-**Specification**: `docs/workflow/specification/{topic}.md`
-
 ## Overview
 
 **Goal**: What we're building and why (one sentence)
@@ -222,7 +222,19 @@ grep -A 5 "### Phase 1" docs/workflow/planning/billing-system.md | grep "\[x\]"
 
 ## Frontmatter
 
-The `format: local-markdown` frontmatter tells implementation that the full plan content is in this file.
+Plan documents use YAML frontmatter for metadata:
+
+```yaml
+---
+topic: {feature-name}        # Matches filename (without .md)
+status: in-progress          # in-progress | concluded
+date: YYYY-MM-DD             # Creation date
+format: local-markdown       # Output format used
+specification: {topic}.md    # Source specification filename
+---
+```
+
+The `format` field tells implementation which output adapter to use for reading/updating the plan.
 
 ## Flagging Incomplete Tasks
 

package/skills/technical-research/SKILL.md

@@ -58,9 +58,18 @@ Ask one question at a time. Wait for the answer. Document. Then ask the next.
 
 **Output**: `docs/workflow/research/exploration.md`
 
+**Template**: Use `references/template.md` for document structure. All research documents use YAML frontmatter:
+
+```yaml
+---
+topic: exploration
+date: YYYY-MM-DD  # Use today's actual date
+---
+```
+
 Start with one file. Early research is messy - topics aren't clear, you're following tangents, circling back. Don't force structure too early.
 
-**Let themes emerge**: Over multiple sessions, topics may become distinct. When they do, split into semantic files (`market-landscape.md`, `technical-feasibility.md`).
+**Let themes emerge**: Over multiple sessions, topics may become distinct. When they do, split into semantic files (`market-landscape.md`, `technical-feasibility.md`). Update the `topic` field to match the filename.
 
 **Periodic review**: Every few sessions, assess: are themes emerging? Split them out. Still fuzzy? Keep exploring. Ready for deeper discussion or specification? Research is complete.
 

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

@@ -0,0 +1,39 @@
+# Research Document Template
+
+Use this template when creating research documents.
+
+## Template
+
+```markdown
+---
+topic: exploration
+date: YYYY-MM-DD  # Use today's actual date
+---
+
+# Research: {Title}
+
+Brief description of what this research covers and what prompted it.
+
+## Starting Point
+
+What we know so far:
+- {Initial thoughts or context from the user}
+- {Any constraints or existing knowledge}
+- {Where we're starting: technical, market, business, etc.}
+
+---
+
+{Content follows - freeform, managed by the skill}
+```
+
+## Field Notes
+
+- `topic`: Use `exploration` for the initial exploration file. Use semantic names (`market-landscape`, `technical-feasibility`) when splitting into focused files.
+- `date`: Today's date when creating the document.
+
+## Notes
+
+- The "Starting Point" section captures context from the initial conversation
+- Content after that is intentionally unstructured - let themes emerge naturally
+- When splitting into topic files, update the `topic` field to match the filename
+- The skill handles content organization during sessions

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

@@ -143,13 +143,14 @@ This is a single file per topic. Structure is **flexible** - organize around pha
 Suggested skeleton:
 
 ```markdown
-# Specification: [Topic Name]
-
-**Status**: Building specification
-**Type**: feature | cross-cutting
-**Last Updated**: YYYY-MM-DD *(use today's actual date)*
-
 ---
+topic: {topic-name}
+status: in-progress
+type: feature
+date: YYYY-MM-DD  # Use today's actual date
+---
+
+# Specification: [Topic Name]
 
 ## Specification
 
@@ -162,6 +163,13 @@ Suggested skeleton:
 [Optional - capture in-progress discussion if needed]
 ```
 
+### Frontmatter Fields
+
+- **topic**: Kebab-case identifier matching the filename
+- **status**: `in-progress` (building) or `concluded` (complete)
+- **type**: `feature` (something to build) or `cross-cutting` (patterns/policies)
+- **date**: Last updated date
+
 ## Specification Types
 
 The `Type` field distinguishes between specifications that result in standalone implementation work versus those that inform how other work is done.
@@ -687,11 +695,12 @@ Once the type is confirmed and tracking files are removed, ask for final sign-of
 After user confirms, update the specification frontmatter:
 
 ```markdown
-# Specification: [Topic Name]
-
-**Status**: Complete
-**Type**: [feature/cross-cutting]
-**Last Updated**: YYYY-MM-DD
+---
+topic: {topic-name}
+status: concluded
+type: feature  # or cross-cutting
+date: YYYY-MM-DD  # Use today's actual date
+---
 ```
 
 Specification is complete when: