Skill Discovery — Rules

These rules are always active.

Set up hooks (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 (gap analysis before code changes) and a PostToolUse hook (self-review after commits).

Run gap analysis before writing new code

Before creating new files or adding new features, use the gap-analysis skill to scan for practice gaps and the skill-search skill to fill them.

When this applies

• Greenfield projects: Every domain is a gap — run the full discovery flow.
• Adding a new feature that introduces a new technology domain (authentication, WebSockets, file uploads, payments, etc.): 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.

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

Classify skills after installing them

After installing new skills, use the skill-classifier skill to classify them as proactive (review always) or reactive (use on demand). Then use the quality-standards skill to update CLAUDE.md.

Review code against proactive skills before moving on

Before finishing a task, use the self-review skill to compare your code against proactive skill checklists. Fix any missing patterns.

Set up verification before building features

Before writing feature code, use the verification-strategy skill to set up test runners, type checking, and linting. Write tests alongside features, not after.

Read installed skills thoroughly

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

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.