Skill Composition Protocol

Skill Composition Protocol

Purpose

Individual skills are functions. This skill teaches you to compose those functions into programs — multi-step workflows where the output of one skill becomes the input of the next, where skills run in parallel when independent, and where the whole pipeline produces results no single skill could achieve alone.

Composition Patterns

Pattern 1: Sequential Pipeline

Skills execute one after another, each building on the previous output.

Structure: Skill A → Output A → Skill B → Output B → Skill C → Final Output

When to use: When each skill needs the output of the previous one. Most common pattern.

Example — Building a Feature:

pm-problem-statement     → Clear problem definition
  ↓
pm-prd-development       → Requirements document
  ↓
architecture-patterns    → Technical design
  ↓
frontend-design          → UI/UX approach
  ↓
react-best-practices     → Implementation
  ↓
test-driven-development  → Tests + verified code
  ↓
code-review-excellence   → Reviewed, polished code

Rules for Sequential Pipelines:

• Each skill's output must be concrete enough to serve as the next skill's input
• If a skill's output is ambiguous, add a checkpoint to clarify before proceeding
• Document what passes between each stage so the chain is traceable

Pattern 2: Parallel Fan-Out

Multiple skills execute simultaneously on the same input, then results are merged.

Structure:

                ┌→ Skill A → Output A ─┐
Input → Fork ──┼→ Skill B → Output B ──┼→ Merge → Combined Output
                └→ Skill C → Output C ─┘

When to use: When multiple independent analyses are needed on the same artifact.

Example — Security + Performance + Accessibility Review:

                        ┌→ owasp-security        → Security findings    ─┐
Completed feature → ────┼→ tlc-perf-lighthouse    → Performance findings ─┼→ Unified review report
                        ├→ accessibility-testing  → A11y findings        ─┤
                        └→ code-review-excellence → Code quality findings─┘

Rules for Parallel Fan-Out:

• Only parallelize skills that are truly independent (no output dependencies)
• Define a merge strategy before fanning out (union, intersection, priority-weighted)
• Resolve conflicts between parallel outputs using the Priority Stack from master-skill-orchestrator

Pattern 3: Iterative Refinement Loop

A skill is applied repeatedly, with each iteration improving the output.

Structure:

Input → Skill A → Output → Evaluate → Good enough? 
                                ↓ No
                          Skill A (again, with feedback) → Output → Evaluate → ...

When to use: When quality emerges through iteration, not single-pass execution.

Example — Design Iteration:

Requirements → ui-ux-pro-max → Initial design
  ↓
ux-audit → Findings
  ↓
ui-ux-pro-max (with findings) → Improved design
  ↓
ux-audit → Fewer findings
  ↓
(repeat until audit passes)

Rules for Iterative Refinement:

• Set a maximum iteration count (typically 3) to prevent infinite loops
• Each iteration must address specific, named issues from the previous evaluation
• If quality plateaus after 2 iterations, the problem is likely upstream — go back to an earlier pipeline stage

Pattern 4: Conditional Branching

Different skills activate based on the characteristics of the input or intermediate results.

Structure:

Input → Classify → If Type A → Skill A → Output
                   If Type B → Skill B → Output
                   If Type C → Skill C → Output

When to use: When the right approach depends on what you discover during analysis.

Example — Bug Triage:

Bug report → systematic-debugging → Classify bug type
  ↓
  ├─ If race condition    → simota-specter → Fix
  ├─ If regression        → simota-rewind → Find introducing commit → Fix
  ├─ If performance       → simota-bolt → Profile → Optimize
  ├─ If security vuln     → owasp-security → Assess severity → Patch
  └─ If unknown root cause → simota-scout → Deep investigation → Fix

Rules for Conditional Branching:

• Classification must be explicit and documented
• Always have a default/fallback branch for unexpected cases
• Re-evaluate the classification if the chosen branch doesn't produce results

Pattern 5: Wrapper/Decorator

One skill wraps around another, adding a cross-cutting concern without changing the core skill's behavior.

Structure:

meta-thinking-engine ─────────────────────────────────────┐
│                                                          │
│  Input → Core Skill → Output                            │
│                                                          │
│  (metacognition monitors reasoning quality throughout)   │
└──────────────────────────────────────────────────────────┘

When to use: When a concern (security, quality, metacognition) should be active throughout, not just at one stage.

Permanent Wrappers (always active):

Situational Wrappers (active when relevant):

Pattern 6: Ensemble/Voting

Multiple skills independently analyze the same question, then their conclusions are compared and synthesized.

Structure:

Question → Skill A → Conclusion A ─┐
Question → Skill B → Conclusion B ──┼→ Compare → Synthesize → Best conclusion
Question → Skill C → Conclusion C ─┘

When to use: For high-stakes decisions where you want multiple independent perspectives.

Example — Architecture Decision:

"Should we use microservices or monolith?"
  ↓
  ├→ thinking-first-principles  → Conclusion based on fundamentals
  ├→ thinking-cynefin            → Conclusion based on complexity domain
  ├→ thinking-lindy-effect       → Conclusion based on what's proven
  ├→ thinking-reversibility      → Conclusion based on reversibility
  └→ thinking-second-order       → Conclusion based on long-term effects
  ↓
  Compare all 5 conclusions → Where do they agree? Where do they disagree?
  ↓
  Synthesize → Decision with high confidence (if agreement) or identified uncertainty (if disagreement)

Rules for Ensemble:

• Use at least 3 independent skills for meaningful ensemble results
• Weight conclusions by relevance (a security skill's opinion on security matters more than a creativity skill's)
• Disagreement between skills is a signal, not a problem — it reveals genuine uncertainty

Composition Depth Levels

Match composition complexity to task complexity.

The Composition Checklist

Before executing a composed skill pipeline, verify:

1. Completeness: Are all necessary skills included? Check master-skill-orchestrator for commonly missed skills.
2. Order: Are skills in the right sequence? Check skill-connection-map for prerequisite chains.
3. Independence: Are parallel skills truly independent? If not, sequentialize them.
4. Termination: Do iterative loops have exit conditions? Set maximum iterations.
5. Conflict Resolution: If parallel skills disagree, how will you resolve it? Define the strategy upfront.
6. Wrappers: Are the right cross-cutting concerns active? At minimum: meta-thinking-engine for reasoning quality.
7. Checkpoints: Are there intermediate checkpoints where you can evaluate progress and re-route if needed?
8. Traceability: Can you trace the reasoning chain from input to output through every skill? If not, add documentation between stages.

Integration

This skill is the "how" that complements the other meta-skills: