product-rd-workflow

name	product-rd-workflow
description	加功能 / 新需求 / 技术方案 / 方案评估 / 技术选型 / 可行性评估 / 工作量评估 / 多阶段重构 / 推倒重来 / 重新开发 / 完全重新开始 / 清除代码重新开发 / redo-from-scratch / 项目分析 / spec·PRD·需求文档实质内容写错要改对（substance 修正） / 方案评审通过开始实现 / 进入实现阶段 → end-to-end product R&D router for requirement shaping, spec/plan, implementation gates, assessment, redo/refactor, and multi-stack standards.

Product R&D Workflow

Use this skill as the top-level workflow for new product development, feature delivery, bug handling, refactoring, release preparation, or repeated process improvement. It is not a replacement for stack-specific skills; it decides which skill should own each stage and what evidence is required before moving on.

Entry precedence. For any product idea, feature delivery, release, cross-cutting refactor, or a restart/redo of an in-flight delivery, invoke this workflow first to classify and route — naming a stack/execution skill (e.g. web-react-dev, multi-agent-delegation) does not by itself skip this workflow's lifecycle gates (design / test / release / acceptance); those still apply unless already covered.

Continuation-proposal output contract (session-wide for product delivery). Every assistant message in a delivery session routed by or through this workflow carries exactly one literal line until the user explicitly ends/pauses the delivery or changes scope: proposed-next: <action and scope> when the message has imperative/future/next-step wording or a proposed action, otherwise proposed-next: none — status only. At the start of every subsequent user turn, read that line before interpreting the reply: absence, multiplicity, or a marker/wording conflict enters blocked:/interim by default, never not-applicable. Coverage detail and the host-layer caveat: references/pre-final-continuation-gate.md (Continuation-proposal output contract).

• Restart/redo of an in-flight delivery (清除代码重新开发 / 完全重新开始 / 推倒重来 / redo-from-scratch): a restart is a fresh delivery entry; mid-delivery coding momentum is NOT a license to skip re-classification and re-enter. Re-entry means re-ESTABLISH the plan and develop against it, not code from memory — "丢脚手架 / 重来" defaults to discarding CODE, not the design/spec artifact; discarding the design/spec itself needs an explicit user opt-out after clarification (an explicit instruction to drop the design always wins). Recovery mechanics and deviation recording live in references/implementation-entry-reentry-gate.md §Baseline Selection.
• Implementation entry / re-entry gate (active plan/spec required by default). For product R&D deliveries that stay in this workflow, "start development" means first establish the current executable artifact set, then code against it; requests routed straight to another owning skill by the Go straight to the owning skill bullet below use that owner's entry rules instead. Use existing specs, implementation plans, assessment reports, issue/MR descriptions, or repo-local task docs only after reading them back or citing artifacts just produced in the active session, then checking freshness, scope, owner skills, acceptance checks, tests, stop conditions, and landing state (local status, MR-ready, landed, release-ready, or shared-status-ready). Full mechanics for every case below live in references/implementation-entry-reentry-gate.md.
  • Baseline authority: only an unmerged plan/spec on the current active delivery branch is the working baseline; anything else needs explicit recorded user selection plus reconciliation against landing evidence, deriving only still-unlanded deltas (§Baseline Selection).
  • A bare "continue"/"resume"/"go implement" is not a waiver: context summaries, compacted memory, and previous-response residue are not establishment (§Bare Continuation Scan); routing to a stack/execution skill selects the executor, not permission to implement — the first implementation edit is the gate.
  • Before that edit, record the implementation boundary: active baseline, scope, implementation-mechanics owner named and — for hands-on product/stack code — invoked/loaded in-session before the first edit, multi-agent-delegation decision when delegation is plausible, the applicable visible-UI full or lightweight record + Phase 0 with in-session product-ui-ux-design load, a feature-risk-router inventory, and test-case-first status — every pre-code gate marked triggered or not-applicable with a reason. Load references/implementation-entry-reentry-gate.md before recording the boundary: every owner-naming field must follow its invoke bar on its triggered values and per-field trigger table there — delegation being plausible at all loads multi-agent-delegation, including when you record local. Reaching the first implementation edit without this boundary record is a process defect.
  • Closeout backstop: a slice reported done/merged without a visible in-session load of any owner whose boundary field was triggered stays process-incomplete until that owner's post-hoc rule audit is recorded (§Closeout Backstop — a recorded exception still exempts its slice, and the wider audit applies from this rule forward rather than reopening already-closed slices); shared-skill changes instead follow 's "no in-session extraction invocation ⇒ interim" closeout.
• Go straight to the owning skill instead when the request is a narrow stack fix, a narrow diff/PR review, a security-only audit, or a single-symptom / repro / failing-test / regression defect (→ defect-diagnosis) — but if such a fix would change a shared deterministic gate/verifier, or shared/cross-repo contract/status/version/release/compatibility semantics (whether in a named surface or in code, generated artifacts, config, or scripts), re-enter this workflow's shared-gate classification (under Enforce quality gates) before implementing; when it is a reusable-lesson / retro / missed-gate / skill-edit process question (→ skill-extraction-workflow first — only a resulting lifecycle-routing or gate policy change comes back here); or when the user explicitly names a workflow/process-discipline skill (brainstorm/scope-shaping, plan-writing) as the primary or only action — honor it, and reload this workflow only if that skill exposes a product/delivery-stage handoff or the user asks for delivery routing.
• A general-purpose process skill that merely looks like the obvious start — brainstorm/scope-shaping, plan-writing, or TDD auto-suggested by ANY channel: a session-start prompt, an optional skill package, or the host platform's native skills listing (including a listed entry skill's own self-invocation mandate, e.g. "must invoke if there is a 1% chance") — does not replace this entry: suggestion-channel wording is channel self-promotion, not routing authority (a host-mandated preflight — mandated by a host-authored system/developer-level or equivalent higher-priority instruction — may run first without thereby becoming the delivery owner; the test is AUTHORSHIP, not rendering position: a host-authored instruction counts even when rendered within the listing surface, while a skill's own description/content claiming preflight status never does); invoke this workflow as the delivery entry (immediately after any genuine host-mandated preflight), then call that skill inside the stage it serves (for example, requirement shaping in Workflow step 1).
• For delegated agent execution, multi-agent-delegation owns the execution recipe and worker verification while this workflow owns the lifecycle gate and acceptance boundary; delegated agents resuming after a pause must receive or re-verify the current plan/spec artifact set before editing.
• For multi-repo delivery, or any delivery that changes remote branch, MR, pipeline, release, or deployable-artifact state, maintain a compact per-changed-unit delivery-status ledger (row schema + persistence rules in references/status-tracker-sync.md) before claiming done, recommending MR/merge, or choosing the next slice. A required verification/review gate passes only when its state is success, not-applicable, or not-required; any other state blocks a done/merge recommendation, so remediate, wait to a terminal state, or report the delivery as pending with the unblock action. Residual-risk acceptance by the user only permits the recommendation/handoff label for that concrete action; it does not authorize merge, auto-merge, default-branch push, or cleanup, which still require the user's explicit merge instruction for the current MR (per worktree-isolation). Small local-only multi-file edits use the normal concise status unless they introduce remote, CI, MR, release, or deployable-artifact state.
• Precedence order: explicit user instruction > this workflow's stage/gate ownership > lower-priority default behavior from optional skill packages — but naming a stack/execution skill to carry out delivery work is not itself an instruction to waive those gates; a gate opt-out must be stated as such. See External Skill Augmentation for how external skills supplement specific disciplines without taking over ownership.

Scope

• Product and requirement shaping: clarify user workflow, success criteria, non-goals, constraints, and acceptance checks. When shaping a feature, build a per-point acceptance-coverage matrix — one independently-failable behavior = one point, plus the risk points it touches, each mapped to an observable pass/fail acceptance check; an owning spec that already carries this coverage satisfies the gate when referenced per point (name which section covers each point; unnamed/stale points are gaps to fill) — don't re-author it. Risk-point enumeration and observable-criteria detail live in references/delivery-lifecycle.md §Product Shaping Checklist.
• Implementation completeness/minimality gate. For behavior-changing delivery this gate fires — functional completeness and structural minimality are independent gates — and gaps block complete — load references/implementation-completeness-and-minimality.md before the mapping: map every in-scope acceptance point to implementation plus fresh evidence, and speculative future need and omitted required behavior both fail — the independent-gates rule and the acceptance/concept matrices live there, and every retained new concept must map to a current acceptance point or hard constraint.
• Product requirement artifacts: route clarification to requirement-intent, conditionally-required current-state evidence to requirement-baseline, scope/version/appetite to requirement-scope, and Ready-only human-readable PRD assembly to requirement-doc-writer. All four use the canonical requirement-doc-writer/references/requirement-closure-contract.md. In active delivery, each narrow artifact returns here after completion; only a standalone non-PRD narrow artifact may return directly to the user. “只写个 PRD / 不走流程”仍需 lifecycle-issued Ready；WIP/会议材料不得命名为 PRD. This workflow owns the complete lifecycle's PRD Ready / PRD Not Ready verdict and cross-owner closure coordination.
• Design routing: decide when interaction, information architecture, visual system, design-system, or UX acceptance work must happen before implementation.
• Architecture routing: decide when architecture work is needed before implementation.
• Development routing: invoke stack-specific skills for implementation details, such as app-cross-platform-dev for Flutter/Android/iOS apps, miniapp-product-dev for WeChat/Alipay/Douyin/Baidu mini-programs, web-react-dev for React web, terminal-cli-dev for terminal/TUI product surfaces and CLI interface design (the rendered interface — layout, input, ANSI, scrollback — plus the command/subcommand/flag/help contract, which it owns even when nothing is rendered); CLI/tooling implementation without terminal-UI concerns must go to that language's dev skill when one owns it (, ) and must not fall back to merely because the deliverable is a command; a CLI in a language with no such dev owner stays with as the default CLI owner, / for Go services, and / for Python services.

Generalization Discipline

• Keep only reusable product-development mechanics: requirement shape, ownership boundaries, skill routing, quality gates, evidence, and learning feedback.
• Do not copy project nouns, repository paths, service names, provider names, IDs, UI themes, or domain-specific cases into this skill.
• When mining an existing product or repository for a new product/team, separate each observation into mechanism, business/domain noun, and source-quality/age. Keep mechanisms, strip or anonymize business nouns, and discard or downgrade obsolete/weak technology before it reaches executable guidance.
• For generic SOP/process docs, write abstract gates and acceptance logic. Put concrete code paths, real chain evidence, dataset rows, and module-by-module proof in project launch materials, evaluation reports, or appendices. Verify the real product chain before naming modules, but do not paste evidence tables into the generic SOP body unless the document is explicitly an audit/report.
• For cross-skill extraction, conflict resolution, or generalized lesson placement, route through skill-extraction-workflow instead of restating extraction doctrine here.
• Preserve product-delivery precedence locally: root-cause real defects before workarounds, define acceptance checks before broad implementation, and prefer deterministic verification over manual inspection alone.

Workflow

At each stage boundary, walk the per-stage entry-state enumeration in Stage-Entry State Checklist — confirm every required state already exists before crossing into the next stage; it points to the owning gate for each criterion rather than restating it.

1. Classify the work.

   • Diagnostic spec-match baseline gate (before any current-state/spec-match judgment or change recommendation): when a request combines a diagnostic verb with a spec-match semantic, do NOT treat the user's single-utterance description as the authoritative spec — identify the evaluation baseline source first, and record it before the diff lands. Details live in references/diagnostic-spec-match-gate.md.
   • Product idea or feature: start with product intent, user workflow, acceptance checks, rollout constraints, and, for user-facing surfaces, an approved design or proportional design/acceptance shape before implementation.
   • Narrow product requirement artifacts follow the canonical route in Scope. Before Ready, reconcile the per-point behavior/acceptance inventory from product shaping against the closure table: every behavior has a requirement_id or a legitimate human decision marks it out / deferred; a missing row is a blocker, not proof of exclusion. Issue Ready with product, version, scope, closure_table_revision, behavior_inventory_revision, and issued_at; any bound input change invalidates it and requires re-evaluation. Active-delivery results return here; only standalone non-PRD narrow artifacts may return directly.
   • Existing project/codebase assessment: separate understanding from judgment. Use codebase understanding to map structure, entry points, flows, and constraints, then assess architecture, implementation, tests, UI/UX, bug/risk, release, and observability through the owning skills below. The evidence bar findings must clear — citation, confidence label, and the promote-from-docs / build-only-check bans — is one rule, owned by the Existing Project Assessment section; do not restate it here.
   • Combined preparation plus assessment: if the user first asks for setup, cleanup, reset, dependency install, checkout, or branch/worktree preparation and then asks to analyze/review/reassess the project, perform the preparation with the relevant safety/tooling skill, but classify the assessment portion here before loading stack-specific skills. Do not let the preparatory action hide the broad project-review trigger.
   • Quality remediation program / engineering-quality baseline: when the request is a cross-cutting, multi-phase engineering-quality initiative (质量专项 / planned tech-debt paydown / "整体架构-实现-质量偏差怎么治理"), or to establish and hold an engineering-quality baseline on an existing project as ongoing practice, load references/quality-remediation-program.md — it owns the program shape, campaign vs continuous-baseline modes, phase ownership, and per-phase exit gates; do not start refactoring before the Phase 0/1/2 exit gates pass.

Pre-Final Continuation Gate

Run this gate before finalizing a product R&D turn after any delivery slice lands. The session-wide continuation-proposal output contract above creates a second, independent trigger at the start of every subsequent user turn in that delivery session when either (a) the immediately preceding assistant message carries an action-form proposed-next: and the user replies, (b) its marker is absent/multiple or none conflicts with imperative/future/next-step wording, or (c) a user reply reads as affirmative/permissive toward an explicit assistant-proposed next action. Paths (a) and (b) are unconditional literal/fail-closed checks. Before any further action or final response, visibly emit exactly one of continuing: <action and scope> or blocked: <proposed action and scope> — <specific stop, missing authority, or ambiguity>; emitting neither or both is invalid. Path-(c) examples and the full outcome contract: references/pre-final-continuation-gate.md (Gate triggers and outcome contract).

1. Confirm the landing state from real evidence (local branch, remote sync, MR/review artifact, CI/pipeline when applicable, review/challenge status when required, status-doc sync, dirty worktree), proving the landing before reading any document (for the remote-backed default, fetch/update the target ref from its remote immediately before classifying the slice landed) per references/pre-final-continuation-gate.md (Landing-state proof); content/tree/patch equivalence never by itself proves a slice landed.
2. Inspect the current product/status source of truth, issue list, repo-local next-step artifact, unresolved acceptance item, or direct user continuation instruction for the next implied slice. Reconcile it against the current branch/MR/merge/CI/tag state from step 1 before deriving: contradicting reality means stale — stop, repair the status source first, and do NOT derive from the stale source or a git-log/grep scan (references/pre-final-continuation-gate.md §Status-source reconciliation).
   • Deferred-evidence continuation check (DFE-CONT). When real/runtime evidence is due (named by an acceptance item, status source, landing-evidence row, required gate, user correction, or because it is the behavior's only meaningful proof) yet deferred, blocked after remediation, skipped at finalization, or replaced by local/mock verification. Report deferred real evidence as interim/outstanding; do NOT report the turn complete while it is outstanding. A local/mock substitution is terminal only when a cited non-agent anchor — agent-authored or agent-co-edited status/router/gate/handoff text never satisfies this — names the same evidence, declares the deferral terminal, and carries the outstanding command/source forward for the active slice/ref. Never add verifier/config/test hardening motivated only by missing deferred evidence; never auto-continue past the pending gate. Load references/pre-final-continuation-gate.md before treating any deferral as terminal — it owns the valid/invalid-anchor list and hardening boundary.
   • Affirmative-assent binding rule lives in references/pre-final-continuation-gate.md §Assent binding — load it before selecting continuing: on any assent, and any concrete next-slice proposal you issue must itself carry the proposed-next: marker or a later assent cannot bind — an unmarked referent is ambiguous, never self-cleared; the rule fires only when the immediately preceding assistant message itself states one concrete next action and its scope, and continuing: binds to that proposal, never to adjacent status or response-format prose; ambiguous assent, referent, or authority ⇒ with step-4 precedence — restate the proposed action/scope plus the specific ambiguity/authority, cite the step-1 evidence and ask one concise question in the same turn; self-classifying the reply or marker away is never an exit, and the default applies only when assent is unambiguous and no step-4 condition holds (the full rule and its fallback are stated there); the visible / outcome obligation is unchanged.

If a user later challenges "why did you stop" or "was the rule too weak", treat it as a product workflow defect: route through skill-extraction-workflow, strengthen the smallest owning skill or validation checklist, validate the diff, and only then claim the process issue is solved.

External Skill Augmentation

CCL skills remain primary owners of every stage and every gate. Installed external skills may supplement a narrow lifecycle discipline, but they never replace CCL ownership, never become required gates, and never block delivery when absent; discover them from the current session's available-skills list and map each to a narrow role before use. Operational detail: references/external-skill-augmentation.md.

Existing Project Assessment

For broad prompts such as "分析项目", "重新分析项目", "分析本项目", "重新分析本项目", "分析本项目，看有哪些做得好的，做得不好的，比如架构、实现、bug", "废弃本地修改后重新分析项目", or "review this repository/codebase", preserve this workflow as the top-level owner even when preparatory safety/setup work runs first. A detected stack skill owns one row of the assessment matrix; product-rd owns the whole matrix.

• Before deep code reading, fix execution, test claims, or complete conclusions, create the assessment launch checklist (product/user paths, architecture/implementation owners, test-layer matrix owner, UI/UX surfaces, runtime/host evidence surface, unavailable/live/manual boundaries, extraction/learning trigger); without it the work is interim exploration, not a complete assessment.
• Ground the evidence boundary before any per-repo gate or absence claim (repo topology, committed-vs-working-tree state, unread/unrun evidence, dirty-tree state) per references/existing-project-assessment-report.md.
• Findings must be evidence-backed and confidence-labeled: cite file paths, commands, and observed outputs; do not promote "docs say" to "code does"; do not let build-only checks replace assertion tests, rendered client evidence, or platform/device checks; visible product surfaces need a UI/UX row; high-consequence auth/account/permission/payment flows need a scenario matrix; reusable routing misses or process defects route through skill-extraction-workflow.
• A verified same-org peer exemplar is calibration input, not authority; split structural and semantic conformance into separate rows — structural presence does not prove semantic parity (calibration detail in the same reference).
• An assessment report is not permission to patch every finding: convert selected next actions into an accepted plan/checkpoint before edits, keeping quick fixes, structural refactors, test/verification debt, product/design follow-ups, release/ops follow-ups, issue/risk registration, and reusable-process disposition separate.

Feature Deprecation

When a feature is sunset, downscoped, or replaced (需求变更导致功能下线、迭代废弃旧能力、产品方向收敛), treat it as a multi-skill delivery slice, not a one-line status change. Load references/feature-deprecation-cascade.md before any TC/test/code deletion or complete label. Coordinate its 7-step cascade in order — (1) confirm scope and source of truth, (2) TC layer (test-artifact-management), (3) test-code cascade (testing-strategy), (4) code removal (owning stack dev skill), (5) operational follow-through, (6) orphan detection, (7) status sync — and never delete on inline summary alone: a test or business symbol is deleted only when the underlying code is removed or has no other product callers. A deprecation slice is complete only when steps 2–7 each have evidence; a missing step is a release defect, not a follow-up.

Reference Loading

• Evidence, lifecycle, and assessment references: references/source-evidence-map.md, references/delivery-lifecycle.md, references/algorithm-launch-templates.md, references/existing-project-assessment-report.md, references/external-skill-augmentation.md.
• Completion, status, isolation, and high-risk gates: references/pre-final-continuation-gate.md, references/status-tracker-sync.md, references/implementation-entry-reentry-gate.md, references/worktree-mechanics.md, references/high-risk-resilience-gates.md.
• Contract-sync mechanics: references/sync-spec-repo-contract.md (repo-local contract sync, upstream-authority value-set handling, upstream-silence claims).
• Developer-experience acceptance: references/verify-developer-experience.md (measured onboarding journey, error-message acceptance, fail-closed safety defaults, per-surface routing).
• Owner-dispatch discipline: references/dispatch-owner-skills.md (design-time complete owner set, firing-gate mechanics, opt-in mechanical enforcement).
• Deprecation and shared-gate references: load references/feature-deprecation-cascade.md before any TC/test/code deletion or complete label; load references/shared-gate-artifact-classification.md for product/spec normalization, standards-to-health-gate work, shared deterministic gate/verifier changes, or cross-repo contract/status/version/release/compatibility coordination-surface semantics changes.
• Design, quality, review, and decision records: references/design-routing-and-readiness.md, references/refactoring-discipline.md, references/quality-remediation-program.md, references/code-review-checklist.md, references/review-reception.md, references/adr-convention.md, references/quality-attributes.md; load references/design-review-gate-mechanics.md whenever the technical design gate is triggered (full recorded-review discipline, self-review row, mechanical-move exception, rerun rules).
• Behavior-changing implementation — and any implementation claiming the refactor/mechanical exemption, since the exemption is classified at entry: load references/implementation-completeness-and-minimality.md before implementation and again before a completion claim; it owns the acceptance-to-evidence and concept-to-current-need closure tables.