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 or 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: 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, a visible-UI design checkpoint 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 or 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 or 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 (go-microservice-dev, python-service-dev) and must not fall back to terminal-cli-dev merely because the deliverable is a command; a CLI in a language with no such dev owner stays with terminal-cli-dev as the default CLI owner, go-microservice-architecture/go-microservice-dev for Go services, and python-service-architecture/python-service-dev for Python services.
• Quality discipline: define test scope, review scope, release checks, and bug-fix verification.
• Defect routing: use defect-diagnosis for hands-on reproduction, isolation, instrumentation, fix, regression verification, root-cause analysis, and prevention routing.
• Research routing: For research groundwork behind a selection or assessment decision (技术选型、方案评估前的主题调研), this workflow must call multi-perspective-research for an evidence-grounded brief; the verdict itself stays with this workflow's gates.
• Existing-project assessment routing: for requests that ask to analyze a repository, product codebase, or project quality across architecture, implementation, tests, UI/UX, bugs, or risks, run codebase understanding first, then route each assessment dimension to the smallest owning skill instead of treating understanding as the final answer.
• AI/algorithm product launch discipline: for new or iterative algorithm capabilities, require product goal, business acceptance baseline, offline evaluation baseline, engineering serving baseline, rollout/rollback plan, and risk owner before launch. The workflow owns the gate; llm-inference-integration, testing, release, and stack skills own their narrower execution details.
• User-visible tips, nudges, release notes, and update notices: treat these as product surfaces, not harmless copy — define audience, eligibility, suppression rules, user-disable path, freshness label, repeat/cooldown policy, maximum interruption level, and success/abuse metrics before launch. Context-derived tips need a privacy review of what local behavior, files, tools, account state, or capability signals may influence eligibility; incomplete, stale, or cached update data must not imply completeness or freshness. Route terminal rendering to terminal-cli-dev, visual hierarchy/accessibility to product-ui-ux-design, behavior-changing defaults/migrations to platform-release-engineering, analytics/diagnostic redaction to platform-observability, scenario coverage to testing-strategy.
• Developer-facing surfaces (CLI / SDK / library / public API / developer docs): the user is a developer, so developer experience is an acceptance dimension. For a new or public developer surface, or a change touching onboarding, install/setup, first-success, defaults, error surfaces, or a breaking migration, prove DX by the measured onboarding journey — run the real discover→install→first-success path as a new user; do not infer DX from README / feature-list quality. Error messages are a first-class acceptance item; a non-safety default needs a safe override or a documented no-escape rationale; a safety / security default stays fail-closed (widening needs risk-owner approval; DX never licenses an --insecure bypass); breaking changes need a migration path. Journey metrics, segment proof, blocked handling, and per-surface executor routing: references/verify-developer-experience.md.
• Artifact-egress confidentiality gate: before a delivery artifact (spec/plan/requirement, status/writeback doc, launch/task card, retrospective) — or any text generated from it — crosses the local trusted boundary, run a confidentiality pass before the write/create/push/send call; it fires only on cross-boundary egress and owns only the semantic confidentiality axis that secret scanners miss. A block stops the egress but preserves the draft locally and never deletes the work; exception authority stays with the user/owner. Egress channels include chat/tracker surfaces (Feishu/Bitable writeback, shared/public docs, MR/issue body or review comment, external trackers), durable VCS/release metadata (commit message, branch/tag name, release note/changelog, CI metadata), external assistants/models, and delegated-worker prompts; the gate's own block reason/finding is itself egress — never quote the raw sensitive span across the boundary; secrets/PII/credentials/raw-logs/customer-data route to their existing owners (`pl

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: ccoalm
• Source: ccoalm/ccl-skills
• License: Apache-2.0

Install and usage instructions live in the source repository linked above.