claude-english-buddy

Configure claude-english-buddy — set language, strictness, toggle auto-correction. <example> Context: User wants to inspect the currently active merged configuration. user: "/claude-english-buddy:config --show" assistant: "Reading project and plugin-data config files and displaying the merged active settings with their source." </example> <example> Context: User wants to raise the strictness level for their next session. user: "/claude-english-buddy:config --set strictness=strict" assistant: "Updating .claude-english-buddy.json with strictness=strict and showing the updated merged config." </example>

Spot-quiz on your top recurring English mistakes — presents one sentence per drill round with an intentional error matching your top-3 mistake categories, then asks you to correct it. Learning tool, not an evaluator. <example> Context: User has several weeks of correction history and wants active practice on their blind spots. user: "/claude-english-buddy:drill" assistant: "Loading your top-3 recurring mistake categories and generating a drill sentence." </example> <example> Context: User wants to focus a drill on just one category. user: "/claude-english-buddy:drill --category article" assistant: "Running a drill round focused on article errors from your history." </example>

Your top recurring English mistakes — all-time patterns that need attention. <example> Context: User wants the default top-20 all-time recurring mistakes. user: "/claude-english-buddy:mistakes" assistant: "Loading all-time correction history and ranking your top 20 recurring patterns by frequency." </example> <example> Context: User wants only the top 5 patterns to focus on. user: "/claude-english-buddy:mistakes --top 5" assistant: "Showing your top 5 recurring mistakes grouped by category with focus areas." </example>

Dry-run review — show what WOULD be corrected in a prompt WITHOUT submitting it or triggering auto-correction. Useful before important prompts, commit messages, or PR descriptions. <example> Context: User is about to submit a high-stakes prompt and wants to see corrections first. user: "/claude-english-buddy:preview refactor the autentication modul, its got too many responsibilties" assistant: "I'll run a preview review and show you what would be corrected before you submit." </example> <example> Context: User drafted a commit message and wants a dry-run of the hook's corrections. user: "/claude-english-buddy:preview Fixed parser bug, updated tests also" assistant: "Previewing the text through the same correction pipeline the hook uses." </example>

Deep English review of any text — commit messages, PR descriptions, docs, emails. <example> Context: User pastes a draft PR description inline and wants a deep review before posting. user: "/claude-english-buddy:review This PR fix the parser bug and add tests for edge case" assistant: "Reviewing the inline text for grammar, clarity, tone, structure, and technical accuracy." </example> <example> Context: User wants to review a longer document saved as a file. user: "/claude-english-buddy:review docs/release-notes.md" assistant: "Reading docs/release-notes.md and producing a full review with corrected version, changes table, and summary." </example>

Sentence-level clarity review — flags run-on sentences, ambiguous references, deeply nested clauses, and terminology drift. Suggests restructuring, not re-wording. Does not correct grammar or judge tone. <example> Context: User wrote a long paragraph with several nested clauses and wants a second opinion on readability. user: "Is this paragraph too hard to follow?" assistant: "I'll use the clarity-enhancer agent to flag nested clauses and ambiguous references." <commentary> Clarity is a distinct axis from grammar and tone. This agent focuses purely on structure and reference integrity. </commentary> </example> <example> Context: User has a draft README where the same concept is referred to as "function", "method", and "handler" in different paragraphs. user: "Check this README for inconsistent terminology." assistant: "I'll dispatch the clarity-enhancer to flag terminology drift and ambiguous pronouns." <commentary> Terminology consistency is a clarity concern, not a grammar concern — the individual words are fine but the reader has to hold three labels for one concept. </commentary> </example>

Fast mechanical grammar and punctuation check — flags spelling, agreement, tense, article, preposition, and punctuation errors against established rules. Does not evaluate tone, clarity, or structure. <example> Context: Orchestrator needs a first pass on a short paragraph before deeper review. user: "Run a grammar check on this README blurb." assistant: "I'll dispatch the grammar-checker agent for a mechanical pass." <commentary> Grammar-checker is the cheap first pass — it catches typos, agreement, and punctuation errors without spending judgement cycles on tone. </commentary> </example> <example> Context: Writing-reviewer orchestrator needs per-sentence error counts for a long doc. user: "Check the API reference for grammar mistakes." assistant: "I'll use the grammar-checker agent to list errors sentence by sentence." <commentary> Because this agent runs on haiku, it is suitable for high-volume mechanical passes where the cost of sonnet-level review is not justified. </commentary> </example>

Judgement-heavy tone evaluation — given a text and its destination (commit / PR / doc / email / chat), scores how well the tone fits and flags mismatches. Does not touch grammar or punctuation. <example> Context: User drafted a commit message and wants tone feedback before running a deeper review. user: "Does this commit message sound right?" assistant: "I'll use the tone-calibrator agent with context-type=commit to score the tone." <commentary> Tone issues (e.g. past tense, trailing period, filler words) are out of scope for grammar-checker. The tone-calibrator is where those judgements happen. </commentary> </example> <example> Context: User pasted an email draft to a senior colleague and is unsure about formality. user: "Is this too casual for an email to my manager?" assistant: "I'll dispatch the tone-calibrator with context-type=email to judge formality and match it to the recipient." <commentary> Register and formality are judgement calls; that is why this agent runs on sonnet, not haiku. </commentary> </example>

Deep English text reviewer — orchestrates three specialist subagents (grammar-checker, tone-calibrator, clarity-enhancer) and merges their findings into one report. Preserves the historical `/review` output format. <example> Context: User wants a thorough review of a long piece of text user: "Review this README draft for English quality" assistant: "I'll use the writing-reviewer agent to orchestrate grammar, tone, and clarity specialists." </example> <example> Context: User wrote a PR description and wants it polished user: "Check if this PR description sounds professional" assistant: "I'll dispatch the writing-reviewer; it will delegate grammar, tone, and clarity to three specialists and merge the findings." </example>

Recurring error patterns from non-native English speakers in developer contexts: article misuse, preposition confusion, tense mismatch, 'I am agree'-style anti-patterns, and other frequent L2 slips. Use when scanning for patterns a reader can map back to familiar mistakes rather than rediscover from first principles.

Core English grammar rules most likely to trip non-native developers: articles, subject-verb agreement, tense consistency, prepositions, countable vs mass nouns, comparatives. Use when reviewing grammar correctness of prose written for developer contexts (commits, docs, emails).

Punctuation conventions for developer prose: commas (serial, Oxford, clause-joining), semicolons, colons, hyphens vs en-dashes vs em-dashes, apostrophes, quotation marks. Use when reviewing punctuation of documentation, commit messages, or any prose where mis-pointing changes meaning.

Technical writing patterns for developer prose: API documentation structure, README shape, error-message wording, terminology consistency, and the active vs passive voice trade-off. Use when the text under review is documentation, a README, an API reference, or an error string.

Per-context tone rubrics for developer communication: commit messages, PR descriptions, code comments, API docs, emails, inline chat. Use when judging whether the register and formality of a piece of text fit its destination, not just whether it is grammatical.

2 hooks across 2 events