Harness Intelligence Wiki
Public DocsDesign Phase

Design Phase Supported Flow Shape

Design Phase Supported Flow Shape

Page Promise

The reader understands when to invoke design-phase, how the route-gated lifecycle moves from existing design evidence to approved artifacts, and how those artifacts become backlog context and active delivery without losing visual evidence.

Structure

  1. Open with design-phase as the Supported Flow for design work between requirements and implementation.
  2. State the standard flow summary bullets: use this when, gives you, ends with, wrapped phase/skills.
  3. Include a Mermaid Runtime Graph matching the other lifecycle-flow pages.
  4. Explain how to read the graph: intake uses existing product truth, the router gates each phase, prototype is delegated, approval is explicit, backlog carries artifacts, delivery starts.
  5. List entrypoints by skill or phase role.
  6. Explain the route-gated contract: router output, phase handoff, direct-entry checks, and staleness.
  7. Explain intake and grill discipline: collect evidence first, then grill only lean constraints.
  8. Explain prototype and approval discipline: artifact intent first, $prototype delegation for prototype artifacts, explicit approval per user-visible scope unit.
  9. Explain backlog and durable evidence: approved artifact context, repo-asset-management, backlog attachments first, repo-provider fallback.
  10. Explain delivery handoff: starts delivery-phase with approved artifacts, frontend taste expectations, browser/screenshot validation, and before/after PR evidence.
  11. Close with decision points, terminal outcome, and validation expectations.

Format Decisions

  • Use prose for the opening argument because the reader needs to understand why design has its own flow.
  • Use the same bullet contract as other Supported Flows pages for quick scanning.
  • Use Mermaid sequence diagram for runtime graph consistency.
  • Use short bullet lists for reading the graph, entrypoints, and decision points.
  • Do not include provider-specific upload commands; route those to repo-asset-management.
  • Do not include a fictional runtime example; the source artifacts do not contain one.

Merge Notes

  • Register the final page in apps/wiki/content/docs/harness/lifecycle-flows/meta.json.
  • Keep the final page reader-facing; do not visibly link back to private writer artifacts.
  • Skill Reference now includes prototype; later patches may add dedicated design-phase and repo-asset-management rows if those need lookup weight.

On this page