@ksuchoi216/ahe 0.1.2 → 0.1.7

package/bin/ahe

@@ -19,12 +19,16 @@ readonly PACKAGE_ROOT="$(CDPATH= cd -- "${SCRIPT_DIR}/.." && pwd)"
 readonly SOURCE_SKILLS_DIR="${PACKAGE_ROOT}/.codex/skills"
 readonly SOURCE_SHARED_DIR="${PACKAGE_ROOT}/.codex/ahe-shared"
 readonly SOURCE_HOOKS_DIR="${PACKAGE_ROOT}/.codex/hooks"
+readonly AHE_CONFIG_BLOCK_START="# BEGIN AHE MANAGED CONFIG"
+readonly AHE_CONFIG_BLOCK_END="# END AHE MANAGED CONFIG"
 readonly MANAGED_SKILLS=(
   "ahe-init"
-  "ahe-conversation"
-  "ahe-thinking"
-  "ahe-spec"
-  "ahe-update"
+  "ahe-compression"
+  "ahe-conversator"
+  "ahe-harness"
+  "ahe-reviewer"
+  "ahe-solver"
+  "ahe-thinker"
 )
 
 usage() {
@@ -48,6 +52,48 @@ backup_existing_installation() {
   mv "${target_dir}" "${backup_root}/${backup_name}-${timestamp}"
 }
 
+cleanup_ahe_config_entries() {
+  local config_path="$1"
+  local temp_path=""
+
+  if [ ! -f "${config_path}" ]; then
+    return 0
+  fi
+
+  temp_path="${config_path}.ahe-cleanup"
+  awk -v block_start="${AHE_CONFIG_BLOCK_START}" -v block_end="${AHE_CONFIG_BLOCK_END}" '
+    function is_ahe_header(line) {
+      return line ~ /^\[agents\."?ahe[-_][^]]*"?\]$/ ||
+        line ~ /^\[hooks\.state\."ahe[^"]*"\]$/ ||
+        line ~ /^\[plugins\."?ahe[^]]*"?\]$/ ||
+        line ~ /^\[plugins\."@ksuchoi216\/ahe[^"]*"\]$/
+    }
+
+    $0 == block_start {
+      skip = 1
+      next
+    }
+
+    $0 == block_end {
+      skip = 0
+      next
+    }
+
+    /^\[/ {
+      if (is_ahe_header($0)) {
+        skip = 1
+        next
+      }
+      skip = 0
+    }
+
+    skip != 1 {
+      print
+    }
+  ' "${config_path}" > "${temp_path}"
+  mv "${temp_path}" "${config_path}"
+}
+
 install_skill() {
   local force="false"
   local backup="false"
@@ -82,10 +128,13 @@ install_skill() {
   local target_skills_dir="${PWD}/.codex/skills"
   local target_shared_dir="${PWD}/.codex/ahe-shared"
   local target_hooks_dir="${PWD}/.codex/hooks"
+  local target_config_path="${PWD}/.codex/config.toml"
   local backup_dir="${PWD}/.codex/_backups"
   local skill_name=""
   local skill_target=""
 
+  cleanup_ahe_config_entries "${target_config_path}"
+
   for skill_name in "${MANAGED_SKILLS[@]}"; do
     skill_target="${target_skills_dir}/${skill_name}"
 
@@ -152,6 +201,7 @@ Next:
 1. Open Codex chat in this workspace.
 2. Use \`ahe init\` for a new start.
 3. Use exact \`ahe\` to continue existing harness work.
+4. Use \`ahe <query>\` for explicit AHE requests such as \`ahe compress feature-list\`.
 EOF
 }
 
@@ -168,6 +218,11 @@ doctor() {
     fi
   done
 
+  if [ ! -f "${target_shared_dir}/config.yaml" ]; then
+    printf 'Missing: %s/config.yaml\n' "${target_shared_dir}" >&2
+    exit 1
+  fi
+
   if [ ! -d "${target_shared_dir}/templates" ]; then
     printf 'Missing: %s/templates\n' "${target_shared_dir}" >&2
     exit 1
@@ -190,6 +245,7 @@ uninstall_skill() {
   local target_skills_dir="${PWD}/.codex/skills"
   local target_shared_dir="${PWD}/.codex/ahe-shared"
   local target_hooks_dir="${PWD}/.codex/hooks"
+  local target_config_path="${PWD}/.codex/config.toml"
   local skill_name=""
 
   echo "Uninstalling AHE skills from ${PWD}/.codex..."
@@ -200,6 +256,7 @@ uninstall_skill() {
 
   rm -rf "${target_shared_dir}"
   rm -rf "${target_hooks_dir}"
+  cleanup_ahe_config_entries "${target_config_path}"
 
   echo "AHE skills uninstalled successfully."
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ksuchoi216/ahe",
-  "version": "0.1.2",
+  "version": "0.1.7",
   "description": "Codex chat workflow skill installer for Awesome Harness Engineering",
   "publishConfig": {
     "access": "public"
@@ -10,7 +10,8 @@
   },
   "scripts": {
     "test": "pytest tests/ -x",
-    "prepublishOnly": "npm run test"
+    "prepublishOnly": "npm run test",
+    "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\""
   },
   "repository": {
     "type": "git",
@@ -30,4 +31,4 @@
     ".codex/"
   ],
   "license": "MIT"
-}
+}

package/.codex/skills/ahe-conversation/SKILL.md

@@ -1,73 +0,0 @@
----
-name: ahe-conversation
-description: Internal AHE protocol for recursive clarification, conversation state, and resume-aware workflow guidance.
----
-
-# AHE Conversation
-
-This is an internal AHE protocol skill, not a user-facing command.
-
-Do not treat `$ahe-conversation` as a user command.
-Use it only when another AHE workflow skill needs more conversation before it can
-continue safely.
-Use it after `ahe-thinking` identifies a missing decision or missing `Why`,
-`What`, or `How`.
-
-## When to Converse
-
-Start or continue an AHE conversation when the missing answer materially changes
-one of these:
-
-- Project purpose or target user.
-- Product behavior, scope, success criteria, or out-of-scope boundaries.
-- Implementation instructions, architecture direction, or verification commands.
-- Harness file ownership, overwrite behavior, or reset behavior.
-- `.ahe/process_status.json`, `PROGRESS.md`, or `SESSION-HANDOFF.md` state.
-- The next workflow step when several valid paths are possible.
-- The missing `Why`, `What`, or `How` for the current `project`, `feature`, or
-  `sub-feature`.
-
-If the missing detail can be inferred safely from existing files, infer
-conservatively and record the assumption in the active workflow artifact.
-
-## Conversation Protocol
-
-- Inspect relevant existing files before asking.
-- Let `ahe-thinking` judge what is missing before you ask.
-- Explain the decision point briefly when context helps the user answer.
-- Ask exactly one question at a time.
-- Use a Codex-supported structured response request when meaningful options exist.
-- Provide 2-3 mutually exclusive options when useful, and allow custom input when
-  predefined options are not enough.
-- Keep each question specific to the active AHE workflow.
-- Think through what the answer will unlock before asking.
-- Ask again when the answer is vague, off-topic, contradictory, or incomplete
-  according to the calling skill's clarification criteria.
-- Continue until the calling workflow has enough information to act.
-- Do not expand the scope of questioning beyond the missing detail that
-  `ahe-thinking` identified.
-
-## State Persistence
-
-Before pausing for user input, update `.ahe/process_status.json` when it exists
-or when the active workflow uses it:
-
-- Set the active command or skill name.
-- Set `workflow_complete` to `false`.
-- Set `current_step` to the pending question, decision point, or missing field.
-- Refresh `updated_at`.
-- Preserve already collected project and product data.
-
-Update `PROGRESS.md` and `SESSION-HANDOFF.md` when the pending conversation
-changes the active workflow state, blocks completion, or affects the next
-session's startup path.
-
-## Resume Protocol
-
-When resuming after the user answers:
-
-- Read `.ahe/process_status.json` and the relevant workflow artifacts.
-- Summarize the already collected data briefly.
-- Identify the missing field or decision that is still blocking progress.
-- Ask the next focused question, or continue the calling workflow when the
-  answer satisfies its clarification criteria.

package/.codex/skills/ahe-spec/SKILL.md

@@ -1,63 +0,0 @@
----
-name: ahe-spec
-description: Internal AHE specification workflow for updating product and instructions docs.
----
-
-# AHE Spec
-
-This is an internal AHE workflow skill, not a user-facing command.
-
-Do not treat `$ahe-spec` as a user command.
-Use it after `ahe-thinking` decides that specification work must continue.
-
-## Command Workflow: ahe-spec
-
-### Spec Inspection
-
-- Read `docs/PRODUCT.md` if it exists.
-- Read `docs/INSTRUCTIONS.md` if it exists.
-- Read `AGENTS.md`, `feature-list.json`, `PROGRESS.md`, and `SESSION-HANDOFF.md`.
-
-### Sequential Spec Conversation Flow
-
-- `docs/PRODUCT.md` is the canonical home for product specification details collected during `ahe init`.
-- Clarify product goal, scope, and success criteria when `docs/PRODUCT.md` needs to change.
-- Clarify project instructions when `docs/INSTRUCTIONS.md` needs to change.
-- Draft the relevant specification updates in chat and ask for user approval.
-- Ask recursively for more detail until the affected specification areas are clear and approved.
-
-### Spec Completion
-
-- Write product behavior, scope, requirements, success criteria, and workflow details into `docs/PRODUCT.md`.
-- `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.
-- Do not move product specification details into `AGENTS.md`.
-- Update only the relevant docs among `docs/PRODUCT.md` and `docs/INSTRUCTIONS.md`.
-- When updating `docs/INSTRUCTIONS.md`, only allow additions/removals/edits to instructions inside `## CAN CHANGE INSTRUCTIONS`; preserve `## MUST NOT CHANGE INSTRUCTIONS`.
-- Update `.ahe/process_status.json`.
-- Update `PROGRESS.md` and `SESSION-HANDOFF.md` when specification changes affect active work.
-
-## Clarification Rule
-
-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.
-
-### User Response Target
-
-- Collect the product or instructions details required to update the relevant specification docs.
-
-### Questions to Ask
-
-- Ask who the product is for and what problem it solves when product intent is unclear.
-- Ask what behavior, scope boundaries, and success criteria should be documented.
-- Ask what rule, practice, or guideline should be documented as an instruction.
-
-### Clarification Criteria
-
-- The answer must identify the target user, product goal, main behavior, scope, and success signal when product details are changing.
-- The answer must describe any instruction and its practical meaning clearly enough that another engineer can follow it.
-- The answer must be concrete enough to update the relevant specification docs without guessing missing intent.
-
-### Re-ask When
-
-- Ask again when the answer is vague, contradictory, or incomplete.
-- Ask again when the response gives features without explaining the user goal or success criteria.
-- Ask again when the response names an instruction topic without the actual rule.

package/.codex/skills/ahe-thinking/SKILL.md

@@ -1,88 +0,0 @@
----
-name: ahe-thinking
-description: Internal AHE orchestration protocol for deciding what to clarify, what to execute, and what to do next.
----
-
-# AHE Thinking
-
-This is an internal AHE protocol skill, not a user-facing command.
-
-Do not treat `$ahe-thinking` as a user command.
-Use it before and between AHE workflow actions when the next safe step is not
-already obvious.
-
-## Purpose
-
-- Judge what is missing before another AHE workflow acts.
-- Decide whether the current unit is clear enough to execute safely.
-- Call `ahe-conversation` only when clarification is still needed.
-- Continue to the next skill or next unfinished feature when the path is clear.
-
-## Units of Work
-
-Inspect the current unit as `project`, `feature`, or `sub-feature`.
-
-- `project`: overall goal, target user, expected outcome, and delivery
-  direction.
-- `feature`: one concrete capability or work item under the project.
-- `sub-feature`: one smaller capability or step under a feature.
-
-## Clarity Judgment
-
-Judge the current unit against `Why`, `What`, and `How`.
-
-- `Why`: why this unit matters, what problem it solves, or what purpose it
-  serves.
-- `What`: what result, behavior, or output should be built.
-- `How`: how the work should be approached when methodology or architecture
-  matters.
-
-### Project Rule
-
-For a `project`, require `Why`, `What`, and `How` by default before moving
-forward.
-
-### Feature Rule
-
-For a `feature` or `sub-feature`, require only the minimum needed to proceed
-safely.
-
-- If the feature is already clear from the project context, do not ask all
-  three again.
-- If only the result is missing, ask only `What`.
-- If the feature goal is clear but the implementation direction is risky or
-  materially different, ask `How`.
-- If the feature exists but its purpose is unclear, ask `Why`.
-
-## Next-Step Decision
-
-- If `docs/PRODUCT.md` or `docs/INSTRUCTIONS.md` is missing or empty, classify the state as
-  `harness engineering not enough` and prioritize product/instructions specification work.
-- `docs/PRODUCT.md` and `docs/INSTRUCTIONS.md` form the required harness contract. `docs/PRODUCT.md` is the product/specification source of truth, and
-  `feature-list.json` is a derived tracker. Do not write specific feature items
-  to `feature-list.json` until `docs/PRODUCT.md` and `docs/INSTRUCTIONS.md` are established.
-- If other harness essentials are missing or inconsistent, classify the state as
-  `harness engineering not enough` and continue the harness-building workflow.
-- If the harness exists and there is unfinished tracked work, classify the
-  state as `in the middle of building features` and continue the first safe
-  unfinished feature.
-- If tracked work is complete and no obvious essential harness gap remains,
-  classify the state as `completed all` and ask for the next task.
-
-## Conversation Handoff
-
-If clarity is missing, call `ahe-conversation` with the exact missing `Why`,
-`What`, or `How`.
-
-- Explain which unit is blocked.
-- Explain what answer will unlock the next action.
-- Ask for only the minimum missing detail.
-- When the path is clear, continue to the next skill or next unfinished feature.
-
-## Execution Loop
-
-Follow this loop whenever AHE is routing or continuing work:
-
-`thinking -> conversation if needed -> execution -> thinking`
-
-After execution, reassess the active unit before choosing the next step.

package/.codex/skills/ahe-update/SKILL.md

@@ -1,66 +0,0 @@
----
-name: ahe-update
-description: Internal AHE workflow for synchronizing tracked work and handoff artifacts.
----
-
-# AHE Update
-
-This is an internal AHE workflow skill, not a user-facing command.
-
-Do not treat `$ahe-update` as a user command.
-Use it after `ahe-thinking` decides that tracked harness work should be synchronized.
-
-## Command Workflow: ahe-update
-
-- Read `feature-list.json`.
-- Read `PROGRESS.md` if it exists.
-- Read `SESSION-HANDOFF.md`.
-- Read `docs/todo.md` when it exists.
-- If the user is adding new work, clarify the todo item, append it under the last `## TODO` section in `docs/todo.md`, and create that section when it does not exist.
-- Apply the queued `docs/todo.md` content to `docs/PRODUCT.md`. If `docs/PRODUCT.md` does not exist, create it.
-- Remove the applied content from `docs/todo.md` because that todo content was already applied in `docs/PRODUCT.md`.
-- Update `feature-list.json` to derive the specific feature items from the updated `docs/PRODUCT.md`.
-- Update `PROGRESS.md`.
-- Update `SESSION-HANDOFF.md`.
-
-## Clarification Rule
-
-When the next update 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.
-
-### User Response Target
-
-- Collect either an actionable todo entry to queue or a clear instruction to synchronize the existing queued work.
-
-### Questions to Ask
-
-- Ask what work needs to be done when the user is adding a new todo item.
-- Ask which file, feature area, or workflow the todo affects.
-- Ask what outcome or completion signal the todo should capture.
-- Ask whether the user wants to queue new work, apply queued work, or do both when that is unclear.
-
-### Clarification Criteria
-
-- The answer must describe actionable work, the affected area, and the intended outcome when queuing a todo item.
-- The answer must be clear enough to decide whether to queue work, apply queued work, or do both.
-
-### Re-ask When
-
-- Ask again when the answer is too broad, off-topic, or only names a topic without describing the work.
-- Ask again when dependencies, affected area, intended outcome, or update action are still unclear.
-
-## Session Tracking and Handoff Sync
-
-### Tracking Update Rules
-
-- Update `.ahe/process_status.json` at workflow start.
-- Update `.ahe/process_status.json` after every answered question.
-- Refresh `updated_at` every time workflow state changes.
-- Keep `current_command`, `current_step`, and `workflow_complete` aligned with the active workflow state.
-- Keep the `files` status map aligned with the actual workspace files.
-
-### Progress and Handoff Content Requirements
-
-- Update `PROGRESS.md` whenever the active feature, workflow status, blockers, or verification state changes.
-- Update `SESSION-HANDOFF.md` whenever the current objective, completed work, important files, verification evidence, or recommended next step changes.
-- PROGRESS.md must reflect the current active feature and latest completed work.
-- SESSION-HANDOFF.md must leave the next Codex session with a concrete startup path.