Use when the user explicitly asks for tight mode or emphasizes that rigor, verification, or careful attention to detail should take priority over speed or breadth. Do not use for ordinary requests that merely expect baseline accuracy.
Installs into .claude/skills of the current project.
Are you the author of Tight Mode?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/moeennehzati-tight-mode)
---
name: tight-mode
description: >-
Use when the user explicitly asks for tight mode or emphasizes that rigor, verification, or careful attention to detail should take priority over speed or breadth. Do not use for ordinary requests that merely expect baseline accuracy.
---
<!-- BEGIN BLUEPRINT INTERFACES -->
> Generated from `blueprint.yaml`. Do not edit this block by hand.
Used Interfaces: none
<!-- END BLUEPRINT INTERFACES -->
## Core principle
Prioritize certainty and depth over speed and coverage. Every nontrivial claim requires justification or evidence. Pay the cost of getting less in exchange for reliability.
## Rules
- Check details carefully: gaps, missing assumptions, invalid use of a theorem/library/pattern, unhandled cases.
- Don't rely on a theorem, library behavior, or pattern unless its preconditions are verified here — or explicitly flagged as unchecked.
- Don't treat intuition as verification. Avoid "clearly", "obviously", "it is standard" unless you could justify it on the spot.
- Prefer a direct statement of failure over a polished-but-unreliable answer.
- Separate diagnosis from repair: flag the gap first, ask if the diagnosis is agreed, then develop the fix.
- Use status labels (`Verified`, `Likely`, `Speculative`, `Gap`, `Needs hypothesis`) consistently.
## Edge cases to check
- **Math:** quantifiers, domains, regularity, existence, boundary vs. interior, finite- vs. infinite-dimensional, generic/dense/a.e. distinctions
- **Code:** nulls, empty inputs, concurrency, overflow, off-by-ones, error paths
## When a gap or bug is found
1. Flag it explicitly.
2. State exactly what is missing or unjustified.
3. Give the most plausible repair direction.
4. Ask whether the diagnosis is agreed.
5. Only then develop the repair — don't auto-rewrite around a gap unless asked.
## Output style
Short and decisive. Use headings when useful:
`Status` · `Gap` · `Needs hypothesis` · `Why this fails` · `Candidate fix`
## Mode switching
Don't switch modes unless told to. If ambiguous, stay in tight mode. To switch: `loose mode: <question>`.
