skills/writing-blog/SKILL.md
Create, diagnose, outline, rewrite, or polish blog posts and articles with reader expectation management, SCQA, Pyramid Principle structure, and concrete revision guidance. Use for writing from notes, optimizing drafts for structure/clarity/readability, polishing notes into publishable form, article outlines, or feedback on whether a draft reads well. Trigger on blog posts, articles, publishing, writing, first drafts, polishing, diagnosis, optimization, structure, outlines, submissions, newsletters, and reader-oriented writing. For raw reader-experience simulation without writing advice, use writing-reader-feedback instead.
npx skillsauth add plimeor/agent-skills writing-blogInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Help the user create, diagnose, outline, rewrite, or polish a blog/article so it serves the reader's path of understanding, not the author's raw thinking path.
Use the user's primary language unless they ask for another language.
Act as an editor who represents an intelligent outside reader. Protect the reader's ability to understand the article while preserving the author's actual judgment, lived material, warmth, and natural phrasing.
Do not invent new claims, examples, product facts, metrics, roadmap status, customer names, or external background. If source material is missing, mark the gap or ask for author input.
Do not turn this skill into raw reader simulation. When the user wants to know
what a reader thinks or feels while reading, use writing-reader-feedback
instead. This skill produces writing decisions, structure, drafts, rewrites, and
revision guidance.
Choose the narrowest mode that matches the request:
references/draft-from-notes.md and
references/structure-framework.md.references/diagnosis.md; read
references/structure-framework.md only when structure or reader flow is part
of the problem.references/structure-framework.md when reorganizing the article; read
references/style-and-humanizer.md before final prose cleanup.references/structure-framework.md.Do not run every mode by default. For example, a direct rewrite request should not become a long diagnosis unless the user asks for one.
audience, takeaway, and
publishing intent.audience, takeaway, source
material, or authorization would materially change the output. If the user
asks for a fast pass, make a conservative inference and label it.Before writing or diagnosing, identify the core reader from these sources, in order:
audience.Treat the core reader as a smart beginner in this specific topic unless the user defines a different reader. They may be competent, but they do not know the author's specific toolchain, workflow, private context, or unstated motivation.
audience, takeaway, and description only when the work mode requires it
and the values are supported by the source or user instruction.The task is complete when the requested artifact is delivered, the assumptions or author-input gaps are clear, and the output has not expanded beyond the requested mode.
tools
Decide whether and how to use authorized sub-agents, then coordinate delegated work while preserving the main agent's context. Use when the user asks for orchestration, parallel agents, delegation, background workers, context isolation, or when another skill needs delegated research, review, implementation, or verification. Owns host-policy checks, delegation packets, non-overlap, report verification, and stop rules. Do not use to bypass tool policy, infer user authorization, or add coordination overhead to simple single-threaded tasks.
development
Use before finalizing a non-trivial answer, recommendation, review, or decision to reconsider it and raise its quality, especially when shallow reasoning, context inertia, false framing, overconfidence, unfit analogy transfer, or an obvious-but-missed defect could distort the result. Trigger especially before applying external evidence, familiar frameworks, or comparisons to the user's specific request, and when the user asks to reconsider, double-check, take a second look, or sanity-check an answer. Reconsider the draft against its most likely failure mode, and use independent scrutiny only when it is useful and authorized.
development
Review concrete code plan drafts, specs, diffs, and implementation shapes. Use for code-review requests, serious code-plan design critique, and judging whether a proposed direction is sound. Prioritize solution direction, premise validity, logic chain, constraints, alternatives, design shape, contracts, tests, local fit, and actionable findings. Near miss: use code-plan to create or revise plans; use code-scope-gate for pre-spec scope shaping.
development
Write evidence-backed coding plans for implementation, debugging, refactoring, migrations, design parity work, and long-running agent tasks. Use when defining, clarifying, refining, or validating a development plan, /goal prompt, implementation approach, scope and non-goals, work sequence, acceptance criteria, regression evidence, verification strategy, or stop condition. Near miss: use code-review when judging an existing diff, spec, or already drafted plan rather than drafting or revising a plan. Also use when the user says `design twice` after a plan and wants an APOSD-style second-design pass over the completed plan.