CC Pattern 4 — Skills System (Lazy-Loaded Per-Domain Behaviors)

status: DESIGN

drafted: 2026-04-22T22:30 UTC

author: TITAN

target-release: R0176

The pattern (from Claude Code)

Claude Code loads skills (e.g. anthropic-skills:brand-guidelines, bio-research:c-trials, claude-code-guide) lazily, only when the user's current task matches the skill's keywords or scope. The skill contributes domain context (colors, typography, tool manifests) that would be wasteful to load on every turn.

Each skill is:

A directory with a manifest + resources + instructions
Lazy — not loaded until relevance detected
Composable — multiple skills can be active at once
Context-frugal — lives outside the global system prompt

Current state (Silent Infinity)

One monolithic 38KB system_v1.md prompt. Contains:

Core voice + witnessing + seduction register
Crisis detection rules
Reflect/plan/teach modes
All examples

Paid every turn, cache TTL 5 min. Cache miss = 4.5s TTFB regression.

Upgrade — R0176 Skills System v1

Concept

Split monolith into:

prompts/core/system_v1.md (~15KB) — always loaded. Voice + witnessing + crisis + forbidden.
prompts/skills/*.md — each ~3-5KB. Loaded on demand.

Proposed skills (v1 set)

| Skill | Triggers when | Content |

|---|---|---|

| reflect | /reflect, "help me journal", "let me think out loud" | Structured reflection prompt pattern, Socratic protocol |

| plan | /plan, "help me plan", "next steps" | Concrete planning framework, milestones, constraints |

| somatic | "body", "tight chest", "can't breathe", "tension" | Somatic protocol — orienting, resourcing, body scan |

| parts | "a part of me", "one side", "conflicted" | IFS framework — parts language, self-energy |

| attachment | "partner", "dad", "mom", "anxious", "distant" | Attachment-style mirror, secure-base language |

| grief | "lost", "died", "miss", "gone" | Grief stages, witnessing disposition, no-fix |

| work | "boss", "job", "career", "fired" | Work-life register, psychological-safety lens |

Loader


# handler.py — new helper
def load_skills(user_message: str, history_tail: list[str]) -> list[str]:
    """Return list of skill prompt paths whose triggers match the turn."""
    corpus = (user_message + " " + " ".join(history_tail[-3:])).lower()
    hits = []
    for skill_name, triggers in SKILL_TRIGGERS.items():
        if any(t in corpus for t in triggers):
            hits.append(f"prompts/skills/{skill_name}.md")
    return hits[:3]  # max 3 concurrent

Prompt assembly


<core-system>
{system_v1.md}
</core-system>

<active-skills>
{skill_1.md}
{skill_2.md}
</active-skills>

<memory>
{memory_block}
</memory>

<user-turn>
...
</user-turn>

Cache strategy

Core system: cache_control: ephemeral — 5 min TTL, shared across users
Skill blocks: cache_control: ephemeral — skill-specific cache key
Memory: NOT cached (user-specific)

Per R0174 (to write): upgrade to 1-hour cache TTL for core system. Combined with skills split → TTFB drop from 4.5s → ~1.2s on cache hits.

Effort

~2 days (split monolith + loader + 7 skill files + tests)

Why this matters

1. Quality — Sonnet applies specific frameworks better when the framework is right in front of it. Monolith dilutes focus.

2. Cost — 23KB less loaded per turn × 1000 DAU × 10 turns = $X/day saved on prompt cache miss

3. Maintainability — domain experts can own individual skill files without touching core

Non-goals

Skills are NOT agents. No tool use. No autonomous action. Just prompt slices.
Skills are NOT memory. No user-specific data.

Observability

Log which skills fired per turn to CW metric skill_fire_count
Track skill_cache_hit_ratio separately from core
Monthly review: which skills never fire? retire them

Dependencies

None new. Uses existing Bedrock prompt cache.

Risk

Trigger lexicon needs tuning. Start with greedy matching + log false fires; prune weekly.
Over-splitting → every turn misses cache. Cap at 3 active skills/turn.

Next step

Build prompts/skills/ directory + 7 skill files + handler loader. File by file, commit per skill. Test each in isolation before shipping.