prototype

Harness Prototype — Build Working Demos

Build or iterate on working prototypes. Follow existing codebase patterns and conventions discovered via KB.

Prerequisites

Check for .harness/kb/stack-profile.md. If missing, tell the user to run /harness:init first.

Context Loading

• .harness/kb/stack-profile.md — languages, frameworks, conventions

• .harness/kb/ui-patterns.md — component library, state management, existing patterns

• .harness/kb/data-layer.md — data models for queries

• .harness/kb/api-surface.md — existing API patterns for data fetching

• Check existing similar pages/components in the codebase

• If spec/design exists, read from target_dir

Boundaries

Read the stack-profile.md to understand where prototype code should live. Follow the project's existing conventions for:

• File location and naming

• Import patterns

• Component structure

• Data fetching

Key principle: Prototypes should be self-contained and deletable without side effects on the rest of the codebase.

Process

Step 1: Classify the Task

Type	When	Action
NEW	Fresh build, no existing prototype	Create new files following project conventions
ITERATE	Add/change existing prototype	Modify in-place
VERSION	Build on existing concept, different approach	New directory, import from previous
REDESIGN	Fundamentally different UX for same feature	Redesign existing

If ambiguous, ask ONE clarifying question.

Step 2: Audit (for ITERATE/VERSION/REDESIGN)

Read ALL files in the existing prototype:

1. Present a component map (hierarchy with import sources)
2. Show what's using shared components vs custom
3. Ask: "What specifically should change?"

Step 3: Find Input (for NEW)

1. Check for spec/design in target_dir
2. Check for related existing pages/components
3. Or user describes what to build

Step 4: Plan the Changes

For ITERATE: Present changeset with impact levels:

• 🟢 Additive — new component/feature

• 🟡 Modification — changing existing component

• 🔴 Structural — changes to layout/data flow

For NEW: Propose file structure following project conventions from stack-profile.md.

Get explicit approval before building.

Step 5: Build in Phases

Phase 1 — Foundation: Types, layout shell, basic page structure Phase 2 — Core Flow: Main components, data fetching Phase 3 — Integration: Real data, API calls, state management Phase 4 — Polish: Loading states, error handling, empty states

Check in after each phase: "Want to review before continuing?"

Step 6: Convention Self-Check

Before presenting, verify against stack-profile.md and ui-patterns.md:

• Using the project's component library?

• Following the project's styling approach?

• Using the project's data fetching pattern?

• Using the project's icon library?

• Following the project's TypeScript/type conventions?

• Loading states using project's pattern?

• File naming follows project conventions?

Step 7: Save

Save implementation guide to {target_dir}/prototype-{slug}-{date}.md with frontmatter:

---
title: "{prototype title}"
type: prototype
date: {ISO date}
files-created: [{list of files created}]
next-skill: report
---

Also store via MCP: call harness_add_skillflow_step with skill_type: "prototype".

Guardrails

• Prototype should be self-contained — deletable without side effects

• Prefer existing shared components over building new ones

• Don't add dependencies for a prototype — use what's already installed

• Don't create database migrations for prototypes — mock data locally if needed

• Follow the project's existing code conventions (from KB), not your own preferences