@leeovery/claude-technical-workflows 2.0.24 → 2.0.26

package/commands/workflow:start-planning.md

@@ -39,12 +39,18 @@ Scan the codebase for specifications and plans:
    - Run `ls docs/workflow/specification/` to list specification files
    - Each file is named `{topic}.md`
 
-2. **Check specification status**: For each specification file
-   - Run `head -20 docs/workflow/specification/{topic}.md` to read the frontmatter and extract the `status:` field
+2. **Check specification metadata**: For each specification file
+   - Run `head -20 docs/workflow/specification/{topic}.md` to read the frontmatter
+   - Extract the `status:` field (Building specification | Complete)
+   - Extract the `type:` field (feature | cross-cutting) - if not present, default to `feature`
    - Do NOT use bash loops - run separate `head` commands for each topic
 
-3. **Check for existing plans**: Look in `docs/workflow/planning/`
-   - Identify specifications that don't have corresponding plans
+3. **Categorize specifications**:
+   - **Feature specifications** (`type: feature` or unspecified): Candidates for planning
+   - **Cross-cutting specifications** (`type: cross-cutting`): Reference context only - do NOT offer for planning
+
+4. **Check for existing plans**: Look in `docs/workflow/planning/`
+   - Identify feature specifications that don't have corresponding plans
 
 ## Step 2: Check Prerequisites
 
@@ -60,22 +66,29 @@ Stop here and wait for the user to acknowledge.
 
 ## Step 3: Present Options to User
 
-Show what you found using a list like below:
+Show what you found, separating feature specs (planning targets) from cross-cutting specs (reference context):
 
 ```
-📂 Specifications found:
+📂 Feature Specifications (planning targets):
   ⚠️ {topic-1} - Building specification - not ready for planning
   ✅ {topic-2} - Complete - ready for planning
   ✅ {topic-3} - Complete - plan exists
 
-Which specification would you like to create a plan for?
+📚 Cross-Cutting Specifications (reference context):
+  ✅ {caching-strategy} - Complete - will inform planning
+  ✅ {rate-limiting} - Complete - will inform planning
+
+Which feature specification would you like to create a plan for?
 ```
 
-**Important:** Only completed specifications should proceed to planning. If a specification is still being built, advise the user to complete the specification phase first.
+**Important:**
+- Only completed **feature** specifications should proceed to planning
+- **Cross-cutting** specifications are NOT planning targets - they inform feature plans
+- If a specification is still being built, advise the user to complete the specification phase first
 
-**Auto-select:** If exactly one specification exists, automatically select it and proceed to Step 4. Inform the user which specification was selected. Do not ask for confirmation.
+**Auto-select:** If exactly one completed feature specification exists, automatically select it and proceed to Step 4. Inform the user which specification was selected. Do not ask for confirmation.
 
-Ask: **Which specification would you like to plan?**
+Ask: **Which feature specification would you like to plan?**
 
 ## Step 4: Choose Output Destination
 
@@ -88,6 +101,26 @@ Load **[output-formats.md](../skills/technical-planning/references/output-format
 - Any additional context or priorities to consider?
 - Any constraints since the specification was completed?
 
+## Step 5b: Surface Cross-Cutting Context
+
+If any **completed cross-cutting specifications** exist, surface them as reference context for planning:
+
+1. **List applicable cross-cutting specs**:
+   - Read each cross-cutting specification
+   - Identify which ones are relevant to the feature being planned
+   - Relevance is determined by topic overlap (e.g., caching strategy applies if the feature involves data retrieval or API calls)
+
+2. **Summarize for handoff**:
+   ```
+   Cross-cutting specifications to reference:
+   - caching-strategy.md: [brief summary of key decisions]
+   - rate-limiting.md: [brief summary of key decisions]
+   ```
+
+These specifications contain validated architectural decisions that should inform the plan. The planning skill will incorporate these as a "Cross-Cutting References" section in the plan.
+
+**If no cross-cutting specifications exist**: Skip this step.
+
 ## Step 6: Invoke the Skill
 
 After completing the steps above, this command's purpose is fulfilled.
@@ -100,6 +133,7 @@ Planning session for: {topic}
 Specification: docs/workflow/specification/{topic}.md
 Output format: {format}
 Additional context: {summary of user's answers from Step 5}
+Cross-cutting references: {list of applicable cross-cutting specs with brief summaries, or "none"}
 
 Invoke the technical-planning skill.
 ```
@@ -107,4 +141,6 @@ Invoke the technical-planning skill.
 ## Notes
 
 - Ask questions clearly and wait for responses before proceeding
-- The specification is the sole source of truth for planning - do not reference discussions
+- The feature specification is the primary source of truth for planning
+- Cross-cutting specifications provide supplementary context for architectural decisions
+- Do not reference discussions - only specifications

package/commands/workflow:start-specification.md

@@ -1,5 +1,5 @@
 ---
-description: Start a specification session from an existing discussion. Discovers available discussions, checks for existing specifications, and invokes the technical-specification skill.
+description: Start a specification session from existing discussions. Discovers available discussions, offers consolidation assessment for multiple discussions, and invokes the technical-specification skill.
 ---
 
 Invoke the **technical-specification** skill for this conversation.
@@ -17,7 +17,7 @@ This is **Phase 3** of the six-phase workflow:
 | 5. Implementation | DOING - tests first, then code | |
 | 6. Review | VALIDATING - check work against artifacts | |
 
-**Stay in your lane**: Validate and refine discussion content into a standalone specification. Don't jump to planning, phases, tasks, or code. The specification is the "line in the sand" - everything after this has hard dependencies on it.
+**Stay in your lane**: Validate and refine discussion content into standalone specifications. Don't jump to planning, phases, tasks, or code. The specification is the "line in the sand" - everything after this has hard dependencies on it.
 
 ---
 
@@ -46,40 +46,221 @@ Scan the codebase for discussions and specifications:
 3. **Check for existing specifications**: Look in `docs/workflow/specification/`
    - Identify discussions that don't have corresponding specifications
 
+4. **Check for cached consolidation analysis** (if multiple discussions):
+   - Check if `docs/workflow/.cache/discussion-consolidation-analysis.md` exists
+   - If it exists, read it to get the stored checksum from the frontmatter
+
+5. **Compute current discussions checksum** (if multiple concluded discussions):
+   - Run exactly: `cat docs/workflow/discussion/*.md 2>/dev/null | md5sum | cut -d' ' -f1`
+   - IMPORTANT: Use this exact command - glob expansion is alphabetically sorted by default
+   - Do NOT modify or "simplify" this command - checksum must be deterministic
+   - Store this value to compare with the cached checksum
+
 ## Step 2: Check Prerequisites
 
 **If no discussions exist:**
 
 ```
-⚠️ No discussions found in docs/workflow/discussion/
+No discussions found in docs/workflow/discussion/
 
 The specification phase requires a completed discussion. Please run /workflow:start-discussion first to document the technical decisions, edge cases, and rationale before creating a specification.
 ```
 
 Stop here and wait for the user to acknowledge.
 
-## Step 3: Present Options to User
+## Step 3: Present Options
 
-Show what you found using a list like below:
+Show what you found:
 
 ```
-📂 Discussions found:
-  ✅ {topic-1} - Concluded - ready for specification
-  ⚠️ {topic-2} - Exploring - not ready for specification
-  ✅ {topic-3} - Concluded - specification exists
-
-Which discussion would you like to create a specification for?
+Discussions found:
+  {topic-1} - Concluded - ready for specification
+  {topic-2} - Exploring - not ready for specification
+  {topic-3} - Concluded - specification exists
 ```
 
 **Important:** Only concluded discussions should proceed to specification. If a discussion is still exploring, advise the user to complete the discussion phase first.
 
-Ask: **Which discussion would you like to specify?**
+**If only ONE concluded discussion is ready:** Skip to Step 4 (single-source path).
+
+**If MORE THAN ONE concluded discussion is ready:** Proceed to Step 3A (consolidation assessment).
+
+---
+
+## Step 3A: Consolidation Assessment (Multiple Discussions)
+
+When multiple concluded discussions exist, offer to assess how they should be organized into specifications.
+
+```
+You have {N} concluded discussions ready for specification.
+
+Would you like me to assess how these might be combined into specifications?
+
+1. **Yes, assess them** - I'll analyze all discussions for natural groupings
+2. **No, proceed individually** - Create specifications 1:1 with discussions
+
+Which approach?
+```
+
+**If user chooses individual:** Skip to Step 4 and ask which discussion to specify.
+
+**If user chooses assessment:** Proceed to Step 3A.1.
+
+### Step 3A.1: Gather Context for Analysis
+
+Before analyzing, ask:
+
+```
+Before I analyze the discussions, is there anything about your project structure or how these topics relate that would help me group them appropriately?
+```
+
+Wait for response.
+
+### Step 3A.2: Check Cache Validity
+
+Compare the current discussions checksum (computed in Step 1.5) with the cached checksum:
+
+**If cache exists AND checksums match:**
+```
+Using cached analysis
+
+Discussion documents unchanged since last analysis ({date from cache}).
+Loading previously identified groupings...
+
+To force a fresh analysis, enter: refresh
+```
+
+Then load the groupings from the cache file and skip to Step 3A.4 (Present Options).
+
+**If cache missing OR checksums differ:**
+```
+Analyzing discussions...
+```
+
+Proceed to Step 3A.3 (Full Analysis).
+
+### Step 3A.3: Full Analysis (when cache invalid)
+
+**This step is critical. You MUST read every concluded discussion document thoroughly.**
+
+For each concluded discussion:
+1. Read the ENTIRE document (not just frontmatter)
+2. Understand the decisions, systems, and concepts it defines
+3. Note dependencies on or references to other discussions
+4. Identify shared data structures, entities, or behaviors
+
+Then analyze coupling between discussions:
+- **Data coupling**: Discussions that define or depend on the same data structures
+- **Behavioral coupling**: Discussions where one's implementation requires another
+- **Conceptual coupling**: Discussions that address different facets of the same problem
+
+Group discussions that are tightly coupled - they should become a single specification because their decisions are inseparable.
+
+**Save to cache:**
+After analysis, ensure `.cache` directory exists: `mkdir -p docs/workflow/.cache`
+
+Create/update `docs/workflow/.cache/discussion-consolidation-analysis.md`:
+
+```markdown
+---
+checksum: {computed_checksum}
+generated: {ISO date}
+discussion_files:
+  - {topic1}.md
+  - {topic2}.md
+---
+
+# Discussion Consolidation Analysis
+
+## Recommended Groupings
+
+### {Suggested Specification Name}
+- **{topic-a}**: {why it belongs in this group}
+- **{topic-b}**: {why it belongs in this group}
+- **{topic-c}**: {why it belongs in this group}
+
+**Coupling**: {Brief explanation of what binds these together - shared data, dependencies, etc.}
+
+### {Another Specification Name}
+- **{topic-d}**: {why it belongs}
+- **{topic-e}**: {why it belongs}
+
+**Coupling**: {Brief explanation}
+
+## Independent Discussions
+- **{topic-f}**: {Why this stands alone - no strong coupling to others}
+
+## Analysis Notes
+{Any additional context about the relationships discovered}
+```
+
+### Step 3A.4: Present Options
+
+Present the analysis and options:
+
+**If using cached analysis:**
+```
+Cached analysis (discussions unchanged since {date})
+
+{Display the Recommended Groupings section from cache}
+
+How would you like to proceed?
+
+1. **Combine as recommended** - Create specifications per the groupings above
+2. **Combine differently** - Tell me your preferred groupings
+3. **Single specification** - Consolidate all discussions into one spec
+4. **Individual specifications** - Create 1:1 (I'll ask which to start with)
+
+(Or enter 'refresh' to re-analyze)
+```
+
+**If fresh analysis:**
+```
+Analysis complete (cached for future sessions)
+
+{Display the Recommended Groupings section}
+
+How would you like to proceed?
+
+1. **Combine as recommended** - Create specifications per the groupings above
+2. **Combine differently** - Tell me your preferred groupings
+3. **Single specification** - Consolidate all discussions into one spec
+4. **Individual specifications** - Create 1:1 (I'll ask which to start with)
+```
+
+Wait for user to choose.
+
+### Step 3A.5: Handle Choices
+
+**If "Combine as recommended":**
+- Confirm the first specification to create
+- Proceed to Step 4 with the grouped sources
+
+**If "Combine differently":**
+- Ask user to describe their preferred groupings
+- Confirm understanding
+- Proceed to Step 4 with user-specified sources
+
+**If "Single specification":**
+- Use "unified" as the specification name (output: `docs/workflow/specification/unified.md`)
+- Proceed to Step 4 with all discussions as sources
+
+**If "Individual specifications":**
+- Ask which discussion to specify first
+- Proceed to Step 4 with single source
+
+**If "refresh":**
+- Delete the cache file: `rm docs/workflow/.cache/discussion-consolidation-analysis.md`
+- Return to Step 3A.3 (Full Analysis)
+- Inform user: "Refreshing analysis..."
+
+---
 
 ## Step 4: Gather Additional Context
 
 Ask:
 - Any additional context or priorities to consider?
-- Any constraints or changes since the discussion concluded?
+- Any constraints or changes since the discussion(s) concluded?
 - Are there any existing partial plans or related documentation I should review?
 
 ## Step 5: Invoke the Skill
@@ -88,7 +269,7 @@ After completing the steps above, this command's purpose is fulfilled.
 
 Invoke the [technical-specification](../skills/technical-specification/SKILL.md) skill for your next instructions. Do not act on the gathered information until the skill is loaded - it contains the instructions for how to proceed.
 
-**Example handoff:**
+**Example handoff (single source):**
 ```
 Specification session for: {topic}
 Source: docs/workflow/discussion/{topic}.md
@@ -98,7 +279,26 @@ Additional context: {summary of user's answers from Step 4}
 Invoke the technical-specification skill.
 ```
 
+**Example handoff (multiple sources):**
+```
+Specification session for: {specification-name}
+
+Sources:
+- docs/workflow/discussion/{topic-1}.md
+- docs/workflow/discussion/{topic-2}.md
+- docs/workflow/discussion/{topic-3}.md
+
+Output: docs/workflow/specification/{specification-name}.md
+Additional context: {summary of user's answers from Step 4}
+
+Invoke the technical-specification skill.
+```
+
+---
+
 ## Notes
 
 - Ask questions clearly and wait for responses before proceeding
-- The specification phase validates and refines discussion content into a standalone document
+- The specification phase validates and refines discussion content into standalone documents
+- When multiple sources are provided, the skill will extract exhaustively from ALL of them
+- Attribution in the specification should trace content back to its source discussion(s)

package/package.json

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

package/skills/technical-planning/SKILL.md

@@ -22,9 +22,20 @@ Either way: Transform specifications into actionable phases, tasks, and acceptan
 - **Specification content** (required) - The validated decisions and requirements to plan from
 - **Topic name** (optional) - Will derive from specification if not provided
 - **Output format preference** (optional) - Will ask if not specified
+- **Cross-cutting references** (optional) - List of cross-cutting specifications that inform this plan
 
 **If missing:** Will ask user for specification location or content.
 
+### Cross-Cutting References
+
+If cross-cutting specifications are provided (e.g., caching strategy, rate limiting policy), incorporate their decisions into the plan:
+
+1. **Include a "Cross-Cutting References" section** in the plan linking to these specifications
+2. **Apply their patterns** when designing phases and tasks (e.g., if caching strategy says "cache API responses for 5 minutes", include that in relevant tasks)
+3. **Note where patterns apply** - when a task implements a cross-cutting pattern, reference it
+
+Cross-cutting specifications are architectural decisions that inform HOW features are built. They don't have their own implementation plans - instead, their patterns are applied within feature plans.
+
 ## Source Material
 
 **The specification is your sole input.** Everything you need should be in the specification - do not request details from prior source material. If information is missing, ask for clarification on the specification itself.

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

@@ -88,6 +88,17 @@ Tasks are organized with labels/priorities:
 
 [Summary of key decisions from specification]
 
+## Cross-Cutting References
+
+Architectural decisions from cross-cutting specifications that inform this plan:
+
+| Specification | Key Decisions | Applies To |
+|---------------|---------------|------------|
+| [Caching Strategy](../specification/caching-strategy.md) | Cache API responses for 5 min | Tasks involving API calls |
+| [Rate Limiting](../specification/rate-limiting.md) | 100 req/min per user | User-facing endpoints |
+
+*Remove this section if no cross-cutting specifications apply.*
+
 ## External Dependencies
 
 [Dependencies on other topics - copy from specification's Dependencies section]

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

@@ -269,6 +269,17 @@ This plan is managed via Beads. Tasks are stored in `.beads/` and tracked as a d
 
 [Summary of key decisions from specification]
 
+## Cross-Cutting References
+
+Architectural decisions from cross-cutting specifications that inform this plan:
+
+| Specification | Key Decisions | Applies To |
+|---------------|---------------|------------|
+| [Caching Strategy](../specification/caching-strategy.md) | Cache API responses for 5 min | Tasks involving API calls |
+| [Rate Limiting](../specification/rate-limiting.md) | 100 req/min per user | User-facing endpoints |
+
+*Remove this section if no cross-cutting specifications apply.*
+
 ## Phase Overview
 
 | Phase | Goal | Epic ID |

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

@@ -179,6 +179,17 @@ This plan is managed in Linear. The source of truth for tasks and progress is th
 
 [Summary of key decisions from specification - for quick reference]
 
+## Cross-Cutting References
+
+Architectural decisions from cross-cutting specifications that inform this plan:
+
+| Specification | Key Decisions | Applies To |
+|---------------|---------------|------------|
+| [Caching Strategy](../specification/caching-strategy.md) | Cache API responses for 5 min | Tasks involving API calls |
+| [Rate Limiting](../specification/rate-limiting.md) | 100 req/min per user | User-facing endpoints |
+
+*Remove this section if no cross-cutting specifications apply.*
+
 ## External Dependencies
 
 [Dependencies on other topics - copy from specification's Dependencies section]

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

@@ -54,6 +54,17 @@ format: local-markdown
 - Decision 1: Rationale
 - Decision 2: Rationale
 
+## Cross-Cutting References
+
+Architectural decisions from cross-cutting specifications that inform this plan:
+
+| Specification | Key Decisions | Applies To |
+|---------------|---------------|------------|
+| [Caching Strategy](../specification/caching-strategy.md) | Cache API responses for 5 min; use Redis | Tasks involving API calls |
+| [Rate Limiting](../specification/rate-limiting.md) | 100 req/min per user; sliding window | User-facing endpoints |
+
+*Remove this section if no cross-cutting specifications apply.*
+
 ## Architecture
 
 - Components

package/skills/technical-specification/SKILL.md

@@ -19,8 +19,8 @@ Either way: Transform unvalidated reference material into a specification that's
 
 ### What This Skill Needs
 
-- **Source material** (required) - The content to synthesize into a specification. Can be:
-  - Discussion documents or research notes
+- **Source material** (required) - One or more sources to synthesize into a specification. Can be:
+  - Discussion documents or research notes (single or multiple)
   - Inline feature descriptions
   - Requirements docs, design documents, or transcripts
   - Any other reference material
@@ -28,6 +28,8 @@ Either way: Transform unvalidated reference material into a specification that's
 
 **If missing:** Will ask user to provide context or point to source files.
 
+**Multiple sources:** When multiple sources are provided, extract exhaustively from ALL of them. Content may be scattered across sources - a decision in one may have constraints or details in another. The specification consolidates everything into a single standalone document.
+
 ## The Process
 
 **Load**: [specification-guide.md](references/specification-guide.md)
@@ -62,7 +64,7 @@ If you are uncertain whether the user approved, **ASK**: "Would you like me to l
 
 ## What You Do
 
-1. **Extract exhaustively**: For each topic, re-scan ALL source material. Search for keywords and related terms. Information is often scattered - collect it all before synthesizing. Include only what we're building (not discarded alternatives).
+1. **Extract exhaustively**: For each topic, re-scan ALL source materials. When working with multiple sources, search each one - information about a single topic may be scattered across documents. Search for keywords and related terms. Collect everything before synthesizing. Include only what we're building (not discarded alternatives).
 
 2. **Filter**: Reference material may contain hallucinations, inaccuracies, or outdated concepts. Validate before including.
 
@@ -88,6 +90,8 @@ The specification is the **golden document** - planning uses only this. If infor
 
 **Trust nothing without validation**: Synthesize and present, but never assume source material is correct.
 
+**Surface conflicts**: When sources contain conflicting decisions, flag the conflict to the user during the discussion. Don't silently pick one - let the user decide what makes it into the specification.
+
 ---
 
 ## Self-Check: Are You Following the Rules?

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

@@ -146,6 +146,7 @@ Suggested skeleton:
 # Specification: [Topic Name]
 
 **Status**: Building specification
+**Type**: feature | cross-cutting
 **Last Updated**: YYYY-MM-DD *(use today's actual date)*
 
 ---
@@ -161,6 +162,73 @@ Suggested skeleton:
 [Optional - capture in-progress discussion if needed]
 ```
 
+## Specification Types
+
+The `Type` field distinguishes between specifications that result in standalone implementation work versus those that inform how other work is done.
+
+### Feature Specifications (`type: feature`)
+
+Feature specifications describe something to **build** - a concrete piece of functionality with its own implementation plan.
+
+**Examples:**
+- User authentication system
+- Order processing pipeline
+- Notification service
+- Dashboard analytics
+
+**Characteristics:**
+- Results in a dedicated implementation plan
+- Has concrete deliverables (code, APIs, UI)
+- Can be planned with phases, tasks, and acceptance criteria
+- Progress is measurable ("the feature is done")
+
+**This is the default type.** If not specified, assume `feature`.
+
+### Cross-Cutting Specifications (`type: cross-cutting`)
+
+Cross-cutting specifications describe **patterns, policies, or architectural decisions** that inform how features are built. They don't result in standalone implementation - instead, they're referenced by feature specifications and plans.
+
+**Examples:**
+- Caching strategy
+- Rate limiting policy
+- Error handling conventions
+- Logging and observability standards
+- API versioning approach
+- Security patterns
+
+**Characteristics:**
+- Does NOT result in a dedicated implementation plan
+- Defines "how to do things" rather than "what to build"
+- Referenced by multiple feature specifications
+- Implementation happens within features that apply these patterns
+- No standalone "done" state - the patterns are applied across features
+
+### Why This Matters
+
+Cross-cutting specifications go through the same Research → Discussion → Specification phases. The decisions are just as important to validate and document. The difference is what happens after:
+
+- **Feature specs** → Planning → Implementation → Review
+- **Cross-cutting specs** → Referenced by feature plans → Applied during feature implementation
+
+When planning a feature, the planning process surfaces relevant cross-cutting specifications as context. This ensures that a "user authentication" plan incorporates the validated caching strategy and error handling conventions.
+
+### Determining the Type
+
+Ask: **"Is there a standalone thing to build, or does this inform how we build other things?"**
+
+| Question | Feature | Cross-Cutting |
+|----------|---------|---------------|
+| Can you demo it when done? | Yes - "here's the login page" | No - it's invisible infrastructure |
+| Does it have its own UI/API/data? | Yes | No - lives within other features |
+| Can you plan phases and tasks for it? | Yes | Tasks would be "apply X to feature Y" |
+| Is it used by one feature or many? | Usually one | By definition, multiple |
+
+**Edge cases:**
+- A "caching service" that provides shared caching infrastructure → **Feature** (you're building something)
+- "How we use caching across the app" → **Cross-cutting** (policy/pattern)
+- Authentication system → **Feature**
+- Authentication patterns and security requirements → **Cross-cutting**
+
 ## Critical Rules
 
 **EXPLICIT APPROVAL REQUIRED FOR EVERY WRITE**: You MUST NOT write to the specification until the user has explicitly approved. "Presenting" is not approval. "Asking a question" is not approval. You need explicit confirmation. If uncertain, ASK. This rule is non-negotiable.
@@ -344,8 +412,61 @@ When you've:
 
 ## Completion
 
+### Step 1: Determine Specification Type
+
+Before asking for sign-off, assess whether this is a **feature** or **cross-cutting** specification:
+
+**Feature specification** - Something to build:
+- Has concrete deliverables (code, APIs, UI)
+- Can be planned with phases, tasks, acceptance criteria
+- Results in a standalone implementation
+
+**Cross-cutting specification** - Patterns/policies that inform other work:
+- Defines "how to do things" rather than "what to build"
+- Will be referenced by multiple feature specifications
+- Implementation happens within features that apply these patterns
+
+Present your assessment to the user:
+
+> "This specification appears to be a **[feature/cross-cutting]** specification.
+>
+> [Brief rationale - e.g., "It defines a caching strategy that will inform how multiple features handle data retrieval, rather than being a standalone piece of functionality to build."]
+>
+> - **Feature specs** proceed to planning and implementation
+> - **Cross-cutting specs** are referenced by feature plans but don't have their own implementation plan
+>
+> Does this assessment seem correct?"
+
+Wait for user confirmation before proceeding.
+
+### Step 2: Sign-Off
+
+Once the type is confirmed, ask for final sign-off:
+
+> "The specification is ready for sign-off:
+> - **Type**: [feature/cross-cutting]
+> - **Status**: Complete
+>
+> [If feature]: This specification can proceed to planning
+> [If cross-cutting]: This specification will be surfaced as reference context when planning features
+>
+> Ready to mark as complete?"
+
+### Step 3: Update Frontmatter
+
+After user confirms, update the specification frontmatter:
+
+```markdown
+# Specification: [Topic Name]
+
+**Status**: Complete
+**Type**: [feature/cross-cutting]
+**Last Updated**: YYYY-MM-DD
+```
+
 Specification is complete when:
 - All topics/phases have validated content
+- Type has been determined and confirmed
 - User confirms the specification is complete
 - No blocking gaps remain