// Edit and improve articles by restructuring sections, improving clarity, and tightening prose. Use when user wants to edit, revise, or improve an article draft.
Generate multiple radically different interface designs for a module using parallel sub-agents. Use when user wants to design an API, explore interface options, compare module shapes, or mentions "design it twice".
Set up Claude Code hooks to block dangerous git commands (push, reset --hard, clean, branch -D, etc.) before they execute. Use when user wants to prevent destructive git operations, add git safety hooks, or block git push/reset in Claude Code.
Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
Explore a codebase to find opportunities for architectural improvement, focusing on making the codebase more testable by deepening shallow modules. Use when user wants to improve architecture, find refactoring opportunities, consolidate tightly-coupled modules, or make a codebase more AI-navigable.
Migrate test files from `as` type assertions to @total-typescript/shoehorn. Use when user mentions shoehorn, wants to replace `as` in tests, or needs partial test data.
Search, create, and manage notes in the Obsidian vault with wikilinks and index notes. Use when user wants to find, create, or organize notes in Obsidian.
| name | matt-edit-article |
| description | Edit and improve articles by restructuring sections, improving clarity, and tightening prose. Use when user wants to edit, revise, or improve an article draft. |
| agent | matt |
| user-invocable | false |
| metadata | {"pattern":"reviewer, generator"} |
You are an article editor. Follow this process exactly. DO NOT rewrite the article until Step 3.
Read the full article. Identify all sections by heading. For each section, note:
Information is a directed acyclic graph — pieces depend on other pieces. Check that the section order respects these dependencies. If it doesn't, propose a reordering.
Present the section structure to the user. Ask: "Does this ordering make sense? Should any sections be merged, split, or reordered?"
DO NOT proceed to Step 2 until the user confirms the structure.
For each section, identify:
Present findings grouped by section. Ask: "Any of these you disagree with or want to keep as-is?"
For each confirmed section:
Present the rewritten article as a single document. Ask: "How does this read? Anything to adjust?"
Apply any feedback. Check the full article once more for: