hk-mock-first

Name: hk-mock-first
Author: deepklarity

84stars12forks

How to install hk-mock-first?

deepklarity/harness-kit/hk-mock-first

$npx -y skills add deepklarity/harness-kit --skill hk-mock-first

Installs into the current project.

Summary

Mock-first, layer-by-layer feature development. Instead of building a feature end-to-end and hoping the interface works, start by mocking at the user-facing surface with realistic data, get user acceptance on the experience, then deepen one complexity layer at a time with TDD. Ev

Files · 1

View on GitHub

SKILL.md

1	# /hk-mock-first — Mock-First, Layer-by-Layer Feature Development
2
3	The traditional approach — build the plumbing, wire the API, then hope the UI works — inverts the feedback loop. You discover experience problems after committing to implementation choices. This skill inverts the flow: validate the experience first with realistic mocks, then progressively replace mocks with real code, one complexity layer at a time.
4
5	Why this matters: A feature that "works" but feels wrong is more expensive to fix than one that was never built. Mock-first means the human curates the experience before any plumbing exists. This directly serves the philosophy tenet of Taste as a Filter — the system produces options, the human filters. And Good Enough — you don't over-engineer layers that haven't been validated yet.
6
7	## Context
8
9	<feature_context> $ARGUMENTS </feature_context>
10
11	If the context above is empty or unclear, ask the user:
12	1. What feature or change are you building?
13	2. Which user-facing interfaces does it touch? (UI pages, CLI output, API responses that drive UI)
14	3. Where should the workspace live? (suggest `docs/mock-first/<feature-slug>/`)
15
16	## The Workspace
17
18	Everything lives on disk. The workspace is the product, not temp files — it's the organized record of what was mocked, what was accepted, and what's been deepened. It also serves as the resumption anchor: if the conversation compacts or a new session starts, the workspace contains everything needed to continue.
19
20	```
21	docs/mock-first/<feature-slug>/
22	├── tracker.md # Live state (the resumption anchor)
23	├── surface/
24	│ ├── interface-map.md # All user-facing interfaces this feature touches
25	│ ├── mock-data/ # Actual mock data files (JSON, fixtures, factories)
26	│ ├── mock-components/ # Mock UI components, stubs, or test pages (if applicable)
27	│ ├── states.md # All UI/interface states catalogued
28	│ └── acceptance.md # User's acceptance notes + screenshots
29	├── layer-1/
30	│ ├── boundary.md # What this layer is, where the complexity boundary sits
31	│ ├── test-plan.md # TDD: tests to write before implementation
32	│ ├── changes.md # What changed (files, diffs)
33	│ └── verification.md # Tests pass + interface still works
34	├── layer-2/
35	│ └── ...
36	└── summary.md # Written when feature ships (or when pausing long-term)
37	```
38
39	### tracker.md template
40
41	This file is the single source of truth. Read it at the start of every session or phase transition.
42
43	```markdown
44	# Mock-First: [feature name]
45
46	## Feature
47	What we're building: [one line]
48	Interfaces affected: [list of UI pages, components, CLI commands]
49	Workspace: [path to this directory]
50
51	## Current State
52	Phase: [exploring \| mocking \| accepting \| deepening-layer-N \| shipped]
53	Current layer: [surface \| layer-N]
54	Mock data quality: [shallow \| realistic \| production-grade]
55
56	## Layer Progression
57	- surface: [status] — [what was mocked, acceptance verdict]
58	- layer-1: [status] — [what was deepened, test results]
59	- layer-2: [status] — [...]
60
61	## Decisions Log
62	- [Date]: [Decision and rationale — things the user accepted, rejected, or modified]
63
64	## What We've Learned
65	- [Accumulated insights — edge cases discovered, states that were missing, etc.]
66
67	## Next
68	[What to do next, or "SHIPPED: [date]"]
69	```
70
71	## The Process
72
73	### Phase 0: EXPLORE & MAP
74
75	Before writing any mock, understand the full scope of what the user will see and touch.
76
77	Step 1: Map the interaction surface.
78
79	Spawn a haiku explorer to identify all user-facing interfaces this feature affects. Not plumbing (services, utilities, middleware) — the points where a human's eyes and hands meet the system.
80
81	```
82	Task(model: haiku, subagent_type: Explore)
83
84	Explore the codebase to map all user-facing interfaces that would be affected by: [feature description]
85
86	For each interface found, note:
87	1. File path and component/page name
88	2. What the user currently sees/does there
89	3. What would change with the new feature
90	4. Data dependencies — what data does this interface need?
91
92	Focus only on interfaces the user directly interacts with (UI components, pages, CLI output, API responses that drive UI). Skip internal services, utilities

People who liked this also viewed

6 picks

Type

hk-mock-first

84stars12forks

View on GitHub

How to install hk-mock-first?

deepklarity/harness-kit/hk-mock-first

$npx -y skills add deepklarity/harness-kit --skill hk-mock-first

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# /hk-mock-first — Mock-First, Layer-by-Layer Feature Development
2
3	The traditional approach — build the plumbing, wire the API, then hope the UI works — inverts the feedback loop. You discover experience problems after committing to implementation choices. This skill inverts the flow: validate the experience first with realistic mocks, then progressively replace mocks with real code, one complexity layer at a time.
4
5	Why this matters: A feature that "works" but feels wrong is more expensive to fix than one that was never built. Mock-first means the human curates the experience before any plumbing exists. This directly serves the philosophy tenet of Taste as a Filter — the system produces options, the human filters. And Good Enough — you don't over-engineer layers that haven't been validated yet.
6
7	## Context
8
9	<feature_context> $ARGUMENTS </feature_context>
10
11	If the context above is empty or unclear, ask the user:
12	1. What feature or change are you building?
13	2. Which user-facing interfaces does it touch? (UI pages, CLI output, API responses that drive UI)
14	3. Where should the workspace live? (suggest `docs/mock-first/<feature-slug>/`)
15
16	## The Workspace
17
18	Everything lives on disk. The workspace is the product, not temp files — it's the organized record of what was mocked, what was accepted, and what's been deepened. It also serves as the resumption anchor: if the conversation compacts or a new session starts, the workspace contains everything needed to continue.
19
20	```
21	docs/mock-first/<feature-slug>/
22	├── tracker.md # Live state (the resumption anchor)
23	├── surface/
24	│ ├── interface-map.md # All user-facing interfaces this feature touches
25	│ ├── mock-data/ # Actual mock data files (JSON, fixtures, factories)
26	│ ├── mock-components/ # Mock UI components, stubs, or test pages (if applicable)
27	│ ├── states.md # All UI/interface states catalogued
28	│ └── acceptance.md # User's acceptance notes + screenshots
29	├── layer-1/
30	│ ├── boundary.md # What this layer is, where the complexity boundary sits
31	│ ├── test-plan.md # TDD: tests to write before implementation
32	│ ├── changes.md # What changed (files, diffs)
33	│ └── verification.md # Tests pass + interface still works
34	├── layer-2/
35	│ └── ...
36	└── summary.md # Written when feature ships (or when pausing long-term)
37	```
38
39	### tracker.md template
40
41	This file is the single source of truth. Read it at the start of every session or phase transition.
42
43	```markdown
44	# Mock-First: [feature name]
45
46	## Feature
47	What we're building: [one line]
48	Interfaces affected: [list of UI pages, components, CLI commands]
49	Workspace: [path to this directory]
50
51	## Current State
52	Phase: [exploring \| mocking \| accepting \| deepening-layer-N \| shipped]
53	Current layer: [surface \| layer-N]
54	Mock data quality: [shallow \| realistic \| production-grade]
55
56	## Layer Progression
57	- surface: [status] — [what was mocked, acceptance verdict]
58	- layer-1: [status] — [what was deepened, test results]
59	- layer-2: [status] — [...]
60
61	## Decisions Log
62	- [Date]: [Decision and rationale — things the user accepted, rejected, or modified]
63
64	## What We've Learned
65	- [Accumulated insights — edge cases discovered, states that were missing, etc.]
66
67	## Next
68	[What to do next, or "SHIPPED: [date]"]
69	```
70
71	## The Process
72
73	### Phase 0: EXPLORE & MAP
74
75	Before writing any mock, understand the full scope of what the user will see and touch.
76
77	Step 1: Map the interaction surface.
78
79	Spawn a haiku explorer to identify all user-facing interfaces this feature affects. Not plumbing (services, utilities, middleware) — the points where a human's eyes and hands meet the system.
80
81	```
82	Task(model: haiku, subagent_type: Explore)
83
84	Explore the codebase to map all user-facing interfaces that would be affected by: [feature description]
85
86	For each interface found, note:
87	1. File path and component/page name
88	2. What the user currently sees/does there
89	3. What would change with the new feature
90	4. Data dependencies — what data does this interface need?
91
92	Focus only on interfaces the user directly interacts with (UI components, pages, CLI output, API responses that drive UI). Skip internal services, utilities

People who liked this also viewed

6 picks

Type