@hagicode/cli 0.4.0 → 0.6.0

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/dist/cli.js CHANGED
@@ -1,3 +1,3 @@
1
1
  #!/usr/bin/env node
2
- Object.defineProperty(exports,Symbol.toStringTag,{value:"Module"});const s=require("./chunks/main-CyDpMd__.js");s.runCli().then(e=>{e!==0&&(process.exitCode=e)}).catch(e=>{const n=e instanceof Error?e.stack??e.message:String(e);process.stderr.write(`${n}
2
+ Object.defineProperty(exports,Symbol.toStringTag,{value:"Module"});const s=require("./chunks/main-IYdi0hAA.js");s.runCli().then(e=>{e!==0&&(process.exitCode=e)}).catch(e=>{const n=e instanceof Error?e.stack??e.message:String(e);process.stderr.write(`${n}
3
3
  `),process.exitCode=s.EXIT_CODES.UNKNOWN});
package/dist/main.js CHANGED
@@ -1 +1 @@
1
- Object.defineProperty(exports,Symbol.toStringTag,{value:"Module"});const e=require("./chunks/main-CyDpMd__.js");exports.createCliApp=e.createCliApp;exports.runCli=e.runCli;
1
+ Object.defineProperty(exports,Symbol.toStringTag,{value:"Module"});const e=require("./chunks/main-IYdi0hAA.js");exports.createCliApp=e.createCliApp;exports.runCli=e.runCli;
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@hagicode/cli",
3
- "version": "0.4.0",
3
+ "version": "0.6.0",
4
4
  "description": "HagiCode CLI for project, proposal, vault, chat, and AutoTask management.",
5
5
  "homepage": "https://github.com/HagiCode-org/cli#readme",
6
6
  "bugs": {
@@ -16,7 +16,9 @@
16
16
  "main": "./dist/main.js",
17
17
  "files": [
18
18
  "dist",
19
- "README.md"
19
+ "README.md",
20
+ "skills",
21
+ "resources/saga"
20
22
  ],
21
23
  "packageManager": "pnpm@12.16.1",
22
24
  "engines": {
@@ -24,7 +26,7 @@
24
26
  },
25
27
  "scripts": {
26
28
  "clean": "rimraf dist",
27
- "build": "export NODE_OPTIONS=\"${NODE_OPTIONS:-} --max-old-space-size=8192\"; pnpm run clean && vite build",
29
+ "build": "export NODE_OPTIONS=\"${NODE_OPTIONS:-} --max-old-space-size=8192\"; pnpm run clean && vite build && node -e \"require('node:fs').chmodSync('dist/cli.js', 0o755)\"",
28
30
  "dev": "tsx ./src/cli.ts",
29
31
  "generate:grpc": "node ./buildTools/generate-grpc.mjs",
30
32
  "generate:grpc:check": "node ./buildTools/generate-grpc.mjs --check",
@@ -0,0 +1 @@
1
+ **/runtime/
@@ -0,0 +1,14 @@
1
+ {
2
+ "schemaVersion": 2,
3
+ "install": {
4
+ ".gitignore": "b43c8b58f191b9e0a0b54b6938c0aa4685d70b8f4ae2294c83a9ad6e728b7c0a"
5
+ },
6
+ "methods": {
7
+ "goal": "a545b01c9f6010df661f02cf62ef9bcae527ccf329f304ea82ffdda239b118df",
8
+ "research": "2504283ea845440c7909ff1da20bfb70f846d55ca16565740168848cfb8060b1",
9
+ "acceptance": "11ca06794d0ec19e87d1a4e883a67014563e9750b9fa62a8bedd43a69d52ca65",
10
+ "plan": "bcc4c0509f2971083775db2b3678f41c55f16e69deba2d994d3ed636f314d917",
11
+ "run": "aaf8a667c163afea0796a8c80d5760ee689923a76b0c7f1855e55405d9b0b5d0",
12
+ "amend": "be621d1221a85656851548aee1e9e9d78480288bd856baf1bdbf50cb3317f49b"
13
+ }
14
+ }
@@ -0,0 +1,15 @@
1
+ # acceptance.md
2
+
3
+ ## Instruction
4
+ Give every plan item one acceptance command. A separate verification worker runs it, so it must decide pass or fail by itself.
5
+
6
+ - One heading per item: `## <ID> <name>`, followed by one line `cmd: <command>`.
7
+ - The command runs from the project root (the folder that holds `.hagicode`), not from the saga root. Write `cd <dir> && ...` when it needs a subfolder. Exit code 0 means the item is done.
8
+ - The command must be able to fail. A command that always passes proves nothing.
9
+ - Every plan item has exactly one heading here, and every heading here is a plan item. If you change the command of an item that is already ticked, the next freeze reopens that item.
10
+
11
+ ## Template
12
+ ```
13
+ ## <ID> <name>
14
+ cmd: <command to run from the project root>
15
+ ```
@@ -0,0 +1,10 @@
1
+ # Folding an amendment into a saga
2
+
3
+ An amendment is a file under `<saga>/amendments/`. It is open while its `merged-in:` line is empty. Folding it in changes the planning artifacts only.
4
+
5
+ 1. `hagi saga status <saga> --path <root> --json` reports the current `revision` N (0 means the saga was never frozen). The merge target is `r<N+1>`.
6
+ 2. Read the amendment. Update `goal.md`, `research.md`, `acceptance.md` and `progress.md` so they agree with each other and with the amendment.
7
+ 3. Items may be added or superseded (`- ~ <ID> <name> | superseded in r<N+1>: <reason>`), never deleted. Do not touch the ticks: when an item's acceptance command changes, the next freeze reopens it.
8
+ 4. Do not decide new open questions yourself. List them under `## Open questions`.
9
+ 5. In the amendment file set `merged-in: r<N+1>`.
10
+ 6. Run `hagi saga check <saga> --phase plan --path <root>` and fix what it reports. Do not run `freeze`.
@@ -0,0 +1,23 @@
1
+ # goal.md
2
+
3
+ ## Instruction
4
+ Write the goal contract of the saga: what it must achieve, in what scope, with which safety rules.
5
+
6
+ - Every work item the saga will have must be checkable by a machine (a command that exits 0 when the item is done). Say so in the goal.
7
+ - Write the non-goals and the block conditions (when an item is blocked instead of forced).
8
+ - Do not write implementation details.
9
+ - Write in the language the user used for the objective.
10
+ - If `amendments/` holds files whose `merged-in:` line is empty, fold them in and set `merged-in: r<next revision>` in each file (see `prompts/amend.md`).
11
+
12
+ ## Template
13
+ ```
14
+ ## Goal
15
+
16
+ ## Scope
17
+
18
+ ## Non-goals
19
+
20
+ ## Safety rules
21
+
22
+ ## Block conditions
23
+ ```
@@ -0,0 +1,16 @@
1
+ # progress.md (the plan)
2
+
3
+ ## Instruction
4
+ List the work items, one line each: `- [ ] <ID> <name> | `. The evidence path is added when an item is ticked.
5
+
6
+ - Items are small enough to verify with one command, mostly independent, and ordered so that earlier items do not depend on later ones.
7
+ - Keep the list short enough to review (roughly 3 to 15 items). Use the user's work items as a start; add or split items only when needed.
8
+ - Do not add items for committing, pushing, opening a pull request, releasing or archiving: they are outside the contract.
9
+ - IDs match the headings of `acceptance.md`.
10
+ - In a revision an item may be added or superseded, never deleted. A superseded item is written without brackets: `- ~ <ID> <name> | superseded in r<N>: <reason>`.
11
+ - Planning ends here. Do not run `freeze`, do not start the run, do not edit project code.
12
+
13
+ ## Template
14
+ ```
15
+ - [ ] <ID> <name> |
16
+ ```
@@ -0,0 +1,16 @@
1
+ # research.md
2
+
3
+ ## Instruction
4
+ Read the project and the references the user gave. Read only: change no project file.
5
+
6
+ - Record what you found: the layout, the existing conventions, the commands that run the tests, anything the plan depends on.
7
+ - List every decision you cannot make yourself under the heading `## Open questions` (the Chinese heading `## 待决问题` also works). One line per question, starting with `- `. Leave them undecided: a human answers them before the run by rewriting a line as `- [decided: <answer>] <question>` (or `- [已决定: <结论>] <问题>`).
8
+ - If there is nothing to decide, write `- none` under that heading.
9
+ - If an item has no honest verification command, say so here as an open question. Do not invent a check.
10
+
11
+ ## Template
12
+ ```
13
+ ## Findings
14
+
15
+ ## Open questions
16
+ ```
@@ -0,0 +1,20 @@
1
+ # Running a saga (the orchestrator)
2
+
3
+ You are the orchestrator. You dispatch work and keep the record. You do not plan, you do not edit the contract, and you do not implement items yourself. A human started this run; starting it is the approval.
4
+
5
+ `<root>` is the registered project path given in the run's input. Every command is `hagi saga <command> <saga> --path <root>` and works from any directory. Every command that changes a Saga also takes `--token <token>`: the token that `claim` printed.
6
+
7
+ 0. **Claim first.** `hagi saga claim <saga> --session <your session id> --path <root> --json`. Keep the printed token for every later command. If it refuses because another owner holds the Saga, stop and report it. Never take over by age, and never write a paused snapshot over another owner's progress.
8
+ 1. **Freeze.** `hagi saga freeze <saga> --path <root> --token <token>`. If it refuses (open questions, open amendments, a changed contract), run `hagi saga set-status <saga> --state paused --note "<reason>" --path <root> --token <token>`, stop and report the reasons. Do not edit contract files and do not decide open questions. A first freeze writes revision 1. After an amendment was merged it writes the next revision, chained to the previous one, and reopens the items whose acceptance command changed.
9
+ 2. **Check before every item and at every heartbeat.** `hagi saga assert-owner <saga> --path <root> --token <token>` before each dispatch, then `hagi saga check <saga> --phase run --path <root>`. If a check fails, pause the same way and report. An open amendment also means: pause.
10
+ 3. **Work one item at a time** (`hagi saga items <saga> --path <root>` lists them with their commands), unless the goal allows parallel items. For each item:
11
+ - Create each Worker with `hagi saga session create --saga <saga> --path <root> --title "<ITEM> <role>" --role <role> --master <your session id> --item <ITEM>`, where `<role>` is `implementation` or `verification`. This command takes the token from `SAGA_EXECUTION_TOKEN`, set to the token that `claim` printed, and refuses `--token`. It creates the chat session with its Saga metadata and records it in `sessions.md`. Then give the Worker its instructions below.
12
+ - An implementation worker writes code and tests only. Give it the goal, the item, the scope and the safety rules, the project root and its report path.
13
+ - A separate verification worker runs the item's command from `acceptance.md` in the project root, writes the output to `<root>/.hagicode/sagas/<saga>/runtime/evidence/<ITEM>.log`, and writes `<root>/.hagicode/sagas/<saga>/runtime/reports/<ITEM>.md` with the line `Status: PASS` (or `状态: PASS`) only if the exit code is 0. It changes no files.
14
+ - Only `hagi saga tick <saga> <ITEM> --path <root> --token <token>` ticks an item. It refuses without a PASS report and an evidence file.
15
+ 4. **On a failed verification, classify it.** An environment fault (missing module, port in use, quota) does not count. A real failure counts: give a tuning worker the failure log path, then verify again. After 3 real failures run `hagi saga block <saga> <ITEM> "<reason>" --path <root> --token <token>` and move on.
16
+ 5. **After a revision reopened items,** also re-verify any item whose command is the full regression: its own command did not change, so it was not reopened.
17
+ 6. **Keep the record.** Append a line to `<root>/.hagicode/sagas/<saga>/runtime/orchestrator-log.md` after every dispatch, verification and tick. `hagi saga session create` records each Worker session it creates in `<root>/.hagicode/sagas/<saga>/runtime/sessions.md`, so do not append those sessions to that file by hand. Run `hagi saga set-status <saga> --state running --note "<heartbeat>" --path <root> --token <token>` at every heartbeat, and `hagi saga status <saga> --path <root> --json` to read the projection at the end.
18
+ 7. **Archive each settled item's sessions.** Once an item is ticked or blocked and its workers have stopped, archive the worker sessions you created for it: `hagi chat archive --session-id <session id> --json`. Take the IDs from `<root>/.hagicode/sagas/<saga>/runtime/sessions.md`. Archive only sessions you created in this run: never your own orchestrator session, a session that is still running, a session you did not create, or the Saga itself (`hagi saga archive` is not part of a run). Archiving leaves the reports, evidence and `sessions.md` record in `runtime/` untouched. Log each archived ID in `orchestrator-log.md`. If an archive call fails, log the error and go on: do not retry in a loop and do not pause for it.
19
+ 8. **Never leave a command hanging.** Every shell command must end on its own: never read from standard input, and give waits a limit. If something does not answer, report it instead of waiting forever.
20
+ 9. **Stop** when every item is ticked or blocked, when a pause condition appears, or when the human's run options say so. Write the terminal snapshot first (`set-status --state done` only when every active item is verified, otherwise `paused` with the reason). Once every worker has stopped, archive any remaining worker sessions as in step 7, then run `hagi saga release <saga> --path <root> --token <token> --workers-settled`. Never archive the Saga itself and do not commit. Report the revision, every item with its state and evidence path, the blocked items with reasons, the sessions you created and which of them you archived, and the next step for a human.
@@ -0,0 +1,52 @@
1
+ # Embedded Skills
2
+
3
+ `repos/cli/skills/` is the repository-level discovery entrypoint for Hagi CLI skills.
4
+ Use this directory when you need the canonical agent-facing contract for the published `@hagicode/cli` package and the installed `hagi` command.
5
+
6
+ ## Package-first usage
7
+
8
+ Treat the published package as the default execution path:
9
+
10
+ ```bash
11
+ npx @hagicode/cli --help
12
+ npx @hagicode/cli proposal list --json
13
+ ```
14
+
15
+ If `@hagicode/cli` is already installed, the same contract is available through:
16
+
17
+ ```bash
18
+ hagi --help
19
+ ```
20
+
21
+ Repository-local commands under `repos/cli` are maintainer workflows only.
22
+
23
+ ## Available skill packages
24
+
25
+ - [`hagi/SKILL.md`](hagi/SKILL.md) - canonical Hagi CLI skill entrypoint
26
+ - [`hagi/agents/openai.yaml`](hagi/agents/openai.yaml) - agent display and invocation metadata
27
+ - [`hagi/references/cli-usage.md`](hagi/references/cli-usage.md) - published package usage and runtime flags
28
+ - [`hagi/references/session-data.md`](hagi/references/session-data.md) - inside a HagiCode session: read-only data commands and the actions that need an explicit request
29
+ - [`hagi/references/proposal-flow.md`](hagi/references/proposal-flow.md) - explicit proposal lifecycle guidance
30
+ - [`hagi/references/openspec-workflow.md`](hagi/references/openspec-workflow.md) - the OpenSpec stage each proposal command starts and how to follow a run
31
+ - [`hagi/references/resource-lock.md`](hagi/references/resource-lock.md) - the shared resource lock: owner, exit codes, the watcher protocol and requisition rules
32
+ - [`hagi/references/super-commit.md`](hagi/references/super-commit.md) - Super Commit through the CLI: prompt-id start, options, result and explicit-request rule
33
+ - [`hagi/references/local-development.md`](hagi/references/local-development.md) - maintainer-only source-tree workflows
34
+ - [`hagi/references/validation.md`](hagi/references/validation.md) - post-change validation steps
35
+
36
+ ## Canonical writable source
37
+
38
+ Update `repos/cli/skills/**` when the Hagi CLI skill contract changes.
39
+
40
+ ## Built-in copy
41
+
42
+ The server also ships this folder as its built-in skill `hagi`. The copy lives in `repos/built-in-skills/content/hagi/` and is an exact byte copy of `repos/cli/skills/hagi/`. Edit this folder, then recopy and rehash the built-in copy.
43
+
44
+ ## Skill installation and discovery
45
+
46
+ If an agent runtime or skill loader needs the Hagi skill source, point it at `repos/cli/skills/hagi/`.
47
+ Start discovery from this README, then open `repos/cli/skills/hagi/SKILL.md`.
48
+
49
+ ## Maintainer note
50
+
51
+ When you are editing the CLI itself, use the maintainer-only workflows in `hagi/references/local-development.md`.
52
+ For normal usage and automation, stay package-first.
@@ -0,0 +1,128 @@
1
+ ---
2
+ name: hagi
3
+ description: Use when the user wants to run, verify, or update the HagiCode CLI against the Hagi API, use local Saga initialization, creation, checks, writes, or read-only queries, or asks about their own projects, proposals, chat sessions, vaults, scheduled plans, or installed skills, including user skills versus built-in skills and enabling or disabling a built-in skill. Also covers the OpenSpec workflow behind proposal commands and Super Commit, which commits a code repository through a HagiTask session. Keep package-first command guidance primary, then follow the Saga, proposal, local development, and validation references as needed. Inside a HagiCode session, read the session-data reference first for questions about the user's own data.
4
+ ---
5
+
6
+ # Hagi
7
+
8
+ Use this skill when the user asks to:
9
+
10
+ - answer questions about their own projects, proposals, chat sessions, vaults, scheduled plans, or installed skills
11
+ - list which installed skills are user skills and which are built-in skills, or which built-in skills are enabled
12
+ - enable or disable a built-in skill
13
+ - run or verify the `hagi` CLI
14
+ - run, explain, or verify local `saga init`, `saga new`, `saga list`, `saga status`, or `saga items` operations
15
+ - read a published Saga method (`goal`, `research`, `acceptance`, `plan`, `run`, `amend`) with `saga method <name>`
16
+ - run, explain, or verify local Saga ownership, checks, and writes: `claim`, `assert-owner`, `release`, `freeze`, `check`, `tick`, `block`, `set-status`, `amend`, `archive`, and `session create` (Saga Worker chat sessions)
17
+ - explain or execute `project`, `proposal`, `chat`, `hagitask`, `vault`, `plan`, `skills`, or `saga` commands
18
+ - explain the OpenSpec workflow behind `proposal` commands, which stage each command starts, or how to follow a run until it settles
19
+ - take turns on a shared resource (a game server, a test environment) with other agents through `hagi agent lock`
20
+ - run, explain or check a Super Commit, which commits the uncommitted changes of a code repository through a HagiTask session
21
+ - inspect CLI flags, environment variables, exit codes, or JSON automation behavior
22
+ - validate proposal-session flows against a backend API
23
+ - modify or debug the CLI implementation in `repos/cli`
24
+
25
+ ## Core rules
26
+
27
+ - Prefer `npx @hagicode/cli ...` for normal usage and package-level verification.
28
+ - Use `hagi ...` only when `@hagicode/cli` is already installed and on `PATH`.
29
+ - Run repository-local install, build, and test commands with the working directory set to `repos/cli`.
30
+ - Never run `pnpm install`, `pnpm run`, or other build commands at the monorepo root.
31
+ - Prioritize API invocation guidance over codebase tours unless the user explicitly wants implementation work.
32
+ - Built-in skills can be enabled or disabled with `hagi skills local enable --skill-name <name>` and `hagi skills local disable --skill-name <name>`. They cannot be uninstalled or updated through the CLI. A change applies to agent runs that start afterwards; a run already in progress keeps the skills it started with.
33
+ - Every proposal names its writable repositories and its read-only repositories, in a `Repository scope` section at the start of `--chief-complaint`. Both lists are always present, and an empty list is written as `none`. Take the paths from `hagi project repositories --id <project-id> --json`. When neither the user's request nor the session gives the scope, ask the user and offer those repositories as the choices; never guess a scope or widen the writable list. Details: [`references/proposal-flow.md`](references/proposal-flow.md#repository-scope).
34
+
35
+ ## Choose the workflow
36
+
37
+ 1. Published package usage -> read [`references/cli-usage.md`](references/cli-usage.md)
38
+ 2. Explicit proposal lifecycle work -> read [`references/proposal-flow.md`](references/proposal-flow.md)
39
+ 3. Which OpenSpec stage a proposal command starts, or following a run to its end -> read [`references/openspec-workflow.md`](references/openspec-workflow.md)
40
+ 4. Super Commit, committing a code repository through a HagiTask session -> read [`references/super-commit.md`](references/super-commit.md)
41
+ 5. Source-tree development in `repos/cli` -> read [`references/local-development.md`](references/local-development.md)
42
+ 6. Post-change validation -> read [`references/validation.md`](references/validation.md)
43
+ 7. The user's own data, inside a HagiCode session -> read [`references/session-data.md`](references/session-data.md)
44
+ 8. Local Saga initialization, creation, list, status, item queries, ownership, checks, freeze, ticks, status writes, amendments, archive, or creating and recording Saga Worker sessions (`session create`) -> read [`references/saga.md`](references/saga.md)
45
+ 9. A shared resource that other agents also use, or any `hagi agent lock` command -> read [`references/resource-lock.md`](references/resource-lock.md)
46
+
47
+ When `hagi` is loaded as a built-in skill inside a HagiCode session, read item 7 first for any question about the user's own data or skills, before the other references.
48
+
49
+ ## Runtime configuration
50
+
51
+ Shared runtime flags:
52
+
53
+ - `--base-url <url>`
54
+ - `--token <token>`
55
+ - `--lang <lang>`
56
+ - `--json`
57
+
58
+ Equivalent environment variables:
59
+
60
+ - `HAGI_API_BASE_URL`
61
+ - `HAGI_API_TOKEN`
62
+ - `HAGI_API_LANG`
63
+
64
+ A base URL can also come from `"baseUrl"` in `$XDG_CONFIG_HOME/hagi/config.json`, or `~/.config/hagi/config.json` when `XDG_CONFIG_HOME` is unset.
65
+
66
+ Precedence: flag, then `HAGI_API_BASE_URL`, then the config file. The base URL has no default. When none of the three is set, the CLI exits with code `2`.
67
+
68
+ Inside a HagiCode session, the server can add four runtime variables to an agent run. They are present only while the built-in `hagi` skill is installed and enabled, and only on Claude Code, Pi, OpenCode, GitHub Copilot and omp:
69
+
70
+ | Variable | Carries |
71
+ | --- | --- |
72
+ | `HAGI_API_BASE_URL` | Address of the backend that started the session |
73
+ | `HAGI_VERSION` | Version of the HagiCode server |
74
+ | `HAGI_DEPLOYMENT_TYPE` | Deployment type of the server |
75
+ | `HAGI_API_LANG` | Effective AI language: `zh-CN` or `en-US`, sent as `Accept-Language` |
76
+
77
+ A variable the server cannot determine is left out, and the run still starts. Report an absent variable as absent; do not guess a value. Conditions and the rest of the session rules are in [`references/session-data.md`](references/session-data.md).
78
+
79
+ ## Command surface
80
+
81
+ The current top-level command families are:
82
+
83
+ - `project`
84
+ - `proposal`
85
+ - `vault`
86
+ - `chat`
87
+ - `hagitask`
88
+ - `plan`
89
+ - `skills`
90
+ - `agent`
91
+ - `saga`
92
+
93
+ `hagi saga` provides `init`, `new`, `list`, `status`, and `items`, plus the write and check commands `claim`, `assert-owner`, `release`, `freeze`, `check`, `tick`, `block`, `set-status`, `amend`, and `archive`, and `session create`, which creates a Saga Worker chat session and records it. Mutating commands take `--token` or `SAGA_EXECUTION_TOKEN`; `session create` takes only `SAGA_EXECUTION_TOKEN`. With `--path`, these operate on host-local files without reading backend configuration or calling the API, except `session create`, which calls the backend to find the registered project; `--project-id` resolves a project through the backend. Creating a Worker changes state, so run `session create` only when the user or a Saga run explicitly asks for it. See [`references/saga.md`](references/saga.md) for initialization, creation, offline behavior, and read-only query guarantees.
94
+
95
+ `project repositories --id <project-id>` is read-only. It lists one project's repositories with each path relative to the project root (for example `repos/cli`). Those paths are the values a proposal's `Repository scope` names; see [`references/proposal-flow.md`](references/proposal-flow.md#repository-scope).
96
+
97
+ Scheduled plans (`hagi plan`) save a proposal or HagiTask input with a schedule. `list`, `get`, `create`, `update`, `enable`, `disable`, `delete` and `run` manage them; `run --background` returns the accepted plan id before the session exists. A manual run never changes a plan's state or next run time. See [`references/cli-usage.md`](references/cli-usage.md#plan-commands) for the action list and a plan document example.
98
+
99
+ HagiTask sessions (`hagi hagitask`) run a preset task with a structured input. `list` shows the active tasks, `schema --task-id <id>` shows one task's scope, commands, parameters and required marks, and `create --task-id <id> --input <file>` creates the session. Read the schema first, write the input from it, then create. `send` posts a follow-up message; `--steer` (or `HAGI_SEND_STEER=1`) inserts it into a running turn instead, and `queued` means no running task took it. The backend rejects any input key the schema does not list. See [`references/cli-usage.md`](references/cli-usage.md#hagitask-commands) for the flow and an input example, and [`references/cli-usage.md`](references/cli-usage.md#steer-for-send-commands) for the Steer options.
100
+
101
+ Each family also reads one session by id. `proposal get` and `hagitask get` read a session; with `--wait` they poll until its status settles, so a run can be followed without guessing. `proposal messages` and `hagitask messages` read a session's messages, and `--last 1` reads the final message of a run. The stage behind each proposal command is in [`references/openspec-workflow.md`](references/openspec-workflow.md). Super Commit is started with `hagitask create --prompt-id auto-compose-commit.<locale>`; see [`references/super-commit.md`](references/super-commit.md).
102
+
103
+ ## Resource lock
104
+
105
+ `hagi agent lock` is a fair queue lock for a resource that several agents share. Read [`references/resource-lock.md`](references/resource-lock.md) before the first lock command. The protocol is watcher-based:
106
+
107
+ - Pass your own session ID as the owner: `hagi agent lock acquire --lock-id eu-1/duckov --owner sess-7f2c`. Every example is `hagi agent lock ...`; there is no `hagi lock`.
108
+ - After `acquire`, read the windows. `Holding`: start the heartbeat watcher (a Monitor running `hagi agent lock heartbeat ...`, or a background process or sub-agent where there is no Monitor) before any work. `Queued`: start a continuous `hagi agent lock acquire --wait ...` watcher; do not sleep and re-check.
109
+ - When all tasks are done, stop the heartbeat watcher and then run `hagi agent lock release`. Stopping alone releases the lock after 10 minutes without a heartbeat; the lock is also taken back after 24 hours. The heartbeat interval is 2 minutes.
110
+ - When a watcher reports loss (exit code `32`), stop using the resource at once. After losing track (for example after compaction), repeat `acquire` with the same owner; it is safe.
111
+ - Never run `hagi agent lock requisition` unless the user explicitly ordered a forced take; nothing else is a requisition, and otherwise you always queue. When ordered, quote the request in `--reason`, start the heartbeat watcher and tell the user which owner was displaced. When you are displaced, stop at once, tell the user, queue again only if the task still needs the resource, and never requisition back. A displaced agent can use the resource until its next heartbeat (up to 2 minutes), and the lock cannot stop work already running on the resource.
112
+
113
+ ## Source of truth
114
+
115
+ - Canonical writable skill source: `repos/cli/skills/hagi/`
116
+ - The server ships a byte-for-byte copy of this folder as its built-in skill `hagi`; edit here, never in the copy
117
+
118
+ ## References
119
+
120
+ - [`references/cli-usage.md`](references/cli-usage.md) - package-first installation, quick start, runtime flags, and exit codes
121
+ - [`references/session-data.md`](references/session-data.md) - inside a HagiCode session: read-only data commands, state-changing actions that need an explicit request, and failure handling
122
+ - [`references/proposal-flow.md`](references/proposal-flow.md) - explicit proposal lifecycle sequence and command examples
123
+ - [`references/openspec-workflow.md`](references/openspec-workflow.md) - the OpenSpec stage each proposal command starts, stage boundaries, who drives each step, and the monitoring rule
124
+ - [`references/super-commit.md`](references/super-commit.md) - Super Commit: starting it by prompt id, its options, result reading and the explicit-request rule
125
+ - [`references/resource-lock.md`](references/resource-lock.md) - the shared resource lock: numbers, owner, exit codes, the watcher protocol, the seven agent rules and requisition
126
+ - [`references/saga.md`](references/saga.md) - local initialization, creation, ownership, checks, Saga writes, Saga Worker sessions (`session create`), and read-only queries
127
+ - [`references/local-development.md`](references/local-development.md) - maintainer-only development, build, and repository internals
128
+ - [`references/validation.md`](references/validation.md) - targeted verification after documentation or code changes
@@ -0,0 +1,7 @@
1
+ interface:
2
+ display_name: "Hagi CLI"
3
+ short_description: "Operate the hagi CLI, including local Saga commands, and work with HagiCode data, skills, proposals, and Super Commit."
4
+ default_prompt: "Use $hagi to operate local Saga init, new, list, status, or items commands and the Saga ownership, check, freeze, tick, set-status, amend, and archive commands; look up HagiCode projects, proposals, sessions, vaults, plans, or skills; follow a proposal's OpenSpec workflow; run a Super Commit; enable or disable a built-in skill; or inspect, run, or update the CLI in repos/cli."
5
+
6
+ policy:
7
+ allow_implicit_invocation: true