@ccoalm/ccl-skills 0.1.0

package/dist/assets/marketplace/plugins/ccl-skills/skills/product-rd-workflow/references/artifact-egress-confidentiality.md

@@ -0,0 +1,58 @@
+# Artifact-Egress Confidentiality Gate
+
+A pre-egress confidentiality pass for delivery artifacts. This gate owns **only the semantic confidentiality axis** that secret/PII scanners miss; it is not a general redaction framework and not a scan-every-internal-doc ritual.
+
+## When it fires (and when it does not)
+
+Fires when a delivery artifact, **or any text generated from it**, crosses the local trusted boundary. Run the pass **before** the write / create / push / send API call, not after:
+
+- shared/collaborative stores: Feishu/Bitable writeback, an external tracker, a shared or public doc, a wiki;
+- request bodies: an MR/issue body, a PR/MR review comment or review packet;
+- **durable VCS / release metadata**: a commit message, a branch or tag name, a release note / changelog, CI or release metadata, or any platform-generated body derived from the artifact (these leak into remote history even when the MR body is clean);
+- model/worker handoffs: an external assistant/model call, or a delegated worker/agent prompt.
+
+Scope of in-scope artifacts: product specs, plans, requirements, status/writeback docs, launch/task cards, and product-delivery retrospectives.
+
+- **Does NOT fire** for work kept on the local machine, an internal need-to-know transient with no cross-boundary handoff, or an artifact that never leaves the box. Egress is the trigger — not "every document".
+
+## The gate's own output is also egress (do not leak via the finding)
+
+The block reason, gate finding, review packet, audit note, and any "categories considered" record are **themselves egress artifacts**. When the destination of that record crosses the boundary, it must **not quote the raw sensitive span or the real name** — that re-leaks exactly what the gate stopped. Use **category + a sanitized placeholder + a local-only locator** (e.g. "named-person+negative-judgment at spec §3, line 12"); the raw context stays local/private unless the owner explicitly approves that exact span for that exact destination.
+
+## What this gate owns vs routes out
+
+Route these to their existing owners — do **not** re-implement secret scanning here:
+
+- secrets / credentials / tokens / keys, raw logs → `platform-observability` redaction + the `feature-risk-router` security-review gate label.
+- diagnosis evidence pasted to an external assistant / public web → `defect-diagnosis` evidence sanitization.
+- PII / customer data fields → the owner above; this gate does not duplicate field-level PII regex.
+
+This gate owns the **semantic confidentiality axis** — sensitive even when no credential or PII field is present:
+
+| Category | Action |
+|---|---|
+| A named person tied to a negative judgment ("underperforming / missed / fired / ignored") | rephrase to a role/function ("the owning team"), do not name the individual |
+| A customer / vendor tied to a negative event | anonymize ("Customer A" / "a vendor") |
+| Unannounced strategy / roadmap / not-yet-public plans, internal staging language, internal KPI targets | remove or generalize, OR confirm the destination is explicitly approved (see below) |
+| NDA-bound material (partner deck, named vendor under NDA) | **block** until the owner explicitly approves — the agent never self-approves |
+| Internal codename not used publicly | replace with a generic/public label |
+
+## Severity and block behavior
+
+- **Hard-category block** (NDA-bound; clear confidential strategy headed to a broad/public destination): do **not** write the raw artifact across the egress boundary — not to the destination, tracker, worker prompt, or review packet.
+- **Confirm category** (named-individual / customer-tied / codename / internal KPI to a need-to-know internal destination): surface it (sanitized, per the output rule above) and let the user/owner decide rephrase / anonymize / proceed-with-acknowledgement; on a broad/public destination, "proceed silently" is not offered — rephrase or stop.
+- **Block stops the egress, never the work.** Do not persist the raw artifact *across the boundary* on block; **preserve it locally** — keep the draft in its normal working location or a local user-controlled scratch path, and if it exists only in model context, save it locally before blocking. Never delete or overwrite the user's draft to "resolve" a finding. The remedy is rephrase-then-resend or an owner decision, not data loss.
+
+## Authority stays with the user/owner
+
+- This gate flags and proposes; it does not unilaterally approve an NDA exception, decide a roadmap is publishable, or push past the user. Cross-model or self-judgment that "it's probably fine" is a recommendation, not a clearance.
+- **"Explicitly approved" = the user/owner approving this exact sensitive content/span for this exact destination** — never a broad "content class" the agent can later sort new raw NDA/roadmap material into. ACL membership, "it's an internal channel", a whole-organization wiki/Feishu/MR being "internal", or agent/cross-model inference is **not** approval. Treat broad-internal, broadly-shared, and unknown destinations as the public/strict tier unless the user/owner confirms need-to-know for that exact content.
+- A confidentiality **proceed-acknowledgement authorizes only that one content-egress decision.** It never authorizes merge, auto-merge, default-branch push, force-push, deletion, or cleanup — those keep their own separate authorization gates.
+
+## Not a "passed" badge (avoid false precision)
+
+A clean pass is not a certification that the artifact is confidential-safe. Record only the categories considered and the action taken (or that none fired), sanitized per the output rule — never emit "semantic safety passed / no confidential content" as a guarantee. The pass is a best-effort LLM-judgment triage, the same posture as any review finding under `skill-extraction-workflow/references/review-finding-standards.md`.
+
+## Delegated-worker firing point: multi-agent-delegation
+
+`multi-agent-delegation` enforces this gate at the delegated-worker firing point: before a worker prompt includes a delivery spec/plan/requirement/status/retro/task card, it runs this pass and sanitizes the prompt (a controller can dispatch from an multi-agent-delegation path without reloading `product-rd-workflow`, so the rule must also live at that dispatch site).

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

@@ -0,0 +1,86 @@
+# Code Review Checklist
+
+Use this for a general product R&D review pass before merge or release. Stack-specific skills may add deeper checks.
+
+## Review Invocation
+
+- Scope independent reviews to the smallest useful diff or file set. Prefer passing the base-branch diff through stdin or an equivalent bounded input over asking for a broad repository review.
+- Load local repository rules and conventions, such as `AGENTS.md`, `CLAUDE.md`, harness rules, or project review context, when they exist.
+- Exclude generated files, vendored code, dependency directories, large artifacts, and docs from review input unless the change specifically targets those files.
+- Treat empty output, timeout, auth failure, or continuation-like output as inconclusive. Record a pending review artifact with scope, attempted command shape, and retry questions; do not call it approved.
+- Retry inconclusive reviews with narrower input before abandoning the gate. If a later retry succeeds, update the pending artifact to completed and capture blocking/non-blocking findings.
+- If a reviewer gives a small non-blocking cleanup that is within the current low-risk change scope, fix it and rerun the relevant deterministic gates before merge.
+
+**Effectiveness rules**：
+
+*Google Engineering Practices 公开 guidance*（google.github.io/eng-practices）：
+- **Small CLs preferred** — Google 原文 "no hard and fast rules" 但给参考："100 lines usually reasonable; 1000 lines usually too large"；reviewer 注意力 / 缺陷检出率随 PR 大小衰减
+- **Reviewer first response within 1 business day**（Google 明确上限）；不是 review 完成是首轮 acknowledge + 首批 finding
+
+*本团队本地操作阈值*（非 Google 数字）：
+- PR ≤ 400 LoC changed 是 sweet spot；> 800 LoC 强烈拆分
+- Reviewer 累积 review queue > 5 个 = 排队信号（默认启发，按团队 size / capacity 配置）
+- **Exception 允许大 PR**：generated / mechanical refactor（如 codemod）/ migration / lockfile-vendor 更新 / pre-approved 大设计变更 — 这些 reviewer consent 后可放行
+
+*Specific feedback*：每条 finding 必含 (a) 具体位置（file:line）+ (b) 问题描述 + (c) 建议方向（"see X pattern" / "this could be done as Y"）。空话如 "looks weird" / "改下" / "不够好"不接受 — 作者无法 act。
+
+*Author 响应纪律*：reviewer 留 N 条，作者**逐条 reply**（修了 + commit ref / 不修 + 理由 / 协商需新一轮讨论），不 silently 改完了之 — 见 `review-reception.md`。大 review（50+ findings）允许按主题 batch reply + 明确标 unresolved/blocking 哪些。
+
+## Security
+
+- Inputs are validated server-side for type, length, format, range, and authorization scope.
+- Queries and commands do not concatenate untrusted input.
+- Protected endpoints authenticate before side effects and authorize resource access; no IDOR-style access.
+- **Enforcement lives in the operation that performs the side effect.** For an agent/LLM surface specifically: a tool omitted from the schema, filtered out of the prompt, hidden behind a facade/wrapper, or gated by listener order is *not* denied — a direct or alternate caller still reaches the executor. Trace every denial path to the code that executes it and require the deny to be tested there (`llm-inference-integration/references/agent-tool-dispatch.md` owns exposure-vs-authorization; `testing-strategy` owns the enforcement matrix).
+- Secrets, tokens, credentials, and PII are not committed, logged, exposed in errors, or returned in responses.
+- Public callbacks, uploads, redirects, outbound fetches, and dependency calls have explicit validation and limits.
+- Rate limits, concurrency limits, or cost guards exist for expensive or abuse-prone paths.
+
+## Correctness
+
+- Empty, nil/null, zero, negative, max, duplicate, and malformed inputs are handled deliberately.
+- Pagination, loop boundaries, time ranges, and cursor/order semantics are correct.
+- Concurrent writes use transaction, compare-and-update, lock, idempotency key, or unique constraint as appropriate.
+- Multi-step durable changes are transactional or have compensation/reconciliation.
+- Time zones, Unicode/multibyte strings, precision, and currency/decimal values use appropriate types.
+- Async errors, dependency errors, and partial failures are not swallowed.
+
+## Performance And Reliability
+
+- No obvious N+1 query, unbounded full-table scan, unbounded fanout, unbounded queue, or indefinite sleep.
+- Lists and exports are paginated, streamed, batched, or otherwise bounded.
+- Expensive work is cached, queued, or rate-limited where appropriate.
+- Timeouts, retries, circuit breakers, and fallback behavior are explicit for dependency calls.
+- Resources are closed or cleaned up: files, response bodies, streams, timers, subscriptions, locks, and temp directories.
+
+## Maintainability
+
+- Names reveal intent and exported APIs have stable semantics.
+- Modules have clear responsibility and dependency direction.
+- Duplicated logic is removed only when shared abstraction is genuinely clearer.
+- Generated files are reproducible and not hand-edited.
+- Comments explain non-obvious decisions, not obvious statements, and state contracts rather than the authoring session — flag dead design-session citations, PR/stack vantage, change narration, reviewer-addressed justification, and hedges per `tighten-doc/references/session-vantage-leakage.md`.
+
+## Scope Completeness And Concept Delta
+
+- **Review both negative space and concept delta.** Review from the original acceptance source, the acceptance-to-evidence closure table, the concept-to-current-need table, and the final diff; the diff alone cannot show required behavior that is absent.
+- For negative space, confirm every in-scope acceptance point maps to an implementation surface and fresh evidence. Reject silent omissions, implementer-created downscoping, and tests derived only from the code that happens to exist.
+- For concept delta, require every new abstraction, indirection, module/service, state/entity, dependency, config/flag, generalized path, or extension point to identify its current acceptance point or observed hard constraint and the simpler alternative considered. Reject hypothetical future reuse; allow refactoring and testability work tied to a current observed constraint.
+- Reconcile the active acceptance-source stable ID set against the closeout table and verify every out/deferred row cites a real product/human decision. Accept two-axis `not-applicable` only for a reviewed documentation-only diff. For a pure refactor or mechanical maintenance with no contract/behavior delta, accept functional-axis `not-applicable` only with the concept-delta table still present. The implementer's label alone is never evidence, and diffs touching the behavior-bearing surface classes enumerated in `implementation-completeness-and-minimality.md` (contracts, schemas/migrations, permissions, quotas/pricing, config defaults, user-visible copy — that list is canonical) qualify for no exemption. A rejected classification returns the delivery to the implementer to build the required tables; do not reconstruct them in review.
+
+## Testing And Evidence
+
+- **Model-visible wording is behavior.** For agent/LLM changes, inspect the exact prompts, tool schemas, tool results, and diagnostics the model receives in every affected mode: flag implementation-only concepts (internal plugin/transport/renderer names the model can neither act on nor needs for a valid call), confirm legitimate tool-contract discriminators survived, and require snapshot/replay or eval evidence for the wording change — "just reworded the description" is an unreviewed behavior change (`llm-inference-integration/references/agent-instruction-composition.md`).
+
+- New behavior has focused tests at the right level.
+- Contract-visible changes include an explicit test matrix before MR readiness is claimed: unit, API/contract, integration, and browser/device/E2E where relevant, with executed commands and unavailable layers called out as residual risk.
+- The MR description is an evidence carrier: record the exact verification commands run and what each proved, precisely enough for a reviewer to reproduce — "tests all pass" is a claim, not evidence. Accepted risks and deferred items get an explicit named section with the accepting owner recorded, never buried in implementation detail; recorded acceptance there is evidence for the reviewer, not merge authorization.
+- API/RPC/event/config or response-envelope changes include the contract definition and compatibility decision in the review context. If reviewers must infer success/error semantics, business-code placement, data location, or compatibility policy from implementation diffs, the MR is not ready.
+- Boundary, failure, permission, idempotency, and compatibility cases are covered when relevant.
+- Generated output, migrations, and contract changes have deterministic checks.
+- Live dependency, browser, real-data, replay, or canary evidence is present for release-critical workflows where mocks cannot prove integration behavior.
+- Failing tests are fixed or invalidated with evidence; they are not deleted or weakened just to pass.
+
+## Review Output
+
+Lead with findings. For each issue include severity, file/line, impact, and suggested correction. If there are no findings, state residual risk and any verification gaps.

package/dist/assets/marketplace/plugins/ccl-skills/skills/product-rd-workflow/references/cross-repo-coordination.md

@@ -0,0 +1,46 @@
+# Cross-repo feature coordination
+
+Load this when **one feature spans repos**. These are the gates the
+`product-rd-workflow` "Cross-repo feature coordination" pointer routes to; each
+section below is an independent gate, not a sequence. The version-coordination
+model is the inline component set used throughout this reference (meta-repo
+manifest / integration branch + central E2E / linked PRs / versioned artifacts);
+`modular-monolith-heuristic.md` holds the related monolith-vs-microservices
+decomposition heuristic that informs the monorepo-vs-polyrepo choice (change
+frequency is a strong signal, not the only factor).
+
+## Feature authority vs contract artifact
+
+- Keep **one feature-authority surface for the slice** — a per-feature spec, or a slice-section of a program spec; don't concurrently redefine the same feature goals in multiple repos.
+- The cross-repo **contract** is a separate concern from the feature spec (the feature spec owns goals/behavior; the contract artifact owns the shared interface + compatibility): keep it in a **stack-neutral independent repo or published artifact** every consumer consumes via an explicit version/compatibility policy, so no implementation repo "owns" it; when the contract has a single authoritative generating source (codegen from one service, gateway-published SDK), an independent **published artifact** substitutes for an independent source repo — but the generating repo still passes contract review before publish (topology doesn't waive governance).
+
+## Consumers, stewardship, and serialization
+
+- **External/un-upgradable consumers** (public SDK, mobile, partners, cached clients, long-lived workers) need an explicit compatibility window + deprecation policy, not assumed same-cadence upgrade.
+- Default a **contract steward** (who can block, review turnaround, escalation) for cross-repo contract/data/rollback work unless explicitly waived — neutrality comes from governance, not repo topology alone.
+- **Concurrent slices touching the same contract region serialize at the contract** (steward/CI); per-slice feature authority does not protect the shared contract.
+
+## Per-repo coordination status
+
+Its per-repo status must name what actually breaks polyrepo launches, not just which repos changed: **contract/data owner, consumed+produced contract version, compatibility & version-skew policy, rollback/promotion owner, central integration evidence (fresh, bound to the exact manifest version-set — stale E2E from another combination doesn't count)**. The version-coordination model is that inline component set (meta-repo manifest / integration branch + central E2E / linked PRs / versioned artifacts); for the related monolith-vs-microservices decomposition heuristic behind the monorepo-vs-polyrepo choice, see `modular-monolith-heuristic.md` (change frequency is a strong signal, not the only factor).
+
+## Staged "done" and non-atomic rollback
+
+- Cross-stack **"done" is staged** (code landed → contract active → traffic enabled → feature complete; traffic-enabled is not binary — partial/shadow/cohort/regional/store-lag, route rollout staging to `platform-release-engineering`); a single "landed" hides partial adoption.
+- **Rollback is not atomic**: reverting the manifest restores only the deployable version combination — stateful/irreversible changes (DB/MQ schema, published app, cache format, external consumers) need expand-contract forward-compat with explicit migration ordering / dual-write windows (route rollout + migration mechanics to `platform-release-engineering`), not a promised atomic rollback.
+
+## Structural vs semantic conformance
+
+Schema/codegen contract-as-code usually covers **structure only**: required files, directories, contracts, version markers, schema/IDL digests, field numbers, and generated enum values must exist and match the declared contract. Cross-stack **semantic** parity (defaults, timezone, idempotency, sampling, redaction, cardinality) needs a semantic conformance suite — route to `testing-strategy`.
+
+## Candidate-until-harness-verified conformance artifacts
+
+**A conformance/contract artifact whose values were *hand-authored / reconstructed from the counterpart's implementation source* (fixtures hand-written from the producer's code, a consumer's expected shapes) — rather than emitted by the authoritative contract generator/IDL — is `candidate`, not authoritative, until a producer-side runtime harness verifies it against the real counterpart** (drive the real handler/serializer; assert envelope/shape/redaction/error-mapping); do not tag / publish / let consumers pin it as the contract before that verification — a released-then-immediately-superseded artifact (the first real check finds the candidate values wrong) means consumers pinned a wrong contract. (Authoritative *generated* artifacts — codegen/IDL/gateway-published SDK — are not `candidate` for this reason, but still pass generator/source review and the normal contract/version gates above.) Sequence the producer-harness verification *before* the immutable version tag; the redaction/visibility set is context-dependent (a field forbidden on one surface can be legitimately public on another), so it is part of what the harness verifies per-surface, not a global constant.
+
+## Vendored-mirror sync
+
+**Vendored-mirror sync** (applies once an authoritative versioned source artifact exists to vendor — the `candidate`-artifact rule above governs the pre-authoritative stage): a consumer's *vendored copy* (fixtures/schema/IDL copied into the consumer repo) is a **read-only mirror of `source@pinned-tag`** — contract changes flow **source-first** (change the source repo, versioned + reviewed, then re-vendor), not hand-edited in the mirror; a hand edit means the consumer has bypassed the source-of-truth flow, and if that edit is the change's only home the **source-of-truth silently falls behind its own consumer** (source older than a downstream copy that advanced under it — the observed failure). A *legitimate* downstream patch is allowed but **must stop calling itself a mirror**: mark it a `local-overlay` with owner / reason / expiry / upstream issue and its own CI. Enforce with a **vendor-sync gate** — each vendored file matches the source's per-tag **manifest** (not necessarily raw bytes: declare any normalization/transform; for *generated* bindings the invariant is "regenerated from `source@pinned-tag` with the pinned generator+options", not byte-equality; subset vendoring verifies its allowlisted files and flags undeclared extras). Divergence is a **blocking signal to classify** (source-first bypass / stale re-vendor / intentional fork / bad normalization / generated drift), never silently merged. Route the version/tag model to `platform-release-engineering`; the drift/conformance **verification mechanic** for this gate (the enumerate→ledger→explicit-verdict procedure, self-contained local-drift default, separate upstream-authenticity gate) is owned by `testing-strategy` (its `testing-strategy/references/vendored-contract-drift-checklist.md`).
+
+## Tooling gaps and the candidate version-set
+
+SDD-style across repos (spec → technical design → implement); **auto repo-discovery and per-repo auto-isolation are target tooling, not assumed** — today there's the spec/ADR/contract sync gate, worktree isolation, and `multi-agent-delegation` dispatch. Caveat on that gap: under a **one-requirement-one-version-boundary** (don't fold another requirement's versions into this integration set; but **merge** into a joint boundary when requirements share a contract / data migration / rollout flag / release-ordering / rollback path), the touched repos + version-set are a **candidate** derived from the per-feature spec — reconcile against actual consumers (spec-unwritten ones = unknown/risk, not "not involved"), so what's missing is discovery *tooling*, not the knowledge. The genuinely un-tooled judgment is the **compatibility baseline + rollback version-set** (incl un-upgradable external consumers). Spec-derivation only scopes the candidate matrix — it does **not** replace central integration / compatibility / rollback validation, which stay independent gates.

package/dist/assets/marketplace/plugins/ccl-skills/skills/product-rd-workflow/references/delivery-lifecycle.md

@@ -0,0 +1,192 @@
+# Delivery Lifecycle
+
+Use this reference when a request needs end-to-end product R&D coordination rather than only code edits.
+
+## Stage Routing
+
+| Stage | Owns | Output |
+| --- | --- | --- |
+| Product shaping | Product workflow | User workflow, acceptance checks, constraints, non-goals |
+| Design readiness | Design skill | Interaction model, UI states, design-system fit, accessibility/visual acceptance |
+| Architecture | Architecture skill | Boundaries, contracts, data ownership, reliability/security decisions |
+| Implementation | Development skill | Code changes, generated artifacts, migrations, tests |
+| Review | Review/debug workflow | Findings by severity, fix decisions, residual risks |
+| Release | Release/runtime workflow | Verification evidence, rollout, rollback, observability |
+| Learning | Skill maintenance | Durable updates to the smallest relevant skill/reference |
+
+## Stage-Entry State Checklist
+
+Walk this at each stage boundary BEFORE crossing into the next stage. Each row names only the required state plus the rule that owns its criteria — it never restates the criteria; open the pointer for the actual bar. A row that genuinely does not apply is marked `N/A + reason`, never silently skipped. This is a firing-point enumeration of the stage-transition gates, not a master table: it duplicates no gate content and is not exhaustive of every rule in this file — it lists only the state that must exist to CROSS each stage boundary, and each pointer opens the owning section for the full gate.
+
+**A row is satisfied only by the owning gate's actual OUTPUT — the decision/evidence/artifact that gate produces — never by a pointer to the gate or a bare claim that it "was considered".** The pointer tells you which gate to run and where its criteria live; it does not itself discharge the row. If the gate produces no output yet, the row is unmet — open the pointer and run the gate now. A row naming an owner gate is discharged only by actually consulting that gate in-session and recording its disposition; a self-written `none` / `N/A` label produced without opening the gate is self-attestation, not the gate's output, and does not discharge the row.
+
+- Do not cross a stage boundary while any of that boundary's rows is unmet or unverified — this is a blocking walk, not a reference list.
+
+- **Exit Product shaping → enter Design readiness / Architecture**
+  - [ ] Product-shaping answers exist → [Product Shaping Checklist](#product-shaping-checklist)
+  - [ ] Product-requirement routing disposition exists → [`../SKILL.md#scope`](../SKILL.md#scope)
+- **Design readiness → enter Architecture / Implementation**
+  - [ ] Design-readiness disposition exists → [`design-routing-and-readiness.md`](design-routing-and-readiness.md)
+- **Architecture Gate → enter Implementation** (also the entry-time firing point for the states below)
+  - [ ] Architecture-gate decision + any required contract definition exists → [Architecture Gate](#architecture-gate)
+  - [ ] High-risk resilience product/architecture disposition exists → [`high-risk-resilience-gates.md`](high-risk-resilience-gates.md) (risk identification → `feature-risk-router`)
+  - [ ] Implementation entry / re-entry preconditions met → [`implementation-entry-reentry-gate.md`](implementation-entry-reentry-gate.md)
+  - [ ] Proportionate plan-authoring output exists → [Plan Authoring](#plan-authoring)
+  - [ ] Implementation-entry invariant state set → [Implementation Gate](#implementation-gate)
+  - [ ] Acceptance/concept closure inputs set → [`implementation-completeness-and-minimality.md`](implementation-completeness-and-minimality.md)
+- **Implementation → before Review**
+  - [ ] Final-diff completeness/minimality closure state met → [Implementation Gate](#implementation-gate), [`implementation-completeness-and-minimality.md`](implementation-completeness-and-minimality.md)
+- **Review Gate → before merge/release**
+  - [ ] Review-gate disposition exists → [Review Gate](#review-gate); checklist [`code-review-checklist.md`](code-review-checklist.md); incoming feedback via [`review-reception.md`](review-reception.md)
+- **Completion Evidence Gate → before any done/fixed/passing claim**
+  - [ ] Completion-evidence state exists → [Completion Evidence Gate](#completion-evidence-gate)
+- **High-risk slice → before starting the next slice**
+  - [ ] High-risk-slice checkpoint run → [Completion Evidence Gate](#completion-evidence-gate)
+- **Release Gate → before release**
+  - [ ] Release-gate precondition state exists → [Release Gate](#release-gate)
+- **Finalization → after a delivery slice lands or reaches pending-MR handoff, before the final response / next-slice decision**
+  - [ ] Pre-Final Continuation Gate walked → [`pre-final-continuation-gate.md`](pre-final-continuation-gate.md)
+
+## Product Shaping Checklist
+
+- Do not start implementation until there is an approved design or acceptance shape proportional to the task.
+- Who is the user or caller?
+- What workflow or job changes?
+- What is the externally visible behavior?
+- What are the non-goals?
+- What data, permission, latency, reliability, and compliance constraints matter?
+- What must be true for acceptance?
+- What can be released incrementally?
+
+For user-facing surfaces, use `design-routing-and-readiness.md` before architecture or implementation when interaction, IA, UI states, visual system, accessibility, or design-system fit is not already clear.
+
+Objective closure belongs to shaping, not only to closeout: before acceptance points are frozen, name the objective's population basis (one static instance vs many members or repeated arrivals) and the outcome classes it implies — positive, negative, corrected/recovered, and ambiguous-or-superficially-successful. A per-operation sample/batch/time/resource bound schedules work and must not be recorded as a narrower total objective. The recorded verdicts, their authority rules, and the no-starvation evidence live in [`implementation-completeness-and-minimality.md`](implementation-completeness-and-minimality.md#objective-closure).
+
+Acceptance-coverage matrix detail: enumerate each functional point plus the risk points it touches (negative / authorization / data-isolation / partial-failure / idempotency, and similar — not limited to these), and map every point to an *observable pass/fail* acceptance check (never a restatement of the feature name), flagging the non-goal boundary where a point's scope is ambiguous. The risk points drive coverage, not grading: how and at which layer to test a point is `testing-strategy`'s scenario/risk matrix downstream, and risk tagging / gate selection stays with `feature-risk-router`.
+
+## Architecture Gate
+
+Run an architecture pass before implementation when any of these change:
+
+- service boundary, ownership, or runtime topology.
+- API/RPC/protobuf contract, public route, callback, or event contract.
+- source-of-truth storage, migration, indexing, or retention.
+- auth, permission, audit, sensitive data, or external integration boundary.
+- async workflow, idempotency, retry, lock, queue, or scheduled job behavior.
+- release runtime, canary, rollback, observability, or operational ownership.
+
+For Go backend work, use `go-microservice-architecture` for this gate. For Python backend, AI-service host, worker, SDK/package, or batch-job architecture, use `python-service-architecture`.
+
+Architecture evidence should name the runtime surface that proves the design can operate after launch: generated-contract ownership, dependency timeout/secret/discovery contracts, health/readiness, trace/log context, durable state for long-running work, retry/idempotency policy, and rollback or repair path. Do not accept a plan that only names the happy-path API or screen while leaving async tasks, generated code, or runtime dependencies implicit.
+
+For any API/RPC/event/config or response-envelope change, the architecture gate must produce a contract definition before implementation: exact request and response shape, success/error semantics, transport status versus business code, where business data lives, versioning or compatibility strategy, launch status, known consumers, and the minimum test matrix. If the shape is not defined, do not let client or server implementation infer it independently.
+
+## Implementation Gate
+
+Use the implementation skill after architecture is stable enough to code. For Go backend work, use `go-microservice-dev`. For Python backend, AI-service host, worker, SDK/package, or batch-job implementation, use `python-service-dev`.
+
+Implementation should preserve:
+
+- local instruction precedence: read the nearest project instruction file such as `AGENTS.md` or `CLAUDE.md`, then parent rules; if child rules merge with or override parent rules, state that precedence explicitly before changing shared boundaries.
+- test-first behavior for user-visible or contract-visible changes: write or update the failing test first and verify it fails for the right reason.
+- contract-first changes for protobuf/OpenAPI/Pydantic/API/DDL/config.
+- clean transport/application/domain/infrastructure layering.
+- deterministic code generation and generated-file ownership.
+- focused tests for the changed behavior.
+- explicit infra-dependent tests when DB, Redis, MQ, or external services are required.
+
+## Plan Authoring
+
+- Plans should use exact file paths, commands, acceptance checks, and verification expectations.
+- Break implementation into bite-sized tasks that produce reviewable, testable progress.
+- Avoid placeholders such as TBD, TODO, "add appropriate validation", or "handle edge cases" without concrete cases.
+- Check that names, types, method signatures, and contract fields are consistent across tasks.
+- Naming known work as out of scope — a defect observed in passing, a debt or hardening item, or follow-up work — is visibility, not tracking: a landed plan is an archive, and "recorded so the next agent sees it" has no reader. Each such named item must carry a disposition that outlives the plan — an owner locator resolving to an item-specific durable entry that names the work and its accepting owner, and records that owner's acceptance (a tracker row, issue, status-document entry, an item-specific entry in the owning skill or gate, an existing successor slice that carries it as in-scope work, or, for an item already owned elsewhere, that owner's item-specific locator — never an ownership assertion, never a bare destination, and never an entry nobody accepted) or a terminal disposition (declined by the authority that owns the decision — cite that decision's durable record, with the reason; a bare authority name is not a decision, and the plan author alone cannot terminate known work). This invariant's closeout instance is the deferred-point rule in `implementation-completeness-and-minimality.md` and its review instance is the accepted-risk/deferred-items row in `code-review-checklist.md`; this bullet is its plan-authoring instance, where the naming happens first.
+- If work will be delegated to agents, route through `multi-agent-delegation`.
+
+Scale the plan to risk: a simple low-risk single-file change can use a short inline plan with concise acceptance checks; multi-file, user-visible, cross-skill, bug-fix, release, branch/MR, or unclear-risk work needs an explicit task split with acceptance checks, verification commands, and stop conditions before edits; larger work (multiple modules/skills, high blast-radius, or a durable process sample) additionally records a requirement summary, decision record, test plan, release plan, and known risks.
+
+Multi-step assessment-to-fix-to-test work always needs a reviewed plan, but it upgrades from a lightweight workflow plan to a formal external spec plan only when scale or risk justifies the extra artifact: the work spans multiple modules or skills, needs branch/worktree isolation, will be executed by subagents or delegated workers, is intended as a durable process sample, changes high-risk user/business or high-blast-radius technical outcomes, or has unclear scope that could expand during implementation. If not upgrading, record why a short inline plan is sufficient.
+
+For any multi-step request that combines assessment, fixes, and verification, the task plan must name the branch/worktree boundary, selected findings and the disposition of findings named but not selected, files to touch, design checkpoint if visible behavior changes, test strategy, test-case register, commands to run, rollback/stop conditions, and whether an external planning/TDD/debugging skill will supplement the CCL workflow.
+
+## Review Gate
+
+Review should lead with findings, not summaries. Classify issues by impact:
+
+- Critical: security, data integrity, broken contract, irreversible migration, release blocker.
+- Major: likely production bug, missing transaction/idempotency, broken permission, missing important test.
+- Minor: maintainability, small performance risk, incomplete edge case.
+- Info: optional cleanup.
+
+Do not approve critical issues without either a fix or an explicit product/engineering decision to defer with risk accepted.
+
+For independent AI reviews, require usable output before treating the review as evidence. If a broad review returns no output, appears continuation-like, or omits the requested finding structure, narrow the prompt to the diff, files, or risk class and rerun. Do not treat silence as approval. For long-running CLI reviews, poll before interrupting; around 30 seconds with no output is a wait-and-observe point, while around 60 seconds with no output is a stuck-review signal unless the process then returns concrete findings.
+
+For a concrete review checklist, use `code-review-checklist.md`.
+For incoming review feedback, use `review-reception.md`.
+
+## Completion Evidence Gate
+
+- After a high-risk slice, run a checkpoint before starting the next slice. Treat schema or migration, protobuf/OpenAPI/Pydantic or external contracts, platform runtime, auth or permission, cross-service behavior, KMS/secrets, observability, deployment, and other high-blast-radius architecture as high risk.
+- The checkpoint definition of done should stay short: review the diff, resolve blocking findings, update the nearest repo docs or harness when boundaries changed, rerun the relevant local gate, and commit before stacking another high-risk slice.
+- Do not make skill or memory updates mandatory for every slice. Update skills only when a reusable pattern has repeated enough to be durable; update memory only when explicitly asked or when the fact cannot be derived from repo docs.
+- Do not claim work is complete, fixed, passing, or ready without fresh verification evidence.
+- Identify the command or inspection that proves the claim, run it, read the output, and report the actual result.
+- A passing linter does not prove the build, test suite, migration, or user workflow passes.
+- Agent or subagent success reports are not evidence until their diff and verification output are checked.
+
+- Deep self-audit rule: never claim complete, fixed, or passing without fresh verification evidence from the current turn. Before that claim — and before handing the change to any third-party/independent review — run the deep self-audit as a **walked enumeration over the properties this delivery asserts**, not as a re-read: list every property the delivery states in prose (design doc, code comment, commit message, MR body, test name), and for each one name the killing mutation that would make it fail, per the `testing-strategy` assert-the-outcome rule. External review is the backstop for what the audit missed, never the substitute that makes it optional. (The executable/unverified discipline, the re-owe rule for review-fix code and outgoing claims, and the `interim` consequence for late commits are stated once in the execution-bounds paragraph below.)
+
+Deep self-audit execution bounds: apply it where it is executable; a mutation you only imagined is a hypothesis, not evidence — bound the killing mutation's blast radius — never disable an authorization, idempotency, or deletion guard and then exercise it against a shared or live dependency, where buying a RED can destroy real data or perform a real unauthorized action. Mutate against isolated dependencies or at the lowest layer that avoids them, and if neither is possible record the property `unverified`. For a property with no executable test — a design-doc claim, an MR-body assertion — name the concrete observation that would contradict it and where that observation lives, then go look — and where no executable check or contradicting observation exists, record the property `unverified` rather than counting it audited. Prove the check itself can fail before believing it: a lookup aimed at the wrong path, matched case-sensitively, scoped too narrowly, or swallowing a non-zero exit returns a confident clean that is indistinguishable from a true one, and it fails toward letting the claim through. Re-reading prose only confirms the prose is self-consistent; it cannot detect prose that disagrees with the code, so it never discharges this. The candidate is whatever exists right now: code produced while fixing review findings re-owes the enumeration, and so does the completion message or MR body you are about to emit. A completion message or MR body that introduces a claim absent from the diff ("all variants supported", "no regressions") is a new asserted property, even though no file changed; walk any new claim in it before sending, or do not write it — a delivery whose last commit landed after the final audit is `interim`, and reporting it as complete is a false completion claim regardless of how many external review rounds preceded it.
+
+Mechanical-gate degradation ladder: prefer a tracked verify script plus blocking CI / branch protection over an untracked local hook; any hook must call only tracked, non-destructive commands and is never the sole evidence; treat the prose norm as the fallback, not the primary control. When no CI / shared runner exists, the mechanical control degrades to a tracked verify script plus an *installed* pre-commit/pre-push hook — committed `hooks/` dir + a setup step that sets `core.hooksPath`, since that config is per-clone and must be installed, not just committed (see `agents-file-coverage-gate` for the worked bootstrap) — with the tracked script as the source of truth.
+
+## Release Gate
+
+Before release, confirm:
+
+- codegen, migrations, config, and deploy metadata are complete.
+- health/readiness, logs, metrics, traces, and alerts cover the changed path.
+- rollback or mitigation is defined.
+- data backfill, replay, or compatibility windows are planned when needed.
+- user-facing or integration-facing acceptance checks have evidence.
+- long-running jobs, uploads, imports, exports, downloads, AI generation, or other async work expose visible status, terminal success/failure, timeout behavior, retry or repair behavior, and persisted result or artifact pointers where relevant.
+- frontend shells, mobile app surfaces, and operational web workspaces have explicit handling for permission, empty, loading, partial, retryable error, unrecoverable error, cancellation, stale data, version/update notice, and responsive/keyboard or collapsed-sidebar behavior where relevant.
+
+## Automated Workflow Evidence
+
+- Automated verification should observe the system, not only exercise it. For UI flows, check visible state, console errors, network failures, and backend logs or traces at critical steps.
+- For backend-only flows, check response contract, trace/log id, persisted state, emitted events, dependency outcomes, and metrics/log signals where relevant.
+- Do not accept "automation passed" when the test only clicked through a path and ignored hidden errors.
+
+## Branching Strategy
+
+**Default：short-lived branch + trunk-based 倾向**。原则：
+
+- **Branch 寿命 < 1-2 天**（本团队启发；trunk-based 倡 daily integration）：超过要么拆 PR，要么开 feature flag 把未完功能合主干（隐藏在 flag 后）— 长寿 branch 会 merge conflict + 阻塞他人 + 测试集成态飘
+- **PR 越小越好**：本团队 sweet spot / split 阈值见 `code-review-checklist.md` Review Invocation 段（本地操作阈值，非外部固定规则）
+- **Trunk-based** 适用：CI 强、测试覆盖好、小团队 / 高频 release；本团队默认走这条
+- **GitFlow / 长寿 release branch / stabilization branch** 仅在 release / version management 需求**真大于** trunk-based CI/CD 收益时考虑：典型场景 — 并行维护多 prod 版本（SDK / 产品 LTS）、scheduled release cycle 含稳定化窗口、prod hotfix channel 与 next-version dev 并行、合规要求 release 隔离审计、外部交付物有版本承诺
+- Feature branch 形态保留作为"开发期协作隔离"工具但**不用作功能可见性 gate** — 那是 feature flag 的事
+
+## Delivery Health Metrics（DORA software delivery metrics）
+
+评估 engineering delivery health 时用 DORA 系列 metrics（起源于 Forsgren / Humble / Kim *Accelerate* 2018，**模型随年度 State of DevOps Report 演进**）作可量化共同词汇。当前 DORA 模型为 5 metric：
+
+| Metric | 定义 | 备注 |
+|---|---|---|
+| **Deployment Frequency** | 多久 deploy 一次 prod | — |
+| **Change Lead Time** | commit 到 prod 的时长 | — |
+| **Change Failure Rate (CFR)** | release 中需要 hotfix / rollback / fail forward 的比例 | — |
+| **Failed Deployment Recovery Time** | failed deployment 恢复时长 | 2023 年 DORA 重命名（原 MTTR）|
+| **Deployment Rework Rate** | release 后需要 rework 的比例 | 2024 年新增 |
+
+Elite / High / Medium / Low 具体阈值**按当年 DORA Annual State of DevOps Report 取**（不同年份数字略有变化，本 ref 不固定数字以免过时）。
+
+操作约束：
+- 提"加 CI step / 简化 release / 改 branching" 等建议**至少关联一个 delivery metric 或邻近 engineering outcome**（on-call 负担 / DX / 可靠性 / 安全 / 认知负载），并显式声明 tradeoff
+- 反对例：单纯说"我们的 CI 太慢" 不是 trigger；"lead time 当前 N 天目标 < 1 天，CI build 占 N% — 优化 build 缓存" 才是
+- 不把 metrics 当 KPI 凑（Goodhart's law）— 当观察轴，不当强制目标
+- Incident retro / 5-Why / blameless post-mortem 走 `problem-resolution-and-learning.md`（该文件覆盖 production symptoms / 5-Why / evidence capture / learning routing）
+- Keep live dependency, browser, or real-data checks separate from fast default tests, but require them for release-critical workflows when mocks cannot prove integration behavior.

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

@@ -0,0 +1,62 @@
+# Design Review Gate Mechanics
+
+Full mechanics for the technical design gate's recorded-review discipline in
+`SKILL.md` Workflow step 3 ("The technical design gate's review is recorded,
+not implied"). The sub-rules below form ONE gate, walked individually at
+their firing points. The entrypoint keeps the firing-point registry; this
+file is the authoritative full text. Load it whenever the technical design
+gate is triggered — before invoking the independent review, before merging
+a triggered diff, and whenever the candidate diff changes after a review.
+
+## Recorded review artifact
+
+(a) a recorded independent adversarial review is the gate for all triggered work — prefer an available review/challenge skill discovered in the session when suitable, otherwise a ccl-owned independent review (the external skill supplements, it is not itself the required gate); save an artifact naming concrete objections, their disposition, and the reviewer or tool identity; same-agent inline prose review is acceptable only for explicitly low-risk, non-cross-boundary work.
+
+## Binds to the implementation diff
+
+When this gate requires the independent review for triggered work, that review **binds to the implementation diff, not only the upstream design/decision**: the adversarial review/challenge must cover the actual code diff before it merges or pushes to a shared branch — green unit/conformance tests do NOT discharge it (tests prove the code does what it does, not that the behavior is correct, and a test written to assert the current behavior can lock in the very flaw the review should catch).
+
+## Bounded exception — verifiably mechanical move commits inside a mixed diff
+
+When the diff is dominated by pure code moves (file splits/renames at declaration boundaries with no semantic edit) so large that a full-diff adversarial pass is objectively infeasible (an actual full-pass attempt failed on time/context limits after normal remediation — chunking/splitting the review packet; a maintainer approval is a risk-owner waiver accepting the unreviewed remainder, recorded as such, never recorded as infeasibility evidence; self-labeling a diff "too big" is not enough), the review may scope to the substantive commits ONLY when all of:
+
+- (a) moves are isolated in their own commits, never mixed with behavior changes, and content-equivalence is verified — any moved declaration/hunk that is not identical to its origin is substantive and joins the full review (whitespace may be disregarded only on whitespace-insensitive surfaces; in indentation-sensitive files — Python, YAML, Makefiles — an indentation change IS a content change);
+- (b) deterministic behavior-preservation evidence is recorded AT the move-only commit(s) — the full suite run green checked out at that commit (a move commit that cannot build/run its suite independently does not qualify for the exception; that is not infeasibility evidence), plus an unchanged conformance/golden digest where one exists — AND the move hunks are checked to touch none of the move-sensitive surfaces (including but not limited to: build-tag lines, file-name-suffix semantics, path-based discovery/registration, init/registration-order code, import-visibility changes, generated-code or embed/link directives; any hit sends that commit back to full review); `git diff --color-moved` is a supplementary visual aid, never sufficient alone;
+- (c) the net non-move diff of the final candidate gets the full adversarial pass — combined, not only per-commit slices, so cross-commit interactions are seen;
+- (d) the scoping decision and its evidence are recorded in the review row bound to the final candidate head SHA — rewriting the candidate after the evidence (rebase/amend/new commits) invalidates the scoping and re-derives it, while a platform merge-time squash that preserves the reviewed tree does not.
+
+A "mechanical"/"refactor-only" label in a commit message is a claim, not evidence; missing any condition, the full-diff binding applies.
+
+## Mechanism-operability check
+
+- **Mechanism-operability check — required whenever the design proposes new mechanical enforcement or verification machinery** (a CI/merge gate, pre-commit hook, schema/signature/checksum validator, evidence or attestation apparatus, migration guard), **and again whenever a landing withdraws or downgrades the evidentiary claim an existing mechanism rests on**: the design must record (a) **author dogfood, scaled to the machinery's statefulness** — for base-relative, stateful, or evidence-regenerating machinery, the intended day-to-day workflow (multi-commit development, a rebase, one routine follow-up change) passes it end-to-end under the same resolution CI will use, before it lands; a trivial stateless check needs only a proportional smoke run; (b) **marginal cost** — what the cheapest routine change costs under it (regenerate/rerun/recompute burden), and that this cost does not defeat normal iteration; (c) **trust-model fit** — what it defends against under the declared trust model; machinery that only defends against adversaries the trust model already excludes (e.g. content digests the author can freely regenerate) is redundant detection at full complexity cost — choose the lighter mechanism that keeps the enforceable core. A mechanism failing this check is redesigned or lightened at design time, not hardened round-by-round after review findings. **Claim liveness — the second firing point, whose actor is whoever kills the claim, not the mechanism's author.** A mechanism's justification is the evidentiary claim it enforces, so when a landing withdraws that claim, restates it as unmeasured, or narrows it below what the mechanism enforces, every mechanism predicated on it is **re-based onto a claim that still holds, or retired, in that same landing** — enumerated from the claim's own record and from what actually invokes the mechanism, never from memory. Leaving it running is not the conservative default: it charges every later change for evidence that no longer proves anything, while the record keeps asserting the withdrawn claim in the present tense. Neither path is a free edit — re-basing rewrites the enforcement surface just as retiring removes it, so **both owe the same walk**, and a re-base additionally has to show that no component still enforces the withdrawn claim, or the tax has only moved rather than gone. The obligations it carried that never depended on the dead claim do not die with it, so walk them (`skill-extraction-workflow/references/rule-consolidation.md`'s obligation-preservation table is that walk) and disposition each as surviving elsewhere, dying with the claim, or a real loss accepted and recorded as accepted. **That last disposition is not self-serviceable, and it deliberately carries no class list to narrow.** Reaching it already means a real control is being abandoned, so it binds whatever that control protects: the give-up routes through `feature-risk-router`, and the mechanism keeps enforcing — retained or re-based — until a **named accountable risk owner** has accepted the loss. An agent writing "accepted" about its own landing is not an acceptance, and a claim's death is not a licence to retire a control that never rested on that claim. The benign case has its own disposition and does not need an exemption here: an obligation that existed only to serve the dead claim takes `dying with the claim`. That split is why enumerating protected risk classes would be the wrong shape — every such list is one unlisted class away from letting a real control out. When the same landing genuinely cannot carry the disposition, the claim's own record — not the mechanism — carries the pending retirement, and that `pending` is an **accepted risk with an end, not a note**: the named accountable risk owner accepts the deferral itself, the record states the per-change cost being paid meanwhile and the event that ends it — at the latest, **the first landing that pays the cost**, meaning the next one that invokes or modifies the mechanism, since a bound tied only to editing it never arrives when nobody edits it and the tax is paid by everyone it runs against — and arriving at that event without the disposition escalates through `feature-risk-router` instead of renewing quietly. A `pending` that names no owner, no cost, or no end is how a dead claim keeps collecting rent indefinitely, which is the tax this firing point exists to stop; an unbounded deferral is the failure wearing the fix's clothes. (The shared-skill-gate instantiation of this rule lives in `skill-extraction-workflow`'s remove-the-capability Core Rule.)
+
+## Cross-cutting shared-runtime primitives
+
+A change to a cross-cutting primitive that shares a runtime — interceptor/middleware chains, logging/metrics/recovery adapters, context/identity propagation, global/env wiring — is a high-hidden-edge class: its happy path passes while edge paths (propagation, caller overrides, nil/empty inputs, optional-dependency failure, request-shape asymmetry) fail silently, so budget an explicit adversarial pass over those edge paths and add a regression test per path found before treating it done.
+
+## Implementer self-review row (before the independent review)
+
+Before invoking that independent review/challenge, persist an implementer self-review row in a revision-tracked record whose history is retrievable that will carry the independent-review result — a commit on the working branch, or a platform artifact with retained revision history; **when this change's own gate requires the independent review before the landing commit (e.g. a shared-skill change under the dual-track gate), the ordering-proof record must be a non-landing revision-tracked artifact, not the landing commit, so this rule never forces a premature landing commit** — the row carries: acceptance criteria rechecked, changed files/scope matched to the active artifact, edge/failure paths considered, a named regression test that fails before the change and passes after (or the recorded reason none is feasible), deterministic gates already run with what each proves, and known residual risks.
+
+Ordering must be provable from that history, not merely asserted: the row must predate the review/challenge run in an immutable or revision-tracked record, and a plain MR/PR description or any in-place-editable field is NOT acceptable ordering proof unless its edit history is retrievable AND was actually checked to confirm the row preceded the review; if the row is added only after review/challenge, that review is invalid for the gate and must be rerun after the row exists. The row is conclusive only when each required field is non-empty and non-placeholder, and the changed-file scope equals the candidate diff's changed-file set or explicitly explains any excluded generated/irrelevant file; otherwise it is inconclusive.
+
+## Changed candidate = refreshed row + fresh full-scope rerun
+
+If the candidate diff changes after the row is saved — a file added or removed, OR the content of any listed file materially changed (not just whitespace/typo) — refresh the row and rerun the independent review/challenge against the new candidate; a stale row does not cover files or rule text it never reviewed. When that changed candidate is a remediation of prior review/challenge findings, the rerun is a fresh full-scope pass over the new candidate, not a scoped confirm-my-fix check — the trigger is the changed candidate diff itself (mechanical), never the author's framing, the author cannot narrow the rerun's scope by describing which findings were fixed, and a "whitespace/typo-only, no rerun needed" classification of a post-review change is not the author's to make alone — it needs diff-based deterministic evidence or an independent reviewer's confirmation: author over-optimism about their own fix is an observed failure mode — especially on high-risk paths (money, concurrency, identity, write-finality), where a second independent round repeatedly catches first-round remediation that is still insufficient and forces a changed approach.
+
+## Independent gate surfacing basics = process defect
+
+If review/challenge is the first place basic scope, contract, privacy, or test issues are discovered, treat it as a process defect and repair the self-review/deterministic-gate loop before rerunning the independent gate; the discovered findings still require disposition under the dual-track gate (fix, or a documented accept/defer/out-of-scope), not waived or downgraded by the process-defect framing.
+
+## Green-tests-alone merge is the same defect
+
+Merging triggered-work implementation on green-tests-alone, with the adversarial review applied only to the upstream decision, or with no checkable implementer self-review row before the diff review, is the same process defect as reaching implementation with only spec plus plan.
+
+## Human/team sign-off
+
+(b) human/team sign-off before implementation, merge, or launch for high-risk money/permission/data paths and for any contract/API change with an external consumer (reviewed interface diff plus compatibility decision); read-only investigation or an isolated disposable prototype that will not be merged, reused, or launched is exempt, and promoting such work to implementation reruns this gate.
+
+## Floor
+
+Reaching implementation with only spec plus plan on triggered work is a process defect, not a shortcut.

package/dist/assets/marketplace/plugins/ccl-skills/skills/product-rd-workflow/references/design-routing-and-readiness.md

@@ -0,0 +1,45 @@
+# Design Routing And Readiness
+
+Use this reference when product work has a user-facing surface, interaction flow, information architecture, visual system impact, or design-system dependency.
+
+## When Design Is Required Before Implementation
+
+- New screen, navigation path, onboarding, creation flow, dashboard, settings surface, or mobile/web interaction pattern.
+- Existing workflow changes that affect user decision-making, empty/loading/error states, permissions, accessibility, or visual hierarchy.
+- Product copy, information architecture, component semantics, or design-system tokens/components are ambiguous.
+- The implementation could lock in a hard-to-change layout, data model presentation, or interaction contract.
+- The product needs a launch/readiness check for UI completeness, visual quality, or interaction polish.
+
+Small backend-only, CLI-only, config-only, or internal refactor tasks can skip design if user-facing behavior and acceptance are already clear.
+
+## Routing
+
+- Use `product-ui-ux-design` for product UI/UX design readiness across community, finance/data, AI workspaces, operational tools, Web, and App surfaces.
+- Use scenario references inside that skill only when the target surface matches; community/feed/creator patterns are optional lenses, not the default model for every product.
+- Use Figma/design plugin skills when the task explicitly requires Figma file creation, design-system rules, component mapping, or design-to-code implementation.
+- Use UI/design review skills for visual QA, accessibility criteria, interaction polish, and launch-readiness review.
+- Keep product-rd-workflow responsible for sequencing, acceptance, and handoff evidence; do not duplicate detailed design-system rules here.
+
+## Design Readiness Evidence
+
+Before implementation, capture only the evidence proportional to risk:
+
+- target user/caller and primary workflow;
+- approved interaction model or wireflow for new/changed surfaces;
+- key states: empty, loading, error, success, permission denied, disabled, offline/timeout where relevant;
+- responsive/mobile expectations and accessibility constraints;
+- component/design-system reuse decisions and any intentional deviations;
+- for a visible-UI design checkpoint, also record: surface type, density mode, layout structure, trust/safety boundary, and visual acceptance criteria;
+- acceptance checks that engineering and QA can verify;
+- **cross-platform brand decisions when the same product surfaces on multiple stacks**: if the product intentionally renders different brand-primary values per platform (web vs native mobile vs mini-program), the product owner MUST record the decision explicitly — which value applies to which platform, why, and which named role in the design source carries each value (`colorPrimary-web` / `colorPrimary-native` / per-platform variable collection). Implicit "we just always used this color on Android" is the failure mode that downstream design + engineering audits keep re-discovering as drift. If the product owner decides the values should converge, that is also recorded with an owner and a target date. See `product-ui-ux-design/references/multi-project-token-consistency.md` Cross-platform brand divergence sub-case for the design-side check.
+
+For dense web shells, app shells, creator workspaces, or AI/task-heavy surfaces, also capture navigation state ownership, permission-gated actions, active task/process visibility, long-label overflow behavior, global feedback placement, and how users return to their previous context after a modal, drawer, upload, generation, or detail view.
+
+For mobile surfaces, also capture safe-area behavior, keyboard avoidance, bottom navigation or sticky action behavior, update/consent dialogs, and whether errors appear inline, as toast, as a result page, or as a blocking dialog.
+
+## Handoff Rules
+
+- Do not treat a vague mock, screenshot, or verbal idea as implementation-ready when states, copy, permissions, or responsive behavior are missing.
+- Do not require full design artifacts for tiny copy/state tweaks when acceptance checks are enough.
+- If design and architecture conflict, resolve sequence explicitly: user workflow and IA first, then service/API/data contracts that support it.
+- If design feedback reveals reusable rules, update the smallest correct design skill/reference rather than this workflow unless the lesson is about sequencing or handoff.

package/dist/assets/marketplace/plugins/ccl-skills/skills/product-rd-workflow/references/diagnostic-spec-match-gate.md

@@ -0,0 +1,36 @@
+# Diagnostic Spec-Match Gate
+
+Use this reference before any current-state/spec-match judgment or change recommendation when the request combines:
+
+- A diagnostic verb, such as 检查, 评估, 审视, 是否满足, 对不对, check, evaluate, does this match, is this correct, or audit.
+- A spec-match semantic, such as 是否满足, 对齐, 符合, 按需求, 当前逻辑是否, matches the requirement, or per the spec.
+
+Standalone "看看 / look at this" without spec-match wording is ordinary code reading, not this gate.
+
+## Required Checks
+
+1. **Identify the evaluation baseline source** — ask explicitly "对应的产品文档 / PRD / wiki / issue 在哪里？" unless one of these applies:
+   - The user already provided the link in this message.
+   - The user explicitly said "没有文档 / 我临时定的".
+   - The request is pure technical refactor with no business rule semantics.
+   - The user explicitly directed "按我这句话做 / 不要查外部文档".
+
+   When using the user's statement as the baseline, record it as `user-provided baseline` with a one-line risk note.
+
+2. **Numeric threshold dimension check** — when the diagnostic mentions a numeric threshold such as N items, X%, or Y seconds, verify the business-entity dimension it binds to in the authoritative source. Similar-looking thresholds can bind to different entities, such as result-count, input-count, or display-count. Compare against any existing same-named constant in code before assuming reuse.
+
+3. **Reverse-trace intentional-design signals** — when code comments, test descriptions, or variable naming carry product-domain semantics such as domain fallback, carry-forward fallback, or domain-specific thresholds, reverse-trace to the authoritative spec before treating them as implementation complexity. Do not delete or simplify such signals until traced, or until explicitly marked unverified with the user.
+
+4. **Option neutrality when proposing changes** — label a "Recommended" option only when tied to a named baseline, risk, or cost. Do not rank options by the agent's own simplicity bias when one alternative aligns with the authoritative spec.
+
+## Failure Shape Prevented
+
+This gate prevents an agent from reading code, comparing it against the user's single-utterance description, silently substituting one business-entity dimension for another, deleting a spec-mandated fallback as "implementation complexity", presenting an option matrix where the spec-aligned choice is labeled the most complex, and shipping a regression that contradicts the authoritative product spec.
+
+## Closeout Evidence
+
+Record the baseline source in working notes before the diff lands:
+
+- `link`
+- `user-provided baseline`
+- `none-confirmed`