hive-lite 0.1.0

package/docs/cli-semantics.md

@@ -0,0 +1,386 @@
+# Hive Lite CLI Semantics
+
+This document explains the important CLI states and what an operator or skill should do next.
+
+Use human-readable output when a person is reading the terminal. Use `--json` when a skill, agent, script, or future companion UI needs stable fields.
+
+```bash
+node bin/hive.js next
+node bin/hive.js next --json
+```
+
+## `--json`
+
+`--json` switches a command from human text to structured JSON.
+
+Use text output for humans:
+
+```bash
+node bin/hive.js next
+```
+
+Use JSON for skills and agents:
+
+```bash
+node bin/hive.js next --json
+node bin/hive.js next --agent codex --json
+```
+
+Human output explains the result. JSON output is a stable contract with fields such as `phaseGuess`, `summaryForHuman`, `primaryAction`, `verdict`, `mode`, and `recommendedActions`.
+
+## `next`
+
+`next` is Hive Lite's "what should happen now?" command. It does not edit files, run agents, validate, accept, commit, stash, or initialize git. It only reads local facts and recommends an operator step.
+
+It reads:
+
+- git repo presence
+- worktree state
+- latest Hive Change Record
+- Project Map health
+- actionable recent split notes
+- pending map delta candidates
+
+By default, `status --json` and `next --json` filter split notes to reduce exploratory clutter. They show active unfinished split notes that already have accepted phase progress. If no active split exists, they show only the newest unstarted split note. `splitNoteSummary` reports how many split notes were hidden by this default policy. Use `status --all --json` to inspect every runtime split note.
+`splitNoteSummary.primaryRecentSplitNote` identifies the split note selected as primary from the visible notes. `splitNoteSummary.otherActiveSplitNotes` lists older active-progress split notes so an operator can tell whether additional historical split work exists.
+
+Hive Lite cannot detect the currently running agent CLI. If the caller provides `--agent <codex|claude|gemini|all>` or `--path <skills-dir>`, `next` treats the recommended Hive Lite operator skill as a precondition. When the selected target is missing that skill or has a stale copy, `phaseGuess` becomes `skill_preflight` and `primaryAction.kind` becomes `install_operator_skill`.
+
+### `phaseGuess`
+
+| Value | Meaning | What To Do |
+| --- | --- | --- |
+| `repo_setup_required` | Current directory is not inside a git repo. | Stop. Switch to the correct repo root, or manually initialize git and create an initial commit before using Hive Lite. |
+| `skill_preflight` | The selected agent target is missing the operator skill needed for the next Hive Lite step. | Run the recommended `skills install` or `skills sync`, then rerun `next`. |
+| `preflight` | Worktree has unmanaged dirty changes. | Stop before starting new work. Commit, stash, use a separate worktree, or stop. |
+| `finish` | A Hive change is in progress, or was accepted without commit. | Use `$hive-lite-finish` to check, validate, record evidence, accept, or commit. |
+| `map` | Project Map is missing, invalid, critical, or needs attention. | Use `$hive-lite-map-maintainer` to bootstrap, refresh, or repair the map. |
+| `split_continue` | A previous large intent has a split note with a ready remaining phase. | Ask the human whether to continue the suggested phase through `$hive-lite-start-prompt`. |
+| `start` | Worktree and map are ready for a new bounded requirement. | Use `$hive-lite-start-prompt` with the user's next requirement. |
+
+### Example Human Output
+
+```text
+Hive Lite Next
+
+Current State:
+  Worktree: dirty
+  Hive State: in_progress
+
+Phase Guess: finish
+
+Recommended Next Action:
+  Use hive-lite-finish
+```
+
+### Example JSON Shape
+
+```json
+{
+  "phaseGuess": "finish",
+  "summaryForHuman": "当前有一个 Hive change 还在进行中，建议先用 hive-lite-finish 收尾。",
+  "primaryAction": {
+    "kind": "run_finish_skill",
+    "label": "Use hive-lite-finish",
+    "prompt": "$hive-lite-finish\nClose Hive Lite change chg_xxx."
+  }
+}
+```
+
+## `status`
+
+`status` classifies the repository boundary. It is the preflight check before starting a requirement.
+
+```bash
+node bin/hive.js status
+node bin/hive.js status --json
+```
+
+### `hive.state`
+
+| Value | Meaning | What To Do |
+| --- | --- | --- |
+| `repo_setup_required` | Not inside a git worktree. | Stop. Do not auto-run `git init`. |
+| `clean` | Worktree is clean. | It is safe to start `find`. |
+| `unmanaged_dirty` | Dirty files are not tied to a Hive Change Record. | Stop and ask the human to commit, stash, use a worktree, or stop. |
+| `in_progress` | Dirty files belong to an unfinished Hive Change Record. | Continue finish flow: `check`, `validate`, manual evidence, or `accept`. |
+| `accepted_uncommitted` | Latest Hive Change Record was accepted, but no commit was created. | Commit the accepted change or isolate the work before starting another requirement. |
+
+## `find`
+
+`find` turns a user intent into a Context Packet.
+
+```bash
+node bin/hive.js find "Dashboard Action Inbox content should align left" --explain
+node bin/hive.js find "Dashboard Action Inbox content should align left" --json
+```
+
+### `mode`
+
+| Value | Meaning | What To Do |
+| --- | --- | --- |
+| `edit_context` | Hive found one bounded area and narrow writable scope. | Give the Context Packet to a coding agent. |
+| `discovery_context` | Hive found useful context, but not a safe edit permit. | Repair the map or use for investigation only. |
+| `needs_map` | Hive could not confidently route the intent. | Use `$hive-lite-map-maintainer` or `map prompt --from-find ctx_xxx`. |
+| `needs_decomposition` | The intent is too broad for one Context Packet / Change Record. | Do not generate a coding prompt. Present phase seeds and ask the human which phase to start. |
+
+### Important Fields
+
+- `id`: Context Packet id, such as `ctx_xxx`
+- `mode`: whether the packet is editable, discovery-only, map-needing, or too broad
+- `area.id`: selected Project Map area
+- `writableScope`: direct writable files
+- `reviewGated`: conditional or broad fallback scope that requires review
+- `splitNote`: split artifact path when mode is `needs_decomposition`
+- `candidatePhaseSeeds`: phase seeds for large intents
+
+When continuing a split phase, pass the recorded split and phase ids plus the phase primary area:
+
+```bash
+node bin/hive.js find "<phase.findIntent>" --from-split split_xxx --phase phase_xxx --area area.id --json
+```
+
+`--from-split` + `--phase` constrains routing to the selected phase's primary area when the split note is available.
+If the split note or phase cannot be found, the result is not an edit permit and `phaseDependencyStatus.canStartNormally` is `false`.
+If `--area` disagrees with the recorded phase area, Hive Lite routes to the recorded phase area and reports a warning.
+Split-note markdown renders the current Hive Lite CLI invocation first, such as `node /path/to/bin/hive.js ...` when run from a source checkout, and includes `hive-lite ...` as a fallback for environments where the package alias is installed.
+
+## `skills`
+
+`skills` installs and checks the Hive Lite operator skills that teach agent CLIs how to drive Hive Lite.
+
+Hive Lite does not detect which agent CLI is installed or currently running. `skills doctor` only checks the selected skills directories: all known target paths by default, explicit target paths with `--agent`, or a custom directory with `--path`.
+
+`--agent codex`, `--agent claude`, and `--agent gemini` are global user-skill targets. They write to and check `~/.codex/skills`, `~/.claude/skills`, and `~/.gemini/skills` respectively; they do not populate repo-local agent skill directories. Use `--path <dir>` only for an intentional custom repo-local copy.
+
+Bundled skills:
+
+- `hive-lite-start-prompt`
+- `hive-lite-finish`
+- `hive-lite-map-maintainer`
+
+### Targets
+
+| Target | Path | Scope |
+| --- | --- | --- |
+| `codex` | `~/.codex/skills` | global user |
+| `claude` | `~/.claude/skills` | global user |
+| `gemini` | `~/.gemini/skills` | global user |
+| `all` | `codex`, `claude`, and `gemini` |
+| `--path <dir>` | custom skills directory | custom |
+
+### Commands
+
+```bash
+node bin/hive.js skills doctor
+node bin/hive.js skills doctor --agent codex
+node bin/hive.js skills doctor --path ~/.codex/skills --json
+```
+
+`doctor` reports each bundled skill as:
+
+| Status | Meaning | What To Do |
+| --- | --- | --- |
+| `current` | Installed copy matches bundled copy. | Nothing needed. |
+| `missing` | Skill is not installed at the target path. | Run `skills install`. |
+| `stale` | Skill exists but differs from the bundled copy. | Run `skills sync` or `skills install --force` if you want to overwrite. |
+
+Install missing skills:
+
+```bash
+node bin/hive.js skills install --agent codex
+node bin/hive.js skills install --agent claude
+node bin/hive.js skills install --agent gemini
+node bin/hive.js skills install --agent all
+node bin/hive.js skills install --path /custom/skills/dir
+```
+
+`install` does not overwrite stale skills by default. This protects local edits.
+
+Overwrite stale skills with bundled copies:
+
+```bash
+node bin/hive.js skills sync --agent codex
+node bin/hive.js skills sync --agent all
+node bin/hive.js skills sync --path /custom/skills/dir
+```
+
+Safety:
+
+- These commands copy only `docs/skills/hive-lite-*` directories.
+- They do not run agents.
+- They do not modify product code.
+- They do not edit secrets or agent runtime config.
+- `sync` may overwrite local edits inside the target Hive Lite skill directories.
+
+## `check`
+
+`check` captures the current dirty diff as a Change Record and evaluates scope, risk, validation status, and evidence policy.
+
+```bash
+node bin/hive.js check --context ctx_xxx
+node bin/hive.js check --context ctx_xxx --json
+node bin/hive.js check chg_xxx
+```
+
+### Scope Status
+
+| Value | Meaning | What To Do |
+| --- | --- | --- |
+| `clean` | Changed files are inside direct writable scope. | Continue to validation/evidence. |
+| `needs_review` | Changed files touched conditional or broad fallback scope. | Require a review reason before accept. |
+| `violation` | Changed files touched forbidden or outside allowed scope. | Stop. Fix the diff or repair the map; do not accept. |
+
+### Evidence Verdict
+
+| Value | Meaning | What To Do |
+| --- | --- | --- |
+| `acceptable` | Required evidence is sufficient. | Ask human whether to accept and commit. |
+| `needs_validation` | Required command validation has not run. | Run `validate`. |
+| `needs_manual_verification` | A directly visible change needs a human evidence note. | Ask the human to verify, then record manual evidence. |
+| `needs_review_reason` | Hive needs an explicit human review reason. | Ask for or draft a review reason and wait for confirmation. |
+| `evidence_insufficient` | Evidence is weak for this kind of change. | Prefer focused evidence; otherwise require review reason or explicit risk acceptance. |
+| `blocked` | Scope violation, failed validation, or another blocker. | Stop. Do not accept. |
+
+## `validate`
+
+`validate` records evidence on a Change Record.
+
+Run configured validation:
+
+```bash
+node bin/hive.js validate chg_xxx
+node bin/hive.js validate chg_xxx --profile dashboard-build
+```
+
+Run a custom validation command:
+
+```bash
+node bin/hive.js validate chg_xxx --cmd "npm test"
+```
+
+Record manual evidence:
+
+```bash
+node bin/hive.js validate chg_xxx \
+  --manual manual-verification \
+  --result passed \
+  --note "Opened the UI and confirmed the requested behavior."
+```
+
+Manual `--result` values:
+
+| Value | Meaning |
+| --- | --- |
+| `passed` | Human verified the behavior. |
+| `failed` | Human checked and found a problem. |
+| `not_applicable` | The manual profile does not apply to this change. |
+
+Manual evidence must come from the human. An agent summary is not manual evidence.
+
+Failed manual evidence is optional. If the human says the implementation is wrong, the default flow is:
+
+```text
+do not accept
+give the same Context Packet plus the failure observation back to the coding agent
+agent repairs within the same boundaries
+rerun check --context ctx_xxx
+rerun validation/manual verification
+accept only after evidence is sufficient
+```
+
+Record `--result failed` only when the human wants the failed attempt captured as evidence. If failed evidence is recorded, the current Change Record is blocked; the repair attempt should produce a fresh Change Record with `check --context ctx_xxx`.
+
+## `accept`
+
+`accept` records the human decision.
+
+Normal accept:
+
+```bash
+node bin/hive.js accept chg_xxx
+node bin/hive.js accept chg_xxx --commit -m "Update Action Inbox layout"
+```
+
+Reviewed accept:
+
+```bash
+node bin/hive.js accept chg_xxx \
+  --reviewed \
+  --reason "Reviewed grouping logic; validation passed and the change is isolated."
+```
+
+Explicit risk acceptance:
+
+```bash
+node bin/hive.js accept chg_xxx \
+  --accept-risk \
+  --reason "No focused test exists yet; accepting a low-risk isolated change after review."
+```
+
+Rules:
+
+- `blocked` cannot be accepted in the MVP.
+- `needs_validation` should validate first.
+- `needs_manual_verification` should record manual evidence first.
+- `needs_review_reason` and `evidence_insufficient` require a human reason or explicit risk acceptance.
+- `--commit` creates the git boundary for the accepted change.
+
+## `map verify`
+
+`map verify` checks whether the Project Map files exist, parse, and reference valid validation profiles and entrypoint shapes.
+
+```bash
+node bin/hive.js map verify
+node bin/hive.js map verify --json
+```
+
+JSON output includes `status`, `mapDir`, `problems`, `errors`, and `warnings`. `errors` is an alias of `problems` for agent workflows that expect an errors field.
+
+## `map health`
+
+`map health` checks whether the Project Map can support safe `find` and useful `check` evidence policy.
+
+```bash
+node bin/hive.js map health
+node bin/hive.js map health --area dashboard.action_inbox
+node bin/hive.js map health --json
+```
+
+### Status
+
+| Value | Meaning | What To Do |
+| --- | --- | --- |
+| `healthy` | No critical/warning findings. | Map can support edit-ready areas. |
+| `needs_attention` | Map has warnings. | Refresh or repair if relevant to the next requirement. |
+| `unsafe_for_edit_context` | Map has critical findings. | Repair map before relying on edit context. |
+| `invalid_map` | Map YAML/schema is missing or invalid. | Fix map files before using Hive Lite. |
+
+## `map prompt`
+
+`map prompt` generates a prompt for a map-maintainer agent. It does not call an LLM and does not edit files itself.
+
+```bash
+node bin/hive.js map prompt --focus "Dashboard surfaces" --max-areas 8
+node bin/hive.js map prompt --from-find ctx_xxx
+node bin/hive.js map prompt --from-find ctx_xxx --json
+```
+
+Use cases:
+
+- bootstrap a first Project Map
+- refresh stale areas
+- repair one intent after `find` returns `needs_map` or `discovery_context`
+- add roles / verification policy so `check` can judge evidence better
+
+## `map delta`
+
+Accepted changes may produce Map Delta Candidates. A delta is a suggestion, not automatic durable knowledge.
+
+```bash
+node bin/hive.js map delta list
+node bin/hive.js map delta apply delta_xxx
+node bin/hive.js map delta reject delta_xxx --reason "One-off change; not durable map knowledge."
+```
+
+Apply only when the lesson is durable and useful for future `find` / `check` behavior.

package/docs/skills/hive-lite-finish/SKILL.md

@@ -0,0 +1,282 @@
+---
+name: hive-lite-finish
+description: Use this skill after a coding agent says a Hive Lite-scoped change is implemented and the user wants help closing it. It runs Hive Lite check/validate, interprets Evidence Policy, asks the human for manual verification or review reasons when required, and only accepts/commits after explicit confirmation.
+---
+
+# Hive Lite Finish
+
+## Purpose
+
+Drive the finish side of a Hive Lite change after code has been edited:
+
+```text
+check -> validate -> human verification or review reason -> accept
+```
+
+Hive Lite is the factual evidence layer. This skill is the operator layer. The human remains responsible for manual verification, risk acceptance, review reasons, and commit confirmation.
+
+## References
+
+- Read [safety.md](references/safety.md) before mutating git state, recording manual evidence, accepting risk, or committing.
+- Read [verdicts.md](references/verdicts.md) when interpreting `evidencePolicy.verdict`.
+
+## Skill Handoffs
+
+Do not assume this skill can invoke `$hive-lite-start-prompt` or `$hive-lite-map-maintainer` automatically. If another skill is needed, output an explicit prompt for the user to run and stop.
+
+- Next phase after split accept: output a `$hive-lite-start-prompt` handoff.
+- Map repair or refresh needed during finish: output a `$hive-lite-map-maintainer` handoff; do not edit map files here.
+
+If the target handoff skill is unavailable in the active agent CLI, tell the user to install or sync Hive Lite skills for their agent first. Hive Lite cannot detect the running agent by itself; use the user's agent target such as `codex`, `claude`, or `gemini`:
+
+```bash
+hive-lite skills doctor --agent <codex|claude|gemini>
+hive-lite skills install --agent <codex|claude|gemini>
+```
+
+## Boundaries
+
+- Do not edit application code.
+- Do not repair Project Map files in this skill; hand off to `$hive-lite-map-maintainer` if map work is required.
+- Do not claim manual UI/product verification yourself.
+- Do not automatically accept risk, commit, stash, reset, clean, push, merge, or deploy.
+- Do not ignore scope violations or failed required validation.
+- Agent summaries are not evidence. Evidence must come from Hive Lite diff/scope, validation logs, manual validation notes, review reasons, or accept records.
+
+## Find The CLI
+
+Run Hive Lite from the target repo root. Prefer the package command:
+
+```bash
+hive-lite <args>
+```
+
+If `hive-lite` is not available, try an explicit path already given by the user or conversation context, such as `node /path/to/hive-lite/bin/hive.js <args>`. Ask for the CLI path if it is not obvious.
+
+In command examples below, replace `hive-lite` with the resolved command.
+
+## Workflow
+
+### 1. Identify The Change
+
+Run `hive-lite status --json` first. If it reports `hive.state = repo_setup_required`, stop immediately. Do not run check/validate/accept and do not initialize git automatically. Tell the user to switch to the correct git repo root, or manually initialize git and create an initial commit before using Hive Lite.
+
+Find one of:
+
+- context id from the coding agent output, such as `ctx_xxx`,
+- change id from the user, such as `chg_xxx`,
+- latest in-progress change from `hive-lite status --json`.
+
+If neither context id nor change id is known, ask the user for the context/check command rather than guessing.
+
+### 2. Run Check
+
+If a context id is known, run:
+
+```bash
+hive-lite check --context <ctx_id> --json
+```
+
+If a change id is known, run:
+
+```bash
+hive-lite check <chg_id> --json
+```
+
+Read JSON fields directly. Key fields:
+
+- `id`
+- `scope.status`
+- `scope.reviewDetails`
+- `validation.status`
+- `validation.plan`
+- `risk.level`
+- `risk.blockingReasons`
+- `risk.reviewReasons`
+- `evidencePolicy.verdict`
+- `evidencePolicy.class`
+- `evidencePolicy.missing`
+- `evidencePolicy.nextActions`
+
+Summarize for the human in plain language:
+
+```text
+I checked the change.
+- Scope: clean / needs review / violation
+- Risk: low / medium / high
+- Current evidence verdict: <human explanation>
+- Next step: <what I can do or what I need from you>
+```
+
+### 3. Follow The Verdict
+
+Read [verdicts.md](references/verdicts.md). Use `evidencePolicy.verdict` as the main decision source.
+
+Safe default:
+
+- `blocked`: stop.
+- `needs_validation`: run safe automatic validation, or ask first if the command looks unsafe.
+- `needs_manual_verification`: ask the human to verify; do not record manual evidence until they confirm.
+- `needs_review_reason` or `evidence_insufficient`: explain options and ask for a review reason, focused test, or risk acceptance.
+- `acceptable`: ask whether to accept and commit.
+
+After running validation or recording manual evidence, run `hive-lite check <chg_id> --json` again before deciding the next step.
+
+If `accept` later returns `postAcceptHint.kind = split_remaining_phases`, explain ready and waiting phases to the human and recommend `postAcceptHint.suggestedNextPhase` when present.
+
+Do not assume this skill can invoke `$hive-lite-start-prompt` automatically. Instead, output a clear handoff prompt and stop:
+
+```text
+To continue the next phase, run:
+
+$hive-lite-start-prompt
+Continue split <split_id> with phase <phase_id>.
+Use this find intent:
+"<findIntent>"
+```
+
+If the user explicitly asks you to continue in the same session, you may run the phase-specific `hive-lite find ... --from-split ... --phase ... --area <primaryAreaId> --json` command and summarize the result, but do not duplicate the full start-skill workflow unless the active agent environment has actually loaded `$hive-lite-start-prompt`.
+
+### 4. Automatic Validation
+
+If validation is needed, inspect `validation.plan`.
+
+You may run a command validation automatically only when it appears safe. Read [safety.md](references/safety.md). If unsure, ask first.
+
+Run:
+
+```bash
+hive-lite validate <chg_id> --json
+```
+
+or, for a selected profile:
+
+```bash
+hive-lite validate <chg_id> --profile <profile> --json
+```
+
+Then rerun:
+
+```bash
+hive-lite check <chg_id> --json
+```
+
+### 5. Manual Verification
+
+If manual verification is required:
+
+1. Explain that you cannot verify UI/product behavior for the human.
+2. Provide concrete checks based on the requirement, changed files, context packet, and evidence policy.
+3. Ask the human to reply with pass/fail and any observation.
+4. If the human confirms pass, record manual evidence.
+
+Use the first profile in `evidencePolicy.manualVerification.profiles`, or `manual-verification` if no profile is configured:
+
+```bash
+hive-lite validate <chg_id> \
+  --manual <profile> \
+  --result passed \
+  --note "<human-confirmed note>" \
+  --json
+```
+
+Do not invent the note. It should reflect the user's confirmation.
+
+If the human reports failure, do not accept and do not treat failed manual evidence as mandatory. The default next step is repair under the same Context Packet:
+
+1. Keep the original context id from the Change Record.
+2. Summarize the human failure clearly.
+3. Output a repair prompt the human can paste into the coding agent session.
+4. Tell the human to rerun `hive-lite check --context <ctx_id>` after the coding agent edits again.
+
+Use this repair prompt shape:
+
+```text
+The previous implementation failed human verification.
+
+Use the same Hive Lite Context Packet:
+.hive/context/<ctx_id>.md
+
+Failure:
+<human failure observation>
+
+Revise the implementation using the same context packet.
+Modify only the Direct Writable files in that packet.
+Do not expand scope.
+If you need a Review-Gated file, stop and explain why.
+After editing, stop and ask the human to rerun:
+  hive-lite check --context <ctx_id>
+```
+
+Only record failed manual evidence if the human explicitly wants the failed attempt captured:
+
+```bash
+hive-lite validate <chg_id> \
+  --manual <profile> \
+  --result failed \
+  --note "<human failure observation>" \
+  --json
+```
+
+If failed evidence is recorded, the current Change Record becomes blocked. The next coding attempt should create a fresh Change Record with `hive-lite check --context <ctx_id>`.
+
+### 6. Review Reason Or Insufficient Evidence
+
+If Hive reports `needs_review_reason` or `evidence_insufficient`, explain the difference:
+
+- review reason: evidence may be enough after human code review, but Hive needs the reason recorded.
+- evidence insufficient: focused verification is preferred; review reason or accept-risk is an explicit escape hatch.
+
+Offer options:
+
+```text
+1. Ask the coding agent to add focused verification.
+2. Record a reviewed accept reason, if you believe evidence is enough.
+3. Accept risk, if you knowingly accept insufficient evidence.
+4. Stop.
+```
+
+You may draft a reason, but the human must approve it before use.
+
+### 7. Accept And Commit
+
+Before accepting, rerun:
+
+```bash
+hive-lite check <chg_id> --json
+```
+
+Accept only when:
+
+- the verdict is `acceptable`, or
+- the human explicitly approved `--reviewed --reason`, or
+- the human explicitly approved `--accept-risk --reason`.
+
+Ask for or propose a commit message. Do not commit silently.
+
+Run one of:
+
+```bash
+hive-lite accept <chg_id> --commit -m "<message>" --json
+hive-lite accept <chg_id> --reviewed --reason "<reason>" --commit -m "<message>" --json
+hive-lite accept <chg_id> --accept-risk --reason "<reason>" --commit -m "<message>" --json
+```
+
+After accepting, summarize:
+
+```text
+Accepted and committed.
+- Change: chg_xxx
+- Commit: <sha>
+- Evidence: .hive/changes/chg_xxx/evidence.json
+- Map Delta Candidate: <id or none>
+- Split next phase: <handoff prompt or none>
+```
+
+If no commit was created because the user explicitly asked not to commit, warn that a new Hive Lite requirement should not start until the worktree is clean.
+
+## Response Style
+
+Do not dump raw JSON unless the user asks. Translate Hive Lite facts into plain language, then show exact commands only when asking for confirmation or reporting what ran.
+
+When you must stop for human input, stop cleanly with choices. Do not continue in the same response unless the user had already explicitly chosen an option.

package/docs/skills/hive-lite-finish/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Hive Lite Finish"
+  short_description: "Close Hive Lite changes safely"
+  default_prompt: "Use $hive-lite-finish to check, validate, and safely accept this Hive Lite change without starting new work."