@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.
@@ -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 backing up, removing, overwriting, or refreshing existing harness files.
27
- - Do not back up, remove, overwrite, or refresh existing harness files until the restart scope is clear.
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`, back up the current product/specification files in scope, 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 after backing up the affected files.
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-spec` so they are written in `docs/PRODUCT.md` first.
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
- - If the workspace already has active harness files and the user chooses a restart scope, create a timestamped backup directory under `.ahe/backups/`.
43
- - Copy `AGENTS.md` into the backup directory when it exists.
44
- - Copy the current `docs/PRODUCT.md` into the backup directory when it exists.
45
- - Copy the current `PROGRESS.md` into the backup directory when it exists.
46
- - Copy the current `SESSION-HANDOFF.md` into the backup directory when it exists.
47
- - Copy the current `feature-list.json` into the backup directory when it exists.
48
- - Copy `init.sh` into the backup directory when it exists.
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 three steps sequentially, updating the progress status (`current_step` in `.ahe/process_status.json`):
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-spec" (status: "ahe-spec")
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-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.
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 backed up or replaced.
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 automatically builds and maintains project harnesses through Codex chat. It installs a set of Codex skills into your workspace, then guides you through defining your project specification, tracking features, and managing progress — all via natural conversation.
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
- ## 1. Installation
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
- ### Quick Start (Recommended)
20
+ ## Routing Model
10
21
 
11
- ```bash
12
- npx --yes --package=@ksuchoi216/ahe ahe install
13
- ```
22
+ The internal model is centered but flexible:
14
23
 
15
- ### Global Install
24
+ `query -> ahe-thinker -> ahe-reviewer | ahe-conversator | ahe-harness | ahe-solver`
16
25
 
17
- ```bash
18
- npm install -g @ksuchoi216/ahe
19
- ahe install
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
- ### Local Development
32
+ ## Query Examples
23
33
 
24
- After cloning the repository:
34
+ - `ahe`
35
+ - `ahe init`
36
+ - `ahe compress feature-list`
37
+ - `ahe update product spec`
38
+ - `ahe add dashboard export feature`
25
39
 
26
- ```bash
27
- npx --yes --package=file:. ahe install
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 &amp; 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-thinking"
29
- "ahe-spec"
30
- "ahe-update"
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.6",
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.