content-improvement

name	content-improvement
description	Improve an existing blog draft, outline, interview-derived note, or rough source material by sharpening the claim, reader value, structure, evidence, and Korean prose while preserving the author's point of view. Use when the user asks for content improvement, 글 개선, 초안 개선, 구조 정리, 주장 강화, 문장 다듬기, or turning rough blog material into a clearer draft without running the full publication workflow.

Content Improvement

Purpose

Improve the content quality of a blog artifact that already has some material. Stay focused on the article itself: claim, structure, evidence, clarity, rhythm, and author voice. Do not take over source discovery, visual design, publication readiness, or public-risk review unless the user asks; hand those off to $external-publication-review, $interactive-elements, or $public-risk-check when needed.

Use Korean by default for user-facing review notes and rewritten prose unless the source or user explicitly requires another language.

Do not treat "better writing" as sufficient for publication. If the draft is intended for external release, the last answer should explicitly route it through $external-publication-review.

Do not make a risky draft more publishable by polishing it while preserving sensitive details. If the material contains private URLs, credentials, exact internal metrics, customer or employee identifiers, screenshots/logs/prompts, or unapproved internal strategy, redact or generalize those details in the rewritten text and route the artifact to $public-risk-check.

Workflow

1. Identify the current state: rough notes, outline, partial draft, near-final draft, or feedback request.
2. Name the main editorial gap before rewriting: unclear thesis, weak reader problem, missing evidence, loose structure, generic prose, abrupt flow, or weak ending.
3. Preserve strong existing material. Do not rewrite a whole draft when targeted edits solve the problem.
4. Improve in this order: reader promise, claim, structure, evidence, section transitions, sentence clarity, title and ending.
5. Mark assumptions and unsupported claims instead of inventing proof.
6. Return a compact change summary plus the revised text or focused patch the user asked for.
7. If the draft is now publication-facing, list what still needs author, fact, or public-risk review.

Source-Bound Editing

When improving material derived from Slack, Notion, AX sharing, interviews, meeting notes, demos, or code results:

• Separate source facts, author judgment, and inference before rewriting.
• Preserve the source owner's point of view; do not turn rough internal notes into confident public claims.
• Keep uncertainty when the source is exploratory, retrospective, or experimental.
• Use placeholders such as [private link removed], [metric generalized], [customer name removed], or [needs author confirmation] instead of copying sensitive source details.
• If the requested rewrite would require facts not present in the source, return a focused question or mark the gap under unsupported or assumed.

Risk-Safe Editing

If the draft includes sensitive-looking details:

• Do not repeat raw credentials, private URL paths, exact private metrics, email local-parts, logs, hidden comments, or customer-identifying snippets in the response.
• In rewritten prose, replace risky specificity with the smallest safe wording that preserves the article's point.
• In review notes, name the risk category and location instead of quoting the sensitive value.
• If the user asks for a full rewrite but the source is risk-heavy, provide a safe partial rewrite plus a $public-risk-check handoff rather than reproducing the whole risky draft.

Editorial Checks

• Reader entry: Can an outside reader understand why this topic matters in the first 30 seconds?
• Author thesis: Is the author's actual judgment visible, or does the text sound like a generic summary?
• Evidence: Are claims backed by examples, decisions, tradeoffs, observations, or source material?
• Structure: Does each section advance the argument instead of repeating context?
• Voice: Keep concrete Korean prose. Avoid inflated claims, empty abstractions, and AI-like transitions.
• Ending: Close with what changed, what the reader can reuse, or what remains uncertain.

Output Shapes

Choose the lightest useful output:

• diagnosis: what works, what blocks publication, and what to fix first.
• outline repair: revised section order with short notes for each section.
• targeted rewrite: only the title, intro, transition, section, or ending that needs work.
• full draft revision: a cleaned-up complete draft when the user asks for it or the whole draft is structurally weak.
• question: one focused question when the missing piece cannot be inferred.

Output Contract

Return:

• main issue: the highest-leverage content problem.
• changed: what was improved and what was intentionally preserved.
• revised text: the edited passage, outline, or draft.
• unsupported or assumed: claims that still need source support or author confirmation.
• risk-safe notes: sensitive or approval-sensitive areas redacted, generalized, or handed off.
• publication handoff: whether to run $external-publication-review next.

Boundaries

Do not invent sensitive facts, customer names, metrics, or internal strategy. Do not approve external publication from this skill. If the draft includes public-disclosure concerns, say that $public-risk-check should run before publication and do not expose the raw risky value in your answer. If the user asks for interaction or HTML, improve the content first, then use $interactive-elements for the expression layer.