@ksuchoi216/ahe 0.1.6 → 0.1.7

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

@@ -1,104 +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
-
-- Before reading full harness files, decide whether compression is needed.
-  Run `sh .codex/skills/ahe-compression/scripts/check-harness-size.sh` when the
-  script exists (which checks against configurable thresholds in `.codex/ahe-shared/config.yaml`),
-  or fall back to `wc -l` over `AGENTS.md`, `docs/PRODUCT.md`, `docs/INSTRUCTIONS.md`, 
-  `feature-list.json`, `PROGRESS.md`, `SESSION-HANDOFF.md`, and `docs/todo.md`.
-- If the detector reports `COMPRESSION_REQUIRED` or exits with code `2`, call
-  `ahe-compression` before normal routing. Do not spend context reading the
-  oversized files wholesale first.
-- 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.
-
-## Broad User Intent Routing
-
-When the user provides a broad natural-language work intent (e.g., "add features", "update spec"), use their original prompt to determine the exact path:
-- Route **product/spec changes** to `ahe-spec`.
-- Route **instruction changes** to `ahe-spec`.
-- Route **feature/todo tracking** to `ahe-update`.
-- Route **unclear AHE work** to `ahe-conversation` and ask exactly one detail question before editing if the request is vague.
-
-## 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.