@ksuchoi216/ahe 0.1.6 → 0.1.7
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/.codex/hooks/ahe-hook.js +162 -203
- package/.codex/skills/ahe-compression/SKILL.md +8 -8
- package/.codex/skills/ahe-conversator/SKILL.md +44 -0
- package/.codex/skills/ahe-harness/SKILL.md +115 -0
- package/.codex/skills/ahe-init/SKILL.md +16 -23
- package/.codex/skills/ahe-reviewer/SKILL.md +35 -0
- package/.codex/skills/ahe-solver/SKILL.md +24 -0
- package/.codex/skills/ahe-thinker/SKILL.md +80 -0
- package/README.md +30 -205
- package/bin/ahe +6 -4
- package/package.json +3 -2
- package/.codex/skills/ahe-conversation/SKILL.md +0 -73
- package/.codex/skills/ahe-spec/SKILL.md +0 -63
- package/.codex/skills/ahe-thinking/SKILL.md +0 -104
- package/.codex/skills/ahe-update/SKILL.md +0 -66
|
@@ -23,42 +23,35 @@ Use this skill when the user invokes `$ahe-init`.
|
|
|
23
23
|
- Treat exact `ahe init` as a possible new start request.
|
|
24
24
|
- If no AHE-managed harness files exist, start initialization normally without asking a restart-scope question.
|
|
25
25
|
- If any AHE-managed harness file already exists, read the existing files first.
|
|
26
|
-
- When existing harness files are present, summarize the current project purpose and product specification state, then ask what restart scope the user wants before
|
|
27
|
-
- Do not
|
|
26
|
+
- When existing harness files are present, summarize the current project purpose and product specification state, then ask what restart scope the user wants before removing, overwriting, or refreshing existing harness files.
|
|
27
|
+
- Do not remove, overwrite, or refresh existing harness files until the restart scope is clear.
|
|
28
28
|
- Interpret the restart scope from the user's free-form answer; examples are guidance only and must not limit valid answers.
|
|
29
29
|
- If the answer says `purpose`, full restart, or equivalent, `purpose` means restart the whole harness from the project purpose.
|
|
30
|
-
- If the answer says `product`, product spec, or equivalent, `product` means preserve the project purpose in `AGENTS.md
|
|
31
|
-
- If the answer names a narrower custom scope, preserve unrelated harness files and restart only the named scope
|
|
30
|
+
- If the answer says `product`, product spec, or equivalent, `product` means preserve the project purpose in `AGENTS.md` and restart product specification work in `docs/PRODUCT.md`.
|
|
31
|
+
- If the answer names a narrower custom scope, preserve unrelated harness files and restart only the named scope.
|
|
32
32
|
- If `AGENTS.md` already exists, ask the user whether the current `AGENTS.md` is right.
|
|
33
33
|
- If the current `AGENTS.md` is not right or does not exist, ask for the purpose of this project.
|
|
34
34
|
- If `AGENTS.md` does not exist, copy `AGENTS.md` from `.codex/ahe-shared/templates/`.
|
|
35
35
|
- Update only the `PROJECT_PURPOSE` portion of `AGENTS.md`.
|
|
36
36
|
- Keep `AGENTS.md` limited to the project purpose and base agent settings.
|
|
37
37
|
- Do not put product specification details in `AGENTS.md`.
|
|
38
|
-
- Send product behavior, scope, requirements, success criteria, and workflow details to `ahe-
|
|
38
|
+
- Send product behavior, scope, requirements, success criteria, and workflow details to `ahe-harness` so they are written in `docs/PRODUCT.md` first.
|
|
39
39
|
- Generating an empty `feature-list.json` from a template is allowed, but do not write concrete feature items until `docs/PRODUCT.md` is populated.
|
|
40
40
|
- Ask whether the project language is Python using a Codex-supported structured response request with meaningful options and custom input.
|
|
41
41
|
- If the user answers that the project language is not Python, ask again: "Which language do you use?".
|
|
42
|
-
-
|
|
43
|
-
-
|
|
44
|
-
-
|
|
45
|
-
-
|
|
46
|
-
-
|
|
47
|
-
-
|
|
48
|
-
-
|
|
49
|
-
- Copy the `docs/` folder into the backup directory when it exists.
|
|
50
|
-
- Remove the previous `docs/PRODUCT.md` and `docs/INSTRUCTIONS.md` when the chosen restart scope includes product specification after backup.
|
|
51
|
-
- Remove the previous `PROGRESS.md` when the chosen restart scope includes progress tracking after backup.
|
|
52
|
-
- Remove the previous `SESSION-HANDOFF.md` when the chosen restart scope includes session handoff after backup.
|
|
53
|
-
- Remove the previous `feature-list.json` when the chosen restart scope includes feature tracking after backup.
|
|
54
|
-
- After backup, remove only the files included in the chosen restart scope before continuing the new start flow.
|
|
42
|
+
- Do not create backup copies of the replaced harness files.
|
|
43
|
+
- When a restart scope replaces prior harness history, summarize the replaced harness history in the refreshed tracking artifacts instead of creating backups.
|
|
44
|
+
- Remove the previous `docs/PRODUCT.md` and `docs/INSTRUCTIONS.md` when the chosen restart scope includes product specification.
|
|
45
|
+
- Remove the previous `PROGRESS.md` when the chosen restart scope includes progress tracking.
|
|
46
|
+
- Remove the previous `SESSION-HANDOFF.md` when the chosen restart scope includes session handoff.
|
|
47
|
+
- Remove the previous `feature-list.json` when the chosen restart scope includes feature tracking.
|
|
48
|
+
- Remove only the files included in the chosen restart scope before continuing the new start flow.
|
|
55
49
|
- Find all template files under `.codex/ahe-shared/templates/`.
|
|
56
50
|
- Ignore `AGENTS.md` and `PRODUCT.md` when copying template files.
|
|
57
51
|
- Before copying a template file into the workspace root, check whether the target file already exists and ask for explicit overwrite confirmation when needed.
|
|
58
|
-
- Execute the following
|
|
52
|
+
- Execute the following two steps sequentially, updating the progress status (`current_step` in `.ahe/process_status.json`):
|
|
59
53
|
1. complete the embedded init setup work (status: "ahe-init")
|
|
60
|
-
2. call "ahe-
|
|
61
|
-
3. call "ahe-update" (status: "ahe-update")
|
|
54
|
+
2. call "ahe-harness" (status: "ahe-harness")
|
|
62
55
|
|
|
63
56
|
### Harness Generation
|
|
64
57
|
|
|
@@ -71,7 +64,7 @@ Use this skill when the user invokes `$ahe-init`.
|
|
|
71
64
|
|
|
72
65
|
## Clarification Rule
|
|
73
66
|
|
|
74
|
-
When the next setup step is not clear, follow the `ahe-
|
|
67
|
+
When the next setup step is not clear, follow the `ahe-thinker` protocol first. If `ahe-thinker` finds missing information, follow the `ahe-conversator` protocol. Ask again recursively using a Codex-supported structured response request, provide 2-3 meaningful mutually exclusive options when possible, and allow custom input when predefined options are not enough.
|
|
75
68
|
|
|
76
69
|
### User Response Target
|
|
77
70
|
|
|
@@ -91,7 +84,7 @@ When the next setup step is not clear, follow the `ahe-thinking` protocol first.
|
|
|
91
84
|
- The answer must be specific enough to update `PROJECT_PURPOSE`.
|
|
92
85
|
- The answer must make it clear whether initialization should continue with the current `AGENTS.md` or with a new purpose.
|
|
93
86
|
- The answer must clearly identify whether Python guidance applies.
|
|
94
|
-
- The answer must make the restart scope clear when existing harness files must be
|
|
87
|
+
- The answer must make the restart scope clear when existing harness files must be replaced.
|
|
95
88
|
- The answer must make overwrite intent explicit for existing template targets.
|
|
96
89
|
- The answer must resolve any setup choice that blocks the next workflow step.
|
|
97
90
|
|
|
@@ -0,0 +1,35 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: ahe-reviewer
|
|
3
|
+
description: Internal AHE review workflow for understanding repo code, harness files, and CodeGraph context before another agent acts.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# AHE Reviewer
|
|
7
|
+
|
|
8
|
+
This is an internal AHE workflow skill, not a user-facing command.
|
|
9
|
+
|
|
10
|
+
Do not treat `$ahe-reviewer` as a user command.
|
|
11
|
+
Use it when `ahe-thinker` or another worker needs evidence from code or harness
|
|
12
|
+
state before deciding what to do next.
|
|
13
|
+
|
|
14
|
+
## Review Scope
|
|
15
|
+
|
|
16
|
+
- Inspect repo code, harness files, verification history, and feature progress.
|
|
17
|
+
- If `.codegraph/` exists, prefer `.codegraph` or CodeGraph-backed review
|
|
18
|
+
context when available.
|
|
19
|
+
- Check `AGENTS.md`, `docs/PRODUCT.md`, `docs/INSTRUCTIONS.md`,
|
|
20
|
+
`feature-list.json`, `PROGRESS.md`, `SESSION-HANDOFF.md`, and `docs/todo.md`
|
|
21
|
+
when the question is about harness state.
|
|
22
|
+
|
|
23
|
+
## Handoffs
|
|
24
|
+
|
|
25
|
+
- Report findings back to `ahe-thinker` by default.
|
|
26
|
+
- Call `ahe-harness` directly when review finds harness drift, stale tracking,
|
|
27
|
+
or Product.md / feature-list mismatches.
|
|
28
|
+
- Call `ahe-conversator` only when the missing information must come from the
|
|
29
|
+
user.
|
|
30
|
+
|
|
31
|
+
## Output
|
|
32
|
+
|
|
33
|
+
- State what was reviewed.
|
|
34
|
+
- State the relevant evidence or mismatch.
|
|
35
|
+
- State the recommended next agent.
|
|
@@ -0,0 +1,24 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: ahe-solver
|
|
3
|
+
description: Internal AHE feature-solving workflow for dividing, planning, and solving feature work after the active goal is clear enough.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# AHE Solver
|
|
7
|
+
|
|
8
|
+
This is an internal AHE workflow skill, not a user-facing command.
|
|
9
|
+
|
|
10
|
+
Do not treat `$ahe-solver` as a user command.
|
|
11
|
+
Use it when `ahe-thinker` decides that the next job is building or planning a
|
|
12
|
+
feature.
|
|
13
|
+
|
|
14
|
+
## Command Workflow: ahe-solver
|
|
15
|
+
|
|
16
|
+
- Read the active feature context from `docs/PRODUCT.md`, `feature-list.json`,
|
|
17
|
+
`PROGRESS.md`, and any relevant code files.
|
|
18
|
+
- Divide broad work into smaller problems when useful.
|
|
19
|
+
- Plan each smaller problem before implementation.
|
|
20
|
+
- Call `ahe-reviewer` when repo or code understanding is needed.
|
|
21
|
+
- Call `ahe-conversator` when feature requirements, scope, or success criteria
|
|
22
|
+
are still unclear.
|
|
23
|
+
- Report the solved step, remaining work, and recommended next agent back to
|
|
24
|
+
`ahe-thinker`.
|
|
@@ -0,0 +1,80 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: ahe-thinker
|
|
3
|
+
description: Internal AHE orchestration protocol for routing exact `ahe` and explicit `ahe <query>` requests through the AHE agent network.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# AHE Thinker
|
|
7
|
+
|
|
8
|
+
This is an internal AHE workflow skill, not a user-facing command.
|
|
9
|
+
|
|
10
|
+
Do not treat `$ahe-thinker` as a user command.
|
|
11
|
+
Use it as the central decision layer for AHE work.
|
|
12
|
+
|
|
13
|
+
## Purpose
|
|
14
|
+
|
|
15
|
+
- Judge what is missing before another agent acts.
|
|
16
|
+
- Judge the active `project`, `feature`, or `sub-feature`.
|
|
17
|
+
- Decide which of `Why`, `What`, and `How` are still missing.
|
|
18
|
+
- Choose the next internal agent: `ahe-reviewer`, `ahe-conversator`,
|
|
19
|
+
`ahe-harness`, or `ahe-solver`.
|
|
20
|
+
- Receive each agent result, reassess the state, and decide the next step.
|
|
21
|
+
|
|
22
|
+
## Routing Inputs
|
|
23
|
+
|
|
24
|
+
- Exact `ahe` means continue existing harness work.
|
|
25
|
+
- Exact `ahe init`, exact `ahe-init`, and exact `$ahe-init` stay on the
|
|
26
|
+
`$ahe-init` path.
|
|
27
|
+
- Explicit `ahe <query>` means route the query through `ahe-thinker`.
|
|
28
|
+
- Broad non-prefixed prompts must not activate AHE.
|
|
29
|
+
|
|
30
|
+
## Size Preflight
|
|
31
|
+
|
|
32
|
+
- Before reading full harness files, run
|
|
33
|
+
`sh .codex/skills/ahe-compression/scripts/check-harness-size.sh`.
|
|
34
|
+
- If the detector exits with `COMPRESSION_REQUIRED` or code `2`, call
|
|
35
|
+
`ahe-compression` before normal routing.
|
|
36
|
+
- Do not read oversized harness files wholesale before compression routing is
|
|
37
|
+
settled.
|
|
38
|
+
|
|
39
|
+
## Decision Rules
|
|
40
|
+
|
|
41
|
+
- For a `project`, require `Why`, `What`, and `How` by default.
|
|
42
|
+
- For a `feature` or `sub-feature`, require only the minimum of `Why`, `What`,
|
|
43
|
+
and `How` needed to proceed safely.
|
|
44
|
+
- If the need is understanding repo code, harness drift, progress evidence, or
|
|
45
|
+
CodeGraph context, call `ahe-reviewer`.
|
|
46
|
+
- If the need is user clarification, call `ahe-conversator`.
|
|
47
|
+
- If the need is updating harness artifacts, product docs, feature tracking,
|
|
48
|
+
todo sync, or compression of completed history, call `ahe-harness`.
|
|
49
|
+
- If the need is solving or decomposing feature work, call `ahe-solver`.
|
|
50
|
+
|
|
51
|
+
## Interaction Model
|
|
52
|
+
|
|
53
|
+
- `ahe-thinker` is centered, but direct worker-to-worker calls are allowed when
|
|
54
|
+
they are the obvious next step.
|
|
55
|
+
- Typical loops:
|
|
56
|
+
- `ahe-thinker -> ahe-reviewer -> ahe-thinker`
|
|
57
|
+
- `ahe-thinker -> ahe-harness -> ahe-thinker`
|
|
58
|
+
- `ahe-thinker -> ahe-conversator -> ahe-thinker`
|
|
59
|
+
- `ahe-thinker -> ahe-solver -> ahe-thinker`
|
|
60
|
+
- Allowed direct handoffs include:
|
|
61
|
+
- `ahe-harness -> ahe-conversator`
|
|
62
|
+
- `ahe-solver -> ahe-reviewer`
|
|
63
|
+
- `ahe-reviewer -> ahe-harness`
|
|
64
|
+
- Every handoff must state the goal, reason, relevant files or context, and the
|
|
65
|
+
expected result.
|
|
66
|
+
|
|
67
|
+
## Broad Intent Routing
|
|
68
|
+
|
|
69
|
+
- Use `ahe-reviewer` for review-first requests.
|
|
70
|
+
- Use `ahe-harness` for product, instructions, progress, feature-list, todo, or
|
|
71
|
+
compression maintenance.
|
|
72
|
+
- Use `ahe-solver` for feature implementation planning or execution work.
|
|
73
|
+
- Use `ahe-conversator` when no safe next step exists without user input.
|
|
74
|
+
|
|
75
|
+
## Completion
|
|
76
|
+
|
|
77
|
+
- Continue to the next skill or next unfinished feature until the active unit is
|
|
78
|
+
resolved.
|
|
79
|
+
- Keep `docs/PRODUCT.md` as the canonical contract and `feature-list.json` as a
|
|
80
|
+
derived tracker.
|
package/README.md
CHANGED
|
@@ -1,216 +1,41 @@
|
|
|
1
1
|
# Awesome Harness Engineering (AHE)
|
|
2
2
|
|
|
3
|
-
AHE
|
|
3
|
+
AHE installs Codex skills that manage harness files through chat. The public
|
|
4
|
+
entrypoints stay small: use `ahe init` to start or reset harness work, `ahe` to
|
|
5
|
+
continue existing work, and `ahe <query>` for explicit AHE requests such as
|
|
6
|
+
`ahe compress feature-list`.
|
|
4
7
|
|
|
5
|
-
|
|
8
|
+
## Installed Skills
|
|
6
9
|
|
|
7
|
-
|
|
10
|
+
| Skill | Role |
|
|
11
|
+
| --- | --- |
|
|
12
|
+
| `ahe-init` | New-start workflow that prepares the workspace and hands product/tracking work to `ahe-harness`. |
|
|
13
|
+
| `ahe-thinker` | Centered internal router that judges what is missing and chooses the next agent. |
|
|
14
|
+
| `ahe-reviewer` | Review agent for repo code, harness state, and CodeGraph context. |
|
|
15
|
+
| `ahe-conversator` | Clarification agent for recursive user conversation. |
|
|
16
|
+
| `ahe-harness` | Harness-management agent for product docs, instructions, feature tracking, todo sync, and compression-aware maintenance. |
|
|
17
|
+
| `ahe-solver` | Feature-solving agent that divides and plans implementation work. |
|
|
18
|
+
| `ahe-compression` | Internal helper that detects oversized harness files before broad reads. |
|
|
8
19
|
|
|
9
|
-
|
|
20
|
+
## Routing Model
|
|
10
21
|
|
|
11
|
-
|
|
12
|
-
npx --yes --package=@ksuchoi216/ahe ahe install
|
|
13
|
-
```
|
|
22
|
+
The internal model is centered but flexible:
|
|
14
23
|
|
|
15
|
-
|
|
24
|
+
`query -> ahe-thinker -> ahe-reviewer | ahe-conversator | ahe-harness | ahe-solver`
|
|
16
25
|
|
|
17
|
-
|
|
18
|
-
|
|
19
|
-
|
|
20
|
-
|
|
26
|
+
- `ahe-thinker` is the center of judgment.
|
|
27
|
+
- Worker agents can call each other directly when that is the logical next
|
|
28
|
+
action.
|
|
29
|
+
- Typical direct handoffs are `ahe-harness -> ahe-conversator`,
|
|
30
|
+
`ahe-solver -> ahe-reviewer`, and `ahe-reviewer -> ahe-harness`.
|
|
21
31
|
|
|
22
|
-
|
|
32
|
+
## Query Examples
|
|
23
33
|
|
|
24
|
-
|
|
34
|
+
- `ahe`
|
|
35
|
+
- `ahe init`
|
|
36
|
+
- `ahe compress feature-list`
|
|
37
|
+
- `ahe update product spec`
|
|
38
|
+
- `ahe add dashboard export feature`
|
|
25
39
|
|
|
26
|
-
|
|
27
|
-
|
|
28
|
-
```
|
|
29
|
-
|
|
30
|
-
### CLI Commands
|
|
31
|
-
|
|
32
|
-
| Command | Description |
|
|
33
|
-
| ---------------------- | ----------------------------------------------- |
|
|
34
|
-
| `ahe install` | Install AHE skills into `.codex/` |
|
|
35
|
-
| `ahe install --force` | Overwrite existing installation |
|
|
36
|
-
| `ahe install --backup` | Backup existing installation before overwriting |
|
|
37
|
-
| `ahe uninstall` | Remove all AHE skills, shared assets, and hooks |
|
|
38
|
-
| `ahe doctor` | Check installation health and integrity |
|
|
39
|
-
| `ahe version` | Print the current version |
|
|
40
|
-
|
|
41
|
-
---
|
|
42
|
-
|
|
43
|
-
## 2. How to Use
|
|
44
|
-
|
|
45
|
-
AHE works inside **Codex chat**. After installing via the terminal, open Codex chat in your workspace and type one of the commands below.
|
|
46
|
-
|
|
47
|
-
### Chat Commands
|
|
48
|
-
|
|
49
|
-
| Command | What it does |
|
|
50
|
-
| ---------- | ----------------------------------------------------------------------------------------------------------------------- |
|
|
51
|
-
| `ahe init` | **Start a new harness.** Creates harness skeleton files, asks about your project, and writes the product specification. |
|
|
52
|
-
| `ahe` | **Continue existing work.** Inspects the current state, reports status, decides the next step, and keeps working. |
|
|
53
|
-
|
|
54
|
-
> **Note:** Only exact commands trigger AHE. Normal messages like "explain ahe" or "what does ahe do" will not start any workflow.
|
|
55
|
-
|
|
56
|
-
### Typical Workflow
|
|
57
|
-
|
|
58
|
-
```
|
|
59
|
-
# Step 1: Install AHE skills into your project
|
|
60
|
-
$ ahe install
|
|
61
|
-
|
|
62
|
-
# Step 2: Open Codex chat and initialize the harness
|
|
63
|
-
> ahe init
|
|
64
|
-
→ AHE asks about your project purpose, language, tech stack, constraints...
|
|
65
|
-
→ Creates AGENTS.md, feature-list.json, PROGRESS.md, docs/PRODUCT.md, etc.
|
|
66
|
-
|
|
67
|
-
# Step 3: Continue working — just type "ahe"
|
|
68
|
-
> ahe
|
|
69
|
-
→ AHE inspects the harness state and prints a status report
|
|
70
|
-
→ Picks the next unfinished feature or asks for missing info
|
|
71
|
-
→ Works on it, then updates tracking artifacts
|
|
72
|
-
|
|
73
|
-
# Step 4: Keep iterating
|
|
74
|
-
> ahe
|
|
75
|
-
→ Reports progress, moves to the next feature
|
|
76
|
-
→ Repeat until all features are done
|
|
77
|
-
```
|
|
78
|
-
|
|
79
|
-
---
|
|
80
|
-
|
|
81
|
-
## 3. How It Works
|
|
82
|
-
|
|
83
|
-
### Skills Overview
|
|
84
|
-
|
|
85
|
-
AHE is composed of six core skills that coordinate automatically:
|
|
86
|
-
|
|
87
|
-
| Skill | Role |
|
|
88
|
-
| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
|
|
89
|
-
| **ahe-init** | Entry point for new projects. Creates harness files, asks for project info, then calls ahe-spec and ahe-update. |
|
|
90
|
-
| **ahe-thinking** | Internal decision engine. Evaluates clarity on **Why** / **What** / **How** for each work unit and routes to the right action. |
|
|
91
|
-
| **ahe-compression** | Internal size detector & compressor. Monitors file sizes via configurable thresholds (`config.yaml`) and compresses bloated files before reading. |
|
|
92
|
-
| **ahe-conversation** | Internal question protocol. Asks exactly one focused question at a time when information is missing. |
|
|
93
|
-
| **ahe-spec** | Writes and updates `docs/PRODUCT.md` (canonical source of truth) and `docs/INSTRUCTIONS.md`. |
|
|
94
|
-
| **ahe-update** | Syncs tracking artifacts: `feature-list.json`, `PROGRESS.md`, `SESSION-HANDOFF.md`. |
|
|
95
|
-
|
|
96
|
-
### Process Flow
|
|
97
|
-
|
|
98
|
-
```mermaid
|
|
99
|
-
flowchart TD
|
|
100
|
-
Install["<b>Terminal</b><br/>ahe install"] --> Chat["Open Codex chat<br/>in the workspace"]
|
|
101
|
-
|
|
102
|
-
Chat --> Command{"What did you type?"}
|
|
103
|
-
Command -->|"ahe init"| Init["<b>ahe-init</b><br/>New-start workflow"]
|
|
104
|
-
Command -->|"ahe"| Router["<b>AHE Router</b><br/>Inspect harness & print status"]
|
|
105
|
-
Command -->|"other message"| Noop["No AHE workflow triggered"]
|
|
106
|
-
|
|
107
|
-
Router --> Classify{"Classify harness state"}
|
|
108
|
-
Classify -->|"Not enough spec"| Init
|
|
109
|
-
Classify -->|"Building features"| Feature["Continue next<br/>unfinished feature"]
|
|
110
|
-
Classify -->|"All completed"| AskNext["Ask user for<br/>the next task"]
|
|
111
|
-
|
|
112
|
-
Init --> Step1["<b>Step 1:</b> Setup<br/>AGENTS.md + templates"]
|
|
113
|
-
Step1 --> Step2["<b>Step 2: ahe-spec</b><br/>Write PRODUCT.md<br/>and INSTRUCTIONS.md"]
|
|
114
|
-
Step2 --> Step3["<b>Step 3: ahe-update</b><br/>Sync feature-list.json<br/>and PROGRESS.md"]
|
|
115
|
-
Step3 --> Done["Harness ready ✓"]
|
|
116
|
-
|
|
117
|
-
Feature --> Compression["<b>ahe-compression</b><br/>Check & compress oversized files"]
|
|
118
|
-
Compression --> Thinking["<b>ahe-thinking</b><br/>Check Why / What / How"]
|
|
119
|
-
Thinking --> Clear{"Clear enough<br/>to proceed?"}
|
|
120
|
-
Clear -->|"No"| Convo["<b>ahe-conversation</b><br/>Ask one focused question"]
|
|
121
|
-
Convo --> UserAnswer["User answers"]
|
|
122
|
-
UserAnswer --> Thinking
|
|
123
|
-
Clear -->|"Yes"| Execute["Execute the<br/>next safe step"]
|
|
124
|
-
Execute --> Update["<b>ahe-update</b><br/>Sync tracking artifacts"]
|
|
125
|
-
Update --> Done2["Ready for next<br/><code>ahe</code> command ✓"]
|
|
126
|
-
```
|
|
127
|
-
|
|
128
|
-
### Detailed Steps
|
|
129
|
-
|
|
130
|
-
#### `ahe init` — New Start
|
|
131
|
-
|
|
132
|
-
1. Scans the workspace for existing harness files.
|
|
133
|
-
2. If files exist, asks the user what scope to restart (full restart, product-only, or custom).
|
|
134
|
-
3. Backs up affected files to `.ahe/backups/`.
|
|
135
|
-
4. Asks about project purpose, language, and tech stack.
|
|
136
|
-
5. Deploys template files (`AGENTS.md`, `PROGRESS.md`, `SESSION-HANDOFF.md`, `feature-list.json`, `init.sh`).
|
|
137
|
-
6. Calls **ahe-spec** → writes `docs/PRODUCT.md` and `docs/INSTRUCTIONS.md`.
|
|
138
|
-
7. Calls **ahe-update** → derives features and syncs tracking artifacts.
|
|
139
|
-
|
|
140
|
-
#### `ahe` — Continue Work
|
|
141
|
-
|
|
142
|
-
1. Hook injects the AHE router directive into the agent context.
|
|
143
|
-
2. Router inspects all harness files and prints a status table.
|
|
144
|
-
3. Classifies the current state:
|
|
145
|
-
- **"Not enough spec"** → routes to `ahe-init` to fill gaps.
|
|
146
|
-
- **"Building features"** → picks the next unfinished feature from `feature-list.json`.
|
|
147
|
-
- **"All completed"** → asks the user for the next task.
|
|
148
|
-
4. **ahe-thinking** checks file sizes using **ahe-compression** and compresses oversized files based on `config.yaml` thresholds.
|
|
149
|
-
5. **ahe-thinking** checks clarity (Why / What / How) for the current work unit.
|
|
150
|
-
6. If unclear → **ahe-conversation** asks exactly one question, then re-evaluates.
|
|
151
|
-
7. If clear → executes the next safe step.
|
|
152
|
-
8. **ahe-update** syncs all tracking artifacts at the end.
|
|
153
|
-
|
|
154
|
-
#### Execution Loop
|
|
155
|
-
|
|
156
|
-
The core loop repeats until the work unit is done:
|
|
157
|
-
|
|
158
|
-
```
|
|
159
|
-
thinking → conversation (if needed) → execution → thinking
|
|
160
|
-
```
|
|
161
|
-
|
|
162
|
-
---
|
|
163
|
-
|
|
164
|
-
## Project Structure
|
|
165
|
-
|
|
166
|
-
After `ahe install`, the following structure is added to your workspace:
|
|
167
|
-
|
|
168
|
-
```
|
|
169
|
-
your-project/
|
|
170
|
-
├── .codex/
|
|
171
|
-
│ ├── skills/
|
|
172
|
-
│ │ ├── ahe-init/ # New-start workflow skill
|
|
173
|
-
│ │ ├── ahe-conversation/ # Internal question protocol
|
|
174
|
-
│ │ ├── ahe-thinking/ # Internal decision engine
|
|
175
|
-
│ │ ├── ahe-compression/ # Internal size detector & compressor
|
|
176
|
-
│ │ ├── ahe-spec/ # Specification writer
|
|
177
|
-
│ │ └── ahe-update/ # Tracking artifact syncer
|
|
178
|
-
│ ├── ahe-shared/
|
|
179
|
-
│ │ ├── config.yaml # Compression thresholds & configuration
|
|
180
|
-
│ │ ├── templates/ # Harness file templates
|
|
181
|
-
│ │ └── schemas/ # Validation schemas
|
|
182
|
-
│ └── hooks/
|
|
183
|
-
│ ├── hooks.json # Chat command trigger patterns
|
|
184
|
-
│ └── ahe-hook.js # Hook script that injects directives
|
|
185
|
-
```
|
|
186
|
-
|
|
187
|
-
After `ahe init`, the harness files are created in your project root:
|
|
188
|
-
|
|
189
|
-
```
|
|
190
|
-
your-project/
|
|
191
|
-
├── docs/
|
|
192
|
-
│ ├── PRODUCT.md # Product specification (source of truth)
|
|
193
|
-
│ └── INSTRUCTIONS.md # Implementation instructions
|
|
194
|
-
├── .ahe/
|
|
195
|
-
│ └── process_status.json # Workflow state persistence
|
|
196
|
-
├── AGENTS.md # Project objectives and agent rules
|
|
197
|
-
├── feature-list.json # Feature state tracker (derived from PRODUCT.md)
|
|
198
|
-
├── PROGRESS.md # Session continuity log
|
|
199
|
-
├── SESSION-HANDOFF.md # Handoff notes between sessions
|
|
200
|
-
└── init.sh # Standard startup/verification script
|
|
201
|
-
```
|
|
202
|
-
|
|
203
|
-
## Agent Working Rules
|
|
204
|
-
|
|
205
|
-
If you are an AI agent working on this repository, please strictly follow the guidelines in [AGENTS.md](AGENTS.md). It includes critical instructions regarding the definition of done, verification commands, and file modification rules (e.g., you must update `PROGRESS.md` and `feature-list.json` appropriately).
|
|
206
|
-
|
|
207
|
-
## References
|
|
208
|
-
|
|
209
|
-
This repository was greatly influenced by the following projects:
|
|
210
|
-
|
|
211
|
-
- [oh-my-openagent](https://github.com/code-yeongyu/oh-my-openagent): Greatly influenced the code structure of this project.
|
|
212
|
-
- [learn-harness-engineering](https://github.com/walkinglabs/learn-harness-engineering): Provided the harness engineering templates used in this project.
|
|
213
|
-
|
|
214
|
-
## License
|
|
215
|
-
|
|
216
|
-
MIT
|
|
40
|
+
Only exact `ahe`, exact `ahe init`, exact `ahe-init`, exact `$ahe-init`, and
|
|
41
|
+
explicit `ahe <query>` activate the hook. Broad non-prefixed prompts do not.
|
package/bin/ahe
CHANGED
|
@@ -23,11 +23,12 @@ readonly AHE_CONFIG_BLOCK_START="# BEGIN AHE MANAGED CONFIG"
|
|
|
23
23
|
readonly AHE_CONFIG_BLOCK_END="# END AHE MANAGED CONFIG"
|
|
24
24
|
readonly MANAGED_SKILLS=(
|
|
25
25
|
"ahe-init"
|
|
26
|
-
"ahe-conversation"
|
|
27
26
|
"ahe-compression"
|
|
28
|
-
"ahe-
|
|
29
|
-
"ahe-
|
|
30
|
-
"ahe-
|
|
27
|
+
"ahe-conversator"
|
|
28
|
+
"ahe-harness"
|
|
29
|
+
"ahe-reviewer"
|
|
30
|
+
"ahe-solver"
|
|
31
|
+
"ahe-thinker"
|
|
31
32
|
)
|
|
32
33
|
|
|
33
34
|
usage() {
|
|
@@ -200,6 +201,7 @@ Next:
|
|
|
200
201
|
1. Open Codex chat in this workspace.
|
|
201
202
|
2. Use \`ahe init\` for a new start.
|
|
202
203
|
3. Use exact \`ahe\` to continue existing harness work.
|
|
204
|
+
4. Use \`ahe <query>\` for explicit AHE requests such as \`ahe compress feature-list\`.
|
|
203
205
|
EOF
|
|
204
206
|
}
|
|
205
207
|
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@ksuchoi216/ahe",
|
|
3
|
-
"version": "0.1.
|
|
3
|
+
"version": "0.1.7",
|
|
4
4
|
"description": "Codex chat workflow skill installer for Awesome Harness Engineering",
|
|
5
5
|
"publishConfig": {
|
|
6
6
|
"access": "public"
|
|
@@ -10,7 +10,8 @@
|
|
|
10
10
|
},
|
|
11
11
|
"scripts": {
|
|
12
12
|
"test": "pytest tests/ -x",
|
|
13
|
-
"prepublishOnly": "npm run test"
|
|
13
|
+
"prepublishOnly": "npm run test",
|
|
14
|
+
"postinstall": "echo \"\" && echo \"Awesome Harness Engineering CLI installed!\" && echo \"To install the skills in your project, run: ahe install\" && echo \"\" && echo \"If you wish to uninstall later, run: npm uninstall -g @ksuchoi216/ahe\""
|
|
14
15
|
},
|
|
15
16
|
"repository": {
|
|
16
17
|
"type": "git",
|
|
@@ -1,73 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: ahe-conversation
|
|
3
|
-
description: Internal AHE protocol for recursive clarification, conversation state, and resume-aware workflow guidance.
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# AHE Conversation
|
|
7
|
-
|
|
8
|
-
This is an internal AHE protocol skill, not a user-facing command.
|
|
9
|
-
|
|
10
|
-
Do not treat `$ahe-conversation` as a user command.
|
|
11
|
-
Use it only when another AHE workflow skill needs more conversation before it can
|
|
12
|
-
continue safely.
|
|
13
|
-
Use it after `ahe-thinking` identifies a missing decision or missing `Why`,
|
|
14
|
-
`What`, or `How`.
|
|
15
|
-
|
|
16
|
-
## When to Converse
|
|
17
|
-
|
|
18
|
-
Start or continue an AHE conversation when the missing answer materially changes
|
|
19
|
-
one of these:
|
|
20
|
-
|
|
21
|
-
- Project purpose or target user.
|
|
22
|
-
- Product behavior, scope, success criteria, or out-of-scope boundaries.
|
|
23
|
-
- Implementation instructions, architecture direction, or verification commands.
|
|
24
|
-
- Harness file ownership, overwrite behavior, or reset behavior.
|
|
25
|
-
- `.ahe/process_status.json`, `PROGRESS.md`, or `SESSION-HANDOFF.md` state.
|
|
26
|
-
- The next workflow step when several valid paths are possible.
|
|
27
|
-
- The missing `Why`, `What`, or `How` for the current `project`, `feature`, or
|
|
28
|
-
`sub-feature`.
|
|
29
|
-
|
|
30
|
-
If the missing detail can be inferred safely from existing files, infer
|
|
31
|
-
conservatively and record the assumption in the active workflow artifact.
|
|
32
|
-
|
|
33
|
-
## Conversation Protocol
|
|
34
|
-
|
|
35
|
-
- Inspect relevant existing files before asking.
|
|
36
|
-
- Let `ahe-thinking` judge what is missing before you ask.
|
|
37
|
-
- Explain the decision point briefly when context helps the user answer.
|
|
38
|
-
- Ask exactly one question at a time.
|
|
39
|
-
- Use a Codex-supported structured response request when meaningful options exist.
|
|
40
|
-
- Provide 2-3 mutually exclusive options when useful, and allow custom input when
|
|
41
|
-
predefined options are not enough.
|
|
42
|
-
- Keep each question specific to the active AHE workflow.
|
|
43
|
-
- Think through what the answer will unlock before asking.
|
|
44
|
-
- Ask again when the answer is vague, off-topic, contradictory, or incomplete
|
|
45
|
-
according to the calling skill's clarification criteria.
|
|
46
|
-
- Continue until the calling workflow has enough information to act.
|
|
47
|
-
- Do not expand the scope of questioning beyond the missing detail that
|
|
48
|
-
`ahe-thinking` identified.
|
|
49
|
-
|
|
50
|
-
## State Persistence
|
|
51
|
-
|
|
52
|
-
Before pausing for user input, update `.ahe/process_status.json` when it exists
|
|
53
|
-
or when the active workflow uses it:
|
|
54
|
-
|
|
55
|
-
- Set the active command or skill name.
|
|
56
|
-
- Set `workflow_complete` to `false`.
|
|
57
|
-
- Set `current_step` to the pending question, decision point, or missing field.
|
|
58
|
-
- Refresh `updated_at`.
|
|
59
|
-
- Preserve already collected project and product data.
|
|
60
|
-
|
|
61
|
-
Update `PROGRESS.md` and `SESSION-HANDOFF.md` when the pending conversation
|
|
62
|
-
changes the active workflow state, blocks completion, or affects the next
|
|
63
|
-
session's startup path.
|
|
64
|
-
|
|
65
|
-
## Resume Protocol
|
|
66
|
-
|
|
67
|
-
When resuming after the user answers:
|
|
68
|
-
|
|
69
|
-
- Read `.ahe/process_status.json` and the relevant workflow artifacts.
|
|
70
|
-
- Summarize the already collected data briefly.
|
|
71
|
-
- Identify the missing field or decision that is still blocking progress.
|
|
72
|
-
- Ask the next focused question, or continue the calling workflow when the
|
|
73
|
-
answer satisfies its clarification criteria.
|
|
@@ -1,63 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: ahe-spec
|
|
3
|
-
description: Internal AHE specification workflow for updating product and instructions docs.
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# AHE Spec
|
|
7
|
-
|
|
8
|
-
This is an internal AHE workflow skill, not a user-facing command.
|
|
9
|
-
|
|
10
|
-
Do not treat `$ahe-spec` as a user command.
|
|
11
|
-
Use it after `ahe-thinking` decides that specification work must continue.
|
|
12
|
-
|
|
13
|
-
## Command Workflow: ahe-spec
|
|
14
|
-
|
|
15
|
-
### Spec Inspection
|
|
16
|
-
|
|
17
|
-
- Read `docs/PRODUCT.md` if it exists.
|
|
18
|
-
- Read `docs/INSTRUCTIONS.md` if it exists.
|
|
19
|
-
- Read `AGENTS.md`, `feature-list.json`, `PROGRESS.md`, and `SESSION-HANDOFF.md`.
|
|
20
|
-
|
|
21
|
-
### Sequential Spec Conversation Flow
|
|
22
|
-
|
|
23
|
-
- `docs/PRODUCT.md` is the canonical home for product specification details collected during `ahe init`.
|
|
24
|
-
- Clarify product goal, scope, and success criteria when `docs/PRODUCT.md` needs to change.
|
|
25
|
-
- Clarify project instructions when `docs/INSTRUCTIONS.md` needs to change. If `docs/INSTRUCTIONS.md` is missing, create it from `.codex/ahe-shared/templates/INSTRUCTIONS.md` first, then ask what additional instructions belong under `## CAN CHANGE INSTRUCTIONS`.
|
|
26
|
-
- Draft the relevant specification updates in chat and ask for user approval.
|
|
27
|
-
- Ask recursively for more detail until the affected specification areas are clear and approved.
|
|
28
|
-
|
|
29
|
-
### Spec Completion
|
|
30
|
-
|
|
31
|
-
- Write product behavior, scope, requirements, success criteria, and workflow details into `docs/PRODUCT.md`.
|
|
32
|
-
- `docs/PRODUCT.md` is the canonical source of truth. Concrete feature items for `feature-list.json` must be derived from it only after it has been populated.
|
|
33
|
-
- Do not move product specification details into `AGENTS.md`.
|
|
34
|
-
- Update only the relevant docs among `docs/PRODUCT.md` and `docs/INSTRUCTIONS.md`.
|
|
35
|
-
- When updating `docs/INSTRUCTIONS.md`, only allow additions/removals/edits to instructions inside `## CAN CHANGE INSTRUCTIONS`; preserve `## MUST NOT CHANGE INSTRUCTIONS`.
|
|
36
|
-
- Update `.ahe/process_status.json`.
|
|
37
|
-
- Update `PROGRESS.md` and `SESSION-HANDOFF.md` when specification changes affect active work.
|
|
38
|
-
|
|
39
|
-
## Clarification Rule
|
|
40
|
-
|
|
41
|
-
When the next specification step is not clear, follow the `ahe-thinking` protocol first. If `ahe-thinking` finds missing information, follow the `ahe-conversation` protocol. Ask again recursively using a Codex-supported structured response request, provide 2-3 meaningful mutually exclusive options when possible, and allow custom input when predefined options are not enough.
|
|
42
|
-
|
|
43
|
-
### User Response Target
|
|
44
|
-
|
|
45
|
-
- Collect the product or instructions details required to update the relevant specification docs.
|
|
46
|
-
|
|
47
|
-
### Questions to Ask
|
|
48
|
-
|
|
49
|
-
- Ask who the product is for and what problem it solves when product intent is unclear.
|
|
50
|
-
- Ask what behavior, scope boundaries, and success criteria should be documented.
|
|
51
|
-
- Ask what rule, practice, or guideline should be documented as an instruction.
|
|
52
|
-
|
|
53
|
-
### Clarification Criteria
|
|
54
|
-
|
|
55
|
-
- The answer must identify the target user, product goal, main behavior, scope, and success signal when product details are changing.
|
|
56
|
-
- The answer must describe any instruction and its practical meaning clearly enough that another engineer can follow it.
|
|
57
|
-
- The answer must be concrete enough to update the relevant specification docs without guessing missing intent.
|
|
58
|
-
|
|
59
|
-
### Re-ask When
|
|
60
|
-
|
|
61
|
-
- Ask again when the answer is vague, contradictory, or incomplete.
|
|
62
|
-
- Ask again when the response gives features without explaining the user goal or success criteria.
|
|
63
|
-
- Ask again when the response names an instruction topic without the actual rule.
|