create-harness-vibe-coding 0.1.7 → 0.1.9
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json
CHANGED
|
@@ -44,6 +44,60 @@ Claude must follow this order:
|
|
|
44
44
|
10. Run `node scripts/validate-harness.mjs --strict`.
|
|
45
45
|
11. Record final verification and next feedback step in `docs/harness/PLAN.md`.
|
|
46
46
|
|
|
47
|
+
### Template Fill Guide
|
|
48
|
+
|
|
49
|
+
Each template doc contains `{{PLACEHOLDER}}` markers. Below is what every placeholder expects. Replace all markers in the doc before moving to the next doc. If a section does not apply yet, leave the `{{...}}` but record why in `docs/harness/PLAN.md`.
|
|
50
|
+
|
|
51
|
+
**`docs/research/PRD.md`** — Product scope. Fill with product facts from user input, not guesses:
|
|
52
|
+
- `{{WHY_THIS_PROJECT_EXISTS}}`: one-sentence motivation
|
|
53
|
+
- `{{MUST_1..3}}`: concrete, testable MVP items (checkbox form)
|
|
54
|
+
- `{{NON_GOAL_1..3}}`: explicitly out-of-scope items
|
|
55
|
+
- `{{USER_ROLE}}`, `{{SCENARIO}}`, `{{FREQUENCY}}`, `{{PAIN}}`: one row per user type
|
|
56
|
+
- `{{ACCEPTANCE_1..3}}`: verifiable project-level acceptance criteria
|
|
57
|
+
- `{{DIMENSION}}`, `{{TARGET}}`, `{{MEASUREMENT}}`: non-functional requirements (perf, security, etc.)
|
|
58
|
+
|
|
59
|
+
**`docs/research/research-results.md`** — Tech decisions. Research before filling:
|
|
60
|
+
- Use `docs/research/README.md` as the research protocol.
|
|
61
|
+
- `{{CANDIDATE_1..3}}`: each candidate (framework, library, architecture style) with Purpose/Strength/Weakness/Decision/Link.
|
|
62
|
+
- `{{Architecture Style}}`: the chosen architectural style (e.g., Hexagonal, Modular Monolith).
|
|
63
|
+
- `{{CONSTRAINT_1..3}}`: hard technical constraints derived from research.
|
|
64
|
+
- `{{ALTERNATIVE_1..2}}`: rejected candidates worth watching for future.
|
|
65
|
+
|
|
66
|
+
**`docs/harness/architecture.md`** — Layer structure. Derive from research-results:
|
|
67
|
+
- Fill the ASCII layer diagram with actual layer names. Do NOT add layers without a proven need.
|
|
68
|
+
- `2.1–2.5`: describe each harness core component (Runner, Permission Policy, Event Bus, State Store, Tool Registry) in project-specific terms.
|
|
69
|
+
- `3. Architectural Constraints`: add project-specific non-negotiables. Keep the domain/harness purity rules.
|
|
70
|
+
|
|
71
|
+
**`docs/domain/ports.md`** — Cross-layer contracts. One driving port + one driven port from the first slice:
|
|
72
|
+
- `{{INBOUND_PORT_1}}`: the first inbound port (e.g., "CreateOrderPort").
|
|
73
|
+
- `{{OUTBOUND_PORT_1}}`: the first outbound port (e.g., "OrderRepository").
|
|
74
|
+
- For each port: fill Purpose, Preconditions, Postconditions, Error Semantics, Idempotency.
|
|
75
|
+
- Leave remaining rows as `{{...}}` until more slices add ports.
|
|
76
|
+
|
|
77
|
+
**`docs/harness/PLAN.md`** — Active execution state. Update continuously:
|
|
78
|
+
- `## Current Goal`: one sentence, what this iteration achieves.
|
|
79
|
+
- `## Phase`: current lifecycle phase (Idea/Research/PRD/Architecture/Plan/Build/Verify/Feedback).
|
|
80
|
+
- `## Success Criteria`: verifiable outcomes for this iteration.
|
|
81
|
+
- `## Tasks`: numbered tasks with owner, write set, and verify command.
|
|
82
|
+
- `## Parallel Dispatch`: only when spawning subagents — fill agent roles, read/write boundaries.
|
|
83
|
+
- `## Verification`: record test results, review findings, docs sync checklist.
|
|
84
|
+
|
|
85
|
+
**`docs/harness/data-flow.md`** — Runtime event paths (only when first slice has async/multi-step flow):
|
|
86
|
+
- `{{EVENT_1}}`: the first event type with producer, consumers, payload fields, delivery semantics.
|
|
87
|
+
- Happy Path: fill the Mermaid sequence diagram with actual ports and actions.
|
|
88
|
+
- Failure Paths: for each failure point, document trigger, system behavior, event, caller perception, recovery.
|
|
89
|
+
- If the first slice is synchronous and stateless, leave this doc as `{{...}}` and note in PLAN.md.
|
|
90
|
+
|
|
91
|
+
**`docs/harness/state-machines.md`** — State transitions (only when first slice has stateful entities):
|
|
92
|
+
- Define states, transitions, guards, and illegal transitions for the first stateful entity.
|
|
93
|
+
- If no stateful entity exists in the first slice, leave as `{{...}}` and note in PLAN.md.
|
|
94
|
+
|
|
95
|
+
**General rules for all templates**:
|
|
96
|
+
- Replace `{{projectName}}` with the actual project name immediately.
|
|
97
|
+
- Never invent content for a `{{...}}` marker. If you lack facts, ask the user or leave the marker.
|
|
98
|
+
- `<!-- HTML comments -->` in templates are instructions to you. Read them. Delete them after filling the section.
|
|
99
|
+
- After filling all templates in a phase, run `node scripts/validate-harness.mjs --strict`. Any remaining `{{...}}` in project-fact files will be flagged.
|
|
100
|
+
|
|
47
101
|
## Architecture Research (Dynamic)
|
|
48
102
|
|
|
49
103
|
Do not guess the architecture. Use `docs/research/README.md` as the protocol and the high-star repos below as seed references. Search within them; do not read them whole.
|
|
@@ -1,9 +1,12 @@
|
|
|
1
1
|
# {{FEATURE_NAME}}
|
|
2
2
|
|
|
3
|
-
> **When to use**:
|
|
3
|
+
> **When to use**: Every PRD scope item in `research/PRD.md` Section 2 must have a feature doc — either a new one from this template, or an iteration on an existing one. Do not code a PRD scope item without a corresponding features doc.
|
|
4
|
+
>
|
|
5
|
+
> **New vs iterate**: If the scope item has ≥85% overlap with an existing feature doc, iterate the existing doc (bump `Version`, add a `## Changelog` entry). If overlap is below 85%, create a new file from this template. When in doubt, ask the user.
|
|
4
6
|
|
|
5
7
|
> **Status**: Draft / In Progress / Blocked / Done
|
|
6
8
|
> **Created**: {{YYYY-MM-DD}}
|
|
9
|
+
> **Version**: 1
|
|
7
10
|
> **Owner**: {{OWNER_OR_AGENT}}
|
|
8
11
|
> **Related Docs**: {{PRD_OR_ARCH_DOC_LINKS}}
|
|
9
12
|
|
|
@@ -142,3 +145,13 @@ Estimate the context budget for this feature. If the main agent would need to re
|
|
|
142
145
|
|
|
143
146
|
Remaining risks:
|
|
144
147
|
- {{RISK_OR_NONE}}
|
|
148
|
+
|
|
149
|
+
---
|
|
150
|
+
|
|
151
|
+
## 5. Changelog
|
|
152
|
+
|
|
153
|
+
> Only populate when iterating an existing feature doc (Version ≥ 2).
|
|
154
|
+
|
|
155
|
+
| Version | Date | What Changed | Reason |
|
|
156
|
+
| --- | --- | --- | --- |
|
|
157
|
+
| 1 | {{YYYY-MM-DD}} | Initial version | — |
|
|
@@ -12,15 +12,11 @@ If context grows, load [context-loading.md](context-loading.md) and split the wo
|
|
|
12
12
|
|
|
13
13
|
## Feature Packet
|
|
14
14
|
|
|
15
|
-
|
|
15
|
+
Every PRD scope item (`research/PRD.md` Section 2) must have its own feature doc at `docs/features/<name>.md` created from `docs/features/_template.md`. One feature = one doc = one implementation unit. Do not code without a feature doc.
|
|
16
16
|
|
|
17
|
-
|
|
17
|
+
Small scope is not an exception — a short feature doc is better than none. If the work is truly too small for a full feature doc (single-file fix, no behavior change), it is not a PRD scope item.
|
|
18
18
|
|
|
19
|
-
|
|
20
|
-
- acceptance criteria
|
|
21
|
-
- allowed write set and forbidden scope
|
|
22
|
-
- task list with verification commands
|
|
23
|
-
- test results and residual risks
|
|
19
|
+
**New vs iterate**: if a PRD scope item has ≥85% overlap with an existing feature doc, open the existing doc, bump `Version`, and add a `## Changelog` entry. Only create a new file when the scope is substantially different. When unsure, ask.
|
|
24
20
|
|
|
25
21
|
## Standard Build Loop
|
|
26
22
|
|