Skill Composer

Modular workflow builder that chains skills into compound pipelines.

Core principle: Feature Layer + Persona Layer separation, modular addon composition

Rules (Absolute)

Separation of concerns. Every skill in a pipeline has exactly one responsibility. No skill does two things.
Explicit data flow. The output of skill N must be defined input for skill N+1. No implicit state.
Composability over complexity. Prefer chaining 3 simple skills over creating 1 complex one.
Layer isolation. Function layer (what to do) is separate from persona layer (how to communicate).
Fail-forward. If one skill in the pipeline fails, the pipeline should degrade gracefully, not crash.

Architecture

Two-Layer Model

Inherited from the 기본설정 에드온 system's modular design:

┌─────────────────────────────────────┐
│         Persona Layer               │
│  (tone, style, communication mode)  │
│  e.g., concise / detailed / Korean  │
├─────────────────────────────────────┤
│        Function Layer               │
│  (what the workflow actually does)  │
│  Skill A → Skill B → Skill C       │
└─────────────────────────────────────┘

Function Layer: The pipeline of skills that process the task
Persona Layer: Communication style applied uniformly across all steps

Pipeline Patterns

Sequential Pipeline

[Input] → Skill A → Skill B → Skill C → [Output]

Each skill transforms the output of the previous one.

Example: Research → Analyze → Review

pipeline: research-then-review
steps:
  1: { skill: cross-verified-research, input: "$TOPIC" }
  2: { skill: deep-dive-analyzer, input: "step.1.output" }
  3: { skill: adversarial-review, input: "step.2.output" }

Fork-Join Pipeline

         ┌→ Skill B ─┐
[Input] →│            │→ Merge → [Output]
         └→ Skill C ─┘

Parallel analysis merged into unified output.

Example: Multi-perspective evaluation

pipeline: multi-perspective
steps:
  1: { skill: creativity-sampler, input: "$DECISION" }
  2a: { skill: adversarial-review, input: "step.1.option_chosen", parallel: true }
  2b: { skill: cross-verified-research, input: "step.1.option_chosen", parallel: true }
  3: { merge: ["step.2a", "step.2b"], format: "comparison-table" }

Iterative Pipeline

[Input] → Skill A → [Check] → Pass? → [Output]
                        ↓ No
                     Skill B → Skill A (retry)

Loop until quality gate passes.

Example: Write-review-refine cycle

pipeline: quality-loop
steps:
  1: { skill: implement, input: "$TASK" }
  2: { skill: adversarial-review, input: "step.1.output" }
  3: { gate: "step.2.verdict == PASS", retry: 1, max_retries: 2 }

Process

Step 1: Identify the Goal

What is the end-to-end outcome?

"Evaluate a technology choice with full rigor"
"Design, implement, and validate a feature"
"Research, decide, and document an architecture decision"

Step 2: Select Skills

Browse available skills and select those that map to pipeline stages:

Category	Available Skills
Research	`cross-verified-research`, `search-first`
Creativity	`creativity-sampler`, `brainstorming`
Analysis	`deep-dive-analyzer`, `adversarial-review`
Testing	`tiered-test-generator`
Persona	`persona-architect`
Planning	`writing-plans`, `plan`
Review	`code-review`, `full-review`

Step 3: Define Data Flow

For each transition between skills, specify:

What data flows from skill N to skill N+1
What format the data should be in
Whether the transition is automatic or requires user approval

Step 4: Build the Pipeline

Write the pipeline as a sequence of skill invocations with clear handoff points.

Output Format

## Workflow: [Name]

### Goal
[What this workflow achieves]

### Pipeline

[Step 1] ──→ [Step 2] ──→ [Step 3] ──→ [Output] skill skill skill


### Steps

#### Step 1: [Name] (skill: [skill-name])
- **Input:** [what it receives]
- **Action:** [what it does]
- **Output:** [what it produces]
- **Gate:** [pass/fail criteria, if any]

#### Step 2: [Name] (skill: [skill-name])
...

### Execution Notes
- [Any special considerations]
- [User approval points]
- [Fallback behavior]

Pre-Built Workflows

1. Full-Rigor Decision

creativity-sampler → cross-verified-research → adversarial-review

Generate options → verify facts → stress-test the choice.

2. Research-to-Architecture

cross-verified-research → creativity-sampler → adversarial-review → architecture ADR

Research the domain → explore approaches → challenge the choice → document the decision.

3. Implementation Quality Gate

implement → tiered-test-generator → adversarial-review → [merge/reject]

Build it → generate tests → review it → gate the merge.

4. Deep Learning Pipeline

deep-dive-analyzer → tiered-test-generator → [assess gaps] → deep-dive-analyzer (retry)

Analyze deeply → test understanding → fill gaps → iterate.

When to Use

Tasks that span multiple concerns (research + decide + validate)
When you want a repeatable, named workflow
When quality gates between steps are needed
When multiple skills should work together in a defined sequence

Integration Notes

With persona-architect: Design a persona with persona-architect first, then inject it as the Persona Layer of your composed workflow. The composer's Persona Layer slot is where persona-architect output goes.
With cross-verified-research: Most common first step in decision pipelines
With adversarial-review: Most common final step as a quality gate

When NOT to Use

Simple tasks where a single skill suffices
When the workflow is obvious and doesn't need formal definition
One-off tasks that won't be repeated

skill-composer