blog-task-router

name	blog-task-router
description	Route ambiguous blog work requests to the right Blog plugin skill or skill sequence. Use when the user asks broadly to review a blog post, improve a draft, prepare for external publication, check whether a post is safe to publish, decide if interaction is needed, or asks which Blog plugin skill should handle the task.

Blog Task Router

Purpose

Choose the smallest useful Blog plugin skill path for a request. If the next action is clear and the needed artifact is available, continue into that first skill instead of stopping at a routing-only answer. Return only a compact routing answer when the user explicitly asks which skill to use or the missing input blocks the next action.

Use Korean by default for user-facing routing notes.

Routing Rules

• Use $content-improvement when the main request is to improve prose, title, structure, claim, reader value, or Korean expression.
• Use $external-publication-review when the question is whether a draft, internal note, converted source, HTML artifact, demo writeup, or company blog post can be published externally.
• Use $public-risk-check when the user asks for sensitive-info review, disclosure risk, anonymization, customer/screenshot/link/data safety, or risky wording only.
• Use $interactive-elements when the user asks whether the article needs interactive HTML, visuals, diagrams, animation, 3D, demo UI, or a richer explanation layer.

If the request mixes multiple goals, route in this order unless the user explicitly prioritizes otherwise:

1. $external-publication-review when external publication, public sharing, company blog release, approval, safety, or "can this go out?" is implied, even if the draft's claim or reader value is weak.
2. $content-improvement when the user asks for writing improvement and no publish/no-publish judgment is implied.
3. $public-risk-check for local files, HTML, demos, screenshots, media, exact metrics, private links, or other disclosure surfaces.
4. $interactive-elements only after the core article and publication boundary are stable.

Do not ask the user to choose a skill when the request already implies one. Make the routing decision and proceed. Default broad blog review with an artifact to $external-publication-review rather than $content-improvement, because broad review usually means publication readiness in this plugin. Do not polish a publication-facing draft before the publication gate has classified whether the problem is author intent, reader value, source faithfulness, public boundary, or publication fit.

Fast Decisions

• "블로그 좀 봐줘" with a draft or artifact but no specific ask -> default to $external-publication-review; route to $content-improvement only when the user explicitly asks for prose, title, structure, or Korean expression improvement.
• "글 개선해줘" -> $content-improvement, then route to $external-publication-review if the result is publication-facing.
• "외부에 내도 돼?" -> $external-publication-review.
• "민감한 거 있어?" -> $public-risk-check.
• "인터랙티브 넣을까?" -> $interactive-elements, but downgrade to $content-improvement first if the claim is unclear.
• "HTML/demo까지 봐줘" -> $external-publication-review plus $public-risk-check for artifact files and visible data.

Output Contract

Return:

• recommended path: one skill or ordered skill sequence.
• why: one or two sentences explaining the route.
• needed input: only the missing artifact or context that changes the next step.
• first action: the exact next skill to run.

When proceeding into another skill, include only a one-line routing note before the actual work. Keep routing compact. A router answer should reduce confusion, not become another review or an extra approval step.