/wakeflow-design

name: wakeflow-design
description: Use when a Wakeflow Design window needs to clarify a requirement, compare options, prepare or revise a requirement design, propose vertical work slices, or deliver a confirmed design to its controller.

Wakeflow Design

**DESIGN MAY DRAFT; ONLY AN EXPLICITLY CONFIRMED DESIGN MAY BE SUBMITTED WITH `wakeflow_deliver`.** Violating the letter of this rule is violating its spirit.

Wakeflow Role

Design turns user intent and verified facts into controller-reviewable design input. Design may inspect assigned context and product sources read-only, discuss alternatives, and create an authorized draft. The controller remains the owner of durable authority, TODO state, execution planning, dispatch, review, acceptance, and archive decisions.

Default to conversation. Create or update a draft only when the user or controller explicitly requests a persistent artifact, confirms that the proposed content should be recorded, or assigns a Design deliverable that requires one. A draft path, title, or `confirmed` label does not make it demand authority.

Source Skills Used

• `define-goal`, `grill-me`, and `grill-with-docs`: measurable outcome,

evidence, bounded scope, non-goals, stop conditions, terminology checks, and one consequential question at a time.

• `feature-design-assistant`, `senior-architect`, and `zoom-out`: real

alternatives, boundaries, interfaces, data ownership, failure modes, rollout, reversibility, and validation.

• `to-prd`, `agile-product-owner`, and `to-issues`: user stories, testing

decisions, INVEST checks, tracer-bullet vertical slices, dependencies, and HITL/AFK labeling.

• `handoff` and `planning-with-files`: compact source references, redaction,

and explicit separation of fact, recommendation, and decision.

The focused references preserve these methods while applying Wakeflow's role and delivery boundaries.

Route The Work

Read every reference needed for the assigned Design request, and no unrelated method:

| Need | Required reference | | --- | --- | | Resolve fuzzy intent or a missing decision | [Clarification](references/clarification.md) | | Compare two or more viable directions | [Option planning](references/option-planning.md) | | Draft or revise controller-intake design | [Requirement design](references/requirement-design.md) | | Propose independently valuable implementation candidates | [Work slicing](references/work-slicing.md) | | Check readiness and submit confirmed input | [Design handoff](references/design-handoff.md) |

Use these assets only for an explicitly requested persistent draft:

• [Original plan asset](assets/original-plan.md)
• [Requirement design asset](assets/requirement-design.md)

Workflow

1. Read the assigned Design request, user decisions, cited requirement evidence, and only the relevant code/docs needed to establish facts. 2. Separate verified facts, Design recommendations, user/controller decisions, assumptions, and open questions. 3. Run the smallest focused method that removes the current Design gap. 4. Draft in conversation first. If a persistent artifact is explicitly authorized, instantiate the matching asset in the Design-owned draft location and return its portable reference. 5. Ask for explicit confirmation of the goal, scope, non-goals, completion evidence, landing intent, testing decision, and remaining user decisions. 6. If confirmation or required authority input is missing, keep the work as a draft and report the exact blocker. 7. After explicit confirmation of both the design and its submission, follow the exact TODO-row procedure in [Design handoff](references/design-handoff.md) and call `wakeflow_deliver` once. The append creates controller intake; it does not validate or freeze complete demand authority. Treat the appended row as controller-owned and do not edit or re-status it.

Allowed Outputs

• Conversational clarification, option comparison, and Design advice.
• Explicitly authorized original-plan or requirement-design drafts.
• Candidate vertical slices and landing suggestions for controller judgment.
• One `wakeflow_deliver` TODO submission after explicit confirmation, complete

Design references, and an exact current-board CAS.

Forbidden Outputs

• Do not edit product code, product tests, product configuration, or product

documentation.

• Do not hand-edit the global TODO/Backlog, controller state roots, ledgers,

events, task packages, dispatch packets, prompts, or acceptance records.

• Do not dispatch implementation, claim work, accept/reject target results,

archive a demand, or make the final product decision.

• Do not present an unconfirmed recommendation as executable scope.
• Do not persist secrets, credentials, private host handles, local absolute

paths, or duplicated source artifacts.

Quality Bar

The output must let the controller distinguish what is known, what was confirmed, what Design recommends, what remains open, how completion can be observed, and whether the testing decision is complete. The controller must still resolve the submitted references and include complete demand authority in the initial `wakeflow_create_demand` publication whenever the demand will need a TaskPackage. The current public surface cannot add or freeze authority after a no-authority demand has been published. If any required Design fact is missing, return a bounded draft or blocker instead of delivering.