external-publication-review

name

external-publication-review

description

Review a blog draft or internal-to-external publication candidate before external release. Use when the user asks for 외부 발행 전 리뷰, 외부공개 검토, publication readiness, publish review, blog approval review, 사내공개 글을 전체공개로 전환할 수 있는지, or whether an internal AX sharing note, Slack/Notion-derived draft, meeting note, agent interview log, experiment report, demo/code-result writeup, interview piece, or company blog post is ready to publish externally.

External Publication Review

Purpose

Act as the pre-publication review gate for a Corca blog artifact before it becomes externally visible. Review the draft as a public knowledge asset, not only as prose. Decide whether it is ready to publish, needs edits, needs source-owner confirmation, needs risk approval, or should stay internal.

Use Korean by default for user-facing review notes. Keep source titles, product names, file names, and technical terms in their original language when translation would reduce clarity.

Review Scope

Review five dimensions together:

1. Author intent: The source owner or named author could plausibly say, "this represents my thinking."
2. External reader value: An outside reader can understand the problem, why it matters, what changed, and what they can reuse.
3. Source faithfulness: Important claims are supported by the provided source, author confirmation, or public references.
4. Public boundary: Sensitive internal details are removed, anonymized, generalized, or explicitly approved.
5. Publication fit: The output shape, CTA, next reading path, and distribution context fit the intended channel.

If the user only wants sensitive-info scanning, use $public-risk-check. Use this skill when the question is broader: "Can this go out?"

Internal Source Conversion

When the artifact comes from internal Corca material, review whether the source was framed before publication work. Name the likely public shape: case study, explainer, tutorial, research note, interview piece, experiment report, living document, interactive article/demo, or internal-only note. If the shape is unclear, treat that as a publication-fit problem, not only a writing problem.

Do not push the source owner to write the post from scratch. Limit author/source-owner burden to confirming direction, intent, facts, missing context, sensitive boundaries, and final approval. If those confirmations are missing, downgrade the decision instead of inventing certainty.

Treat the operating loop as background context: Discover -> Frame -> Transform -> Review -> Publish -> Learn. This skill owns the Review gate. It may identify missing framing or transformation work, but it should hand narrower repairs to $content-improvement, $public-risk-check, or $interactive-elements.

Inputs To Request Or Infer

Prefer reviewing with:

• draft or HTML artifact
• source material or source links
• intended publication channel: company blog, LinkedIn, recruiting, customer-facing page, personal blog, or internal-only
• named author/source owner
• target reader
• known no-go areas

If some inputs are missing, continue with the provided artifact and mark the review as limited. Ask one focused question only when the missing answer changes the publish/no-publish decision.

If the user names a local file, Notion page, Slack thread, URL, or source artifact, read or fetch it before making a source-specific judgment. If access fails, say exactly what could not be read and downgrade the decision scope to the provided material only.

Minimum Review Packet

Try to establish these fields before saying anything is ready:

• source owner or author
• target channel and audience
• source material or explicit note that source access is unavailable
• publication status: internal draft, internal published post, external candidate, or final artifact
• known sensitive boundaries
• desired next action after publication

If any of the first four are missing, do not return ready or ready after edits. Use needs author confirmation unless the missing item is only access to optional supporting material and the reviewed public artifact already has source-backed claims. Do not hide unresolved fields inside a longer value. Phrases like unknown owner, source not reviewed, date not provided, access unavailable, or approval pending still block ready and ready after edits.

When inputs are incomplete, start by reconstructing the packet from the artifact and label unknown fields as unknown, not provided, or not reviewed. Do not silently fill gaps with guesses. Use this compact shape:

• author/source owner:
• target channel/audience:
• source material reviewed:
• publication status:
• sensitive boundaries:
• desired next action:

Then apply the decision to that packet. This makes the review usable as a handoff note for the source owner or final publisher.

Decision Downgrades

Use the strictest relevant downgrade:

• Missing author/source owner for a first-person, interview, or experience piece -> needs author confirmation.
• Source material unavailable for source-derived claims -> needs author confirmation unless the draft clearly cites public sources.
• Sensitive detail found but likely removable -> ready after edits.
• Sensitive detail found that requires owner, legal/security, customer-facing, or manager approval -> needs risk approval.
• Public reader/value unclear even after edits -> internal only for now or not ready.
• No reviewed artifact, only a vague request -> ask for the artifact instead of issuing a publication decision.

Use ready after edits only when the remaining blockers are concrete edits the publisher can make without new author, risk, customer, legal/security, or manager confirmation. Do not use it when the review packet still has unknown source owner, target audience/channel, source material reviewed, or publication status. If any confirmation, approval, or review-packet uncertainty remains, use needs author confirmation or needs risk approval instead.

Hard Stops

Do not return ready when any of these are true:

• No author/source owner is identified for a first-person, interview, or experience-based piece.
• Important claims are not traceable to source material, author confirmation, or public references.
• The artifact contains private URLs, customer details, private metrics, screenshots, logs, credentials, or security/incident detail that has not been removed or approved.
• The article's public reader and value are unclear.
• The piece implies company, customer, partner, or third-party endorsement without explicit support.
• HTML/demo assets contain example data, labels, filenames, or screenshots that have not been reviewed.

Decision States

Lead with one decision:

• ready: externally publishable from the available evidence.
• ready after edits: publish after the listed concrete edits; no remaining confirmation or approval is needed.
• needs author confirmation: author/source owner must confirm intent, facts, or attribution.
• needs risk approval: sensitive details require an owner, manager, legal/security, or customer-facing approval.
• internal only for now: useful internally, but not safe or valuable enough for external release yet.
• not ready: draft lacks enough substance, evidence, or public-safe framing.

Keep the decision consistent with gate summary: ready requires all gates to be pass; ready after edits may include edit-resolvable thin gates but no block or confirmation/approval-dependent gate; non-ready decisions need at least one thin or block gate.

Review Checks

Author Intent

• Does the draft preserve the author's actual perspective rather than flattening it into generic AI prose?
• Is the credited person, team, or company voice clear?
• Are quotes, first-person passages, and strong opinions supported by the source owner?
• Does the article overclaim what the author learned, built, or believes?
• If the source began as Slack/Notion/AX sharing material, is the author comfortable with converting that internal context into a public asset?

Reader Value

• Can a reader outside Corca understand the context without internal shorthand?
• Is the first 30 seconds clear: problem, stakes, and why now?
• Does the piece include a reusable lesson, method, decision criterion, caution, or example?
• Is the target reader explicit enough to shape depth and language?
• Does the title and introduction promise something the body actually delivers?

Source Faithfulness

• Separate source facts, author judgment, inference, and unsupported claims.
• Flag claims that need a source, public reference, screenshot, benchmark note, or author confirmation.
• Downgrade exact claims when only qualitative evidence exists.
• Do not invent metrics, customer impact, adoption, or causality.
• Preserve uncertainty when the source is exploratory, experimental, or retrospective.

Public Boundary

Check whether the artifact exposes:

• customer, partner, vendor, candidate, or employee details
• internal product names, code names, private links, Slack/Notion/Google Workspace URLs, repo names, file paths, logs, prompts, credentials, or screenshots
• exact private metrics, revenue, roadmap dates, strategy, sales process, incident details, or security posture
• unsupported third-party comparisons or implied endorsements

For detailed disclosure scanning and replacement wording, hand off to $public-risk-check. For local files, HTML, demos, or asset directories, ask $public-risk-check to include its bundled scripts/risk_scan.py pass before finalizing the publication decision. When reporting risk, identify location and category without copying raw credentials, private URL paths, exact private metrics, personal contact details, hidden comments, or other sensitive snippets into the response. When reviewing Notion/Slack connector exports or fetched pages, treat wrapper metadata as private source metadata: ancestor paths, discussion markers, page/user/data-source IDs, and connector URL schemes for discussions, page discussions, collections, or users. Do not copy those values into public drafts or review output; report only the location and category, and require $public-risk-check before a final positive publication decision.

Publication Fit

• Does the output shape fit the source: article, case study, interview, tutorial, research note, experiment report, living document, or interactive demo?
• Does it need a CTA, next reading path, recruiting link, product link, or LinkedIn summary?
• If it includes HTML/interactive elements, does the interaction clarify the article rather than decorate it?
• Does the final artifact need internal comments/feedback before external posting?
• Is there a clear owner for the final publish action and post-publication response?

Output Contract

Return:

• decision: one decision state.
• why: 2-4 sentence rationale.
• review scope: what artifact and source material were actually reviewed.
• gate summary: author intent, reader value, source faithfulness, public boundary, and publication fit, each starting with pass, thin, or block.
• source access: source, access status, read scope, source date/revision, supports, and gaps. Say exactly what could not be read.
• public shape: one explicit publication shape, such as case study, explainer, tutorial, research note, interview piece, experiment report, living document, interactive article/demo, or internal-only note. Do not return an undecided option set.
• publication metadata: author/credited voice, contributors, created/revised date, source context, reader takeaway, disclosure changes, and CTA or next reading path; mark unknowns instead of inventing them.
• review packet: the minimum packet fields, including unknowns.
• required edits: concrete blockers to resolve before publication.
• recommended edits: quality improvements that are not blockers.
• confirmations needed: author, fact, risk, approval, or distribution owners.
• public-risk notes: sensitive areas to remove, anonymize, generalize, or approve.
• ready-to-publish checklist: short checklist tailored to this artifact.
• next skill: $content-improvement, $interactive-elements, $public-risk-check, or none if no narrower repair is needed.

When editing is requested, provide replacement wording for the risky or weak passages instead of only diagnosing them.

For saved review artifacts, validate the response shape with the bundled linter before treating the review packet as handoff-ready:

python3 ../../scripts/review_output_lint.py <review-output.md>
# or pipe a copied review:
python3 ../../scripts/review_output_lint.py -

Keep the result strict. A useful review can say "not ready" with three concrete fixes; a vague approval is worse than no review.

Boundaries

Do not publish, deploy, post to Slack, or create social posts unless the user explicitly asks. Do not treat this review as legal approval. If source access is incomplete, label the decision as limited to the provided material. If the draft is not ready, say what would make it ready rather than forcing it into an external article.