en un clic
improve-article
Use when improving an article or long-form draft for structure, clarity, coherence, flow, readability, or prose quality while preserving meaning, accuracy, intent, and voice.
Menu
Use when improving an article or long-form draft for structure, clarity, coherence, flow, readability, or prose quality while preserving meaning, accuracy, intent, and voice.
| name | improve-article |
| description | Use when improving an article or long-form draft for structure, clarity, coherence, flow, readability, or prose quality while preserving meaning, accuracy, intent, and voice. |
| disable-model-invocation | true |
Improve structure, clarity, coherence, flow, readability, and prose quality while preserving factual meaning, core argument, technical accuracy, authorial intent, and voice.
Do not invent facts, add unsupported claims, remove important nuance, or turn the article into generic polished writing.
Review the full article first.
Internally analyze section order, idea dependencies, unclear or unsupported claims, redundancy, gaps, transitions, tone drift, and readability problems.
Before rewriting, show only a brief review:
Key Issues: at most 6 bulletsProposed Rewrite Direction: at most 4 bulletsQuestions: at most 3 bullets, only when neededIf there are no blocking questions, write: No blocking questions. Share priority or tone adjustments; otherwise I’ll rewrite from this direction.
After feedback, rewrite the full article in one pass.
Use large coherent chunks only when length or accuracy makes one pass unsafe.
Finish with a concise editorial summary:
Use one feedback checkpoint before rewriting. Do not require outline approval or section-by-section approval unless the user asks or the article is too long or risky to revise accurately in one pass.
Use when posting validated code review findings as GitHub PR line-level comments or a GitHub PR review after completing a review.
Use when reviewing branch or PR changes against a base branch for correctness, security, concurrency, architecture, maintainability, testing, and performance risks.
Applies Karl Popper’s critical rationalism to software engineering, programming, and product building by treating requirements, designs, implementations, and product ideas as falsifiable hypotheses. Emphasizes conjectures and refutations, explicit assumptions, fast error discovery, small risky experiments, observable failure signals, reversible designs, and iterative elimination of mistakes.
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.
Baseline coding behavior. Use before writing, reviewing, debugging, or refactoring code. Establishes ground rules for assumptions, simplicity, surgical edits, and verification.
Generate or check Codex CLI .codex-plugin/plugin.json and Gemini CLI gemini-extension.json manifests from a Claude Code .claude-plugin/plugin.json source manifest. Use when maintaining one plugin across Claude Code, Codex CLI, and Gemini CLI, syncing plugin metadata, preserving platform-specific manifest fields, or validating cross-platform plugin manifests before release.