skill-extraction-workflow

Skill Extraction Workflow

Turn observed experience into reusable skills without business-specific details. writing-skills and skill-creator define format and authoring discipline; this skill covers mining, filtering, generalizing, validating and landing. When shared-skill changes are ready, invoke code-review automatically before completion. Apply code-review/references/development-completion.md and this owner's required review/challenge gate.

Start here (30 秒定位)

下面的 Core Rules 很长——不用全读。按这个顺序走:

1. 跑流程:references/extraction-quickstart.md 是一页式执行流(charter → source register → 分批 → 每批 draft / sibling-map / sanitize / dual-track / commit → closeout)。任何新提炼先读它。
2. 三道必读闸(任何 shared-skill 改动都过):
   • R0 泄漏审计零命中 → references/r0-leakage-audit.md
   • dual-track 评审 = 独立 review + 对抗 challenge → references/dual-track-review-gate.md
   • 生命周期/provenance 隔离(WIP 进 per-host scratch,shared 树只放 label 化规则)→ references/extraction-lifecycle-handoff.md
3. 长尾方法(按场景触发,完整清单见底部 ## Reference Loading):UI/UX 判断提炼、incident 复盘、两源(design+code)、parallel-stack、归因核验、example-domain 预选 等。

下面 ## Core Rules 是按主题分组的红线/不变式定义;## Extraction Workflow 是 Step 0–6 的有序执行流程。两者各持一面、互相指引、不深抄对方:某步骤引用拥有该闸的 Core Rule、只写顺序 + 步骤特有的执行细节,不复述该规则的原则;某 Core Rule 不内嵌步骤的模板/清单,只给红线 + 指针。同一 facet 同时写进两边 = drift 缺陷(改一处忘另一处即矛盾);冲突时以 ## Core Rules 的定义为准,新增时向它收敛。向 canonical 面收敛时若需改写/删除既有规则文本,按 references/rule-consolidation.md 的零损失义务表治理。

Core Rules

Sanitization, provenance & naming（脱敏 / provenance / 命名）

• R0 (mandatory clean-landing gate): Before marking any skill or reference change R0-clean, landing-clean, merge-ready, or cleanly landed, run the leakage audit (audit_cmd from the maintainer's private alias YAML) and require zero hits across all leakage categories — design-source file keys/URLs/node-ids, project/team identifiers, real subproject paths / repo / branch names, contributor names/emails, ticket ids, internal domains/hosts, and any non-distilled business/product noun pointing to one specific organization.
  • Probe, don't infer: a local environment without ALIAS_AUDIT_CMD is normal, but you must observe that — before recording interim / r0_status, run check-ccl-skills.sh and cite the actual r0_status= / final-token line it produced; never infer the branch from "unset is common" or a bare printenv ALIAS_AUDIT_CMD pre-check. Skipping straight to the interim fallback is a blocked-verification miss (a set var means the private audit is configured; it is available only once it runs clean to alias_audit_ok, and a set-but-broken var is itself a blocked-verification failure to fix or waive, not a fallback licence).
  • Interim commit semantics: when ALIAS_AUDIT_CMD is genuinely unset, the contributor may commit, push, or open a Draft/WIP MR only as interim with R0 pending maintainer audit recorded, but must not merge or claim clean landing until R0 passes or an explicit risk-owner waiver is recorded. (Label semantics: interim alone does not decide commit permission — this R0-pending interim allows commit/push/Draft-MR but blocks merge/clean-landing, while the review/challenge gate's interim is an uncommitted checkpoint that blocks commit itself; each gate's failure carries its own commit permission, and when both fail the stricter applies.)
  • Edit-time gates that stay inline: every new sanitized label MUST already exist in the alias YAML before clean landing (fail-closed); pre-existing leakage may be known_debt but new/modified content MUST stay zero-hit; grep cannot catch source-shaped example identifiers (variable/function/class/file/package names lifted verbatim) so adversarial review (codex challenge or equivalent) is the practical safety net.
  • False-green guard: the public fallback is public interim evidence only — the private alias audit (alias_audit_ok) has NOT run when those tokens print, so record interim / R0 pending and never treat ccl_skill_check_ok, ccl_skill_check_interim_ok, generic_r0_leak_scan_ok, or alias_audit_unavailable as clean-landing R0 evidence; the clean-landing signal is ccl_skill_check_clean_ok (r0_status=private-ok); no project alias is not a waiver (use the generic process-retro profile when no product corpus applies; neither the generic fallback nor an ad-hoc grep is the clean-landing gate).
  • For category definitions, alias-YAML structure, the false-green guard and fallback/token semantics, known_debt semantics, example-identifier substitution, the generic process-retro profile, and ALIAS_AUDIT_CMD enforcement, read references/r0-leakage-audit.md.
• Pre-draft example domain selection (preempts retroactive R0 cleanup cycles): R0 catches identifier leakage at audit time; this rule catches scenario-domain leakage at drafting time — scenario shape (entities + verbs + invariants together) reads as source-shaped to adversarial review even when identifiers are sanitized, so apply BOTH axes. Trigger: pre-selection is REQUIRED whenever the changed unit has an example set — ≥2 new/edited examples across the changed files, OR any multi-line / code-fence example (ONE single-line example may use canonical placeholders Acme*/Foo*/sample* without pre-selection; agents cannot bypass by splitting examples). Record a durable closeout validation row (commit body / source map / per-host scratch, NOT chat-only) naming the selected domains, the rejected source domain abstractly — record THAT a domain was rejected, never WHICH industry — and the changed examples checked. Pre-selection feeds adversarial review, never replaces it — codex/adversarial review stays the R0 safety net. For the worked two-axis example, the neutral-domain selection method (source-artifact-relative, not workspace-wide), the exact row format, and row-accuracy rules, read references/example-domain-preselect.md.
• Extraction lifecycle handoff: project-specific provenance NEVER enters the shared skill tree — three phases (WIP in per-host scratch → closed-batch provenance in per-host private alias → shared tree carries only label-based capability rules); the shared-repo history (commit messages, branch names, and the entire MR/PR record) is itself shared tree and names only sanitized labels, never real source artifacts — when unsure a surface is shared, sanitize. Existing in-skill registers with real provenance are known_debt and MUST migrate to the private alias before any new provenance is added. For per-phase content lists, migration workflow, R0 jurisdiction boundary, the shared-history sanitization rule, the generic-methodology (shape-vs-content) carve-out, known_debt grandfather cleanup, and authoring-from-a-plugin-install, read references/extraction-lifecycle-handoff.md.
• Name extracted skills and reference files by reusable capability, not by the source artifact, source page, project nickname, migration task, or original UI label. Keep source names only as provenance in source maps or reference metadata.
• Preserve provenance during analysis, but strip provenance from executable guidance unless source identity is needed for auditing.
• For private or domain-sensitive sources, strip identifiable source names from shared skills, shared source registers, and shared source maps. Keep the duplicate-extraction lookup in a local private alias map outside the shared skill tree, mapping original source names to sanitized capability labels.
• Renaming a source-derived skill or reference is not complete until the executable wording is generalized too. Search for old source names, old scenario labels, and old capability labels; update them to the new reusable concept or keep them only in explicit provenance.
• Do not preserve long verbatim source text in skills. Keep structured summaries, short necessary excerpts, and source status instead of copied dumps.