Files
antigravity-skills-reference/skills/writing-skills/references/cso/README.md

269 lines
6.2 KiB
Markdown

# CSO Guide - Claude Search Optimization
Advanced techniques for making skills discoverable by agents.
## The Discovery Problem
You have 100+ skills. Agent receives a task. How does it find the RIGHT skill?
**Answer**: The `description` field.
## Critical Rule: Description = Triggers, NOT Workflow
### The Trap
When description summarizes workflow, agents take a shortcut.
**Real example that failed**:
```yaml
# Agent did ONE review instead of TWO
description: Code review between tasks
# Skill body had flowchart showing TWO reviews:
# 1. Spec compliance
# 2. Code quality
```
**Why it failed**: Agent read description, thought "code review between tasks means one review", never read the flowchart.
**Fix**:
```yaml
# Agent now reads full skill and follows flowchart
description: Use when executing implementation plans with independent tasks
```
### The Pattern
```yaml
# ❌ BAD: Workflow summary
description: Analyzes git diff, generates commit message in conventional format
# ✅ GOOD: Trigger conditions only
description: Use when generating commit messages or reviewing staged changes
```
## Token Efficiency Critical for Skills
**Problem**: Frequently-loaded skills consume tokens in EVERY conversation.
**Target word counts**:
- Frequently-loaded skills: <200 words total
- Other skills: <500 words
### Techniques
**1. Move details to tool help**:
```bash
# ❌ BAD: Document all flags in SKILL.md
search-conversations supports --text, --both, --after DATE, --before DATE, --limit N
# ✅ GOOD: Reference --help
search-conversations supports multiple modes. Run --help for details.
```
**2. Use cross-references**:
```markdown
# ❌ BAD: Repeat workflow
When searching, dispatch agent with template...
[20 lines of repeated instructions]
# ✅ GOOD: Reference other skill
Use subagents for searches. See [delegating-to-subagents] for workflow.
```
**3. Compress examples**:
```markdown
# ❌ BAD: Verbose (42 words)
Partner: "How did we handle auth errors in React Router?"
You: I'll search past conversations for patterns.
[Dispatch subagent with query: "React Router authentication error handling 401"]
# ✅ GOOD: Minimal (20 words)
Partner: "Auth errors in React Router?"
You: Searching...
[Dispatch subagent → synthesis]
```
## Keyword Strategy
### Error Messages
Include EXACT error text users will see:
- "Hook timed out after 5000ms"
- "ENOTEMPTY: directory not empty"
- "jest --watch is not responding"
### Symptoms
Use words users naturally say:
- "flaky", "hangs", "zombie process"
- "slow", "timeout", "race condition"
- "cleanup failed", "pollution"
### Tools & Commands
Actual names, not descriptions:
- "pytest", not "Python testing"
- "git rebase", not "rebasing"
- ".docx files", not "Word documents"
### Synonyms
Cover multiple ways to describe same thing:
- timeout/hang/freeze
- cleanup/teardown/after Each
- mock/stub/fake
## Naming Conventions
### Gerunds (-ing) for Processes
`creating-skills`, `debugging-with-logs`, `testing-async-code`
### Verb-first for Actions
`flatten-with-flags`, `reduce-complexity`, `trace-root-cause`
### ❌ Avoid
- `skill-creation` (passive, less searchable)
- `async-test-helpers` (too generic)
- `debugging-techniques` (vague)
## Description Template
```yaml
description: "Use when [SPECIFIC TRIGGER]."
metadata:
triggers: [error1], [symptom2], [tool3]
```
**Examples**:
```yaml
# Technique skill
description: "Use when tests have race conditions, timing dependencies, or pass/fail inconsistently."
metadata:
triggers: flaky tests, timeout, race condition
# Pattern skill
description: "Use when complex data structures make code hard to follow."
metadata:
triggers: nested loops, multiple flags, confusing state
# Reference skill
description: "Use when working with React Router and authentication."
metadata:
triggers: 401 redirect, login flow, protected routes
# Discipline skill
description: "Use when implementing any feature or bugfix, before writing implementation code."
metadata:
triggers: new feature, bug fix, code change
```
## Third Person Rule
Description is injected into system prompt. Inconsistent POV breaks discovery.
```yaml
# ❌ BAD: First person
description: "I can help you with async tests"
# ❌ BAD: Second person
description: "You can use this for race conditions"
# ✅ GOOD: Third person
description: "Handles async tests with race conditions"
```
## Cross-Referencing Other Skills
**When documenting a skill that references other skills**:
Use skill name only, with explicit requirement markers:
```markdown
# ✅ GOOD: Clear requirement
**REQUIRED BACKGROUND**: You MUST understand test-driven-development before using this skill.
**REQUIRED SUB-SKILL**: Use defensive-programming for error handling.
# ❌ BAD: Unclear if required
See test-driven-development skill for context.
# ❌ NEVER: Force-loads (burns context)
@skills/testing/test-driven-development/SKILL.md
```
**Why no @ links**: `@` syntax force-loads files immediately, consuming tokens before needed.
## Verification Checklist
Before deploying:
- [ ] Description starts with "Use when..."?
- [ ] Description is <500 characters?
- [ ] Description lists ONLY triggers, not workflow?
- [ ] Includes 3+ keywords (errors/symptoms/tools)?
- [ ] Third person throughout?
- [ ] Name uses gerund or verb-first format?
- [ ] Name has only letters, numbers, hyphens?
- [ ] No @ syntax for cross-references?
- [ ] Word count <200 (frequent) or <500 (other)?
## Real-World Examples
### Before/After: TDD Skill
**Before** (workflow in description):
```yaml
description: Write test first, watch it fail, write minimal code, refactor
```
Result: Agents followed description, skipped reading full skill.
**After** (triggers only):
```yaml
description: Use when implementing any feature or bugfix, before writing implementation code
```
Result: Agents read full skill, followed complete TDD cycle.
### Before/After: BigQuery Skill
**Before** (too vague):
```yaml
description: Helps with database queries
```
Result: Never loaded (too generic, agents couldn't identify relevance).
**After** (specific triggers):
```yaml
description: Use when analyzing BigQuery data. Triggers: revenue metrics, pipeline data, API usage, campaign attribution.
```
Result: Loads for relevant queries, includes domain keywords.