القائمة
Compress each paragraph without losing argument. Cut filler, merge redundant sentences, shorten.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | tighten |
| description | Compress each paragraph without losing argument. Cut filler, merge redundant sentences, shorten. |
| argument-hint | <file_path> |
| allowed-tools | Read, Edit, Grep, AskUserQuestion |
Compress every paragraph in a post. Preserve the argument; cut the slack. Do not fix anything until the user approves.
Dead weight. "The fact that", "in terms of", "there is/are...that", "it should be noted that", "essentially", "basically" → delete or restructure.
Redundant modifiers. If the adjective doesn't change the noun's meaning, cut it. "Completely eliminate" → "eliminate".
Throat-clearing. See /humanize for the full pattern list. Cut sentences that announce what the next sentence will say.
Double-barreled phrases. "Each and every" → "every". "First and foremost" → "first". Pick one.
Passive → active. "The playbook was updated by Grove" → "Grove updated the playbook". Keep passive only when the actor is unknown or irrelevant.
Nominalizations. "Make a decision" → "decide". "Provide an explanation" → "explain". Let the verb work.
Hedge stacking. One hedge per claim. Two hedges signal the writer doesn't believe their own sentence.
Prepositional chains. 2+ consecutive prepositional phrases is a compression opportunity.
Voice. Short punchy sentences that land a point. Fragments used for rhythm. The author's distinctive patterns. Compression should sharpen voice, not flatten it.
Precision. Technical terms, specific numbers, named examples. These are load-bearing. A tight paragraph with vague claims is worse than a loose paragraph with precise ones. A plain-language gloss that carries a jargon term for the reader (the "guess-test-prune" before "methodeutics") is content, not filler. Don't compress it back down to the bare term, or you undo what readability did to make it legible.
Rhythm. A paragraph that alternates long and short sentences has a pulse. Don't compress a long sentence that's earning its length by building momentum for the short sentence that follows.
Transitions. "But" and "therefore" are structural. Don't cut them. "However" can usually become "but". "Additionally" can usually be cut entirely (the new sentence is already additional by appearing).
Aim for 10-20% compression on prose paragraphs. Tables, code blocks, and lists are already tight. If a paragraph is already under 30 words, leave it alone. If a paragraph is over 80 words, it's the highest-priority target.
Only propose cuts where the compressed version is clearly better. If compression loses nuance, rhythm, or voice, leave the paragraph alone. Report "already tight" and move on. The goal is fewer words carrying the same weight, not fewer words carrying less.
Filter recent Hacker News for live threads on June's topics and hand him the list. Separately, flag the rare subset where work he has already done settles a specific quoted claim, and draft that comment as a plain argument with no link to his own writing. Use when June asks to check HN or find threads worth reading or commenting on.
Scan blog posts for AI writing tics and missed opportunities for human voice. Reports subtractions (AI patterns to remove) and additions (wordplay, arc, and claims to strengthen).
Poll June's Hacker News feeds, report what is new since the last run, and idempotently arm a background watch for replies to his comments. State persists in ~/Documents/sweep/ so it survives across sessions. Use when June asks what is new on HN, whether anyone replied, or to start watching a thread.
Argument-level compression by a strengthened absence test (does the argument stand with the same force, clarity, evidence, scope, pacing, and misreading-resistance?). Removes passages that fail it (self-referential cruft, cross-section restatement, self-recap, re-derivation, scaffolding, expired reader-orientation, stakes inflation, inert hedges, redundant examples); grafts good rhetoric onto an adjacent essential point rather than deleting. Idempotent. The structural cousin of /tighten (word-level) and /not-but (negation).
Audit a technical candidate's resume/CV by verifying its claims against the public contribution graph instead of taking the text at face value. Sorts every claim onto the self/peer/world attestation lattice, applies a cost-and-stake filter so cheap proxies (stars, downloads, backlinks) don't count, runs LIVE checks (GitHub, arXiv, package registries, CVEs), and reports two separate axes — merit (staked acceptance of the candidate's specific work) and attention (timestamped output) — plus a verifiability score in [0,1]. For technical recruiters and hiring managers. Invoke when given a candidate — a GitHub handle, a resume/CV, an arXiv author, a personal site — and asked to verify, audit, vet, or check their claims. Runs at two depths — a quick triage scan or a deep per-claim audit — and elicits which. Checks the provenance of a personal site or self-hosted resume (Internet Archive + git history) as an un-backdatable anti-tailoring anchor. Needs tool access (Bash/curl or WebFetch).
Find and defuse "not X but Y" / "isn't X; it's Y" / "X — not Y" constructions. Deterministic grep for detection (no LLM blind spot), the not-but subagent for triage. Split-or-cut tail negations ("X, not Y") aggressively — promote the point to its own sentence or delete it; recast in place only mid-clause "not X but Y" that genuinely can't be split; keep just the rare iconic thesis line literal.
