Initial commit

skills/code-refactoring/knowledge/patterns/builder-map-decomposition.md

@@ -0,0 +1,9 @@
+# Builder Map Decomposition
+
+**Problem**: Command dispatchers with large switch statements cause high cyclomatic complexity and brittle branching (see iterations/iteration-1.md).
+
+**Solution**: Replace the monolithic switch with a map of tool names to builder functions plus shared helpers for defaults. Keep scope flags as separate helpers for readability.
+
+**Outcome**: Cyclomatic complexity dropped from 51 to 3 on `(*ToolExecutor).buildCommand`, with behaviour validated by existing executor tests.
+
+**When to Use**: Any CLI/tool dispatcher with ≥8 branches or duplicated flag wiring.

skills/code-refactoring/knowledge/patterns/conversation-turn-pipeline.md

@@ -0,0 +1,9 @@
+# Conversation Turn Pipeline
+
+**Problem**: Conversation queries bundled user/assistant extraction, duration math, and output assembly into one 80+ line function, inflating cyclomatic complexity (25) and risking regressions when adding filters.
+
+**Solution**: Extract helpers for user indexing, assistant metrics, turn collection, and timestamp finalization. Each step focuses on a single responsibility, enabling targeted unit tests and reuse across similar commands.
+
+**Evidence**: `cmd/query_conversation.go` (CLI iteration-3) reduced `buildConversationTurns` to a coordinator with helper functions ≤6 complexity.
+
+**When to Use**: Any CLI/API that pairs multi-role messages into aggregate records (e.g., chat analytics, ticket conversations) where duplicating loops would obscure business rules.

skills/code-refactoring/knowledge/patterns/prompt-outcome-analyzer.md

@@ -0,0 +1,9 @@
+# Prompt Outcome Analyzer
+
+**Problem**: Analytics commands that inspect user prompts often intermingle success detection, error counting, and deliverable extraction within one loop, leading to brittle logic and high cyclomatic complexity.
+
+**Solution**: Break the analysis into helpers that (1) detect user-confirmed success, (2) count tool errors, (3) aggregate deliverables, and (4) finalize status. The orchestration function composes these steps, making behaviour explicit and testable.
+
+**Evidence**: Meta-CC CLI Iteration 4 refactored `analyzePromptOutcome` using this pattern, dropping complexity from 25 to 5 while preserving behaviour across short-mode tests.
+
+**When to Use**: Any Go CLI or service that evaluates multi-step workflows (prompts, tasks, pipelines) and needs to separate signal extraction from aggregation logic.