Tighten

---
name: tighten
description: Condense verbose prose in project docs without dropping facts or restructuring; docs only, never emails or messages. Use when the user says "tighten this doc", "condense these files" or "make this less wordy".
---

# tighten

Rewrite existing prose in files to be shorter and higher-signal, in place.
This is a density pass, not a rewrite — meaning, facts, and structure must
survive exactly.

## Scope

Never assume a default scope (not "whole project," not "last-touched
files"). Always ask for the file list/glob if the invocation didn't include
one, every run — scope is not remembered between runs.

Once you have candidate files, auto-drop these before confirming (no need
to ask about them individually):

- Any file whose header/frontmatter marks it generated or do-not-edit-by-hand
  (e.g. "generated by X — do not edit", "Never edit by hand").
- Known generated indexes in this repo, e.g. `SKILLS.md`.

Confirm the final resolved file list back to the user before editing
anything. If it's empty after exclusions, say so and stop.

## Style target

Docs only. Never apply email/message conventions — no shorthand ("pls",
"thx"), no sign-off, no informal tone shift.

Load these sources each run, when available:

1. A personal email-style reference, if you keep one (e.g. in a notes vault
   under something like `<vault>/email-style.md`) — use only the conciseness
   principles (the core "if it can be said in one sentence, do that" rule,
   short sentences, bullets over prose, no fluff/filler/jargon). Ignore its
   VOICE section's informalities and skip the ENDING section entirely — those
   are email-specific. If this file is
   missing or unreadable, skip it and note that in the final report.
2. A communication-style rules file (banned jargon words and banned filler
   phrases), only if the user names one — use it as the hygiene checklist. If
   none is named, skip it and note that in the final report.

Core test per sentence: "if it can be said in one sentence, do that." Cut
filler, hedging, restated ideas, throat-clearing preamble, and trailing
summaries. Prefer bullets to prose.

## What not to touch

- Code blocks, frontmatter, tables/data, links, headings/structure.
- Facts, numbers, caveats, conditionals — meaning must survive exactly.
- Section order and heading structure — this is a density pass, not a
  reorganization.

## How to run

1. Resolve scope (above) and confirm the file list with the user.
2. Spawn one agent per file, in parallel (files are independent — no shared
   state, so no need to serialize). Each agent gets: the file path, the
   style-target excerpt from above, the "what not to touch" constraints, and
   instructions to:
   - Read the file.
   - Rewrite prose sections tighter, editing in place.
   - Report back: word count before, word count after, one-line summary of
     what changed. If the file had no cuttable prose (already tight, or
     all code/tables), report 0% change rather than forcing an edit.
3. Collect all reports into one summary table: file | before | after | %
   reduction | note.
4. Do not commit. Tell the user the diffs are ready for `git diff` review —
   a multi-file rewrite is worth eyeballing before it lands.