design-loops

name	design-loops
description	Design compounding feedback loops — what data accumulates, what reads it, and how the system gets smarter with use.

/design-loops - Feedback Loop Design

When to Use

• After skills and sub-agents are designed
• When designing the compounding data model for the target OS
• When domain-input/feedback-loops.md needs to be filled

Inputs

• Auto-loaded: domain-input/domain-workflow.md (pipeline stages and metrics)
• Auto-loaded: domain-input/identity-model.md (context files that accumulate)
• Auto-loaded: output/designs/skill-designs.md (which skills produce and consume data)
• Auto-loaded: output/designs/sub-agent-designs.md (which reviews produce scores)

Process

Step 1: Identify Data Producers

From the skill designs, list every skill that produces data worth keeping:

Skill	Data Produced	Where It's Stored
/[debrief skill]	Performance scores, patterns	[history file]
/[tracker skill]	Pipeline status, dates, stages	[tracker file]
/[review sub-agent]	Quality scores per output	[embedded in output / history]
/[briefing]	Daily activity log	[briefings/ folder]

Step 2: Identify Data Consumers

From the skill designs, list every skill that reads accumulated data:

Skill	Data Consumed	What It Does With It
/[prep skill]	[history file]	Identifies weaknesses to coach on
/[retro skill]	[tracker, history, briefings]	Calculates metrics and trends
/[briefing]	[tracker, connections, history]	Prioritizes daily actions
/[practice skill]	[history file]	Targets weak areas for rehearsal

Step 3: Map the Loops

A loop is: action → data → analysis → better action. Identify each loop:

## Loop 1: [Name] (e.g., "Performance Improvement Loop")

Action: User completes [event] (e.g., interview, client call, pitch)
    ↓
Data: /[debrief skill] scores performance → writes to [history file]
    ↓
Analysis: /[retro skill] reads accumulated scores → identifies patterns
    ↓
Coaching: /[briefing] surfaces weakness → recommends /[practice skill]
    ↓
Better Action: User practices weak area → performs better next time
    ↓
(Cycle repeats with richer data each iteration)

**Minimum data for loop activation:** [N] entries (e.g., 3 debriefs before patterns emerge)
**Signal quality over time:** [how the insight improves as data accumulates]

## Loop 2: [Name] (e.g., "Pipeline Intelligence Loop")

Action: User adds [opportunity] to tracker
    ↓
Data: /[tracker] logs status, dates, referral paths
    ↓
Analysis: /[retro] calculates conversion rates by stage
    ↓
Coaching: /[briefing] identifies bottleneck → adjusts daily priorities
    ↓
Better Action: User focuses on the bottleneck stage
    ↓
(Cycle repeats with longer pipeline history)

Step 4: Design Degradation Behavior

For each loop, design what happens when data is thin or missing:

1. Cold start (0 entries): What does the skill do? Skip the analysis? Use defaults? Say "not enough data yet"?
2. Thin data (1-2 entries): What can be inferred? What can't?
3. Rich data (10+ entries): What new analysis becomes possible?

## Degradation: [Loop Name]

| Data Volume | Behavior |
|-------------|----------|
| 0 entries | Skip [analysis section]. Note: "Not enough data for [X]. Complete [N] more [events] to activate [loop name]." |
| 1-2 entries | Show raw data, no pattern analysis. Note: "Early data — patterns will emerge after [N] more entries." |
| 3-9 entries | Basic pattern analysis. Flag low-confidence trends. |
| 10+ entries | Full trend analysis, cross-entry patterns, confidence-weighted recommendations. |

Step 5: Design the Retro Skill's Data Model

The retro skill (weekly/periodic review) is the primary consumer of compounding data. Design what it calculates:

1. Activity metrics: What happened this period? (volume of actions, by type)
2. Conversion metrics: What moved forward? What died? At what rates?
3. Performance metrics: How well did the user perform? (from debrief scores)
4. Trend analysis: Are things getting better, worse, or flat?
5. Bottleneck identification: Where is the biggest constraint right now?
6. Recommendation: What should the user do differently next period?

## Retro Data Model

### Activity Metrics
| Metric | Source | Calculation |
|--------|--------|-------------|
| [X] | [file] | [how to calculate] |

### Bottleneck Detection Rules
| Pattern | Diagnostic | Recommended Fix |
|---------|-----------|----------------|
| [symptom] | [data check] | [action] |

Step 6: Design the Briefing's Compounding Behavior

The daily/periodic briefing is the primary delivery mechanism for compounding intelligence. Design how it evolves:

• Week 1: Basic scanning and task generation (no history to draw from)
• Week 2-3: Starts referencing pipeline data and early patterns
• Month 2+: Rich trend analysis, personalized coaching, bottleneck detection with historical context

Output

Write the complete feedback loop design to domain-input/feedback-loops.md and output/designs/loop-designs.md.

Tell the designer:

Feedback loops designed:
- [N] compounding loops identified: [list]
- Key loop: [the one that makes the biggest difference over time]
- Cold-start behavior: defined for all loops
- Retro data model: [N] metrics tracked
- Bottleneck patterns: [N] detection rules

The system reaches full intelligence after approximately [N] [events/weeks] of use.

Next: Run /generate-os to assemble everything into a complete repository.

Quality Checks

Good loop design:

• Every loop has a clear action → data → analysis → better action chain
• Degradation behavior is defined for every data volume level
• Minimum data thresholds are specified (not "when enough data exists")
• The retro has specific bottleneck detection rules, not just "analyze the data"
• Loops connect to each other (pipeline data informs preparation, which informs performance)

Bad loop design:

• Loops are described abstractly ("the system learns over time")
• No degradation behavior — skills crash or produce nonsense with thin data
• No minimum data thresholds
• Retro is generic ("review your progress") with no specific metrics
• Loops are isolated — each loop only feeds back into itself