@ck123pm/harness-kit 0.1.2 → 0.1.4
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.
|
@@ -0,0 +1 @@
|
|
|
1
|
+
{"sessionId":"3f555614-8398-44a9-8eaf-c6392cea7744","pid":24940,"acquiredAt":1779795641460}
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: harness-init
|
|
3
|
-
description: Initialize a project's .harness/ directory by
|
|
3
|
+
description: Initialize a project's .harness/ directory by exploring the real codebase and generating structured project knowledge docs. Use when starting harness for a new project or rebuilding stale .harness/ content.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Harness Init
|
|
@@ -15,16 +15,16 @@ Use this skill when the user wants to initialize a project's `.harness/` directo
|
|
|
15
15
|
4. Put human-oriented docs in `human-docs/` as Markdown first, convert them to HTML with `md-to-html-doc`, then remove the Markdown source if the workflow requires generated HTML only.
|
|
16
16
|
5. Never fabricate content that is not supported by the actual repository state.
|
|
17
17
|
|
|
18
|
-
##
|
|
18
|
+
## Directory Structure and Content Routing
|
|
19
19
|
|
|
20
|
-
|
|
20
|
+
The `.harness/` directory uses a category-based layout. The reference files below are **starting points** — create only files with real content, add new files when needed, and skip empty placeholders.
|
|
21
21
|
|
|
22
22
|
```text
|
|
23
23
|
.harness/
|
|
24
|
-
├── README.md
|
|
24
|
+
├── README.md # always create: explain injection routing via index/routing.md and priority via index/priority.md
|
|
25
25
|
├── index/
|
|
26
|
-
│ ├── routing.md
|
|
27
|
-
│ ├── priority.md
|
|
26
|
+
│ ├── routing.md # always create
|
|
27
|
+
│ ├── priority.md # always create
|
|
28
28
|
│ ├── module-map.md
|
|
29
29
|
│ └── project-profile.md
|
|
30
30
|
├── rules/
|
|
@@ -48,30 +48,26 @@ Create this structure under `.harness/`:
|
|
|
48
48
|
│ ├── patterns.md
|
|
49
49
|
│ └── lessons.md
|
|
50
50
|
└── human-docs/
|
|
51
|
-
|
|
52
|
-
├── architecture-intro.html
|
|
53
|
-
└── operation-manual.html
|
|
51
|
+
└── ... # onboarding.html, architecture-intro.html, operation-manual.html
|
|
54
52
|
```
|
|
55
53
|
|
|
56
|
-
|
|
57
|
-
|
|
58
|
-
| Information type | Destination |
|
|
54
|
+
| Information type | Reference file |
|
|
59
55
|
| --- | --- |
|
|
60
|
-
| Project identity, tech stack, module structure
|
|
56
|
+
| Project identity, tech stack, module structure | `index/project-profile.md` |
|
|
61
57
|
| Task-to-context routing | `index/routing.md` |
|
|
62
58
|
| Injection priority and intensity | `index/priority.md` |
|
|
63
59
|
| Module-to-spec mapping | `index/module-map.md` |
|
|
64
|
-
| Architecture constraints,
|
|
65
|
-
| Coding standards,
|
|
66
|
-
| Test framework,
|
|
60
|
+
| Architecture constraints, boundaries, ownership | `rules/architecture.md` |
|
|
61
|
+
| Coding standards, conventions | `rules/coding.md` |
|
|
62
|
+
| Test framework, strategy, commands | `rules/testing.md` |
|
|
67
63
|
| Security constraints | `rules/security.md` |
|
|
68
64
|
| Domain terminology | `domain/glossary.md` |
|
|
69
65
|
| Stable business rules | `domain/business-rules.md` |
|
|
70
|
-
| Runtime semantics, state transitions
|
|
71
|
-
| External
|
|
72
|
-
| Build,
|
|
73
|
-
| ADRs
|
|
74
|
-
|
|
|
66
|
+
| Runtime semantics, state transitions | `domain/runtime-semantics.md` |
|
|
67
|
+
| External integrations, message flow | `guides/backend.md` |
|
|
68
|
+
| Build, config, monitoring, troubleshooting | `guides/ops.md` |
|
|
69
|
+
| ADRs, design tradeoffs | `decisions/` |
|
|
70
|
+
| Pitfalls, regressions, patterns, lessons | `memory/` |
|
|
75
71
|
|
|
76
72
|
## Exploration Strategy
|
|
77
73
|
|
|
@@ -83,10 +79,10 @@ Before writing files, inspect the repository in at least three passes:
|
|
|
83
79
|
|
|
84
80
|
Prefer CodeGraph when it is available. Use local search only when you need literal text or filesystem details.
|
|
85
81
|
|
|
86
|
-
##
|
|
82
|
+
## Language
|
|
83
|
+
|
|
84
|
+
Before generating any content, determine the output language:
|
|
87
85
|
|
|
88
|
-
1.
|
|
89
|
-
2.
|
|
90
|
-
3.
|
|
91
|
-
4. If `human-docs/` content is needed, write Markdown first, then use `md-to-html-doc` to produce HTML.
|
|
92
|
-
5. Verify the final `.harness/` tree is complete.
|
|
86
|
+
1. Read the project's `CLAUDE.md` (or `.claude/CLAUDE.md`) if it exists. If it declares a language preference (e.g. `language: zh-CN`, "使用中文", "write in English"), follow that.
|
|
87
|
+
2. If no language preference is found, match the language of the current conversation.
|
|
88
|
+
3. All generated files in `.harness/` must use the same language consistently.
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: harness-update-spec
|
|
3
|
-
description: Analyze an existing project's .harness/ specs against the current codebase
|
|
3
|
+
description: Analyze and incrementally update an existing project's .harness/ specs against the current codebase. Use when the codebase has changed and .harness/ content may be stale, or when the user wants to check spec freshness.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Harness Update Spec
|
|
@@ -41,7 +41,7 @@ Prefer CodeGraph when it is available.
|
|
|
41
41
|
|
|
42
42
|
### 3. Derive a diff matrix
|
|
43
43
|
|
|
44
|
-
Map detected changes to spec targets
|
|
44
|
+
Map detected changes to spec targets. These are reference mappings — create new files when the change doesn't fit an existing one.
|
|
45
45
|
|
|
46
46
|
| Change type | Likely spec target |
|
|
47
47
|
| --- | --- |
|
|
@@ -73,15 +73,13 @@ When updating:
|
|
|
73
73
|
3. Keep internal references inside `.harness/` consistent after edits.
|
|
74
74
|
4. Re-run a quick file list check to ensure the directory remains coherent.
|
|
75
75
|
|
|
76
|
-
##
|
|
76
|
+
## Language
|
|
77
77
|
|
|
78
|
-
|
|
78
|
+
Before generating or updating any content, determine the output language using the same rules as `harness-init`:
|
|
79
79
|
|
|
80
|
-
|
|
81
|
-
|
|
82
|
-
|
|
83
|
-
- Decisions and tradeoffs go to `decisions/`.
|
|
84
|
-
- Historical pitfalls, regressions, and patterns go to `memory/`.
|
|
80
|
+
1. Read the project's `CLAUDE.md` (or `.claude/CLAUDE.md`) if it exists. If it declares a language preference, follow that.
|
|
81
|
+
2. If no preference is found, match the language of the current conversation.
|
|
82
|
+
3. All generated files in `.harness/` must use the same language consistently and match the language of existing `.harness/` files.
|
|
85
83
|
|
|
86
84
|
## Human Docs
|
|
87
85
|
|