@mohammadhprp/system-prompt 0.12.3 → 0.12.4

package/framework/skills/how/references/critique-rubric.md

@@ -0,0 +1,58 @@
+# Architectural Critique Rubric
+
+Review through whichever of these lenses are relevant. Not every lens applies to every subsystem.
+
+## Abstraction Fit
+
+Are the abstractions pulling their weight?
+
+- Does each abstraction represent a real concept, or is it an indirection layer "in case we need it"?
+- Are the boundaries in the right place? Do they separate things that change independently?
+- Is there accidental coupling where components share implementation details they shouldn't need to know about?
+- Is business logic entangled with framework wiring, or cleanly separated?
+
+Over-abstraction is as much a problem as under-abstraction. A flat, simple design is fine when the domain is simple.
+
+## Data Model
+
+Do the data structures fit the actual usage patterns?
+
+- Are the data models designed for how data is actually accessed, or for how it was conceptually modeled?
+- Are there impedance mismatches, places where code constantly reshapes data because the model doesn't match the access pattern?
+- Are types honest? Do they represent what data actually looks like at runtime, or claim more structure than exists?
+
+## Boundary Discipline
+
+Are system boundaries clean and well-placed?
+
+- Is validation concentrated at entry points, or scattered through internal code?
+- Are errors handled at boundaries and propagated cleanly, or caught and re-thrown at every layer?
+- Does data cross boundaries in well-typed shapes, or as bags of optional fields?
+- Could this subsystem be tested in isolation, or does it require the entire system to be running?
+
+## Evolution Readiness
+
+How well will this architecture handle likely changes?
+
+- If the most probable next requirement landed tomorrow, how much would change? "One file" or "everything"?
+- Are there hardcoded assumptions that would need to be relaxed?
+- Is the design bolted-on (integrated as an afterthought) or integrated (looks like it was always part of the plan)?
+- Are legacy paths preserved for compatibility that no one depends on?
+
+Don't penalize for not handling hypothetical changes. Focus on changes plausible given the codebase's trajectory.
+
+## Complexity vs. Value
+
+Is the complexity budget spent wisely?
+
+- Is complexity concentrated in the parts that need it (core logic, tricky invariants) or in accidental places (boilerplate, unnecessary indirection, configuration)?
+- Are there simpler ways to achieve the same behavior?
+- Does every component earn its existence, or are there vestigial pieces from an earlier design?
+
+## Consistency
+
+Does this subsystem follow the patterns established elsewhere in the codebase?
+
+- Are similar problems solved the same way here as elsewhere, or does this area invent its own patterns?
+- If the patterns differ, is there a good reason, or did it just evolve independently?
+- Inconsistency isn't automatically bad. But unexplained inconsistency is a maintenance burden.

package/framework/skills/how/references/explainer-prompt.md

@@ -0,0 +1,55 @@
+# Explainer Prompt Template
+
+Build the explainer subagent's prompt from this template. Fill in the placeholders.
+
+---
+
+You are writing an architectural explanation for a senior engineer. Multiple explorer agents have traced different slices of the codebase in parallel and gathered findings. Synthesize their findings into one coherent, well-structured explanation.
+
+## Original Question
+
+> {QUESTION}
+
+## Explorer Findings
+
+{EXPLORER_FINDINGS_ALL}
+
+## Instructions
+
+The explorers each investigated a different angle of the same subsystem. Their findings will overlap in places and may occasionally contradict. Reconcile them. Merge overlapping descriptions, resolve contradictions by checking the code yourself, and weave the separate slices into a unified picture.
+
+Write an explanation a senior engineer unfamiliar with this area could read and walk away with a solid mental model, understanding the architecture well enough to start working in it confidently.
+
+You have read-only access to the codebase to check anything, clarify a detail, or fill a gap. Use Read, Grep, and Glob as needed. The explorers did the heavy lifting, so you shouldn't need to re-explore from scratch.
+
+## Output Format
+
+Use this structure, adapted to what makes sense for the question. Not every section is needed for every question.
+
+### Overview
+1-2 paragraphs. What is this thing, what does it do, why does it exist. Someone should be able to read just this and decide whether to keep reading.
+
+### Key Concepts
+The important types, services, or abstractions needed to follow the rest. Brief definitions, not exhaustive.
+
+### How It Works
+The core of the explanation, and the longest section. Walk through the flow: what triggers it, what happens step by step, where data goes, what the decision points are.
+
+Use prose, not pseudocode. Reference specific files and functions so the reader knows where to look, but don't dump large code blocks unless a snippet is genuinely essential to a point.
+
+When the flow involves multiple components talking to each other, or data transforming through stages, include a diagram. Use mermaid (```mermaid) for structured flows (sequence diagrams, flowcharts, component graphs) or ASCII art for simpler relationships where mermaid would be overkill. Use your judgment. A diagram should clarify, not decorate. If prose covers the flow, skip the diagram.
+
+### Where Things Live
+A brief file/directory map. Just the ones someone would need to start working here.
+
+### Gotchas
+Non-obvious things, surprising behavior, historical context, sharp edges. Skip this section if there's nothing worth calling out.
+
+## Communication Style
+
+- Use concrete language, not abstractions-about-abstractions
+- Say "the `UserService` calls `AuthClient.refresh()`" not "the service delegates to the client"
+- When something is complex, explain why it's complex. Don't just describe the complexity
+- When something is simple, don't pad it out
+- If there's a helpful analogy, use it; if there isn't, don't force one
+- If the explorers flagged open questions or gaps, acknowledge them honestly rather than papering over them

package/framework/skills/how/references/explorer-prompt.md

@@ -0,0 +1,52 @@
+# Explorer Prompt Template
+
+Build each explorer subagent's prompt from this template. Fill in the placeholders.
+
+---
+
+You are exploring a codebase to understand how something works. Gather facts: trace code paths, read implementations, map components. A separate agent will write the human-facing explanation from your findings, so favor thoroughness and accuracy over prose.
+
+Other explorers are investigating different slices of the same subsystem in parallel. Don't try to cover everything. Focus on your assigned angle and go deep.
+
+## Question
+
+> {QUESTION}
+
+## Your Exploration Angle
+
+{EXPLORATION_ANGLE}
+
+## Exploration Instructions
+
+Start by finding the relevant code. Use Glob to find directories and files, Grep to find key symbols, Read to understand the actual implementation. Don't guess from names. Read the code.
+
+Follow this pattern:
+1. **Find the entry point.** What triggers this behavior? A user action, an API call, a scheduled job? Find where it starts.
+2. **Trace the flow.** Follow the call chain from the entry point. Read each function. Understand what data flows through and how it transforms.
+3. **Map the key abstractions.** What types, interfaces, services, or classes are central? Read their definitions. Understand what they represent and why they exist.
+4. **Find the boundaries.** Where does this subsystem interface with others? What goes in, what comes out?
+5. **Look for the non-obvious.** Anything surprising? Anything that looks like a historical artifact? Anything a newcomer would misunderstand?
+
+Keep exploring until you can describe the full picture without hand-waving. If you hit a part you can't trace, say so explicitly. "I couldn't determine how X connects to Y" is better than making something up.
+
+## Output
+
+Return your findings in this structure. Be factual and specific. Reference exact file paths, function names, type names, and line numbers where relevant.
+
+### Components Found
+The key types, services, classes, and abstractions. For each: name, file path, and a one-sentence description of what it does.
+
+### Flow
+The execution flow step by step. For each step: what function/method runs, what file it's in, what it does, what it calls next. Include the data that flows between steps.
+
+### Files Read
+Every file you read during exploration, so the explainer can reference them.
+
+### Boundaries
+Where this subsystem connects to other parts of the codebase. The inputs and outputs.
+
+### Non-Obvious Things
+Anything surprising, historically motivated, or easy to get wrong. Things that look like they should work one way but actually work another.
+
+### Open Questions
+Anything you couldn't fully trace or understand. Be honest about gaps.

package/framework/skills/merge-request/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: merge-request
+description: Create a GitLab merge request (MR) for the current branch using the glab CLI. Use this skill whenever the user asks to open, create, update, or prepare a GitLab MR or merge request.
+---
+
+# `merge-request` skill instructions
+
+Create a merge request for the current branch.
+
+## Process
+
+1. **Collect information**
+   - Get the current branch name: `git branch --show-current`
+   - Read the MR template from `.gitlab/merge_request_templates/default.md` if it exists.
+
+2. **Format MR title**
+   - Take the branch name, replace all `-` with spaces, and capitalize the first character.
+
+3. **Collect commits and build summary**
+   - List commits on the branch that are not on `develop`: `git log develop..HEAD --oneline`
+   - Read each commit message and convert it to a bullet list summarizing user-facing changes.
+   - Merge/squash related commits (for example, multiple commits for the same change).
+   - Keep the summary concise, with one bullet per logical change.
+
+4. **Fill template**
+   - Set Summary to the bullet list from step 3.
+   - Keep the Checklist section as-is.
+
+5. **Present plan and confirm** - Show the source branch, target branch (`develop`), title, and filled description. Ask: "Shall I create this MR?" Push the changes if the user says yes.
+
+6. **Create upon confirmation** - Use `glab mr create` with:
+   - `--source-branch`: Current branch
+   - `--target-branch`: `develop`
+   - `--title`: Prepend `Draft: ` to the formatted branch name
+   - `--description`: Filled template content
+   - `--assignee`: `1`
+   - `--squash`
+   - `--remove-source-branch`
+
+7. **Show the resulting URL.**

package/framework/skills/merge-request/examples.md

@@ -0,0 +1,5 @@
+# Examples
+
+- Read the GitLab MR template and current branch history before drafting the request.
+- Summarize related commits into concise user-facing bullets while leaving the checklist unchanged.
+- Display the complete MR plan and wait for approval before pushing or invoking `glab mr create`.

package/framework/skills/pull-request/SKILL.md

@@ -0,0 +1,31 @@
+---
+name: pull-request
+description: Create or update a GitHub pull request (PR) for the current branch using the gh CLI. Use this skill whenever the user asks to open, create, update, or prepare a GitHub PR or pull request.
+---
+
+# `pull-request` skill instructions
+
+Create or update a pull request for the current branch using `gh` CLI.
+
+## Process
+
+1. **Collect information**
+   - Get the current branch name: `git branch --show-current`
+   - Read the PR template from `.github/pull_request_template.md` if it exists.
+
+2. **Format PR title**
+   - Take the branch name, replace all `-` with spaces, and capitalize the first character.
+
+3. **Collect commits and build summary**
+   - List commits on the branch that are not on `develop`: `git log develop..HEAD --oneline`
+   - Read each commit message and convert it to a bullet list summarizing user-facing changes.
+   - Merge/squash related commits (for example, multiple commits for the same change).
+   - Keep the summary concise, with one bullet per logical change.
+
+4. **Fill template**
+   - Set Summary to the bullet list from step 3.
+   - Keep the Checklist section as-is.
+
+5. **Present plan and confirm** - Show the source branch, target branch (`develop`), title, and filled description. Ask: "Shall I create this PR?" Push the changes if the user says yes.
+
+6. **Create upon confirmation** - Use `gh pr create --title "<title>" --body "<body>" --base <target>` and show the resulting URL.

package/framework/skills/pull-request/examples.md

@@ -0,0 +1,5 @@
+# Examples
+
+- Build a PR title and concise summary from the current branch and commits, then show the complete body before asking for confirmation.
+- Preserve an existing `.github/pull_request_template.md` checklist while replacing only its summary content.
+- Push and create the GitHub PR only after the user approves the displayed plan.

package/framework/skills/release/SKILL.md

@@ -0,0 +1,30 @@
+---
+name: release
+description: Create a software release by reviewing commits, determining the semantic version, updating the changelog and package versions, committing release metadata, and tagging the result. Use this skill whenever the user asks to cut, prepare, publish, or tag a release.
+---
+
+# `release` skill instructions
+
+Create a release from the current branch state.
+
+## Process
+
+1. **Review recent commits** - Run `git fetch --tags`, `git describe --tags --abbrev=0` to find the latest tag. Run `git log <latest-tag>..HEAD --oneline --format="%s"` to collect all conventional commits since the last release. Read any existing `CHANGELOG.md`.
+2. **Categorize commits** - Group commits by conventional commit type:
+   - `feat!:` or `BREAKING CHANGE:` → breaking change
+   - `feat:` → minor feature
+   - `fix:` → patch fix
+   - `perf:`, `refactor:`, `test:` → patch (if no features)
+   - `chore:`, `docs:`, `ci:` → filtered from changelog
+3. **Determine next version** - Based on the [`commit` skill](../commit/SKILL.md) semver convention:
+   - Breaking changes → increment major version (e.g., `1.2.3` → `2.0.0`)
+   - New features → increment minor version (e.g., `1.2.3` → `1.3.0`)
+   - Only fixes/refactors → increment patch version (e.g., `1.2.3` → `1.2.4`)
+   - If no previous tag exists, propose `0.1.0`
+4. **Present release plan** - Show the current version, new version, categorized changelog entries, and ask: "Shall I create this release (tag vX.Y.Z and update CHANGELOG.md)?"
+5. **Execute on confirmation**:
+   - Update `CHANGELOG.md`: create a new `## [vX.Y.Z]` section under `## Unreleased`, move categorized entries (excluding chore/docs/ci) into it, add the release date, and keep the `## Unreleased` section empty for future work.
+   - Update project version metadata such as `package.json` and `package-lock.json` when present.
+   - Run `git add CHANGELOG.md package.json package-lock.json` for files that exist and commit with `chore: release vX.Y.Z`.
+   - Run `git tag -a vX.Y.Z -m "vX.Y.Z"`.
+6. **Verify** - Run `git log --oneline -n 3` and `git tag --list --sort=-v:refname -n5` to confirm the release tag and commit are in place.

package/framework/skills/release/examples.md

@@ -0,0 +1,5 @@
+# Examples
+
+- Inspect tags and conventional commits, propose the next semantic version, and show the release plan before changing files.
+- Move categorized entries from `Unreleased` into a dated version section while leaving a clean `Unreleased` section.
+- Update available package version metadata, commit the release files, create the annotated tag, and verify both afterward.

package/framework/skills/review/SKILL.md

@@ -0,0 +1,18 @@
+---
+name: review
+description: Perform a comprehensive code quality review of changes. Use this skill whenever the user asks to review code, inspect a diff, find bugs, assess production readiness, or perform a code review.
+---
+
+# `review` skill instructions
+
+Perform comprehensive code quality review.
+
+## Process
+
+1. **Review conversation and diff** - Read conversation history, run `git diff` for staged/unstaged changes, identify the problem being solved and the behavior being modified. Read related standards: [`references/standards/naming.md`](../../references/standards/naming.md), [`references/standards/testing.md`](../../references/standards/testing.md), [`references/standards/security.md`](../../references/standards/security.md), [`references/standards/performance.md`](../../references/standards/performance.md).
+2. **Check correctness** - Edge cases, concurrency, error handling, state transitions, and backward compatibility. Read contracts and interfaces before implementation.
+3. **Check maintainability** - Naming reflects business meaning, structure matches project conventions, and comments explain why rather than what.
+4. **Check testing** - Do tests prove the behavior change? Identify missing edge cases or failure paths. Tests should verify behavior, not mirror implementation.
+5. **Check performance** - Look for N+1 queries, unbounded loops, unnecessary allocations, and caching opportunities.
+6. **Check security** - Check input validation, authentication enforcement, secrets exposure, and least privilege.
+7. **Present findings** - Distinguish blockers from suggestions, explain the reasoning for each, and summarize overall risk and production readiness.

package/framework/skills/review/examples.md

@@ -0,0 +1,5 @@
+# Examples
+
+- Review the staged and unstaged diff, then report findings ordered by severity with file and line references.
+- Check correctness, tests, performance, security, and maintainability rather than only formatting.
+- End with an overall risk and production-readiness summary.

package/framework/skills/tdd/SKILL.md

@@ -0,0 +1,44 @@
+---
+name: tdd
+description: "Use only when the user explicitly asks for TDD, a failing test, or a regression test, OR when the bug has an obvious cheap local test target. Skip when the test path is unclear, expensive, integration-heavy, or not requested."
+disable-model-invocation: true
+---
+
+# TDD Bug Fix
+
+When fixing a bug with a clear, cheap test path, make the broken behavior executable before changing production code. The goal is a focused regression test that fails before the fix and passes after it.
+
+Do not force a test when it would be impractical. If the available test would require broad harness setup, brittle mocks, slow end-to-end infrastructure, production-only state, vague reproduction steps, or large unrelated fixture churn, skip adding a new test and use the closest useful verification instead.
+
+## Workflow
+
+1. **Understand the bug.** Identify the intended behavior, current behavior, affected path, and smallest observable reproduction.
+2. **Choose the narrowest executable check.** Prefer the closest unit, component, integration, or regression test already used for that codepath. If no practical test path is obvious, do not create one from scratch just to satisfy the workflow.
+3. **Write the failing test first.** Add the smallest focused test that would have caught the bug. The test should encode intended behavior, not mirror the current implementation.
+4. **Run the new test before fixing.** Confirm it fails for the intended reason. If it passes or fails for an unrelated reason, correct the test or reproduction before editing the implementation.
+5. **Fix the bug.** Make the smallest production change that satisfies the intended behavior while preserving nearby contracts.
+6. **Rerun the regression test.** Confirm the test now passes.
+7. **Run nearby validation.** Run relevant adjacent tests, type checks, lint, or scenario checks when the change has broader risk.
+
+## If a Failing Test Is Impractical
+
+Do not silently skip the regression step. Before fixing, explicitly explain why a failing test is impossible or not worth the cost, then choose the closest executable regression check available. Examples include a targeted script, manual reproduction command, browser automation, snapshot comparison, log assertion, or focused integration check.
+
+Prefer no new test over a bad test. A bad test is one that mostly tests mocks, encodes current implementation details, depends on timing or unrelated global state, needs expensive infrastructure for a small fix, or would be deleted immediately after proving the fix.
+
+## Guardrails
+
+- Do not change tests merely to match a wrong implementation.
+- Do not weaken existing assertions unless the expected behavior has genuinely changed and the reason is clear.
+- Keep the regression test focused on the bug; avoid broad fixture churn or unrelated coverage expansion.
+- Do not add tests when the practical signal is weak; use manual or scripted verification and say why.
+- If the bug is flaky, make the test deterministic where possible and document the signal being locked down.
+- If the bug exposes a broader class of failures, first land the focused regression path, then consider additional sibling coverage.
+
+## Final Response
+
+Report the evidence, not just the outcome:
+
+- Name the failing-before test or executable check and the failure it produced.
+- Name the passing-after test run and any nearby validation performed.
+- If failing-before evidence could not be demonstrated, state why and describe the closest regression check used instead.

package/framework/skills/tdd/examples.md

@@ -0,0 +1,5 @@
+# Examples
+
+- Reproduce a bug with a focused failing regression test before changing the implementation.
+- Use the narrowest practical test path, then run the regression test and relevant nearby validation after the fix.
+- Explain why a failing test is impractical and use the closest reliable executable check instead.

package/framework/skills/unslop/SKILL.md

@@ -0,0 +1,81 @@
+---
+name: unslop
+description: Cut AI tells from any writing. Must always apply.
+disable-model-invocation: true
+---
+
+# Unslop
+
+Edit text to remove AI patterns and add human voice.
+
+## Process
+
+1. Scan for the patterns below.
+2. Rewrite. Preserve meaning, match intended tone.
+3. Add soul (see next section).
+4. Self-audit: "What makes this obviously AI generated?" Fix remaining tells.
+
+## Adding soul
+
+Removing patterns is half the job. Sterile, voiceless writing is just as obvious.
+
+- **Have opinions.** React to facts instead of neutrally listing pros and cons.
+- **Vary rhythm.** Short sentences. Then longer ones that take their time. Mix it up.
+- **Acknowledge complexity.** "Impressive but also kind of unsettling" beats "impressive."
+- **Use "I" when it fits.** First person isn't unprofessional.
+- **Let some mess in.** Perfect structure looks machine-made.
+- **Be specific.** Not "this is concerning" but "there's something unsettling about agents churning away at 3am."
+
+## Patterns to detect and fix
+
+### Content
+
+1. **Puffery.** "pivotal moment", "testament to", "evolving landscape", "setting the stage for", "indelible mark", "deeply rooted". Cut puffery, state what happened.
+2. **Name-dropping.** Listing media outlets without context. Pick one, say what was said.
+3. **Superficial -ing phrases.** "highlighting...", "ensuring...", "reflecting...", "showcasing...", "fostering...". Delete or expand with real sources.
+4. **Promotional language.** "nestled", "vibrant", "breathtaking", "groundbreaking", "renowned", "stunning", "must-visit". Use neutral descriptions.
+5. **Vague attributions.** "Experts believe", "Industry reports suggest", "Some critics argue". Name the source or delete.
+6. **Formulaic challenges.** "Despite challenges... continues to thrive." Replace with specific facts.
+
+### Language
+
+7. **AI vocabulary.** Additionally, crucial, delve, enduring, enhance, fostering, garner, interplay, intricate, landscape (abstract), pivotal, showcase, tapestry (abstract), testament, underscore, vibrant. Replace with plain words.
+8. **Fancy ways to say "is".** "serves as", "stands as", "boasts", "features". Just say "is" or "has".
+9. **"Not just X, but Y."** State the point directly instead.
+10. **Rule of three.** Forcing ideas into groups of three. Use the natural number.
+11. **Synonym cycling.** Protagonist, main character, central figure, hero all in one paragraph. Pick one, repeat it.
+12. **False ranges.** "from X to Y" where X and Y aren't on a meaningful scale. List topics directly.
+
+### Style
+
+13. **Em dash overuse.** Avoid em dashes entirely. Use periods or commas only (no parentheses, no en dashes, no hyphen-as-dash substitutes). Em dashes are an AI tell, and reaching for parentheses instead just trades one tell for another. If a thought needs separation, end the sentence or use a comma.
+14. **Colon overuse.** Colons are fine before a list or example. Not as mid-sentence connectors. "If you're coming from traditional automation: instead of registering event handlers, you describe conditions" adds nothing with the colon. Rewrite to let the point stand on its own without comparison framing. "Describing when the scheduler should fire works best as plain English." Same meaning, no crutch punctuation.
+15. **Boldface overuse.** Don't bold every proper noun or acronym.
+16. **Inline-header lists.** The tell is a bold label and colon that restates the line: "**Performance:** Performance improved...". Convert those to prose. A bold lead-in that ends in a period, names the item, and is followed by genuinely new detail ("**Schema in TypeScript.** Tables live in one file.") is fine, not a tell.
+17. **Title case headings.** Use sentence case.
+18. **Decorative emojis.** Remove from headings and bullets.
+19. **Curly quotes.** Replace with straight quotes.
+
+### Communication artifacts
+
+20. **Chatbot phrases.** "I hope this helps!", "Let me know if...", "Of course!", "Certainly!", "Found the smoking gun!" Remove.
+21. **Cutoff disclaimers.** "While specific details are limited..." Find sources or remove.
+22. **Sycophantic tone.** "Great question! You're absolutely right!" Respond directly.
+
+### Filler
+
+23. **Filler phrases.** "In order to" becomes "To". "Due to the fact that" becomes "Because". "It is important to note that" gets deleted.
+24. **Excessive hedging.** "could potentially possibly be argued that it might" becomes "may".
+25. **Generic conclusions.** "The future looks bright." State specific plans or facts.
+
+### Jargon
+
+26. **Abstract metaphor nouns.** Substrate, wedge, vector, locus, vantage, nexus, primitive (as noun), harness (as metaphor), surface (as in "API surface"), bedrock, scaffolding (as metaphor), modality, paradigm, gold-plating, ratchet (as metaphor), evacuate (for moving code), endgame, north star, flywheel. These read as technical but usually have a plainer concrete word. "Substrate" becomes "base". "Wedge in" becomes "add". "Vector" becomes "way" or "method". "Gold-plating" becomes "more than the job needs". "Ratchet" becomes the mechanism's real name or "a limit that only tightens". "Evacuate" becomes "move out". "Endgame" becomes "the last phase". Pick the concrete word.
+
+### Plain speech
+
+27. **Say what it does, not how it feels.** "the database stays close at hand", "SQL you can read", "types that follow your schema" name a feeling. The fix names the mechanism or a number: "`.toSQL()` returns the exact string sent to the database", "a column rename fails the build". Ask what the sentence tells the reader to do or know, then write that. If you can't restate it as a concrete instruction, fact, or number, cut it. One more check: if the sentence could appear unchanged in another project's docs, it says nothing about this one. Cut it.
+28. **Shorten or split dense sentences.** If the reader has to backtrack to parse a sentence, break it in two or drop clauses. One idea per sentence.
+29. **Active voice.** Prefer it. Catch "is/are/was/were + past participle" and name the actor: "queries are validated" becomes "the compiler validates queries", "the file is parsed by the loader" becomes "the loader parses the file". Passive is fine only when the actor is unknown or genuinely doesn't matter.
+30. **Cut adverbs, or use a stronger verb.** "runs quickly" becomes "is fast" or the number. "significantly improves" becomes the measured delta. An adverb propping up a weak verb means the verb is wrong.
+31. **Prefer the plain word.** "utilize" becomes "use", "leverage" becomes "use", "facilitate" becomes "help", "numerous" becomes "many", "in the event that" becomes "if". The fancier synonym is rarely clearer.

package/framework/skills/unslop/examples.md

@@ -0,0 +1,5 @@
+# Examples
+
+- Rewrite release notes to remove inflated claims, filler, and generic AI phrasing while preserving meaning.
+- Edit technical prose for plain language, varied rhythm, active voice, and a natural human tone.
+- Scan a document for em-dash overuse, formulaic transitions, vague claims, and unnecessary jargon before rewriting it.