public-risk-check

name

public-risk-check

description

Check blog drafts, HTML pages, demo copy, screenshots, source notes, social snippets, and publication artifacts specifically for public disclosure risk and risky wording before external sharing. Use when the user asks for 공개 리스크 체크, 민감정보 점검, publish safety, confidential information review, wording risk, customer anonymization, screenshot/data/link safety, or sensitive detail removal. For broader publish/no-publish judgment, use external-publication-review instead.

Public Risk Check

Purpose

Review whether a blog artifact can be shared publicly without exposing sensitive internal information, private third-party details, unsupported claims, or risky wording. This skill is a publication gate, not a style editor. It may suggest edits, anonymization, removal, or human approval requirements.

Use Korean by default for review notes. Keep sensitive source excerpts short and avoid repeating unnecessary confidential details in the response.

Use this as the narrow risk scanner inside or after $external-publication-review. It does not decide whether the article is valuable or well written; it decides whether public exposure creates avoidable disclosure or wording risk.

If the user names a local file, HTML file, screenshot directory, Notion page, Slack thread, URL, or source artifact, inspect it before making a source-specific risk claim. If access fails, label the scan as limited to the provided text.

For local files or directories, first run the bundled scanner when practical:

python3 scripts/risk_scan.py <path>
# or scan pasted text:
python3 scripts/risk_scan.py -

Run it from this skill directory, or resolve scripts/risk_scan.py relative to this SKILL.md. Use --json when you need machine-readable output; JSON includes summary and findings. The scanner covers common text, Markdown, HTML, SVG, JSON, YAML, TOML, JS/TS modules, shell scripts, SQL/config files, Astro/Vue/Svelte components, notebooks, source maps, web manifests, logs, Dockerfile/Makefile variants, .env* and package/deploy config files, stdin snippets passed as -, publication output folders such as dist/, build/, .next/, and .nuxt/, private Slack/Notion/Google Workspace links, Notion internal metadata URLs, source path strings with local, internal, admin, preview, draft, or debug markers, and risky filename/path metadata for text and non-text artifacts. Text and JSON summaries include scanned text-file count, skipped non-text file count, severity counts, highest severity, scope warning, and recommended action. Exit code 0 means no scanner finding, 1 means findings were detected, and 2 means a path/input error.

The scanner redacts sensitive excerpts in its output. It ignores obvious placeholders such as redacted values, your-token-here, and changeme, but still flags realistic key formats. Do not recover or repeat raw secrets, private URL paths, exact metric values, email local-parts, or HTML comment contents in the review response unless the user explicitly asks for local remediation detail. If the scanner reports 0 scanned text files, treat that as an insufficient automated scan, not as evidence that the artifact is safe. Treat all scanner hits as leads, not final judgment; still apply the manual review categories below.

When changing the scanner, run its bundled regression test before trusting the result:

python3 scripts/risk_scan_selftest.py

Risk Categories

• Internal names, private Slack/Notion/Google Workspace/GitHub links, unreleased projects, credentials, GitHub/Slack/OpenAI/AWS/JWT-like tokens, bearer authorization headers, logs, prompts, private URLs, local/private-network hosts, or implementation details that reveal security posture.
• Customer, partner, vendor, candidate, or employee details that are not clearly approved for public use.
• Exact private metrics, revenue, performance numbers, roadmap dates, sales strategy, pricing, or operational process.
• Screenshots, diagrams, demo data, file names, IDs, or metadata that reveal confidential context.
• Legal, security, hiring, personnel, incident, or competitive claims that require explicit human review.
• Unsupported factual claims, exaggerated benchmarks, or statements that imply endorsement by a third party.
• Wording that sounds accusatory, comparative, or absolute without source support.

Also inspect non-prose surfaces:

• HTML labels, meta tags, filenames, alt text, comments, bundled JSON, sample data, screenshots, URLs, and console-visible strings.
• LinkedIn/social snippets, previews, Open Graph copy, and CTA text.
• Demo payloads, generated examples, and placeholder data that look like real internal or customer data.
• Asset references in src, href, content, poster, Open Graph, and Twitter preview fields when filenames or paths reveal customer, candidate, employee, internal, private, or staging context.
• Connector export metadata from Notion/Slack fetches, including wrapper markup, ancestor paths, discussion URLs, page/user/data-source IDs, and source-system links that are not intended for readers.

False Positive Control

Do not block a detail only because it is specific. Treat it as lower risk when it is already public, cited to an approved public source, intentionally part of the author's public identity, or necessary for a useful technical explanation. Still note it when the source of public approval is unclear.

Workflow

1. Identify the publication target: internal-only, company blog, personal blog, recruiting, customer-facing, or social sharing.
2. Separate source facts, author judgment, inference, and unsupported claims.
3. Scan the artifact and any visible media/data for the risk categories above.
4. Classify each finding as blocker, needs approval, edit before publish, or acceptable with note.
5. Recommend the smallest safe edit: remove, anonymize, generalize, replace with public source, add caveat, or request approval.
6. State residual risk and whether the artifact is clear from the disclosure-risk perspective.

Severity Rules

• blocker: likely confidential, private, security-sensitive, personal, or legally/commercially risky. Remove or get explicit owner approval.
• needs approval: may be publishable, but only after source owner, manager, customer-facing owner, legal/security, or relevant reviewer confirms.
• edit before publish: risk can be fixed with anonymization, generalization, caveat, or replacement wording.
• acceptable with note: low-risk detail worth recording so reviewers know it was considered.

Output Format

Lead with the decision:

• ready: no material public-risk issue found from the reviewed scope.
• ready after edits: publish only after the listed edits.
• needs approval: a human owner must approve the named claim or detail.
• not ready: public sharing should stop until blockers are resolved.

Then list findings in a compact table or bullets with:

• Location or phrase.
• Risk type.
• Severity.
• Required edit or approval.
• Suggested replacement when an edit is straightforward.

When the user asks for revised copy, provide replacement wording that reduces disclosure while preserving the article's point.

If no issue is found, still state the scope that was reviewed, especially whether media, HTML, links, and source material were included.

Boundaries

This is not legal advice. If a finding touches contracts, customer permissions, employment matters, security incidents, regulated claims, or unresolved disputes, require human approval even if the prose can be softened. If source access is incomplete, label the review as limited to the provided material.