product-rd-workflow

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). Use proposed-next: <action and scope> to make a next action observable, or proposed-next: none — status only for a status-only handoff. A missing, repeated, or conflicting marker triggers intent recovery, not a stop. Follow the current explicit user request; bind short assent to one recoverable concrete proposal and its scope. Repair your own formatting without asking the user to repeat an already-clear instruction. Markers never grant authority. Recovery, ambiguity, and outcome rules: 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 owner-load: not-required 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 skill-extraction-workflow'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.