wiki-policy-check

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

wiki-policy-check — Audit business-rule leaks in this repo

wiki-policy-check — 审核仓库中的业务规则泄露问题

Convention this skill enforces: technical rules live in the project repo; business and product rules live in the central wiki. This skill audits all markdown in the current repo for content that crossed the line and reports what should migrate.

本Skill遵循的约定：技术规则存放在项目仓库中；业务与产品规则存放在中央wiki中。 本Skill会审核当前仓库中的所有markdown内容，找出越界的内容并给出迁移建议。

Project guardrails

项目约束规则

.wiki-guardrails.yml

exists, treat it as the local policy source for wiki path, markdown allowlist, and sensitive paths. Do not infer a different allowlist from the skill. If it is missing, read

CLAUDE.md

AGENTS.md

and report that guardrails are missing.

若存在

.wiki-guardrails.yml

文件，则将其视为wiki路径、markdown允许列表和敏感路径的本地策略来源，不得从Skill中推断其他允许列表。若该文件缺失，则读取

CLAUDE.md

AGENTS.md

并报告约束规则缺失。

Where the wiki lives

Wiki的存放位置

The path of "the central wiki" is project-specific. Before running, read the project's

CLAUDE.md

and/or

AGENTS.md

(and

.agents/rules/

if present) to find:

The wiki location (e.g.
```
wiki/
```
as a subfolder,
```
../knowledge-base/
```
as a sibling, an external URL).
The project's own definition of what is a business rule — most projects spell this out in a "Business rules — policy" section. Respect the line they draw, especially nuances (e.g. a tax product might say "regulatory algorithm = technical, regulatory scope decision = product"; a public site might say "marketing copy = local, the rule it encodes = wiki").

If the project has no policy spelled out, fall back to the generic definition below and report that the policy is missing as part of the audit.

“中央wiki”的路径因项目而异。运行前，请读取项目的

CLAUDE.md

和/或

AGENTS.md

（若存在

.agents/rules/

也需读取）以获取：

Wiki位置（例如作为子文件夹的
```
wiki/
```
、作为同级目录的
```
../knowledge-base/
```
、外部URL）。
项目自身对业务规则的定义——大多数项目会在“业务规则——政策”部分明确说明。请遵循项目划定的界限，尤其是细节差异（例如税务产品可能规定“监管算法=技术内容，监管范围决策=产品内容”；公共网站可能规定“营销文案=本地存储，其编码的规则=存于wiki”）。

若项目未明确说明政策，则采用以下通用定义，并在审计报告中指出政策缺失。

When to run

运行时机

After a long stretch of doc updates in this repo.
Before opening a PR that adds substantial documentation.
Periodically (monthly cadence works in most projects).
Whenever the user asks "is anything leaking?", "audit the docs", or similar.

仓库文档经过长时间更新后。
提交包含大量文档内容的PR之前。
定期运行（大多数项目每月一次即可）。
每当用户询问“是否有内容越界？”“审核文档”或类似问题时。

Steps

操作步骤

Read the project's policy (
```
CLAUDE.md
```
,
```
AGENTS.md
```
, optionally
```
.agents/rules/
```
). Extract:
- The path of the wiki (subdir or sibling).
- The project's specific examples of "this is technical" vs "this is product" (project-specific nuances override the generic list below).
List every
.md
in this repo, excluding:
- ```
node_modules/**
```
  ,
```
.git/**
```
  ,
```
dist/**
```
  ,
```
build/**
```
  ,
```
.next/**
```
  ,
```
.wrangler/**
```
  ,
```
.astro/**
```
  ,
```
.cache/**
```
- Auto-generated outputs (Playwright
```
test-results/
```
  , lockfiles, generated types).
Read each file fully — leaks hide in the middle of mostly-technical docs. Skim is not enough.
Classify each file's content:
- Pure technical → no action.
- Pure business (anything customer-facing, pricing, policy, monetization, journey, compliance, product decision) → flag for migration.
- Mixed → identify the business chunks specifically and flag those, not the whole file.
Generic signals that almost always indicate a leak (project policy may add or override):
- Pricing / monetization: currency mentions ("R$", "$", "€"), percentage rates, "monthly fee", "take-rate", "subscription tier", "Free/Pro plan", "fixed monthly".
- Customer-facing policies: "cancellation", "refund", "no-show", "courtesy credit", "warranty", "terms of use", "service-level agreement".
- Journeys / personas: target customer descriptions, anchor customer mentions, ICP language used as product framing rather than just example labels.
- Compliance posture: "LGPD", "GDPR", "CCPA", "consent", "privacy policy", "data retention", "anonymization", "right to be forgotten", liability statements.
- Scope decisions: "we will support X but not Y", phased rollout language, anchor-customer commitments.
- External integrations rationale: when, why, billing impact (technical "how to integrate" stays here; the "should we use it" is product).
- Open product questions: anything phrased as a question for the owner, parked decisions, "decide later" markers about features.
Cross-check the wiki: for each flagged item, look in the wiki location identified in step 1 to see if a canonical version already exists.
- If yes → suggested action is "cross-ref + delete here" (do not duplicate).
- If no → suggested action is "migrate via
  /wiki-ingest
  " (run from the wiki repo / wiki folder, not from this repo).
Output a single report. Do not modify files.
Ask before applying changes. The skill only reports; the user decides what migrates.

读取项目政策（
```
CLAUDE.md
```
、
```
AGENTS.md
```
，可选
```
.agents/rules/
```
）。提取：
- Wiki的路径（子目录或同级目录）。
- 项目对“技术内容”与“产品内容”的具体示例（项目特定细节优先于以下通用列表）。
列出仓库中所有
.md
文件，排除：
- ```
node_modules/**
```
  、
```
.git/**
```
  、
```
dist/**
```
  、
```
build/**
```
  、
```
.next/**
```
  、
```
.wrangler/**
```
  、
```
.astro/**
```
  、
```
.cache/**
```
- 自动生成的输出内容（Playwright
```
test-results/
```
  、锁定文件、生成的类型文件）。
完整读取每个文件——越界内容可能隐藏在以技术内容为主的文档中间，仅浏览是不够的。
对每个文件的内容进行分类：
- 纯技术内容 → 无需操作。
- 纯业务内容（任何面向客户、定价、政策、盈利模式、用户旅程、合规性、产品决策相关内容）→ 标记为需迁移。
- 混合内容 → 明确识别其中的业务片段并标记，而非标记整个文件。
几乎总能表明内容越界的通用信号（项目政策可补充或覆盖）：
- 定价/盈利模式：提及货币（“R$”、“$”、“€”）、百分比费率、“月费”、“抽成比例”、“订阅层级”、“免费/专业版”、“固定月付”。
- 面向客户的政策：“取消”、“退款”、“爽约”、“礼遇信用额度”、“保修”、“使用条款”、“服务水平协议”。
- 用户旅程/用户画像：目标客户描述、核心客户提及、作为产品框架而非仅示例标签的ICP术语。
- 合规姿态：“LGPD”、“GDPR”、“CCPA”、“同意”、“隐私政策”、“数据保留”、“匿名化”、“被遗忘权”、责任声明。
- 范围决策：“我们将支持X但不支持Y”、分阶段推出相关表述、核心客户承诺。
- 外部集成理由：何时、为何集成以及计费影响（技术层面的“如何集成”留在此处；“是否应使用该集成”属于产品内容）。
- 未解决的产品问题：任何以问题形式向负责人提出的内容、暂未决定的事项、关于功能的“稍后决定”标记。
交叉核对wiki：对于每个标记项，查看步骤1中确定的wiki位置，确认是否已存在标准版本。
- 若已存在 → 建议操作是“添加交叉引用 + 删除此处内容”（避免重复）。
- 若不存在 → 建议操作是“通过
  /wiki-ingest
  迁移”（从wiki仓库/wiki文件夹运行，而非当前仓库）。
输出一份完整报告。不得修改文件。
执行更改前需询问用户。本Skill仅提供报告，由用户决定迁移内容。

Output format

输出格式

undefined

undefined

Wiki Policy Check — <YYYY-MM-DD>

Findings (<n>)

File	Excerpt	Type	Suggested action	Confidence
<path>:<line>	"<short quote>"	business	migrate to <wiki>/business/<page>.md	high
...	...	mixed	cross-ref + delete	medium

File	Excerpt	Type	Suggested action	Confidence
<path>:<line>	"<short quote>"	business	migrate to <wiki>/business/<page>.md	high
...	...	mixed	cross-ref + delete	medium

Files audited and clean (<n>)

<list>

<list>

Notes

Auto-generated content skipped: <count> files
Already covered by the wiki: <count> findings (cross-ref recommended)
Project policy gaps observed: <list any policy text that was missing or unclear>

undefined

Auto-generated content skipped: <count> files
Already covered by the wiki: <count> findings (cross-ref recommended)
Project policy gaps observed: <list any policy text that was missing or unclear>

undefined

Rules

规则说明

Read-only: this skill never modifies files. The user runs
```
/wiki-ingest
```
(in the wiki repo or wiki folder) to actually migrate.
Project policy beats generic policy: when the project's own
```
CLAUDE.md
```
declares a nuance (e.g. "tax algorithms stay technical here"), follow it even if the generic signal list above would flag the content.
Default to flagging: when in doubt about whether something is a business rule, flag it — the owner decides.
Do not duplicate: if a rule already exists in the wiki, the recommended action is "cross-ref + delete here", not "migrate again".
Do not flag generic stack mentions: technology names ("React", "TanStack Start", "Drizzle", "Better Auth", "Convex", "Cloudflare Workers") are technical and stay. Flag only when these appear bundled with product framing — "we use X because our customers Y" — and the leak is the product framing, not the tech.
Marketing-copy special case: if the project ships a public site, the copy itself lives there (it has to render), but the rule the copy encodes belongs in the wiki and the copy should reference the rule rather than restate it.
Skip auto-generated content (build output, lockfiles, generated types, test-results).
Be specific in the excerpt: pull the actual quote, not a paraphrase. The user's decision depends on seeing the exact wording.

只读模式：本Skill绝不会修改文件。用户需在wiki仓库/wiki文件夹中运行
```
/wiki-ingest
```
来实际执行迁移。
项目政策优先于通用政策：当项目自身的
```
CLAUDE.md
```
明确细节差异（例如“税务算法作为技术内容留在此处”）时，需遵循项目政策，即使上述通用信号列表会标记该内容。
默认标记：若不确定某内容是否为业务规则，应标记它——由负责人最终决定。
避免重复：若规则已存在于wiki中，建议操作是“添加交叉引用 + 删除此处内容”，而非“再次迁移”。
勿标记通用技术栈提及内容：技术名称（"React"、"TanStack Start"、"Drizzle"、"Better Auth"、"Convex"、"Cloudflare Workers"）属于技术内容，应留在此处。仅当这些技术名称与产品框架绑定出现时才需标记——例如“我们使用X是因为客户Y的需求”，此时越界的是产品框架部分，而非技术本身。
营销文案特殊情况：若项目包含公开网站，文案本身需存放在网站中（用于渲染），但文案所编码的规则应存于wiki，文案应引用规则而非重复规则内容。
跳过自动生成内容（构建输出、锁定文件、生成的类型文件、测试结果）。
摘录需具体：引用实际原文，而非改写。用户的决策依赖于准确的措辞。