@ccoalm/ccl-skills 0.1.0

package/dist/assets/marketplace/plugins/ccl-skills/skills/skill-extraction-workflow/references/eval-routing.md

@@ -0,0 +1,86 @@
+# Routing Eval — Tier-1 静态分析器契约（+ T2/T3 阶段计划）
+
+可执行的技能有效性 harness。本 ref 定义 Tier-1 的契约;完整方案见 [docs/f4-skill-effectiveness-harness.md](../../../docs/f4-skill-effectiveness-harness.md)。
+
+可执行 benchmark 从 **Tier-1 起步**;Tier-2(冻结路由 task-bank)、Tier-3(hub golden trace)分阶段落地。
+
+## Tier-1:静态路由分析器
+
+`scripts/eval-routing.rb <repo-root> [--json <path>] [--quiet]`。只读每个 `skills/*/SKILL.md` 的**frontmatter `description`**(body 里的 `→` 是叙述,不是路由),分段抽:
+
+- **claim 触发词** = `Use when` / `Proactively invoke` 段里的引号短语(归一 = 去引号 + trim + lowercase,CJK 原样)。
+- **redirect** = `Skip` 段里 `->`/`→` 后的 skill token(backtick 可选)。
+
+退出码:`0` = 无 blocking;`1` = 有 blocking;`2` = 用法/解析错。
+
+## 发现分类
+
+只让**客观可判**的挡 merge;模糊/随机的只报告。
+
+| 类型 | 级别 | 判据 |
+|---|---|---|
+| `dangling_redirect` | **blocking** | backtick 的 `` `X` `` redirect,X 不是已装 skill(显式 skill-ref 语法 + 未知目标) |
+| `exact_trigger_collision` | **blocking** | 同一归一触发词被 ≥2 skill 认领,且认领方之间无互相 redirect 消歧 |
+| `exact_trigger_collision_disambiguated` | advisory | 同上但认领方之间存在 redirect(已消歧) |
+| `fuzzy_collision` | advisory | 一个 skill 的完整触发词是另一 skill 触发词的子串 |
+| `possible_dangling` | advisory | 裸(无 backtick)redirect 目标含连字符、像 skill 名但未安装(疑似改名/删除) |
+| `prose_redirect_target` | advisory | Skip redirect 的目标从句含 `owner`/`reviewer` 却没有任何 backtick 的已装 skill —— 无法确定路由的散文死链(如 `→ the adversarial or delete-code review owner`) |
+
+**为什么这么分级**:真正的风险是造出 flaky/可作弊、于是被无视的门禁。裸单词 redirect(`-> stack skill`)按普通英文忽略,不误报;单向 `A->B`(枢纽→叶)是正确路由,不报。`prose_redirect_target` 只在从句显式说"owner/reviewer"却给不出可解析 skill 时报,避免对通用散文误报——刻意留在 advisory:散文匹配非 ground truth,只 nudge 作者点名真 skill,不挡 merge。
+
+## 怎么用
+
+- `make eval-routing` — 人读报告。
+- `check-ccl-skills.sh` 末尾自动跑;有 blocking → 整个校验失败(`eval_routing_blocking`),否则 `eval_routing_ok`。
+- 落地门禁见 host 技能 Core Rule「Routing-surface change gate」。
+
+## 解 blocking
+
+- `dangling_redirect`:目标 skill 不存在 —— 改对名字,或目标确实没装就别用 backtick skill-ref 语法。
+- `exact_trigger_collision`:两个 skill 抢同一触发词 —— 要么在一方 `Skip when … → 另一方` 显式消歧,要么把触发词改具体让两者不再字面相同。
+
+## Tier-2:路由 task-bank + 廉价 grader(已落地,advisory)
+
+`scripts/eval-routing-bank.rb <repo-root> [--bank p] [--model m] [--limit N] [--dry-run] [--json p] [--baseline p] [--desc-budget-chars N]`。`--desc-budget-chars N` 把每条 description 截到前 N 字符再评（消费端截断臂——如 Codex 在 ~2% 上下文预算/未知窗口 8,000 字符下压缩技能清单）；plain 与 budgeted 各跑一遍即可定位"只活在描述尾部"的路由触发词。`make eval-routing-bank`。
+
+- 冻结 task-bank `eval/routing-tasks.jsonl`:每行 `{id, utterance, expected_skill, must_not_route_to?, source, why_expected, frozen_at_sha}`,种子取自 source-register 历史 miss + bootstrap 路由规则。
+- grader = 每 task 一次本机 `claude --print --tools "" --model <haiku>`,喂 utterance + 全部 skill description(agent 真正路由的那份面),要 `{selected_skill, confidence, rationale_short}`。
+- **路由兼容性信号,不是真值预言机** —— grader 自己可能错;只衡量"当前 description 能否让廉价模型把固定 utterance 路由到 expected"。
+- **advisory**:不接 `check-ccl-skills.sh`,不挡 merge。退出码:`0` = 跑完;`2` = 用法;`3` = grader 整体不可用(claude CLI 缺失则打印 skipped 后 `0`)。路由 miss 永不非 0。
+- **防作弊**:runner 校验每 task 的 `frozen_at_sha` 是 HEAD 祖先(非祖先 = drift,排除出回归判定);同一改动若同时动 task-bank 和 SKILL.md description 会显式告警(防"改 skill 顺手改测试让它过")。
+- `--baseline <json>` 给 diff 式报告(newly_failed / newly_passed)。
+
+### Bank 用例修复的测量纪律(normative)
+
+对 bank 失败用例做路由面修复时,以下每条都是修复轮的过闸条件,不是建议:
+
+1. 动任何 description 之前必须先跑 **≥10 轮有效观测**的稳定性基线,把稳定失败与抖动分开;抖动不得作为修改依据(grader 超时/不可解析轮不算有效观测,须补跑)。
+2. 改后通过数必须在**最终措辞**上重测:中间稿的通过数在措辞再变的那一刻作废,不得挪用到最终候选的证据里。
+3. 受影响邻居用例集必须改前/改后各 **≥3 轮**,集合须含期望 owner 自己的兄弟用例与高词面重叠的他 owner 用例;任何邻居回归都阻断本轮。
+4. 每轮判决必须连同 **runner 调用、grader 模型身份、候选身份**(commit 或描述内容指纹)与**原始逐轮工件的持久定位符**一并记入轮记录;没有定位符的通过数只能标注为 operator-reported,不得据以宣称修复轮已 concluded。
+
+## Tier-3:hub golden trace 真 agent 回放(已落地,advisory,人工判定)
+
+`scripts/eval-golden-trace.rb <repo-root> [--traces d] [--max-turns N] [--timeout S] [--only id] [--limit N] [--json p] [--dry-run]`。`make eval-golden-trace`。
+
+- golden trace `eval/golden-traces/*.json`(每个 hub skill 一条):`{id, hub_skill, trigger_prompt, assert{must_invoke_skill, must_not_invoke_skill, no_destructive_command}, allowed_variance, frozen_at_sha}`。当前 3 条:product-rd-workflow / defect-diagnosis / testing-strategy。
+- runner 把 trigger 喂给 headless `claude -p --output-format stream-json --max-turns N --allowedTools Skill Read Grep Glob`(**allowlist:只读 + Skill,无副作用** —— Bash/Edit/Write/NotebookEdit/cron/task 全因不在白名单而禁用),从事件流抽**真 agent 实际 invoke 的 Skill**,做**结构化断言**:must_invoke ⊆ invoked、must_not ∩ invoked = ∅、命令无破坏性类。
+- **只断言路由结构,不断言措辞/顺序/tool 数**。v1 因禁用工具,聚焦路由结构;产物/命令族断言留待沙箱化后扩展。
+- **比 Tier-2 高保真**:观察真 agent(完整 skill 体 + hook + context),不是廉价模型对 description 的看法。
+- **advisory + 人工判定**:不接门禁、不挡 merge。状态 PASS / FAIL / INCONCLUSIVE(agent 未在 max-turns 内路由)。退出码:`0` = 跑完;`2` = 用法;`3` = agent 整体不可用(claude 缺失则 skipped 后 `0`)。路由漂移永不非 0。
+- **随机性**:agent 非确定;判定先人工、nightly 起步,有稳定史前不自动 gate。防作弊同 T2(`frozen_at_sha` 祖先校验)。
+- **双用途**:除回归外,Tier-3 还可当**改技能前的 RED-baseline**(改前手动跑触发场景看真 agent 是否真路由错,改后看 compliance)——可选;只有真观察到 miss 才算 RED(PASS/INCONCLUSIVE 不算),小 N + 非确定有噪声,手动跑两次自己留两份报告。落地 + 防作弊注意见 [validation-and-landing.md](validation-and-landing.md) "Optional real-agent RED-baseline"。
+
+## Health roll-up:综合分 + 趋势(已落地,advisory)
+
+把上面各信号卷成**一个加权 0–10 分 + 趋势**,答"仓库在变好还是变差"。这是 OpenSSF Scorecard 给代码仓用的形态(每 check 0–10 → 按风险加权聚合 0–10 → 跨时间追);我们把它套到 **F4 技能 eval 信号**上,不是去打分代码工具。映射依据见 [harness-patterns-and-eval.md](harness-patterns-and-eval.md) §3.4。
+
+`scripts/eval-health.rb <repo-root> [--trace-json p] [--bank-json p] [--history p] [--no-write] [--json p] [--quiet]`。`make eval-health`。
+
+- **维度(各 0–10,按风险加权,OpenSSF 风格)**:`structural` 权重 10(Critical,`validate-skill.sh` pass/fail)· `routing_static` 权重 10(Critical,T1 blocking=0 满分、有 blocking 砸到 3、advisory 轻罚)· `trace` 权重 7.5(High,T3 pass/considered)· `bank` 权重 5(Medium,T2 pass/tasks)。
+- **只跑确定性两维**(structural + routing_static,无 LLM、快);`trace`/`bank` 需 `claude` 且随机,**不自动跑** —— 用 `--trace-json` / `--bank-json` 把 T3/T2 报告喂进来,否则该维 **skip,权重按比例重分**给在场维(诚实标注 `dims=…`)。
+- `composite = Σ(score_i·w_i) / Σ(w_i)`,只对在场维求和;skip 维自动从分母剔除。band:≥9 CLEAN / ≥7 WARNING / ≥4 NEEDS WORK / <4 CRITICAL。
+- **advisory,永不因分数阻断**:退出码 `0` = 跑完 **或** 没有可算的维(都不是失败);`2` = 用法/setup 错(`<repo-root>` 不对或无 `skills/` 目录)。低分、坏报告、空历史都不会非 0。畸形的 T2/T3 报告(非对象 / 非整数 / `pass>total`)直接 **skip,不静默打分**。**绝不接进 `check-ccl-skills.sh`**。二元门禁(结构校验 + T1 blocking)仍是真值、独立挡 merge,与这个分无关。理由是 Goodhart 律(measure 变成 target 就不再是好 measure):一旦这个综合分成了 merge gate,人会去调分而不是修仓。
+- **corpus/version 守卫(防跨变更 task-bank 当稳定指标比)**:每条历史记 `corpus`(= task-bank + golden-traces 输入内容的指纹)+ `repo_sha` + 在场 `dims`。**趋势 delta(IMPROVING/DECLINING)只跟最近一条 `(corpus, dims)` 都相同的历史比**;否则打印"baseline reset, not compared",不偷偷比。这样"加了 10 条简单 task → 分涨了"不会被读成真进步(尺子换了)。
+- **历史文件**:默认 `eval/health-history.jsonl`,**git-ignore**(同 Goodhart 理由:committed 的数会招"调数不修仓";也免 append 把树搞脏)。`--history` 可改路径,`--no-write` 不落盘。
+- **基线**(本机、本 corpus):确定性两维 = `9.5/10`(structural 10 + routing_static 9,advisory=1)。

package/dist/assets/marketplace/plugins/ccl-skills/skills/skill-extraction-workflow/references/evidence-card-template.md

@@ -0,0 +1,51 @@
+# Evidence Card Template
+
+Phase 1 material (design source: `docs/skill-extraction-optimization-design.md`). An evidence card is the lightweight, structured record produced during step 2 of the five-step analysis (see `references/l0-l1-l2-routing.md`). It keeps a conclusion from arriving before its evidence and makes a later re-check cheap.
+
+A card is required for an L0 capture and for the short-form evidence record of an L1 change; an L2 change uses it as the entry point into the full source register.
+
+## Template
+
+```markdown
+## Evidence Card
+
+- Trigger / context:
+- Observed failure or opportunity:
+- First-hand evidence:
+  - transcript / diff / test output / incident / command output:
+- Reusable pattern:
+- Proposed skill effect:
+- Scope:
+  - Applies when:
+  - Does not apply when:
+- Risk:
+  - Routing impact: yes/no
+  - Privacy/leakage risk: yes/no
+  - User-authority impact: yes/no
+  - Validation impact: yes/no
+- Behavioral cases:
+  - Should trigger:
+  - Should not trigger:
+- Recommended path: L0 / L1 / L2
+- Owner / follow-up:
+```
+
+## Why each field exists
+
+- **First-hand evidence** blocks extraction-by-vibe: a transcript, diff, test output, incident, or command output must exist before any RCA. "An LLM said so" is hypothesis-grade, not first-hand (see the Core Rules on LLM-consultation evidence). If the only evidence is second-hand, record the gap rather than inventing a card.
+- **Applies / does not apply** keeps the rule from over-generalizing — a rule with no stated boundary tends to over-fire.
+- **Should trigger / should not trigger** feed directly into behavioral regression cases for L1/L2.
+- **Risk (routing / privacy / authority / validation)** decides escalation: any `yes` on routing, authorization, or validation pushes the card toward L2 (see the L2 trigger list).
+
+## How to fill a card (abstract walkthrough — no persisted capture)
+
+This describes HOW each field gets filled; it deliberately uses **no concrete values, no tier verdict, and no real quotes**. A real card — with filled fields and a `Recommended path` conclusion — lives in per-host scratch / a private alias and is **never persisted under `skills/**`**, so this reference keeps only the blank template above. Reading this is not a precedent for committing a card into the shared tree.
+
+- Fill *trigger / context* with the situation that surfaced the lesson (for a process-meta case, the workflow step where it appeared).
+- Fill *observed failure or opportunity* with what actually went wrong, or what could be better.
+- Fill *first-hand evidence* with the concrete artifact — a transcript, diff, test output, command output, or incident — never "an LLM said so".
+- Fill *reusable pattern* with the generalization, only if the case abstracts beyond itself.
+- Fill *scope* with the applies / does-not-apply boundary.
+- Fill *risk* by marking the routing / privacy / authority / validation axes yes or no.
+- Fill *behavioral cases* by describing the should-trigger and should-not-trigger conditions (described, not transcribed).
+- The *tier decision* then follows from risk: if routing, authorization, or validation reads yes, the recommended path escalates toward the higher tiers; otherwise it stays low. Record the chosen path in the private card, not here.

package/dist/assets/marketplace/plugins/ccl-skills/skills/skill-extraction-workflow/references/example-domain-preselect.md

@@ -0,0 +1,79 @@
+# Pre-Draft Example Domain Selection
+
+A complement to R0 (`references/r0-leakage-audit.md`). R0 catches **identifier leakage** at audit time (a name's role lifted from source); this rule preempts **scenario-domain leakage** at drafting time. Without pre-draft selection, the R0 example-identifier audit fires repeatedly on bare common nouns drawn from the workspace's source-domain shape — and rework is more expensive than upfront choice.
+
+## Why Scenario-Domain Leakage Happens
+
+The R0 example-identifier audit fires on bare common nouns drawn from the workspace's source-domain shape — transaction / membership / payment vocabulary in a commerce workspace, stage / grade / curriculum vocabulary in an education workspace, claim / billing / policy vocabulary in an insurance workspace. The reason: *scenario-domain shape* (entities + verbs + invariants) reads as source-shaped to adversarial review even when identifiers are sanitized.
+
+## Two-Axis Substitution — Not Interchangeable
+
+The two leakage classes need two different substitution disciplines:
+
+| Axis | Leakage class | Substitution discipline |
+|---|---|---|
+| **R0 placeholder** (`Acme*` / `Foo*` / `sample*`) | identifier leakage — a name's role lifted from source | Replace the identifier at audit / review time |
+| **Pre-draft domain selection** | scenario-domain leakage — entities + verbs + invariants together read as source-shaped | Choose scenario domain BEFORE drafting examples |
+
+`AcmeOrderService` is identifier-clean but scenario-leaked if "Order" is the source domain. **Apply both axes.** Neither alone is sufficient.
+
+## Threshold — When Pre-Selection Is REQUIRED
+
+Pre-selection is REQUIRED whenever the changed extraction unit contains an **example set**, defined as:
+
+- Two or more new / edited examples total across the changed files, OR
+- Any multi-line / code-fence example
+
+Only when the changed unit has at most ONE new / edited one-line example total may the canonical placeholder pattern (`Acme*` / `Foo*` / `sample*`) be used without pre-selection.
+
+**Anti-bypass rule**: agents cannot split examples across separate one-liners and claim each is individually exempt. The threshold is cumulative across the changed extraction unit.
+
+## How To Pick A Neutral Domain
+
+**"Neutral" is relative to the source artifact, not the whole workspace.**
+
+- **Source artifact** = the specific corpus / file / design / code slice being mined for THIS extraction. Not the workspace as a whole.
+- In generic or multi-domain repos, "neutral" means a domain distant from THAT source artifact's domain, not the whole repo.
+
+Suggested neutral domains (file export retention, auth / token flow, document preview, generic ordered list) are *examples, not safe defaults*. In a SaaS workspace, auth / export themselves can read source-shaped — choose a domain distant from BOTH the workspace business model AND the changed skill's target.
+
+## Validation Row — Durable, Not Chat-Only
+
+For any non-wording extraction (as defined in the dual-track gate) that includes new examples, record this row in the durable extraction trace (commit message body, source map, or per-host scratch artifact per `references/source-to-skill-extraction.md`):
+
+```
+example-domain preselect: selected=<domains>; rejected source domain=<the workspace domain>; changed examples checked=<file:line>
+```
+
+Without the durable row, pre-selection is unverifiable and the work is `interim`. Final-chat-only rows do not satisfy the gate.
+
+## Row Accuracy — Not Just Durability
+
+The row must accurately describe what is in the changed content. Claiming "no concrete domain examples used" while the changed bullet still contains literal source-domain vocabulary fails the gate even if the row is durable.
+
+- Reread the changed lines before writing the row.
+- Verify each `rejected source domain=` claim against actual diff content.
+
+## Narrate The Rejected Domain Abstractly
+
+Write the row as:
+
+```
+rejected source domain=[the workspace's primary business domain literal vocabulary]
+```
+
+Do NOT write:
+
+```
+rejected source domain=[finance / commerce / education / etc literal vocabulary]
+```
+
+Naming the workspace's industry category in the row body propagates a soft domain hint into commit messages and other durable traces (observed recurring). The row records THAT a domain was rejected, not WHICH.
+
+## Relationship To Adversarial Review
+
+Pre-draft selection reduces the rework cycle; it does NOT replace the safety net.
+
+- Codex / adversarial review remains the safety net per the R0 rule.
+- Pre-selection is *input* to adversarial review, not a substitute for it.
+- Passing pre-selection does not authorize skipping the dual-track gate.

package/dist/assets/marketplace/plugins/ccl-skills/skills/skill-extraction-workflow/references/external-practice-controls.md

@@ -0,0 +1,57 @@
+# External Practice Controls
+
+This note records the public evidence boundary for three shared controls. It is a design comparison, not a claim that these skills implement PRISMA, NIST, in-toto, SLSA, or any vendor runtime specification.
+
+## Research coverage
+
+Primary and official sources:
+
+- [OpenAI Deep research guide](https://developers.openai.com/api/docs/guides/deep-research): research prompts should be sufficiently specified; source priorities should be explicit; scientific work should prefer original papers or official publications; citations and source metadata make results reviewable; private inputs and public-web retrieval are separate source surfaces.
+- [PRISMA 2020 checklist](https://www.prisma-statement.org/s/PRISMA_2020_checklist-ab3g.pdf): a systematic review reports its question, eligibility criteria, information sources, search strategy, selection method, data items, and risk-of-bias method.
+- [Cochrane Handbook, Chapter 4](https://www.cochrane.org/authors/handbooks-and-manuals/handbook/current/chapter-04): high-certainty reviews plan broad, documented searches across multiple source types; it also records the counterpoint that abbreviated searches can be acceptable when decision-makers explicitly accept lower certainty.
+- [UK government institutional-analysis guidance](https://www.gov.uk/government/publications/understanding-institutional-analysis/understanding-institutional-analysis): triangulation should use different sources and perspectives, not repeated claims derived from one powerful informant or document.
+- [CIA Tradecraft Primer](https://www.cia.gov/resources/csi/static/955180a45afe3f5013772c313b16face/Tradecraft-Primer-apr09.pdf): information-quality checks, competing hypotheses, and contrarian techniques make disconfirming evidence an explicit analysis surface.
+
+Disposition:
+
+- Supported: define the question and source classes before retrieval; do not let supplied material silently become the whole boundary; prefer primary/official evidence for load-bearing claims; triangulate independently; search for contradictory evidence; record unresolved cells and lower confidence/coverage claims.
+- repository control, not an external mandate: the four visible rows (`user leads`, `primary/official`, `independent external`, `counter/negative`) are this skill's minimum for a result labelled complete/deep. PRISMA and Cochrane do not prescribe those exact four rows for every research domain.
+- Boundary: PRISMA/Cochrane are systematic-review methods, so this skill borrows their question/source/search/closure discipline without claiming formal systematic-review compliance. Simple facts and explicitly scoped rapid/partial research stay outside the complete/deep label; a nonexistent user-lead class is closed as `not-applicable`, not fabricated.
+
+## Leaf delegation
+
+Primary and official sources:
+
+- [NIST SP 800-53 Rev. 5, AC-6](https://doi.org/10.6028/NIST.SP.800-53r5): users and processes receive only the authorized access needed for their assigned task; privileged-function use is logged.
+- [OWASP Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html): enforce least privilege, deny by default, and prefer explicit configuration over framework defaults that can change.
+- [OpenAI Agents SDK tool controls](https://openai.github.io/openai-agents-python/tools/#conditional-tool-enabling): `is_enabled` can hide a disabled tool from the model at runtime.
+- [Anthropic subagent documentation](https://docs.anthropic.com/en/docs/claude-code/sub-agents): tool allow/deny lists restrict a worker's effective capabilities. The same page is important counterevidence to stale assumptions: current versions allow nested subagents, with a fixed host depth limit, whereas older versions did not.
+
+Disposition:
+
+- Supported: enforce a leaf role by removing the delegation capability when the host permits it, verify the effective tool set, log/observe privileged attempts, and fail safely when neither denial nor observation is available.
+- repository control, not a vendor requirement: `can_delegate=false`, promotion to orchestrator, and whole-return invalidation after a prohibited nested attempt are local containment rules. They deliberately remain stricter than a host's built-in nesting support.
+- Boundary: host behavior is versioned. Resolve the live host capability instead of writing a timeless claim that a named host can or cannot nest; a host depth limit does not replace the controller's role-specific admission decision.
+
+## Behavioral evidence and attestation
+
+Primary and official sources:
+
+- [in-toto Statement v1](https://github.com/in-toto/attestation/blob/main/spec/v1/statement.md): an attestation statement binds a predicate to immutable subjects identified by digest.
+- [SLSA v1.2 provenance](https://slsa.dev/spec/v1.2/provenance): provenance describes where, when, and how an artifact was produced so a verifier can trace it through a supply chain.
+- [Open Policy Agent policy testing](https://www.openpolicyagent.org/docs/policy-testing): policy tests exercise decisions, while coverage reports identify rules whose bodies were never true or expressions never evaluated.
+
+Disposition:
+
+- Supported: a rule's existence is not proof it executed; use behavioral assertions and coverage/firing evidence. The digest-binding practices these sources describe (complete subject sets, provenance, raw-result digests) are sound for supply-chain trust boundaries where authors and verifiers are distinct parties; the local policy below explains why this repository adopts the firing/coverage principle but not the digest binding.
+- Local evidence policy: the impact-chain gate machine-verifies what is cheap and deterministic — an owner-scoped firing path that resolves to its round's added lines (a unique anchor on a changed normative numbered/list rule, or a changed owner executable), the letters/digits-free wording-only classification computed from that round's owner diff, and the owner-level floor that a non-wording package carries at least one `RED-baseline` row (a `semantic-control` label may supplement but never close a package alone, because an author-selected stable label cannot vouch for a different hidden delta). The `behavioral-evidence` and `observed-failure` fields themselves are required author declarations. A digest-bound attestation apparatus for these rows (in-toto-style subject digests, same-prompt model result pairs, command-result envelopes) was built, evaluated against real iteration, and deliberately removed: under the unsigned-repository-local trust model the author can regenerate every hash, so the apparatus only detected stale records — while costing a full-suite rerun and whole-evidence regeneration whenever any owner script changed by a single byte. That cost defeated normal multi-commit iteration (it broke its own author's branch twice), so behavior claims rest on the firing-path gate, honest authorship, and the mandatory independent review/challenge instead of hashes.
+- Local trust model: register rows remain honest-but-fallible workflow evidence, not a hostile-author security boundary. The gate proves that a changed, normative, owner-scoped rule line (or changed owner executable) exists for every claimed firing path; it does not prove a model run occurred, that a named executable implements the claimed enforcement (a shebang stub passes the static check), that a mangled or ambiguous ledger row was honest (those are warned, not blocked, to avoid false positives on other table shapes), author identity, or non-tampering by an authorized contributor. Independent review/challenge and the fixed checker remain the assurance case.
+- Machine format (relocated from the `SKILL.md` firing-mechanism rule; the local evidence policy above carries the rationale): every added source-register row must carry `behavioral-evidence: RED-baseline` (any observed delta — `observed-failure: yes` requires it) or `semantic-control` (only with `observed-failure: no`), an `observed-failure: yes/no` state, and an owner-scoped `firing-path` — each declaration in its own semicolon-delimited fragment of the cell (`…prose; behavioral-evidence: …; observed-failure: …; firing-path: …`), so a key embedded mid-prose never parses as a declaration. The firing-path anchor is at least 16 characters, occurs once in the file and once in its round's added lines, and lands on a numbered/list Markdown rule with a normative action.
+
+- **Round scoping — a row is judged against the round it landed in, never the accumulating range.** A row is authored against one round's diff, so reading the whole `base..HEAD` range to classify it judges the row against work it never described. That mismatch produced both directions of the same defect: an already-gated row turned red once a LATER round touched the same owner (which is what the ledger's superseded-row notes were absorbing), and a description-only round lost its routing-surface locator because an EARLIER round had edited that owner's body. The gate cuts rounds at the commits that touch the ledger, walked first-parent so one merged worktree round is one boundary, and each round spans from the previous boundary so work commits sit in the round whose ledger append describes them. The partition is derived from git alone — an author cannot nominate, widen, or move their own scope.
+  - Both obligations move together, in opposite directions. **Classification** narrows to the round: whether a diff is wording-only, an identifier retarget, or description-only is asked of that round's bytes, which is what makes a verdict stable once it lands. **Presence** narrows to the round too: the round that changed an owner is the round that owes the row, so owner work committed after a ledger append can no longer ride on an earlier round's row. Narrowing classification without narrowing presence would have opened exactly that laundering route.
+  - **Known exception, inherited not introduced: a renamed-away owner escapes round presence.** The round's subject set is intersected with the cumulative one, and the cumulative pass drops an owner whose package was renamed away (a row citing it would be refused for naming a SKILL.md that no longer exists). So an owner changed substantively in an earlier round, with an intervening ledger boundary that closed that round without its row, and renamed away in a later round, is demanded by neither round. Differential check on the same fixture: the pre-round-scoping gate passes it too, so this is not a regression of the narrowing — but the per-round presence contract above does not hold in this shape, and saying so is the point of this bullet. Closing it needs the evidence-file existence check to resolve at the row's round head instead of the worktree, which is its own change.
+  - The owner-level `RED-baseline` floor deliberately stays **cumulative**: it asks whether anything in the owner's whole change is left unvouched-for, and per-round would let a package self-clear on the one round that happened to be punctuation-only. Cumulative is the stricter of the two readings, so the round scoping cannot loosen it.
+- Machine-verified no-behavior classes (each drops the firing-path requirement, each requires `observed-failure: no`, and neither is an author waiver — the gate recomputes the predicate from the owner's diff for that row's round and refuses on any mismatch): `not-required wording-only` when no changed line differs by a letter or digit and every changed owner file is Markdown prose; `not-required identifier-rename` when rewriting the base bytes with git-derived rename pairs reproduces the head bytes exactly. Both exist because the anchor uses the SHAPE of a changed line as a proxy for "an obligation changed", and both are diff shapes that carry no obligation at all.
+- Canonical field locator for a routing-surface-only owner — NOT a third no-behavior class. When an owner's entire change is the `SKILL.md` frontmatter `description` entry (same body, same other top-level keys, the value still a YAML string, all checked byte-exact), its firing path is the constant `file:skills/<owner>/SKILL.md#description`. The row still declares `RED-baseline`, still owes its behavioural evidence — for a routing change that is the measured routing delta — and only the free-text anchor is replaced. It is deliberately not an exemption: a description edit decides which requests reach the skill, so exempting it would drop evidence from the class carrying the most behaviour. The locator is canonical rather than a substring because three successive substring designs were refuted — a numbered/list rule shape, then the `description:` line, then any line of the entry — the last because a substring that merely SURVIVES the edit identifies nothing. Same class three times is the signal to drop the proxy, not to patch it again; the predicate is what carries the proof, and the locator only names the field it proved. The predicate matters more here than in the two classes above because a wrong judgement is LOOSER rather than stricter, so it accounts for every changed byte and refuses whatever it cannot account for. A further shape that cannot be located is a signal to replace the proxy, not to widen again. The precondition judges BEHAVIOUR, not file count: the rest of the package — and the entrypoint's own body and other frontmatter keys — may differ by a rename retarget, because that is already a machine-proven no-behaviour class, and the two compose under one normalizer (apply git's rename pairs to the base bytes, then require the head bytes exactly, mode included). Without the composition an owner on an integration branch that accumulates rounds gets refused for retargets it already declared no-behaviour, while having no other rule to anchor on. The description entry is the one part exempt from the normalizer, because it is the change being evidenced; anything the normalizer cannot account for — one real byte — takes the locator away. Siblings are further restricted to regular-file Markdown: a script's bytes reproducing under a substitution says nothing about whether rewriting that identifier was safe there, and a `.md` SYMLINK's blob is its target, so a retargeted target reproduces while what the path resolves to changes. **Disclosed residual, unchanged from the rename class it composes with**: a Markdown sibling can still carry a fenced command or a persisted key whose old identifier is deliberately preserved — an installed artifact name that must not follow a source rename is the observed instance — and rewriting one of those IS a behaviour change the normalizer clears. The exposure is identical to the identifier-rename class, which already reproduces whole packages under the same pairs; this composition inherits that residual rather than widening it, and the pairs still come only from git's own tree state, so a slug is rewritten only when that skill was actually renamed in the same diff. Closing it means distinguishing prose mentions from executable/persisted ones inside Markdown, which needs its own evidence round. Two shapes are knowingly left refused, and refusal here costs nothing that was not already lost: before this locator existed no routing-surface owner could satisfy an anchor at all, so a refused shape simply keeps that prior behaviour rather than regressing from it. (1) A sibling frontmatter value whose YAML tag or class `safe_load` will not construct makes the parse fail, and a failed parse refuses rather than guesses. (2) The owner that ships `references/source-register.md` cannot use the class at all, because its own evidence row lands inside its package and so its diff is never the description alone — a consequence of not special-casing that file, which is what would otherwise let arbitrary ledger content ride along. Both are usability limits on a strictly additive path, not bypasses; closing either one means loosening a predicate whose wrong answers are LOOSER than the bar, so neither is worth doing without its own evidence.
+- Boundary: OPA coverage supports the general distinction between policy presence and policy execution; the repository does not run OPA. in-toto/SLSA supply-chain formats were consulted for the evaluated-and-removed digest apparatus; the shipped gate deliberately does not bind digests and does not reuse or claim their security levels.

package/dist/assets/marketplace/plugins/ccl-skills/skills/skill-extraction-workflow/references/extraction-lifecycle-handoff.md

@@ -0,0 +1,65 @@
+# Extraction Lifecycle Handoff
+
+The SKILL.md entrypoint states the principle: project-specific provenance never enters the shared skill tree. This file is the operational mechanism: what lives where in each lifecycle phase, what migrates between phases, what the shared-repo history (commits, branch refs, and the MR/PR record) is allowed to say, and how to handle existing dirty registers.
+
+Sibling skills routing to "Extraction lifecycle handoff" (e.g. `python-service-architecture / dev`, `go-microservice-architecture / dev` source-evidence-map files) route to this rule as a whole.
+
+## The Three Phases
+
+| Phase | Lives in | Contents |
+|---|---|---|
+| **Work in progress** | per-host scratch `~/.<host>/skills/.extraction-work/` | charters tied to one Figma project / one codebase / one document set, source registers populated with that project's file keys and paths, batch findings, extraction reports, review packets, codex replies |
+| **Closed batch — provenance archive** | per-host private alias `~/.<host>/.private-aliases/<project>.yaml` | file keys, project URLs, real subproject paths, real branches, dated re-extraction logs, known-debt list, sanitized-label dictionary |
+| **Shared skill tree** | the ccl-skills repo | label-based capability rules only |
+
+Working artifacts are NEVER committed to the shared skill tree. The shared tree only sees the rules abstracted from the work, not the work itself.
+
+## Migration — Scratch → Private Alias
+
+Once an extraction batch closes, its provenance migrates from the scratch folder into the private alias file:
+
+- File keys, project URLs, real subproject paths, real branches, dated re-extraction logs, known-debt list all move into `~/.<host>/.private-aliases/<project>.yaml`.
+- The matching shared-skill content keeps only label-based capability rules — no concrete artifact names, paths, or dates.
+- The scratch folder can be deleted or kept for the maintainer's own reference; either way, the shared skill tree must not know it existed.
+
+## Shared VCS-Surface Discipline (commit, branch, MR record)
+
+Every shared surface the integration flow creates names only:
+
+- The sanitized capability labels touched
+- The target skill / reference path
+- The private alias archive that holds the provenance (by alias label, not by real project name)
+
+This applies to the commit message(s), the **feature branch name**, the eventual **merge/squash message**, and the **entire MR/PR record** (title, body, comments/discussion, labels/metadata) — not the commit body alone. Never name real source artifacts (real repo names, real Figma project names, real document titles, real branch/ticket names, real contributor names) in any of them. Git history, branch refs, and the MR record are all the shared skill tree's history — a sanitized commit under a source-shaped branch name or MR title still leaks, and leaks here are as severe as leaks in skill text. When unsure whether a surface is shared, treat it as shared and sanitize.
+
+## R0 Audit Scope
+
+The R0 leakage audit (see `references/r0-leakage-audit.md`) runs against the shared-skill content, NOT against the working artifacts in scratch. Scratch is the maintainer's private workspace; R0 has no jurisdiction there. R0's jurisdiction begins at the commit boundary into the shared repo.
+
+## Generic Methodology Carve-Out
+
+A generic, reusable register / template / methodology reference (one that documents the *shape* of charters, registers, evidence maps, or judgment matrices without naming any specific project's keys / paths) MAY live in the shared skill tree.
+
+**Example**: a `references/source-register.md` that is a template / sample is allowed; it may also carry a source-neutral ledger zone, as long as it describes reusable columns, methodology, and shared impact-chain history without containing any project's actual rows.
+
+The distinction is **shape vs content**: shape-documenting refs are shared, content-bearing artifacts are private.
+
+## Grandfather Rule — Existing Dirty Registers
+
+Any existing in-skill register that already contains real project provenance (concrete file keys, dated re-extraction logs, real repo names) is grandfathered as `known_debt`. It can stay in place temporarily but:
+
+- It MUST be migrated to a private alias file before new project-specific provenance is added to it.
+- Adding fresh project provenance to a grandfathered register is treated as a new R0 hit, not protected by the grandfather status.
+- The grandfather status is for cleanup planning, not for indefinite tolerance.
+
+## Authoring From a Plugin / Read-Only Install
+
+When the workflow is consumed as a plugin (or any read-only install mechanism), skills load from a consumption cache, not from an editable checkout. To land an extraction you must author in the canonical source repo — and that repo is discoverable from the install itself, so do not guess a path or edit the wrong copy:
+
+- **Discover the source URL from the install.** The plugin/marketplace registration that shipped with the install records it: the marketplace clone's git remote (`git -C <marketplace-clone> remote get-url origin`), the marketplace `source.url` in the host's plugin config/registry, and the install URLs documented in the consuming project's README each help identify the canonical repo. Cross-check them rather than trusting one — a README can be stale or absent, and an install/marketplace URL can differ from the canonical source repo (e.g. http vs ssh, or a mirror).
+- **Author in one standing checkout — clone once, reuse.** Clone that URL a single time (or reuse an existing checkout) and reuse it for every later extraction. Do not clone per change.
+- **Never edit the consumption copies.** The plugin cache and the marketplace-managed clone are overwritten on update; edits there are lost and never reach the repo. Author only in your own checkout, then land through the normal review/MR gates.
+- **Isolate each change with a worktree, not a clone.** Make every extraction in a dedicated worktree off the standing checkout — worktrees share the object store and are not full repo copies — and remove it once the change lands (`git worktree remove`). This meets the concurrent-session isolation rule without proliferating repo copies.
+- **Accumulation is consumption-side, not authoring.** Plugin caches on some hosts keep one directory per installed version, so old version dirs can linger after updates — unrelated to authoring. Prune them with the host's plugin prune command if disk matters.
+
+After landing, the change reaches every install through the normal update path (marketplace refresh + plugin update); the exact update command lives in the consuming project's README, not in the shared skill tree.

package/dist/assets/marketplace/plugins/ccl-skills/skills/skill-extraction-workflow/references/extraction-quickstart.md

@@ -0,0 +1,194 @@
+# Extraction Quickstart — One-Page Flow
+
+For maintainers running a fresh codebase / Figma / doc extraction. Read this first; deep references handle each step's detail.
+
+## Flow at a glance
+
+```
+0. Charter        → ~/.<host>/skills/.extraction-work/<project>-charter.md
+                    Purpose / Scope / Depth / RCA baseline / Open questions
+                          │
+1. Source register → ~/.<host>/skills/.extraction-work/<project>-source-register.md
+                    Each row: source id / class / status / target skill / extracted mechanisms
+                          │
+2. Batch plan      → B1..Bn in charter §Batch plan; one batch per problem domain, not time slice
+                          │
+3. Per-batch loop:
+   ├─ a. Read sources to documented min depth
+   ├─ b. Draft skill / reference (new or update existing)
+   ├─ c. Sibling-generalization mini-map (which sibling skills may share / route)
+   ├─ d. Sanitization pass with checklist (cheap, seconds)
+   ├─ e. Dual-track gate per mandatory table (deep, minutes)
+   │     ├─ Review pass (codex review --base) — fact / consistency / sanitization
+   │     └─ Challenge pass (codex exec adversarial) — race / data loss / security / algorithm
+   ├─ f. Apply fixes, re-sanitize
+   ├─ g. Commit per batch on a feature branch → MR pending review (never push to main)
+   └─ h. Update charter completion log
+                          │
+4. Closeout       → ~/.<host>/skills/.extraction-work/<project>-completion.md
+                    Final state + deferred backlog + lessons for future extractions
+                          │
+5. Provenance migration → ~/.<host>/.private-aliases/<project>.yaml
+                    Move file keys / paths / counts / dates out of working files
+                          │
+6. (If lesson applies broadly) → patch skill-extraction-workflow itself
+                    New anti-pattern → recurring-anti-patterns-checklist.md
+                    New review angle → dual-track-review-gate.md
+                    New workflow step → SKILL.md core rules
+```
+
+## Per-step quick reference
+
+### 0. Charter (always)
+
+- Owner: maintainer
+- Location: `~/.<host>/skills/.extraction-work/<project>-charter.md`
+- Required fields: Purpose, Scope, Depth, Root cause (Deep RCA: widen → counterfactual-test → control), Failure modes, Lifecycle impact, Evidence plan, Completion standard.
+- Full structure: `SKILL.md` Core Workflow Step 0.
+- Output: a file the maintainer can re-read in 3 months and understand what they were trying to do.
+
+### 1. Source register
+
+- Owner: maintainer
+- Each row: `source_id / class (A1/A2/B/C/D) / path / status (pending|read|deep-read|excluded|unavailable|routed) / min_depth / actual_depth / extracted_mechanisms / discarded_business_details / target_skill / evidence_link`.
+- Full structure: `references/source-register.md` template; the shared file also contains source-neutral ledger rows, not project provenance.
+- Discipline: every dimension has a status before any "complete" claim.
+
+### 2. Batch plan
+
+- Decompose by problem domain (observability / connectivity / release), not time slice.
+- Each batch closes its own row in source register before the next batch starts.
+- Charter section §Batch plan tracks status.
+
+### 3. Per-batch loop
+
+#### 3a. Read sources
+
+- Respect min-depth from source register row.
+- For source-read failures (timeout, branch missing, doc unavailable): apply remediation (smaller read, different branch, screenshot fallback) BEFORE marking unavailable.
+- Reference: `SKILL.md` "Source-read remediation standard".
+
+#### 3b. Draft skill / reference
+
+- New shared skill → frontmatter with trigger-focused description.
+- Update existing → minimal surgical edit; preserve existing content unless contradicted by new evidence.
+- Reference files: `<verb>-<noun>.md` naming; entrypoint = `SKILL.md`.
+
+#### 3c. Sibling mini-map (required for stack-specific extraction)
+
+- Map: source stack → sibling stacks → shared workflow owner → per-sibling decision.
+- For each sibling skill: `update / unchanged / route-to-shared` with reason.
+- Don't skip even when "obvious"; documenting `unchanged` is part of the gate.
+
+#### 3d. Sanitization (cheap)
+
+- Run `references/recurring-anti-patterns-checklist.md` grep panel against changed files.
+- The current checklist patterns (count grows over time as new anti-patterns are added); ~30 seconds total runtime for the full panel.
+- Hits → fix in this commit, OR record `known_debt` in private alias map (pre-existing only).
+
+#### 3e. Dual-track review/challenge
+
+- When required: see `references/dual-track-review-gate.md` table.
+- Choose the review tier from that table, not from intuition. Do not restate the rows locally; record the exact `dual-track-review-gate.md` table row used. Record `challenge: not-required` only when that row classifies the actual diff as challenge-not-required (for shared skills, this means strict wording-only with deterministic scope proof + independent review confirmation). Non-wording shared-skill changes cannot skip challenge.
+- Run deterministic checks and implementer self-review first, and record what each proves before invoking review/challenge (this self-review-before-review ordering applies to every non-wording shared-skill change the dual-track table requires review for, not only the rows that look high-risk): `git diff --check` proves whitespace/conflict-marker hygiene only; validators prove schema/link/routing invariants; leakage/sanitization scans prove only their configured patterns; scope checks must name the changed files or expected file set; the self-review row is conclusive only when each required field is non-empty (acceptance criteria, changed-file scope, edge/failure paths, known residual risks) and the changed-file scope equals the candidate diff's changed-file set, or explicitly explains any excluded generated/irrelevant file. The row must be persisted in inspectable/revision-tracked history before the review/challenge run (same ordering-proof rule as `product-rd-workflow`'s technical-design gate: a plain in-place-editable MR description or scratch log is not acceptable proof unless its edit history is retrievable and was checked); a row backfilled after review/challenge is invalid and forces a rerun. If the candidate diff changes after the row is saved — a file added/removed OR the content of any listed file materially changed — refresh the row and rerun review/challenge against the new candidate. A missing field, "ok" placeholder, mismatched scope, or unprovable ordering makes the row inconclusive. Do not spend LLM review rounds on issues a script or implementer-side checklist can decide. If the independent pass is the first place basic scope, contract, privacy, or test issues surface, apply those findings to the diff, close the self-review gap, and rerun the deterministic gates before rerunning review/challenge; the process-defect repair is in addition to resolving the findings, not a way to discard or downgrade them.
+- Review pass: resolve a pinned/trusted `CODE_REVIEW_SKILL_DIR/scripts/review_gate.sh`; never scan writable plugin roots. Persist the complete self-review row and encode it in the review plan you pass to the gate. Take the command itself from `code-review`'s runnable recipe, never from a copy kept here. When the dual-track row requires a challenge, that run is multi-round: use the recipe's review→challenge pair — supplying the stage and the exact base ref this candidate is actually at, not whatever the example defaults to — the one shape that opens the Agent chain on round 1 — it cannot be retrofitted, so a run started outside it is thrown away and restarted. A row that legitimately records `challenge: not-required` takes whichever single-round shape the staged review contract permits for this candidate's stage and risk tags; the gate, not this page, decides whether a chainless review is legal, and it may still demand the tracked pair. Read the chain-opening and packet-composition rules in `references/dual-track-review-gate.md` (Running the review pass) first: they decide the round budget and what goes in the packet before the command is built. Require conclusive JSON, selected-client attribution, packet/profile binding, family exclusion, and wrapper runtime evidence. When the host returns a live execution handle (`session_id`, `cell_id`, or equivalent), keep polling that exact handle until terminal exit; empty current output is progress, not a verdict, and no replacement/fallback reviewer may start while the original process is live. The result row records handle type, an opaque host transcript/tool-call reference, and terminal exit status. If the handle is lost, the lane is infrastructure-inconclusive/manual-review-required and no replacement or fallback may be started or credited; process-tree and wrapper artifacts are diagnostic only. This is a procedural host obligation because the inner gate cannot observe the outer handle; machine enforcement requires a trusted host adapter. Never copy a credential-like raw handle into shared evidence. `findings` is not pass; inconclusive/malformed/free-form output stays interim. Do not add a separate behavior probe.
+- Challenge pass: invoke that gate separately with the same plan, stage, candidate, and family. Pass a one-based index within the staged-contract budget; later rounds include a distinct focus and all prior focuses. A tracked round additionally carries the chain fields defined in `code-review/references/staged-review-contract.md` (Agent review chain); follow that section for what each round must supply. Preserve a separate result row with the same binding, exclusion, egress, attribution, and conclusive checks. Review never satisfies challenge; missing/inconclusive required challenge keeps extraction interim.
+- Treat review/challenge as batch-level gates over the landing candidate, not as a per-bullet or per-line edit loop. Apply all findings from a round; when both lenses are required, re-run both on the updated candidate before landing.
+- Skipping a required challenge = work can only land as interim, not complete.
+
+#### 3f. Apply fixes, re-sanitize
+
+- Each P0/P1 finding: applied fix OR deferred row with reason.
+- After fixes: re-run sanitization (fixes can introduce new leakage).
+- Re-run `check-ccl-skills.sh` for static validation.
+
+#### 3g. Commit per batch
+
+- Branch: never `main` — work in a dedicated worktree + feature branch and integrate via MR (worktree-isolation / MR-not-main discipline). `main` is the integration point, not the dev surface.
+- Commit shape in a multi-batch same-branch program: every findings fix is a NEW commit; never reach for `git commit --amend` — with several batches' commits stacked on one branch, `--amend` silently retargets whatever commit HEAD happens to be, and "fold the fix into the previous batch" is exactly the instinct that hits the wrong one (one program amended the wrong commit three times before noticing). That NEW-commit shape is not negotiable for a findings fix, and **a findings fix is defined by provenance, not by edit shape**: any edit requested by — or made to disposition — a review/challenge finding is a findings fix, including one whose shape is evidence completion or mirror synchronization, and including the sync fix in `validation-and-landing.md` step 5 when a finding is what surfaced the drift. Provenance is the test because edit shape is self-classified, and "it's just a sync" is the label the wrong amend arrives wearing. So inside such a program `--amend` stays available only for a correction you discovered independently of any finding, on a commit still unpushed AND the one just created, confirmed with `git log -1` immediately before amending. That NEW-commit consequence is scoped to this program shape and nothing wider: outside a multi-batch same-branch program a finding-derived fix may amend on those same unpushed-and-just-created terms, and only the provenance record still applies — `validation-and-landing.md` step 5 states the identical boundary. A findings fix that happens to land right after its own commit is still a findings fix and still takes a NEW commit; "it's unpushed and it's HEAD" is a necessary condition for amending, never a licence to fold a finding in.
+- Sanitize **every shared surface the MR flow creates**, not just the commit body — when unsure whether a surface is shared, treat it as shared and sanitize. This covers the feature branch name, the commit message(s), the eventual merge/squash message, and the **entire MR record** (title, body, comments/discussion, labels/metadata). Each names only sanitized capability labels, the target skill/reference, and the private archive by alias — NEVER real source artifacts, project/repo names, real branch/ticket names, or other provenance. Git history, branch refs, and the MR record are all shared tree (see the Extraction lifecycle handoff rule); a sanitized commit with a source-shaped branch name or MR title still leaks.
+- Push the branch and open/update the MR, then stop: leave it pending review — do not merge, and do not enable auto-merge / merge-when-pipeline-succeeds. Merge only on the user's explicit merge instruction for that MR.
+
+#### 3h. Update charter completion log
+
+- Append batch result: read sources, mechanisms extracted, sibling mini-map decisions, review/challenge counts, fixes applied/deferred.
+
+### 4. Closeout
+
+- File: `~/.<host>/skills/.extraction-work/<project>-completion.md`
+- Final state: which batches done, which deferred, which sources unavailable.
+- Lessons: what surprised; what would change in next extraction; what to add to skill-extraction-workflow.
+
+### 5. Provenance migration
+
+- Move from working artifacts → `~/.<host>/.private-aliases/<project>.yaml`:
+  - Real file keys / URLs / paths / branches
+  - Counts / dates / branch state
+  - Contributor habits and team notes
+  - Known-debt list
+- For task/session/process retrospectives with no single product corpus, use the generic private profile `~/.<host>/.private-aliases/process-retro.yaml` for the R0 audit; do not replace it with an inline grep. If the retro also cites a concrete product artifact, run both the project alias and `process-retro`.
+- The shared skill tree keeps only label-based capability rules.
+- Working artifacts may stay as the maintainer's local notes; they are never pushed.
+
+### 6. Patch the workflow itself
+
+If the extraction surfaced:
+- **A new anti-pattern in ≥ 2 skills** → add to `references/recurring-anti-patterns-checklist.md`.
+- **A new review/challenge angle** → add to `references/dual-track-review-gate.md` (e.g. a new category in the challenge prompt template).
+- **A new workflow step** → add to `SKILL.md` Core Rules or Core Workflow.
+- **A new validation gate** → add to Step 6 validation list.
+
+Skip this step when nothing transferable surfaced.
+
+## Tool inventory
+
+| Tool | Where | When |
+|---|---|---|
+| Anti-pattern grep panel | `references/recurring-anti-patterns-checklist.md` | Every commit; ~30s |
+| `check-ccl-skills.sh` | `scripts/check-ccl-skills.sh` | Every commit; ~10s |
+| `codex review --base <sha>` | shell, in shared skill repo | When the mandatory dual-track table requires independent review (every shared-skill change); ~5-10 min |
+| `codex exec` adversarial prompt | shell, in shared skill repo | When the mandatory dual-track table requires challenge (every non-wording shared-skill change); ~10-15 min |
+| Source-read fallback ladder | `SKILL.md` Source-read remediation | When a source read fails or times out |
+| Sibling mini-map | `SKILL.md` Step 4 stack-specific updates | Every stack-specific change |
+| Private alias map `audit_cmd` | `~/.<host>/.private-aliases/<project>.yaml` or process-retro profile | Every commit's R0 audit |
+
+## Typical timings
+
+For a medium extraction project (~5 source domains, ~10 skills touched, ~50 references created or modified):
+
+| Step | Time |
+|---|---|
+| Charter | 1-2 hours |
+| Source register populate | 2-4 hours |
+| Per batch (read + draft + sibling + sanitize) | 3-6 hours × N batches |
+| Dual-track review per batch (review + challenge + fixes) | 1-3 hours × N batches |
+| Closeout + provenance migration | 1-2 hours |
+| Workflow self-patch (only if applicable) | 1-2 hours |
+
+For a representative real-project extraction (the worked example for this skill): ~7 batches over multiple sessions; ~4 reviews + 4 challenges; ~50 issues found across all batches; ~3 workflow self-patches landed (dual-track gate, recurring anti-patterns checklist, this quickstart).
+
+## Worked example
+
+See `~/.<host>/skills/.extraction-work/<project>-extraction-summary.md` (the maintainer's local notes) for a full real-project extraction run — every batch, every codex pass count, every deferred item — as a reference shape.
+
+## When to NOT use this workflow
+
+- Wording-only typo / grammar / formatting fix in one file (no change to trigger / routing / scope / validation / acceptance / meaning) → no charter; still record the independent review row. Anything beyond true wording-only is non-wording and takes the full dual-track + behavioral-evidence row — `description` / frontmatter edits never qualify as wording-only (routing surface).
+- Reverting a commit → use git; charter not required.
+- Updating only the maintainer's working notes → no shared skill change → no R0 audit, no review.
+
+If in doubt, the charter step is cheap (20-30 min); doing it for borderline work is fine.
+
+## Failure modes to avoid
+
+- Skipping charter → "wait, what was I trying to extract here?" 2 weeks later.
+- Skipping source register → re-extraction can't reproduce coverage; "complete" claims can't be verified.
+- Skipping sibling mini-map → cross-language rules drift between language pairs.
+- Skipping sanitization checklist → real ccl-specific names ship into shared skill tree.
+- Skipping challenge pass → P0/P1 production-safety issues survive into shared skills (worst class).
+- Stuffing provenance into shared skills → leaks; later re-extraction has to delete + rewrite.
+- Patching workflow without a real ≥ 2-skill pattern → workflow bloat.
+
+## One-line summary
+
+**Charter → register → batch (read, draft, sibling, sanitize, dual-track, fix, commit) → closeout → migrate provenance → patch workflow if applicable.**