@ccoalm/ccl-skills 0.1.0

package/dist/assets/marketplace/plugins/ccl-skills/skills/product-rd-workflow/references/quality-remediation-program.md

@@ -0,0 +1,88 @@
+# Quality Remediation Program
+
+Structure for a cross-cutting, multi-phase engineering-quality initiative — a "quality special project" / planned technical-debt paydown across architecture, implementation, and code structure.
+
+This is a distinct work type from its neighbors, which is why it has its own reference:
+- An **existing-project assessment** (`existing-project-assessment-report.md`) ends at diagnosis plus next actions; it does not own a multi-week program with metric baselines and exit gates.
+- A **single behavior-preserving refactor** (`refactoring-discipline.md`) owns one change; it does not own program sequencing, baselines, or stop-the-bleeding institutional changes.
+
+This reference owns the **program shape and per-phase exit gates**, and routes each phase's execution to the smallest owning skill.
+
+## When to use
+
+The request is a cross-cutting, multi-phase quality initiative ("做一次质量专项", "治理工程质量", "整体架构/实现/质量偏差怎么规划", "pay down tech debt as a program") rather than one feature, one bug, or one isolated refactor. Also use it when a team wants to **establish and hold an engineering-quality baseline on an existing project** — raising and protecting quality as ongoing practice, not as a one-off cleanup.
+
+## Two operating modes
+
+The same phase logic runs at two altitudes; pick the lighter one that fits the request, and record which mode and why. When debt already makes normal iteration unsafe or slow, or the hotspots being touched have no safety net, default to campaign rather than continuous (or record why continuous is still sufficient) — do not pick the lighter mode just to avoid closeout pressure:
+
+- **Remediation campaign** (heavyweight, time-boxed): a deliberate quality special project / tech-debt paydown that runs all phases to a defined acceptance, then ends. Use when debt has accumulated enough that normal iteration is unsafe or slow.
+- **Continuous baseline-and-hold** (lightweight, standing): for an existing project that is simply raising and protecting quality while it keeps shipping features. Run Phase 0 once to capture starting numbers, stand up the Phase 1 new-code gates permanently, and add Phase 2 safety-net coverage incrementally — mandatory before any refactor or behavior-risking change to a hotspot, never deferred under delivery pressure — with no time-boxed campaign required.
+
+**Minimum standing floor — every existing project should have this, campaign or not:** Phase 0 baseline numbers recorded, plus Phase 1's changed-line-scoped new-code gates live (gate intent and thresholds are owned by Phase 1 and `testing-strategy`, not redefined here), enforced with Phase 1's anti-gaming controls — suppressions and analyzer-config weakening need owner approval, generated/vendored code is excluded, test deletions are reviewed, and coverage is mapped to the changed behavior/risk surface, not just touched lines. This floor stops the bleed and makes quality measurable; Phases 2–4 layer on as need and capacity allow. A project with neither a recorded baseline nor new-code gates has no quality baseline, regardless of how much one-off cleanup has happened. The floor covers *ordinary* quality debt only: when a change touches a high-risk surface (security / permission / privacy / money / data-isolation / high-impact-AI), that surface's baseline is not "held" until it also has `feature-risk-router` classification, a known-bad inventory, and the selected high-risk gates from `high-risk-resilience-gates.md` — gates-plus-baseline alone is never sufficient there.
+
+The failure modes, exit gates, stop conditions, and ownership boundaries below apply to both modes. The only difference is program closeout: a campaign drives each phase to its exit gate and then *ends*, so `complete` (every exit gate has evidence) is the goal; continuous mode has no closeout and runs Phase 1 — plus the parts of Phase 2 it has reached — indefinitely. "No closeout" does not weaken evidence discipline: every phase that has been reached, and every hotspot touch, still needs its relevant exit-gate evidence (Phase 0 baseline numbers backed by command output, Phase 2 RED/GREEN on the touched flow). The phase-order invariants do not relax in either mode: the Phase 2 safety net for a given hotspot is still mandatory before any Phase 3 refactor of it.
+
+## Core principle: phase order prevents three failure modes
+
+Quality programs fail in three predictable ways; the phase order exists to block each:
+
+- **No baseline → no acceptance.** Without quantified before-numbers the program becomes an unbounded refactor with no definition of done. → Phase 0.
+- **Refactor before stopping the bleed → debt re-accumulates.** If the conventions and CI that let debt grow stay unchanged, cleaned-up code rots again. → Phase 1 before Phase 3.
+- **Refactor before a safety net → regressions.** Large legacy hotspot files usually have no tests; refactoring them blind ships bugs. → Phase 2 before Phase 3.
+
+If time pressure tempts skipping Phase 0 (baseline) or Phase 2 (safety net), treat that as a process defect, not a shortcut.
+
+## Phases (each has an exit gate)
+
+### Phase 0 — Baseline & charter
+- Quantify current state with repeatable commands: hotspot / largest-file inventory, static-analyzer warning count, test coverage, CI presence and status, and production defect/crash rate where available (if unavailable, mark stability targets provisional and name a substitute signal). Exclude generated / vendored / non-owned code from hotspot and size metrics.
+- Classify high-risk surfaces now (security / permission / privacy / money / data-isolation / high-impact-AI) with `feature-risk-router`, so no later phase touches them ungated.
+- Pick the program driver (stability / iteration speed / maintainability / test foundation, or a custom driver such as security / compliance / cost / DX with matching metrics). The driver decides Phase 3 ordering.
+- Define quantified acceptance targets per driver as before → target pairs.
+- Follow the host workflow's branch/worktree and clean-tree preflight before broad edits.
+- **Exit gate:** a baseline report exists with a real starting number per target, backed by command + output + commit evidence (not mere file existence). Missing baseline → the program is `interim`, not started; scoped emergency stabilization is allowed only with the missing baseline documented and a follow-up baseline task filed.
+
+### Phase 1 — Stop the bleeding
+- Add CI gates that block *new* debt, scoped to changed lines/files: no net-new analyzer warnings, changed-line coverage non-decreasing, and a size/line cap on new files as a review trigger (not a hard block that fragments cohesion). Dry-run gates against unchanged mainline first and promote to blocking only after they pass clean; track any suppression as debt needing owner approval. Route gate thresholds and CI placement to `testing-strategy`; this phase names gate *intent*. Global-percentage coverage gates are gameable and can punish deletion/refactor — do not use them as the bar.
+- If evidence shows a repo/team convention is blocking scoped, test-protected structural improvement (for example a contributor guide that forbids all structural change), revise it *with the convention owner's approval* — unapproved convention edits are advisory drafts only. Flip the default from "no structural change" to "structural change allowed when it is test-protected, small-step, and inside a scoped program task"; keep the prohibition on *unscoped* churn and pure-style noise so the original over-correction is not merely reversed.
+- Add a PR/review gate scoped to the program.
+- **Exit gate:** new code can no longer pile onto hotspot files unprotected; the revised convention is owner-approved and merged.
+
+### Phase 2 — Safety net
+- Before locking any behavior, inventory known-bad behavior on high-risk surfaces (security / permission / privacy / money / data-isolation / high-impact-AI) that must NOT be preserved; fix those (route via `feature-risk-router` / `high-risk-resilience-gates.md`) instead of characterizing them. Characterization tests freeze whatever exists today, bugs included — freezing a security or compliance defect is a failure, not coverage. On a high-risk surface, a "no known-bad behavior" conclusion needs the domain/security owner's signoff plus evidence of a defect / vuln / incident search, not a bare assertion.
+- For the rest, add characterization tests (golden / snapshot / widget / contract, as fits the stack) that lock current observable behavior; route layer and fixture selection to `testing-strategy`. Where a target's refactor will touch shared contracts or transitive consumers, add dependency-impact mapping and contract/integration coverage for those seams, not only the hotspot file.
+- Classify each target as **test-lockable** or `needs-seam` before relying on it as netted: some logic (library-private, or entangled with native / platform / UI machinery) cannot be locked without first changing production code to expose it, so "add characterization tests" is not always a drop-in. A `needs-seam` target is blocked, not covered — it gets an owner and a resolution path, is barred from Phase 3 until netted, and must not be papered over with low-value tests that raise the count without locking risk. The minimal enabling seam-cut needed to create the locking test may happen before Phase 3, landing together with that test (otherwise netting deadlocks); the target's full structural refactor stays barred until netted. Route seam design and locking-test-layer choice to `refactoring-discipline.md` and `testing-strategy`.
+- **Exit gate:** the targeted flows verify RED/GREEN, the known-bad inventory is recorded so no defect is silently frozen, and any `needs-seam` target is excluded from the ready-for-Phase-3 set and reported as an explicit not-done row in the Phase 4 acceptance report.
+
+### Phase 3 — Controlled refactor
+- Order targets by risk-adjusted ROI — change-frequency × defect-density × business-risk × testability — and defer targets too unsafe to start until confidence and coverage are higher. Do not auto-pick the most-churned critical file first if the team lacks domain confidence in it.
+- Each refactor is behavior-preserving, test-protected, and committed in small steps, each with a rollback path; gate runtime-impacting changes with staged rollout / feature flags per `high-risk-resilience-gates.md`. Route single-change discipline to `refactoring-discipline.md` and stack execution to the owning development skill.
+- **Exit gate:** targeted hotspots meet their size/structure targets with all safety-net tests green and no behavior regression.
+
+### Phase 4 — Institutionalize
+- Keep a running decision log from Phase 0 onward; consolidate it here so Phase 1/2 lessons are not lost to the end of the program.
+- Write the new structural rules back into the repo convention / team doc so the improvement holds.
+- Compare final metrics against the Phase 0 baseline; report before → after per driver.
+- Route any reusable cross-project lesson through `skill-extraction-workflow`.
+- **Exit gate:** an acceptance report shows before → after numbers for each target and the new rules are merged.
+
+## Stop conditions
+
+Any regression on a security / permission / privacy / money / data-isolation / high-impact-AI surface is an immediate pause-and-rollback, regardless of count. For the softer signals — regressions traced to the refactors, CI instability from the new gates, or a target trending away from its goal — set numeric thresholds up front (for example N regressions in a week) and name the stop authority, rather than leaving "repeated" or "below the bar" to in-the-moment judgment. Re-baseline or re-scope before resuming.
+
+## Exit-gate evidence
+
+Every exit gate needs evidence, not artifact existence: the command run, an output excerpt, the commit SHA, the scope, and the owner/reviewer. When a phase routes to another skill, that skill's concrete output (test file, gate config, plan) must be linked in the phase evidence, or the routing is ceremonial.
+
+## Ownership boundaries
+
+- This reference owns the program shape and phase gates.
+- `feature-risk-router` and `high-risk-resilience-gates.md` own high-risk surface classification and resilience gating (used from Phase 0 onward).
+- `existing-project-assessment-report.md` owns the Phase 0 diagnosis report format.
+- `testing-strategy` owns Phase 1 new-debt CI-gate design and Phase 2 layer / fixture / CI-gate selection.
+- `refactoring-discipline.md` owns Phase 3 single-change behavior preservation.
+- The owning stack development skill owns the actual code changes and rendered/runtime evidence.
+- `skill-extraction-workflow` owns Phase 4 durable lesson landing.
+
+A program is `complete` only when each phase's exit gate has evidence. A skipped Phase 0 baseline or Phase 2 safety net is a process defect, not a shortcut.

package/dist/assets/marketplace/plugins/ccl-skills/skills/product-rd-workflow/references/rd-standards-doc-family-checklist.md

@@ -0,0 +1,27 @@
+# R&D Standards Doc Family Checklist
+
+Use this checklist for R&D standards, specs, guidelines, or Feishu/wiki doc families before marking docs done.
+
+## Checklist
+
+1. Classify the layer: overview/index, product or requirements Spec, stack/service guideline, repo-local execution Spec, ADR, checklist, or evidence report.
+2. If any child doc, second stack/service, or cross-doc product-goal reference exists, create or update a parent overview/index first and link child docs.
+3. Scope evidence must name the parent node(s) or repo scope searched, include the product Spec surface checked, list candidate child locations, and attach concrete enumeration evidence: command/output, node list, or two independent manual passes listing parent index URL plus each checked child node title/link when no programmatic tool exists. If scoped evidence is absent, mark `blocked: family enumeration unverified`, with no sign-off.
+4. Only when step 3 evidence shows zero child docs may a single existing doc be treated as its own overview/index; cite that evidence and record its path/link and authority statement.
+5. Multi-doc families require an authority statement plus sync-gate rule before child docs are marked done.
+6. If the family defines any implementation, stack, service, client, CI, harness, release, or QA norm, include or update a testing standard child doc. It must cover test deliverables, unit/contract/integration/E2E/manual layers, harness, CI gates, high-risk coverage, evidence format, and stack handoff; route the template to `testing-strategy`.
+7. If the family will drive project health checks, add a conformance appendix or sibling checklist that maps each rule to `deterministic`, `agent_review`, `manual`, or `not_automatable_yet`, with severity, evidence, command/prompt owner, and CI behavior. Route architecture fitness functions to `testing-strategy`; route directory-contract coverage to `agents-file-coverage-gate`; route stack mechanics to the owning stack skills.
+8. Before invoking `tighten-doc`, record `owner-ready` with the authority statement, doc-family layer, enumeration evidence, and conformance mapping evidence when applicable, or `blocked: family enumeration unverified`.
+9. Re-confirm the doc-set enumeration at completion/sign-off, or add the sync gate if the family has grown.
+
+## Architecture / System-Overview Honesty Pass
+
+For an architecture or system-overview doc, one that describes how an already-built system works, run a current-state-honesty pass before sign-off:
+
+- For each load-bearing "enforced / automated / already does X" maturity claim, record claim → evidence source → status (`implemented`, `convention-or-target`, or `unknown`) verified against real code, CI, or hooks. Non-load-bearing prose does not trigger a repo audit.
+- Give a diagram for nontrivial multi-component runtime, dependency, or data-flow concepts where prose alone would mislead. A simple doc may record one doc-level "diagram not needed".
+- Align terminology to a named external standard only when the doc invokes one.
+- Frame any "advanced" or "best-practice" claim as alignment with an external standard plus honest gaps, never as self-praise of own components.
+- The independent review must check claims against the real repository, including code, CI, and hooks, not only wording. A wording-only review can pass prose that misstates system maturity.
+
+This is the substance/honesty axis. Readability and jargon are the `tighten-doc` axis; run both.

package/dist/assets/marketplace/plugins/ccl-skills/skills/product-rd-workflow/references/refactoring-discipline.md

@@ -0,0 +1,52 @@
+# Refactoring Discipline
+
+Use this when improving code structure, splitting responsibilities, reducing duplication, changing data shapes, or cleaning technical debt without intending to change product behavior.
+
+## Rules
+
+- Keep behavior-preserving refactors separate from feature changes and bug fixes unless the user explicitly accepts the combined risk.
+- Establish a green baseline first: run the smallest relevant tests or record why the current baseline is already failing.
+- Refactor in small steps. Each step should be reviewable and, when practical, independently testable.
+- Search all call sites before changing public functions, DTOs, generated contracts, config keys, storage fields, events, or exported helpers.
+- Preserve external behavior, response shape, errors, telemetry, permissions, and side effects unless the change is intentional and documented.
+- Do not broaden a refactor while debugging an unknown defect; use `defect-diagnosis` first.
+
+## Impact Analysis
+
+Before changing a shared shape or function, identify:
+
+- direct callers and generated callers.
+- tests, fixtures, mocks, and fakes.
+- API/RPC/protobuf/OpenAPI/Pydantic/DDL/config/event contracts.
+- persisted historical data, cached values, queued messages, and replay/backfill inputs.
+- observability and dashboards that depend on names, status, or error codes.
+
+## Data Shape Changes
+
+- Prefer additive, compatible changes first.
+- Keep old readers/writers working until migrated.
+- Treat shipped or externally consumed API/RPC/event/config/response contracts as compatible-by-default. Do not remove, rename, repurpose, or stop accepting existing fields/codes/semantics unless a human explicitly approves a breaking change after seeing a risk assessment.
+- A breaking-change risk assessment must name consumers, rollout order, compatibility window, migration or dual-read/dual-write plan, monitoring, rollback path, user/customer impact, and the tests or replay evidence that prove the cutover is safe.
+- If the user asks to remove compatibility for a contract that may already be live, first clarify or verify launch status. If launch status is unknown, assume live for compatibility planning and present the breaking-change risk before implementing.
+- Decide which fields are immutable, preserved, recalculated, or backfilled.
+- Include rollback behavior for schema, generated code, dynamic config, and data migration.
+
+## Verification
+
+- Run focused tests before and after when feasible.
+- Add characterization tests before risky legacy refactors.
+- When the behavior to lock is unreachable by the current test harness (library-private, or entangled with native / platform / UI machinery), the "characterization tests before risky legacy refactors" rule needs a narrow, explicit exception: introduce the smallest behavior-preserving testability boundary first — extract the pure logic, pass an existing dependency / clock / client in as an argument, or wrap the native/UI boundary behind an interface, then write the characterization test before the risky refactor continues. That pre-test boundary change is not free protection: keep it reviewably mechanical and guard it with the strongest *practical* before/after evidence available (existing tests, compiler/static checks, golden output, or a recorded before/after trace); if no meaningful check exists, say so and do not call the result test-protected. Do not expose secrets, auth/permission decisions, privileged internals, or unsafe native/platform handles just to test them — prefer same-package/in-module tests, a narrow adapter, or an interface; widen a visible boundary only when it is independently a defensible product/code boundary.
+- For shared contracts, run contract/codegen checks and affected integration tests.
+- Prove a "zero behavior change" claim with a deterministic anchor, not a verbal assertion: a conformance digest, golden output, or differential test whose result stays identical across the whole refactor. For multi-step refactors, run the anchor and the relevant suite green at every step, not only at the end — a step that cannot be proven green is where the drift hides.
+- When retiring an old path in stages, keep a thin compatibility shim until every caller is migrated, so deleting the old symbol fails at compile/build time for any missed call site instead of changing behavior silently.
+- Review diffs for behavior drift, not just formatting or decomposition.
+
+## Module Depth & Tactical-vs-Strategic（Ousterhout *A Philosophy of Software Design* 2018）
+
+判断"是否值得 refactor"的设计原则：
+
+- **Deep module** = 简单 interface 包覆较深功能（high benefit / low cost — abstraction 是负担抵不过省的心智）。**Shallow module** = interface 与 implementation 几乎同体量（abstraction 几乎无收益，只是包了一层）。指标：interface 字段 / 方法数 vs internal 行数；前者远小于后者 = deep；接近 = shallow
+- **Refactor 优先吃 shallow module**：合并到调用方或重设计 interface 让它变 deep；不要为复用而抽 shallow module
+- **Tactical 编程**（快速 patch + 局部最优 + 持续 hack）vs **Strategic 编程**（每改动留代码比改动前更好 — investing-in-design）：tactical debt 累计后只能 strategic 还。Refactor 是 strategic 模式的工具
+- **Red flags**（Ousterhout-aligned design 反信号；命中 → 是 refactor 候选 — 本 ref 选用 5 个常见 + 本地补充 generic name 例）：information leakage（多模块知同一秘密）、temporal decomposition（按时间步拆模块而非按概念）、overexposure（接口暴露过多 implementation 细节）、pass-through method（只转手调用无实质，应消除中间层）、vague / generic name（本地补充：`Util` / `Helper` / `Manager` 模糊责任）
+- **不仅因"代码看着不爽" refactor**：每次 refactor 必指出对应的具体动因 — 团队 convention 对齐 / cognitive load 降低 / 命中 red flag / shallow module / 测试可达性等可表述的影响；纯主观"不优雅"不接受作单独理由

package/dist/assets/marketplace/plugins/ccl-skills/skills/product-rd-workflow/references/review-reception.md

@@ -0,0 +1,34 @@
+# Review Reception
+
+Use this when receiving review feedback from a human reviewer, AI reviewer, CI analysis, or external auditor.
+
+## Rules
+
+- Read all feedback before changing code.
+- Understand the requested change before implementing it.
+- Verify feedback against the current codebase; do not assume every suggestion is correct.
+- Ask when feedback is ambiguous, incomplete, or appears to conflict with requirements.
+- Push back with technical evidence when a suggestion is incorrect or harmful.
+- If your pushback was wrong, correct it factually and move on: retract only after re-verifying against the codebase or the authority that settles the point (requirement owner, product decision, observed runtime behavior) — state the concrete counter-evidence; reviewer insistence alone is never grounds, and an inconclusive re-check goes to the risk owner rather than holding the pushback — except on a scope-adding finding, which follows the mirror-case procedure below instead. Once re-verification or that risk owner establishes the pushback was wrong, retract and implement — no long apology, no defending the earlier pushback.
+- Implement one coherent review item or group at a time, then verify.
+- Partition findings before fixing: a mechanical finding (bug, missing check, wrong value) goes on the fix list; a design-level finding — one questioning a mechanism's cost, operability, trust-model fit, or existence — is a risk-owner decision item (keep / delete / narrow / replace) to surface BEFORE investing hardening rounds in the questioned mechanism. Hardening first and deciding later pays the cost twice — once to build, once to tear down. The mirror case — a finding that adds scope or abstraction beyond the agreed deliverable (a new capability or abstraction layer — not a guard, error path, or rollback that a current acceptance point or observed hard constraint already requires for behavior already in scope; a remedy that itself introduces a new capability or abstraction stays scope-adding however it is labelled; an arguable classification is settled by running the test named next, never by defaulting either way) — is never an automatic build: answer it against the structural-minimality test in `implementation-completeness-and-minimality.md` — name the current acceptance point or observed hard constraint that needs it, or state that there is none — and reply with that answer before deciding. No locator means the answer is decline, not build: building it anyway first requires the risk owner to change the governing acceptance requirement. that evidence-backed answer is the receiver's to give and the reviewer's to confirm, and a rejected answer returns the item to the receiver to rebuild the evidence rather than to a risk owner — on this question the risk owner's role is to change the governing acceptance requirement, not to override the reviewer's rejection. When one finding is both design-level and scope-adding — it questions an existing mechanism AND proposes a new capability or abstraction, whether that wraps, supplements, or replaces the mechanism — the two paths govern different objects and both run: the minimality test decides the proposed addition (receiver answers, reviewer confirms), while the questioned mechanism's keep / delete / narrow / replace stays the risk owner's. Neither substitutes for the other, and neither decision alone authorizes the addition.
+- Avoid performative agreement. Technical correctness matters more than sounding agreeable: agree only after verifying — the reply shows what you checked and what you found, and praise or thanks offered in place of that evidence is the failure ("you're absolutely right" / "great point" are the common forms).
+
+## Response Pattern
+
+1. Restate the technical requirement if it is not obvious.
+2. Check the relevant code, tests, contracts, or docs.
+3. Decide: accept, clarify, defer with risk, or reject with evidence.
+4. Make the change only after the decision is clear.
+5. Run focused verification.
+6. Report what changed, what was verified, and any remaining risk.
+
+## When To Stop
+
+Stop before implementation when:
+
+- multiple review items may be related and some are unclear.
+- the suggestion would change product behavior or public contract.
+- the suggestion conflicts with architecture, security, data integrity, or compatibility constraints.
+- the reviewer may not have full codebase context.
+

package/dist/assets/marketplace/plugins/ccl-skills/skills/product-rd-workflow/references/shared-gate-artifact-classification.md

@@ -0,0 +1,76 @@
+# Shared gate artifact classification
+
+Use this reference before implementing product/spec normalization, standards-to-health-gate work, or changes to shared deterministic gates and coordination surfaces.
+
+## Trigger
+
+This gate applies to any change that edits a shared deterministic gate/verifier, including:
+
+- Workspace verifier.
+- Conformance script.
+- Contract-coverage gate.
+- Status-source validator.
+- CI harness.
+- Continuation-state checker.
+- Cross-repo contract/status/version/release/compatibility coordination surface.
+
+It also applies when shared or cross-repo contract/status/version/release/compatibility semantics change, whether the change is made in a named gate/status surface or in runtime code, generated artifacts, config, or scripts.
+
+## Artifact classification
+
+Before implementation, classify the artifact as one of:
+
+- `spec/plan`
+- `gate design`
+- `gate implementation`
+- `status sync`
+- `runtime/code`
+
+Do not delegate the spec-vs-plan-vs-code decision to `feature-risk-router`. After artifact classification, route every shared-gate change through `feature-risk-router` and apply its `shared-gate` decision before shared branch push or MR merge.
+
+## Persistent artifact requirement
+
+When a `gate implementation`, `gate design`, or `status sync` change — or any change to shared or cross-repo contract/status/version/release/compatibility semantics, whether made in a named gate/status surface or in runtime code, generated artifacts, config, or scripts — alters the affected rule, scope, failure, or completion semantics, create or cite the persistent implementation-plan artifact before editing.
+
+Accepted artifact forms:
+
+- Implementation plan.
+- ADR.
+- Status doc.
+- Issue/MR description mirrored into a repo-local file.
+
+The plan must be a concrete repo-local path on the next executing agent's read path. Chat-only plans and platform-only issue/MR text are not enough.
+
+The plan must contain:
+
+- Artifact classification.
+- Scope.
+- Acceptance matrix. For a verifier/gate/status surface that emits a verdict or completion status (`ready`/`not_ready`/`pass`/`fail`/`pending` or equivalent), this matrix must be a decision table mapping its named inputs to one verdict — at least a planned input row per verdict, with executed traces by closeout — not a prose list that only names the fields.
+- Test/register coverage.
+- Status-sync target.
+- Review/challenge gate.
+
+A simple low-risk single-file gate edit that preserves existing semantics may use an inline plan, but the inline plan must state why no rule, scope, failure, or completion semantics changed.
+
+## Verifier discovery
+
+For a `gate implementation`, also discover the plan/status verifier from:
+
+- Repo agent contract.
+- README.
+- Scripts.
+- Makefile/package scripts.
+- CI config.
+- Explicit status-source validator.
+
+An explicit status-source validator takes precedence. Otherwise run every authoritative non-alias plan/status verifier declared by the agent contract, status source, or CI. One canonical command may cover equivalent wrappers with evidence. Run each authoritative verifier, or record why it is not applicable, before implementation and before claiming the plan active.
+
+If the slice's own purpose is to create the first such verifier, record the absence search and require the newly created verifier to run before claiming the plan active or the slice complete.
+
+If no verifier is discoverable and the slice does not create one, record the search evidence and named artifact path as an open verifier gap. Use `interim` / pending-verification status until a verifier runs or an explicit human waiver is recorded.
+
+## Review and closeout
+
+Local mutation tests and passing verifier output prove script behavior. They do not replace review of whether the gate's rule, scope, and failure semantics are correct when the risk route requires review/challenge.
+
+If the required review/challenge is unavailable after remediation and any approved fallback reviewer also fails to produce valid evidence, stop at `interim` / pending-review status instead of claiming the slice complete.

package/dist/assets/marketplace/plugins/ccl-skills/skills/product-rd-workflow/references/source-evidence-map.md

@@ -0,0 +1,31 @@
+# Product R&D Source Evidence Map
+
+Internal provenance only. Use this when auditing or re-extracting the top-level product R&D workflow.
+
+## Source Coverage
+
+| Dimension | Sources inspected | Useful extraction | Decision |
+| --- | --- | --- | --- |
+| Design sources | Batch Figma reads across web shell, mobile app, creation, analytics, review, scan/upload, assignment, resource library, resource center, object/config management, and design systems | Product workflow must require design readiness for human-facing surfaces before implementation, including states, density, trust, and rendered acceptance | Keep routing/gate only; design details stay in design skill |
+| Web/client code | Batch manifests and representative package scripts across Umi/React, Vite React, Vue, admin, H5, document/media, and operations apps | Product workflow must route web/app implementation separately and require rendered evidence, not only code/build success | Keep |
+| Backend code | Go/Python service inventories, Makefiles, service manifests, tests, integration scripts, generated contracts | Product workflow must route architecture before code when contracts, runtime, source-of-truth, auth, async, or release surfaces change | Keep |
+| High-risk backend review samples | Targeted local review of quota/accounting/audit/worker patterns and defect-review notes in high-risk service samples | Good patterns: durable idempotency, trace/request correlation, worker status, stale counters, admin repair states, contract tests. Bad patterns to guard against: default-context fallback on missing scope, Redis/TTL-only dedupe for durable side effects, mutation committed before audit/outbox evidence, and repair flows without visible stale/pending evidence | Merge into high-risk resilience gates and backend/testing skills; do not copy product nouns or paths into executable guidance |
+| Mature service and frontend samples | Broad inventory plus representative source reads from a mature multi-service and interaction-heavy frontend workspace | Useful mechanisms: gateway/RPC/worker/service-package classification, handler/logic/service/infra layering, generated contract ownership, Wire/codegen gates, structured config, trace/log context propagation, DB/MQ lifecycle, route/layout/workbench separation, API wrappers, table/filter/bulk patterns, upload/scan/long-task state, chart/canvas lifecycle, H5 gesture/WebView constraints | Keep mechanics; route stack details to Go/Python/Web/App/testing/design skills; discard source-domain vocabulary |
+| Current source-register pass | New-product skill-suite register, frontend/app subagent review, Go subagent review, local Python/AI runtime reads, and selected direct file reads | Corrected coverage and source-quality discipline: package/module inventory is not line-level completion; primary Go modules count is 78 plus one downgraded demo/test module; strong frontend/app sources are modern React workbench/H5/admin projects; Python evidence supports microservice/runtime wiring but still has broader read gaps | Keep as extraction-control evidence; route concrete rules to target skills |
+| Testing topology | Go/Python/Web/App tests, markers, Playwright/Vitest, integration scripts, structure checks, CI-like commands | Product workflow must use testing strategy for layer selection and require evidence matched to risk | Keep |
+| Skill extraction corrections | Repeated user corrections about shallow extraction, source-depth overstatement, and missing RCA | Product workflow should route durable learning through `skill-extraction-workflow` and not bury extraction method in product docs | Keep |
+
+## Keep / Merge / Discard
+
+- Keep: product R&D is the top-level router and gate owner, not the owner of stack-specific implementation details.
+- Keep: human-facing surfaces need design checkpoint and rendered inspection; backend/runtime surfaces need architecture gate and risk-matched verification.
+- Keep: when extracting from an old or different-domain product, require mechanism/business/source-quality separation before product planning or skills reuse.
+- Merge: testing, design, web/app, Go, Python, and extraction skills through explicit routing.
+- Route: all source-derived skill changes to `skill-extraction-workflow`; UI details to design; implementation to stack skills.
+- Discard: business-domain structure, source repo names, old product IA, and any one-off local tool habit that is not a general lifecycle gate.
+
+Coverage label: broad cross-source workflow extraction, not node-by-node product/code inventory.
+
+Latest high-risk resilience pass label: targeted code-and-review extraction from local high-risk service samples, not full repository inventory.
+
+Latest mature-workspace pass label: representative broad extraction across service, frontend, and Figma-indexed design sources; not a node-by-node inventory of every source file.

package/dist/assets/marketplace/plugins/ccl-skills/skills/product-rd-workflow/references/status-tracker-sync.md

@@ -0,0 +1,77 @@
+# Status tracker sync
+
+Use this reference when a delivery changes shared product status, roadmap, verification state, cross-repository readiness, or any repo-local status source that a future agent may consume.
+
+## Human-facing status docs
+
+When the delivery changes shared product status, roadmap, verification state, or cross-repository readiness, update the owning product/status document in the same delivery batch after the code MR lands.
+
+Keep it factual and evidence-based:
+
+- Linked review artifact.
+- Merged state.
+- Pipeline result.
+- Verified commands.
+- Remaining risk.
+
+Do not let product docs claim stale pending work after implementation has landed.
+
+Implementation-progress fields embedded inside a spec, design doc, or ADR (per-section implemented/pending/done markers) are status surfaces under the same rule: flip them in the same PR/batch that lands the implementation — status drift repaired by after-the-fact "sync status" batches is the failure shape this prevents. Discovery of these surfaces is not optional: a slice delivering against an owning spec/design doc/ADR includes a status-surface inventory in its readiness evidence (grep the owning docs for embedded progress markers and as-built divergence), with `none found` recorded as an explicit checked result — otherwise the same-batch rule never fires because nobody looked. Better still, avoid embedding mutable progress fields in prose docs at all: point the doc at the single owning tracker/ledger so status has one writer. (An ADR's decision `Status` field is decision lifecycle, not delivery progress, and stays in the ADR.)
+
+The "after the code MR lands" rule applies to the human-facing / shared status doc.
+
+## Agent-consumed status-doc rule
+
+A tracker that is **agent-consumed** — an executing agent reads it to orient on current state and next action — is part of the work itself, not a follow-up.
+
+Land it by state:
+
+- **Shared landing**: status is in the same final shared change-set or orchestrated batch. Cross-repo work is cross-linked and not complete until both sides land.
+- **Local handback**: status is in the same local diff/patch or reported `pending` with owner.
+- **RED/WIP commits**: tracker is not required per commit, but must match the final handed-off, green, or shared state. Never code-first-status-after.
+
+## Final-state gate
+
+Before merge, and after any reviewer edit, squash, rebase, or platform-side merge, re-validate the tracker against the final diff/ref/CI.
+
+A behavior-changing implementation row may become `complete` only when both closure tables are present, the acceptance IDs reconcile to the active source, and no blocking row remains in either table (a concept-delta `simplify`/`remove` decision not reflected in the final diff is blocking); a documentation-only row records the reviewed two-axis `not-applicable`, and a pure-refactor/mechanical-maintenance row records functional-axis `not-applicable` plus its concept-delta table. Record the closeout artifact and reviewed diff identity; missing or stale closure evidence keeps the row pending.
+
+The tracker can be fresh at push and stale at merge. Point status at the final landed ref, not the pre-squash branch commit.
+
+## Live tracker shape
+
+Keep the tracker on the agent's read path: a repo-local file that the agent contract points to.
+
+Keep the live tracker compact:
+
+- Exactly one current state.
+- Exactly one next action.
+- Only the risks/blockers affecting the next slice or current acceptance.
+- Each risk/blocker has owner and stale-after.
+
+Closed, mitigated, and background items move to history, not the live doc.
+
+Do not use a raw append-only checkpoint log as the live tracker. It buries the next action and duplicates VCS history.
+
+## Delivery-status ledger (multi-repo / remote-state delivery)
+
+The entry-precedence rule in `SKILL.md` requires this ledger for multi-repo delivery or any delivery that changes remote branch / MR / pipeline / release / deployable-artifact state. Keep one row per changed unit:
+
+- target branch; local/remote sync state; artifact or commit state; verification state (`not-run`, `running`, `pending`, `success`, `failed`, `blocked`, `inconclusive`, `not-applicable`, or `not-required`); MR/main-dev state; cleanup state; residual risk; next action.
+- **Set-completeness reconciliation.** The ledger's rows must equal the *intended* set of changed units, not merely the units the batch happened to touch. Before any "all N / every / done / current" claim over an enumerable set (e.g. repo sweep, multi-file edit, fan-out, per-member bump), re-derive each member's actual post-state from **ground truth** — re-scan the targets themselves (the repos/files/refs) — NOT from the batch loop's own success output: a hand-maintained ledger, or a loop whose item list silently lost an entry, under-counts without erroring, and the drop is often already visible as a count mismatch (a claim of N against N−1 executed rows is the tell). Assert `intended set == covered set` and keep the re-derived coverage table as the evidence the check fired. "The loop ran over the list" is not proof the list was complete; the reconciliation, not the loop, is what licenses the "all N" claim.
+- When a final/status response covers remote-state delivery and could be read as completion, split **Agent jobs** from **External async waits**. Agent jobs cover tracked subagents/workers only. External async waits are open-ended — such as MR/PR pipelines, CI jobs, platform reviews, deploys, canaries, release promotions, data migrations/backfills, async callbacks, artifact/package publish propagation, or external tracker waits; a background job board showing no active agent jobs does not prove there is no pending work. For each external wait, record the object/link, branch/ref/head SHA, pipeline/job/deploy/canary/review id, last known state with evidence source/time, and the next gate or owner/unblock action. A pending/running external wait keeps completion and merge recommendation pending unless the owning workflow explicitly records a safe deferral; a failed external wait remains failed until resolved, or until the merge-authorization gate records user acceptance of that non-green state for the specific object and head SHA.
+
+Persistence: for a short batch the ledger may be reported in the final response as closeout evidence; but if it will guide a later slice, persist it in a repo-local/status artifact (or an explicit external tracker) before using it as the continuation baseline — chat (including the prior final response) is not a continuation baseline. The blocking required-gate rule and the merge-authorization boundary (residual-risk acceptance is not merge authorization) stay in the `SKILL.md` entry-precedence bullet.
+
+## Durable decisions
+
+Route must-not-lose decisions to a durable record with path/link and owner:
+
+- ADR.
+- Stable-path changelog.
+- Spec decision log.
+- Policy-durable issue/MR permalink.
+
+A squashable MR comment/log is not durable unless mirrored into one of those records.
+
+Human-facing rollup may live in a tracker or milestone. It is not the agent's continuation truth, and the two do not copy each other.

package/dist/assets/marketplace/plugins/ccl-skills/skills/product-rd-workflow/references/sync-spec-repo-contract.md

@@ -0,0 +1,25 @@
+# Sync Spec / Repo Contract
+
+Use this reference for the spec / repo-contract sync gate's detailed mechanics: how the repo-local agent contract stays in sync with the slice, and how to handle value sets owned by an upstream authority the repo does not own. The entrypoint keeps the gate's firing rule and a pointer here; the upstream no-copy rule itself and the handling detail live in this file.
+
+## Repo-local contract sync
+
+- `agents-file-coverage-gate` owns AGENTS.md coverage, nearest-file-wins/source-directory scan semantics, `--check`/`--fix`/`--enforce`, hook/CI wiring, and incremental adoption.
+- Lint/build counts as contract evidence only when that target runs the coverage gate.
+- Repo-local agent contracts carry version-independent rules plus a version-authority pointer (manifest/lockfile/dependency declaration); never copy the current pin — `platform-release-engineering` owns the layered version model and the audit/snapshot inline-version exception.
+
+## Upstream-authority value sets (no-copy handling)
+
+- Never restate an upstream authority's value sets: **The same no-copy rule governs any UPSTREAM AUTHORITY the repo does not own** — restating its *value sets* creates a second source that drifts silently — keep a pointer plus the revision you read, and make the MR checkable without redistributing the upstream: default to the access-controlled pointer + revision + the reviewer's own comparison result.
+
+Handling mechanics:
+
+- When implementation genuinely needs the values fixed, freeze them in the **contract artifact** (IDL enum, schema, generated code) so the values live in one reviewable place instead of scattered prose.
+- The reviewer opens the source and attests the values match; record that comparison result next to the pointer.
+- Only quote an excerpt when the upstream's classification and redistribution permissions actually allow it — a partner contract, an access-controlled spec, or anything under NDA must not be pasted into an MR body or review comment, which are durable platform history that outlives the repo (this is the artifact-egress confidentiality gate, applied to the upstream side).
+
+## "The upstream is silent" is a whole-document claim
+
+When you conclude the upstream is SILENT on something, that is a claim about the whole document, not about the sections you happened to open: keyword-hit-and-stop reads the sections that mention your search term, which is exactly the wrong sample for an absence claim. Enumerate the upstream's own section list for the topic and read them, or scope the conclusion to the sections you actually read.
+
+Failure shape: three sections searched, an "upstream never specified this" open-decision registered, downstream work blocked on it — while a fourth section held a titled, closed specification; the same repo had also drifted the upstream's version number and two of its state counts.

package/dist/assets/marketplace/plugins/ccl-skills/skills/product-rd-workflow/references/verify-developer-experience.md

@@ -0,0 +1,34 @@
+# Verify Developer Experience
+
+Use this reference when a delivery touches developer-facing surfaces — CLI, SDK, library, public API, or developer docs — and must prove developer experience (DX) as an acceptance dimension. The entrypoint keeps the acceptance gate and the routing decision; this file carries the journey-proof mechanics.
+
+## Measured onboarding journey
+
+For a new or public developer surface, or a change touching onboarding, install/setup, first-success, defaults, error surfaces, or a breaking migration, prove DX by the measured onboarding journey: run the real discover→install→first-success path as a new user and capture steps, time-to-first-success, friction, and the actual error messages. Do not infer DX from README / feature-list quality.
+
+- A smaller change proves only its affected segment, or cites recent unchanged-journey evidence.
+- An unavailable real environment after remediation uses `testing-strategy`'s proportional / lowest-sufficient-layer model and `blocked` / `pre-runtime-test ready` handling — never a faked pass.
+
+## Error messages are a first-class acceptance item
+
+Every error surface a new user can hit states the problem, the likely cause, and the fix — ideally with a docs link. A green build or a 200 response is not DX evidence when the failure paths are unreadable.
+
+## Defaults: safety stays fail-closed
+
+- A non-safety product default needs a safe override (escape hatch) or a documented no-escape rationale.
+- A safety / security default (auth, sandbox, TLS, destructive-action, privacy, compliance) stays fail-closed: widening it needs risk-owner approval, and it may legitimately have no normal escape hatch. DX never licenses an `--insecure` / `--no-sandbox` bypass.
+- Breaking changes need a migration path.
+
+## Route per-surface execution to the owning executor
+
+The workflow owns the acceptance dimension only; route execution + evidence per surface:
+
+- SDK / library / package → the target stack / package owner.
+- React/browser-consuming surface → `web-react-dev` only.
+- CLI / TUI → `terminal-cli-dev`.
+- Service APIs → the API/contract + `*-architecture` owner.
+- Developer-doc authoring → `tighten-doc` + the stack/API owner.
+- Onboarding-journey scenario coverage → `testing-strategy`.
+- Deprecation / migration → `platform-release-engineering`.
+
+Do not build a generic DX-scorecard skill — the acceptance gate lives in the entrypoint, and the recipes stay with the executor owners.

package/dist/assets/marketplace/plugins/ccl-skills/skills/product-rd-workflow/references/worktree-mechanics.md

@@ -0,0 +1,55 @@
+# Worktree Mechanics
+
+Use this reference for the concrete mechanics behind product R&D worktree isolation and cleanup.
+
+## Create A Dedicated Worktree
+
+Use a unique per-line branch so it never collides with a branch already checked out elsewhere:
+
+```bash
+git worktree list
+git worktree add -b <line-branch> <path> <base>
+```
+
+## Shared Git State
+
+A worktree isolates only the working directory and index. Sibling worktrees of the same repository still share git objects, refs, hooks, config, and remotes.
+
+Coordinate repo-global mutation such as:
+
+- Hook or config edits.
+- Remote changes.
+- Global cleanup.
+- `git gc`.
+
+## Concurrent-Session Hazards
+
+A branch alone is not concurrent isolation. `git checkout` moves the single shared working tree and index under every other line in that checkout, so branch-with-committed-WIP is safe only for serialized handoff (commit, then switch away), not for simultaneous edits.
+
+Never `git stash` another line's uncommitted changes to clear your own view. `git stash` / `refs/stash` is shared mutable state a concurrent session can overwrite or drop. A dropped stash is only sometimes recoverable before garbage collection by locating its unreachable commit and inspecting or applying it; treat that as emergency recovery, not a workflow.
+
+Host-install symlinks are shared-tree edits too: editing `~/.<host>/skills/<skill>/…` or any path that symlinks into a shared repository working tree edits that shared tree, even when it looks like a local file. Isolate it the same way.
+
+If isolation was skipped and a concurrent session may act, do not commit unreviewed or work-in-progress shared changes merely to dodge a clobber. Move the patch into a dedicated worktree or private scratch, then land it through the normal review and release gates.
+
+## Branch Sharing Boundary
+
+A per-line WIP branch stays local/private until the normal shared-branch-push and MR gates pass. Never force-push a shared branch to "isolate" it.
+
+## Closeout Cleanup
+
+At closeout, after the work lands or is abandoned, clean up the worktree and private branch:
+
+```bash
+git worktree remove <path>
+git worktree prune
+git branch -d <line-branch>
+```
+
+## Owner Routing
+
+Route the concrete worktree recipe to the organization `worktree-isolation` skill, especially its Step 0 isolation self-check and integration cleanup. If the session has an installed branch/worktree-hygiene skill, such as `superpowers:using-git-worktrees`, it may supplement the mechanics. Otherwise apply these steps directly.
+
+## Pre-Merge Freshness
+
+Before merging a branch back, especially via squash, check whether it is behind the target. If it is stale, follow `worktree-isolation`'s pre-merge freshness gate: update onto the target and verify the collision set so the stale branch does not silently revert recent target fixes.

package/dist/assets/marketplace/plugins/ccl-skills/skills/product-rd-workflow/scripts/AGENTS.md

@@ -0,0 +1,18 @@
+# skills/product-rd-workflow/scripts Agent Contract
+
+Scripts here implement product-RD workflow checks such as AGENTS coverage.
+
+Rules:
+
+- Keep checks deterministic, repo-scoped, and safe on legacy repositories.
+- Group-parent detection must avoid false root findings for GitLab group
+  checkouts.
+- `--fix` may add files but must never overwrite existing contracts or follow
+  symlinks.
+- Enforcement behavior changes require focused tests or explicit behavioral
+  evidence plus independent review/challenge.
+
+Validation:
+
+- Run the touched script against a fixture or representative repo.
+- `bash skills/skill-extraction-workflow/scripts/check-ccl-skills.sh .`