revise
Revise
Structurally edit an article draft through an interactive, section-by-section process. Unlike prose-fix (cosmetic polish), this skill rewrites for clarity, flow, and argument strength.
Step 1 — Understand Context
Before editing, ask the user (skip questions they already answered). Use AskUserQuestion when available; otherwise ask directly:
- Audience: "Who is the target audience?" — Options: "Beginners", "Experienced developers", "General tech readers"
- Venue: "Where will this be published?" — Options: "Blog post", "Newsletter", "Documentation"
- Takeaway: "What is the one thing the reader should remember?" — ask separately as text (too specific for predefined options)
Step 2 — Analyze Structure
Read the full article. Map the sections as an information DAG — each concept depends on prior concepts. Identify:
- Dependency violations: concept used before it is introduced
- Redundant sections: same point made twice in different places
- Missing sections: logical gaps the reader needs bridged
- Weak intro: does the first paragraph hook and set expectations?
- Weak conclusion: does it reinforce the one takeaway?
Present the current section outline and a proposed reordering. Wait for user confirmation before proceeding.
Step 3 — Rewrite Section by Section
For each section, in order:
- Lead with the point — first sentence states what the section proves or teaches
- Max 240 characters per paragraph — split longer paragraphs
- Cut ruthlessly — remove sentences that don't serve the section's point
- Smooth transitions — each section's opening should connect to the previous section's conclusion
- Show, don't tell — prefer concrete examples over abstract claims
Edit the file in place, one section at a time.
Step 4 — Final Check
After all sections are revised:
- Re-read the full article for flow
- Verify the intro promises what the article delivers
- Verify the conclusion reinforces the one takeaway
- Check that no concept is used before it is introduced
- Report a summary of structural changes made
Rules
- Always read the file before editing
- Always confirm structural changes with the user before rewriting
- Preserve the author's voice — restructure and tighten, don't impose a new style
- Preserve code blocks, technical terms, and proper nouns exactly
- Do not fix typos or formatting — that is prose-fix's job
- If the article is already well-structured, say so and suggest prose-fix instead
Scope
- Works on
.mdfiles - If no file is specified, ask the user which file to revise
More from helderberto/skills
explain-code
Explains code with visual diagrams and analogies. Use when explaining how code works, teaching about a codebase, or when the user asks "how does this work?" Don't use for modifying code, fixing bugs, or generating new implementations.
45ship
Commit and push changes using atomic commits. Use when user asks to "ship", "commit and push", or requests committing and pushing changes. Don't use for creating pull requests or reviewing changes before committing.
45refactor-plan
Create structured refactoring plans. Use when user wants to plan a refactor, needs a refactoring strategy, or mentions breaking down large changes into small commits. Don't use for implementing code changes directly, small one-line fixes, or renaming a single variable.
44safe-repo
Check for sensitive data in repository. Use when user asks to "check for sensitive data", "/safe-repo", or wants to verify no company/credential data is in the repository. Don't use for general code review, adding .gitignore entries, or scanning non-git directories.
41lint
Run linting and formatting checks. Use when user asks to "run linter", "/lint", "check linting", "fix lint errors", or requests code linting/formatting. Don't use for running tests, type-checking only, or projects without a lint script in package.json.
40tdd
Guides test-driven development with red-green-refactor loop. Use when user wants to build features or fix bugs using TDD, mentions "red-green-refactor", wants test-first development, or requests TDD workflow. Don't use for writing tests after implementation, adding tests to existing untested code, or one-off test fixes.
40