Skill Discovery — Rules

These rules are always active.

Set up the gap analysis hook (once per project)

If .claude/settings.json does not contain a gap-check-hook entry, run:

bash .tessl/tiles/tessl-labs/skill-discovery/skills/skill-discovery/scripts/setup.sh

This adds a PreToolUse hook that enforces gap analysis before code changes.

Search for skills to fill practice gaps before writing new code

Before creating new files or adding new features, scan the project for practice gaps and search the Tessl registry for skills to fill them.

IMPORTANT: Use the tessl CLI for searching, not MCP tools. The MCP search tool only returns tiles and misses community skills. Always search via Bash:

tessl search --type skills "<query>"

A gap is either:

1. A practice domain the project should have but doesn't (e.g., no tests, no error handling)
2. An existing domain that lacks best practices (e.g., database exists but no indexes on foreign keys, auth exists but JWT secret is hardcoded)
3. A new technology domain being introduced that the project hasn't used before

When this applies

Greenfield projects: Every domain is a gap — search for ALL of them.

Adding a new feature that introduces a new technology domain (authentication, WebSockets, file uploads, payments, caching, email, queuing, etc.): Search for skills specific to that domain before writing code, even if existing practice domains are already covered. The new domain is a gap regardless of how well the rest of the project is set up.

Joining an existing codebase or starting a major feature (3+ new files): Scan the existing code for quality gaps — not just missing domains, but domains where the implementation could benefit from best practices.

When this does NOT apply

• Fixing a typo, renaming, or formatting
• Editing a single existing file with a small change
• Reading, explaining, or reviewing code

Assess the codebase, not just the file tree

When scanning for gaps, read the code and assess whether it follows best practices. A project can have a database.ts file and still have a database gap if it's missing indexes, WAL mode, or migration support.

For each domain, ask: "Does this implementation follow production best practices, or could a skill improve it?"

Do not install skills that conflict with existing project patterns

If the project has an established pattern for a domain AND that pattern follows best practices, skip it. The goal is to fill gaps and improve weak implementations, not override good decisions already made.

Search for skills when entering a new technology domain

When the task introduces a domain the project hasn't used before, always search for skills specific to that domain before writing code.

Set up verification before building features

Before writing feature code, set up feedback mechanisms: type checking, linting, and a test runner. Write tests alongside features, not after. Run all checks before every commit. Never commit code you haven't verified.

The pattern is: Build → Test → Fix → Commit. Not: Build everything → Test at the end → Hope it works.

Read installed skills thoroughly

When a skill is installed, read the full SKILL.md before writing code. Do not skim.

Review installed skill checklists before committing

Before your final commit, go through EVERY installed skill's checklist section and verify each item is addressed in your code. This is not optional.

If a skill is installed but its core pattern is not present in your code, that is a bug. Fix it before committing.