skill-tighten

$npx mdskill add techygarg/lattice/skill-tighten

Audit SKILL.md files for language compliance and tighten phrasing.

  • Fixes phrasing that causes agents to skip or underweight instructions.
  • Operates standalone on SKILL.md files by path, name, tier, or all.
  • Removes rationale prose, soft language, and redundant repetition.
  • Outputs edited files and a per-skill change report.

SKILL.md

.github/skills/skill-tightenView on GitHub ↗
---
name: skill-tighten
description: "Audit any Lattice SKILL.md for language compliance — removes rationale prose, converts soft language to imperatives, adds STOP: gates on hard rules, and cuts redundant repetition. Complements skill-review (which finds behavioral gaps) by fixing phrasing that causes agents to skip or underweight instructions at runtime. Use after writing or significantly changing any skill, or when the user says 'tighten this skill', 'clean up the language', 'make this more effective', 'reduce the bloat', 'tighten the language', or 'skill tighten'. Standalone — does not call other skills."
---

# Skill Tighten

**Core responsibility:** Fix language that causes agents to skip or underweight instructions. Not behavioral gaps — that is `skill-review`'s job. Only phrasing: rationale prose, soft language, missing enforcement signals, redundant repetition.

**Input:** One or more of:
- A file path: `skills/atoms/clean-code/SKILL.md`
- A skill name: `clean-code` (resolves to the correct path automatically)
- A tier: `atoms` (tightens all skills in that tier)
- No argument: tightens all skills across all tiers

**Output:** Edited files + a report per skill:
```
## skill-tighten — {skill-name}
Lines: {before} → {after}
Changes:
1. {what changed} — {one-line reason}
2. ...
Result: TIGHTENED ({N} changes) | CLEAN (no changes needed)
```

**How to verify this skill did its job:**
- Every cut section had zero commands — only rationale
- Every softened phrase was "consider / think about / you may want to / it is recommended"
- Every added STOP: was on a hard rule that previously had no enforcement signal
- No rule, gate, checklist item, or branching logic was removed
- Re-running after edits returns CLEAN

---

## Step 1: Read the skill

Read the full SKILL.md. Also read all sibling files: `references/defaults.md`, `references/methodology-detail.md`, `assets/template.md`, or any file referenced by a `Read` instruction in the skill body.

Do not edit yet — complete the full audit first.

---

## Step 2: Apply the tighten checklist

For each item, scan the entire file. Mark every instance found — do not stop at the first.

### T1 — Non-actionable sections

Sections that explain why the skill exists, describe the problem, or narrate context without issuing a single command. Cut the entire section. Preserve the pointer to a referenced file if one exists.

Patterns that always qualify:
- Section titled "Core Principle", "Purpose", "Problem", "Background", "Why This Matters", "How It Is Used", "Integration with Other Skills"
- Opening paragraph before a numbered list that restates what the numbered list will do
- Closing paragraph after a gate that explains what happens if the gate were skipped

**Pass:** Section contains at least one imperative instruction (do, read, write, verify, check, apply, stop, flag).
**Fail:** Section contains only declarative statements, rationale, or scope commentary.

### T2 — Soft language

Words and phrases that agents treat as optional:

| Pattern | Replace with |
|---|---|
| `consider X` | `X` (imperative) or remove |
| `think about X` | remove |
| `you may want to X` | remove |
| `it is recommended to X` | `X` |
| `should` (as soft suggestion) | `must` or remove |
| `try to X` | `X` |
| `where possible, X` | `X` or remove |

**Pass:** Instruction is an imperative verb with no hedging qualifier.
**Fail:** Instruction contains any of the patterns above.

### T3 — Missing STOP: gates

Hard rules that must not be skipped — gates on advancing to next steps, checklist preambles, non-negotiable constraints — stated as bold prose without a `**STOP:**` prefix.

**Pass:** Hard gate reads `**STOP:**` as the first token of its line or sentence.
**Fail:** Hard gate is phrased as "Do NOT...", "Never...", "Always verify...", "Must not..." without the STOP: prefix.

Add `**STOP:**` prefix. Do not rewrite the instruction itself.

### T4 — Redundant repetition

The same point stated twice in different words. Keep the sharper version; cut the other.

Patterns:
- Section heading restated in the section's opening sentence
- Instruction followed by a sentence explaining what the instruction means
- Rationale sentence after a clear gate ("Without this, X would happen")
- Same rule in two adjacent bullets

**Pass:** Each statement appears once in its sharpest form.
**Fail:** Two sentences convey the same instruction or the same constraint.

### T5 — Table column bloat

Columns whose content explains why a trigger exists, rather than being the trigger.

Common offenders: columns titled "Why", "Reason", "Rationale", "Because", "Notes" in a table whose other columns already encode the actionable information.

**Pass:** Every column in the table is actionable — the agent does something with it.
**Fail:** A column contains only explanatory prose the agent reads but cannot act on.

Drop the column. Do not drop the row.

### T6 — Trailing rationale sentences

Sentences appended to a clear instruction that explain why the instruction exists. The instruction is already sufficient — the explanation adds tokens without adding compliance.

Patterns:
- "Without this, agents will X"
- "This ensures that X"
- "This is because X"
- "X is important because Y"
- Any sentence beginning with "This" that follows a complete imperative

**Pass:** Instruction ends at the action. No trailing explanation.
**Fail:** Instruction is followed by a sentence that begins with "This", "Without", "Because", or restates the consequence of not following the instruction.

---

## Step 3: Make edits

Apply all findings. Edits in order of checklist item (T1 first, T6 last) — structural cuts before phrasing fixes.

Rules:
- Cut sections entirely when T1 applies — do not rephrase them
- Add `**STOP:**` as a prefix — do not rewrite the surrounding instruction
- Do not remove checklist items, branching logic, gates, or output format specifications
- Do not restructure sections — targeted cuts and additions only
- If a T1 section contains one buried imperative, extract that line and discard the section wrapper

---

## Step 4: Report

After all edits:

```
## skill-tighten — {skill-name}
Lines: {before} → {after} ({delta})
Files changed: SKILL.md [, defaults.md, ...]

Changes:
1. [T1] Cut "{section name}" — no commands, pure rationale
2. [T3] Added STOP: to "{rule}" — was bold prose, now enforced gate
3. [T5] Dropped "Reason" column from {table name} — rationale, not instruction
...

Result: TIGHTENED ({N} changes)
```

If no changes needed:
```
Result: CLEAN — no language compliance issues found
```

More from techygarg/lattice

SkillDescription
architecture-compassArchitectural thinking partner for an existing repository — scans the codebase, conducts a structured interview, agrees on current architectural state and recommended direction, and produces a shareable insights document. Scoped to one repository, module, or folder. Does not execute transformation — it orients. Use when the user says 'assess my codebase architecture', 'what direction should my codebase go', 'architecture compass', 'understand my architecture', 'audit architecture drift', 'architectural assessment', or 'help me understand what is wrong with my codebase'.
architecture-refinerFacilitate a structured conversation to define architecture principles for a repository. Supports multiple architecture styles: clean architecture (default), hexagonal / ports & adapters, modular monolith, or custom. Produces a formal architecture document that the corresponding atom will use. Use when setting up a new project, defining architecture standards, or when the user says 'setup architecture', 'define layers', 'architecture principles', 'help me define my architecture', 'hexagonal architecture', 'modular monolith', 'ports and adapters', or 'define my architecture style'.
bug-fixInvestigate, reproduce, and safely fix a bug with regression protection. Composes context, diagnosis, architecture, code quality, and testing guardrails into a reproduce-first repair workflow. Use when the user says 'fix this bug', 'debug this', 'investigate this failure', 'patch this regression', 'repair this issue', or 'why is this broken'.
clean-code-refinerFacilitate a structured conversation to define clean code principles for a repository. Produces a formal clean-code.md document that the clean-code atom will use as its override. Use when setting up coding standards, defining code quality rules, or when the user says 'setup clean code', 'define coding standards', 'code quality principles', 'coding guidelines', or 'help me define my code standards'.
code-forgeGenerate implementation code from an approved design blueprint or verbal requirements. Composes context anchoring, architecture, clean code, DDD, security, and test quality into an inside-out implementation workflow. Use when moving from design to code, implementing approved contracts, or when the user says 'implement', 'code this', 'build it', 'forge the code', or 'generate the code'.
collaborative-judgmentProtocol for handling ambiguous decisions and missing/conflicting knowledge during code generation, design, and review. Ensures AI surfaces genuine judgment calls with structured options and stops on hallucination risk instead of silently assuming. Use when a decision has multiple valid approaches, when facts are missing or contradictory, when the user asks 'what should we do here?', 'is this a judgment call?', 'should I ask about this?', 'am I guessing here?', 'what are the tradeoffs?', or when deciding between two reasonable architectural or design options. Also composed by molecules to define how judgment calls and clarification requests are surfaced and resolved.
context-anchoringManage per-feature living documents that capture decisions, constraints, and reasoning across AI sessions during active development. Scoped to feature-level work — design, implementation, bugfix, refactor — not for codebase-wide assessments or product-wide specifications (those define their own document lifecycles). Handles creating new context documents, loading existing ones, and enriching them with new decisions. Use when starting a new feature, resuming work, making technical decisions, resolving questions, or when context needs to persist across sessions. Use this skill whenever the user mentions 'load context', 'update context', 'context doc', 'decisions', 'continue where we left off', 'what did we decide', or 'capture this decision'.
ddd-refinerFacilitate a structured conversation to define DDD guardrails for domain design within a repository. Produces a formal ddd-principles.md document that the domain-driven-design atom will use as its override. Use when setting up domain design principles, defining aggregate rules, or when the user says 'setup DDD', 'define domain rules', 'DDD principles', or 'help me define my domain patterns'.
design-blueprintRun a complete design workflow -- from establishing context through 5 progressive design levels to an approved blueprint. Composes context anchoring, design-first methodology, architecture, and DDD into a unified process. Handles both new features (create context doc) and resuming existing work (load context doc). Use when starting a design, planning architecture, or when the user says 'design a feature', 'blueprint', 'start designing', 'plan the architecture', or 'let's design before coding'.
knowledge-primingLoad project-specific context -- tech stack, architecture overview, directory layout, trusted sources, and conventions -- so that all skills operate with awareness of what this project actually is. Use when a knowledge base document exists, or when the user asks about the project's tech stack, architecture, conventions, framework, directory layout, or says 'tell me about this project', 'what are we using?', 'what's our stack?', or 'what framework is this?'. Use the knowledge-priming-refiner to create a knowledge base document.