Skill Classifier

Classify installed skills so downstream skills know which to apply universally and which to apply on demand.

Why Classify?

Not all skills should be reviewed on every commit. Error handling patterns apply to all code. SQLite indexing patterns only apply when you're writing database code. Reviewing every skill on every commit wastes time and dilutes focus. Classification solves this.

Two Categories

Proactive Skills

Skills whose patterns should be applied to all code and reviewed at every commit or self-review.

Characteristics:

• Has a ## Checklist section with items that apply broadly
• Covers cross-cutting concerns (error handling, security, accessibility, logging, testing)
• Patterns should be present regardless of which feature you're building
• Missing these patterns is a quality gap in any code

Examples: error handling, security headers, accessibility, structured logging, testing patterns

Reactive Skills

Skills whose patterns are used only when working in that specific domain.

Characteristics:

• Domain-specific guidance (SQLite optimization, JWT implementation, WebSocket patterns)
• Patterns only apply when you're actively working in that domain
• It would be wrong to check for these patterns in unrelated code
• Applied during coding, not reviewed at commit time

Examples: SQLite best practices, JWT security, WebSocket patterns, file upload handling

Workflow

Step 1 — List Installed Skills

Find all installed SKILL.md files:

find .tessl/tiles -name "SKILL.md" 2>/dev/null

Step 2 — Read and Classify Each Skill

For each SKILL.md, read it and determine:

1. Does it have a ## Checklist section? Skills with checklists are candidates for proactive.
2. Are the checklist items universal? If they apply to any code (e.g., "use error classes", "add ARIA attributes"), it's proactive. If they apply only to a specific technology (e.g., "enable WAL mode for SQLite"), it's reactive.
3. Is it a cross-cutting concern? Error handling, security, accessibility, logging, and testing are almost always proactive. Specific technology implementations are almost always reactive.

Decision Table

Borderline cases: If a skill is framework-specific but the project uses that framework for everything (e.g., React patterns in an all-React frontend), classify it as proactive. If the framework is used in only part of the project, classify it as reactive.

Step 3 — Update State

Update .skill-discovery-state.json with the classification:

{
  "proactiveSkills": [
    ".tessl/tiles/acme/error-handling/skills/error-handling/SKILL.md",
    ".tessl/tiles/acme/security-headers/skills/security-headers/SKILL.md",
    ".tessl/tiles/acme/web-accessibility/skills/web-accessibility/SKILL.md"
  ],
  "reactiveSkills": [
    ".tessl/tiles/acme/jwt-security/skills/jwt-security/SKILL.md",
    ".tessl/tiles/acme/sqlite-patterns/skills/sqlite-patterns/SKILL.md"
  ]
}

Store the full paths to the SKILL.md files so downstream skills can read them directly.

After Classification

Run the quality-standards skill to generate a CLAUDE.md quality block from your proactive skills.

Reclassification

When new skills are installed mid-session, re-run classification for the new skills only. Add them to the appropriate list — don't reclassify skills that are already classified.