Right. Focus on injection mechanics and why it works, not what skills exist.
Not "here's all documentation upfront" - it's pull, not push:
Session starts → Minimal bootstrap injected
Agent encounters task → Agent searches for skill
Agent finds match → Agent reads SKILL.md
Agent uses skill → Follows instructions
Key: Context only loaded when needed. Main context stays clean.
Not documentation. Not guidelines. Executable process:
---
name: Thing To Do
when_to_use: Specific trigger conditions
---
# Overview
Core principle in 1-2 sentences
# Quick Reference
Pattern matching
# Implementation
Step-by-step checklist
# Supporting files
Tools/scripts if neededWhy it works:
- Frontmatter: Machine-parseable metadata
- Checklist: Unambiguous steps (→ TodoWrite)
when_to_use: Clear trigger conditions- Markdown: LLM-native format, easy to read/write
Skills tested against realistic failure modes:
Write skill → Test on subagent → Find ways subagent skips it
→ Strengthen language → Retest → Iterate until bulletproof
Uses persuasion principles not as hack but as reliability mechanism:
- Authority framing makes instructions stick
- Commitment patterns force acknowledgment
- Scarcity/pressure scenarios ensure compliance under stress
Result: Skills that survive adversarial testing actually work in practice.
Bootstrap establishes operating rules:
1. You have skills
2. Skills are discoverable (search tool)
3. If skill exists for task → YOU MUST USE IT
Not "helpful docs" - it's required procedure. Like aviation checklists.
Reinforced by:
- EXTREMELY_IMPORTANT framing
- Mandatory announcement ("I'm using X skill...")
- TodoWrite tracking for checklists
- Tested scenarios where agent tries to skip → fails test → skill strengthened
Two-phase discovery:
Phase 1: Search
find-skills [pattern] # Returns list with when_to_useAgent matches pattern to task.
Phase 2: Read & Execute
Read skill → Announce usage → Follow checklistWhy separation matters:
- Search is cheap (grep/metadata)
- Read is expensive (full file in context)
- Only read what's needed
Meta-skill that writes skills:
Agent learns pattern → Extracts to SKILL.md → Tests on subagents
→ If passes: Add to library → Future agents use it
Genius part: System gets smarter over time. Lessons codified, not lost.
Don't pollute main context with exploration:
Need to search? → Dispatch subagent with query
→ Subagent returns synthesis only
→ Main agent uses result
Principle: Keep main context for active work. Delegate research/search.
- RAG: Retrieves chunks, agent figures out what to do
- Skills: Retrieves instructions, agent executes
- System prompt: Fixed, everything upfront, context bloat
- Skills: Dynamic, loaded on-demand, scales indefinitely
- Docs: Reference material, agent interprets
- Skills: Executable procedures, agent follows
Skills are code for LLMs.
Not data. Not documentation. Executable procedures that:
- Load on-demand (JIT)
- Have clear triggers (
when_to_use) - Provide unambiguous steps (checklists)
- Are tested adversarially (TDD for docs)
- Use persuasion principles for reliability
- Self-improve (meta-skill writes skills)
The injection system:
- Minimal bootstrap (establish rules)
- Search tool (discovery)
- SKILL.md format (standard interface)
- Mandatory compliance (enforcement)
- Adversarial testing (quality gate)
Result: System that scales because context cost is O(1) per task, not O(n) for all knowledge.
Two Repos vs One vs Three: Architecture Analysis
Two repos, not one. Skills separation is non-negotiable.
Critical Distinction
The repo split isn't about technical complexity—it's about evolution mechanics.
What Breaks with Single Repo
Self-improvement loop dies:
When agent writes to plugin directory:
The pattern REQUIRES skills to evolve independently from plugin code.
What Each Repo Does
Plugin repo (code):
Skills repo (content):
Marketplace repo (catalog):
The Real Question: Two or Three?
Three repos makes sense if:
Two repos makes sense if:
Two-Repo Pattern (Recommended)
Recommended compromise:
Installation:
Works because:
What You CANNOT Consolidate
Skills must be separate repo. Here's why:
Fork workflow:
If skills in plugin repo → editing skills = editing plugin = dangerous
Update workflow:
If skills in plugin → need reinstall for every skill change
Agent writes skills:
If skills in plugin directory → agent writing to code directory = bad
Multiple plugins share skills:
Can't do this if skills embedded in plugin
Architecture Principle
Code vs Content vs Catalog:
Anti-pattern:
My Recommendation
Use two repos:
my-agent(plugin + embedded marketplace.json)my-agent-skills(skills)Why:
Skip three repos UNLESS:
Never use one repo because:
Proof Point
Superpowers uses three because obra/superpowers-marketplace is designed to grow. It's currently one plugin but architected for many.
If you're building one agent for personal use, two repos is pragmatic.
If you're building a template others will use to create marketplaces, keep three to teach the pattern properly.
Bottom line: Skills separation = non-negotiable. Marketplace separation = situational.