菜单
Creates or updates a Markdown specification file for an Ambler walk in the specs/ directory. Use this whenever a user wants to document, plan, or describe a walk — including "write a spec", "document this walk", or "plan out the nodes" — even before any code exists.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | ambler-spec |
| description | Creates or updates a Markdown specification file for an Ambler walk in the specs/ directory. Use this whenever a user wants to document, plan, or describe a walk — including "write a spec", "document this walk", or "plan out the nodes" — even before any code exists. |
| metadata | {"author":"leandro","version":"2.1"} |
This skill guides you in creating a Markdown specification file (specs/<walk-name>.md) for an Ambler walk. These specs describe the program's flow (nodes and edges) and the resulting shared state.
specs/<name>.md.### <Node Name> subsection under ## Nodes.## Shared State heading.Follow this exact format:
# Program Specifications
<Brief description of the program and its purpose.>
## Nodes
### <Node Name 1>
- <Role — e.g., "Initial node.">
- <Logic — e.g., "Prompts the user to enter X.">
- <Edges — e.g., "If valid, transitions to `NEXT`. If invalid, transitions to `START`.">
### <Node Name 2>
- <Role.>
- <Logic.>
- <Edges.>
### <Node Name N>
- <Role — e.g., termination node.>
- <Logic.>
- <Termination — e.g., "Displays result and terminates.">
## Shared State
<Description of the state object, derived from the collective needs of the nodes.>
Use the Write tool to create specs/<name>.md.
specs/*.md before starting to identify reusable nodes and ensure the new specification follows the established style and formatting.### Count) and backtick-quoted ALL_CAPS for references in edge descriptions (`COUNT`).walks/<name>.ts already exists, ensure the spec reflects the implementation. If it doesn't, treat the spec as a blueprint.# Program Specifications, ## Nodes, and ## Shared State — no additional top-level sections unless the walk clearly requires them.# Program Specifications
This program is a simple counter application.
## Nodes
### Start
- Initial node of the application.
- Prompts the user to enter a starting number for the count.
- If the number entered is valid, it transitions to `COUNT`.
- If the number entered is invalid, it displays an error message and transitions to `START`.
### Count
- Prints the current count and increments the counter.
- Transitions to `COUNT` or to `STOP`.
### Stop
- Displays the final count and terminates.
## Shared State
The shared state consists of:
- `count`: An integer representing the current value.
On-demand reference for the globally-installed `azk` CLI — exact JSON output shapes and non-obvious gotchas per subcommand (search, create, get, update, delete, link, reindex) that aren't covered by the binary's own usage/error output. Use this once `azk-install` has already installed `azk` globally, whenever you're about to run a CRUD operation and need to know the response shape or an edge case (e.g. what happens on empty stdin, what partial update returns, what delete cascades to). For installing `azk` globally in the first place, use azk-install instead.
Installs the `azk` CLI globally for the current user — a one-time, project-independent setup so any workspace can use `azk search/create/get/update/delete/link/reindex` as a bare command, backed by ambler-ts's Zettelkasten-RAG walk. Also installs the on-demand `azk-reference` skill (CRUD JSON shapes and gotchas) into the current agent's own global skills directory. Use this whenever a user wants to install azk (or "the zettel/zettelkasten command") globally, system-wide, or for every project, without vendoring the walk's code into any specific project. For vendoring the walk's code into one Ambler project instead (so it doesn't depend on this global install), use azk-init.
On-demand reference for a project's already-installed vendored `azk` deno task — exact JSON output shapes and non-obvious gotchas per subcommand (search, create, get, update, delete, link, reindex) that aren't covered by the walk's own usage/error output. Use this once `azk-init` has already installed the walk, whenever you're about to run a CRUD operation and need to know the response shape or an edge case (e.g. what happens on empty stdin, what partial update returns, what delete cascades to). For installing the walk into a project in the first place, use azk-init instead.
Installs a Zettelkasten-RAG knowledge store into an Ambler project by vendoring the `azk` walk's actual code into it — version-controlled Markdown notes in `notes/`, a derived SQLite search index, the unified `azk` walk/nodes/utils, a project `AGENTS.md` enforcing retrieve-before/store-after, and local copies of this skill and azk-reference. Use this whenever a user wants to add a knowledge base, notes, memory, or "second brain" to an Ambler project — even if they say "set up zettelkasten", "add RAG", "let the agent remember things", or "add AGENTS.md". For day-to-day search/create/get/update/delete/link/reindex once installed, use azk-reference instead. For a global, project-independent `azk` command instead of vendoring code into this one project, use azk-install.
Creates a complete Ambler walk — the TypeScript wiring file (walks/<name>.ts) and the Markdown spec (specs/<name>.md) — and ensures all required nodes exist. Use this whenever a user wants to add a new program or flow to an Ambler project, even if they say "new walk", "add a program", "wire up these nodes", or just describe what they want the app to do.
Creates a new Ambler node — with tests, using test-driven development. Use this whenever the user wants to add a node, step, or state to an Ambler project — even if they phrase it as "add a step", "create a handler", or describe the behavior without using the word "node". Also use when creating a node WITH tests or following TDD for a new node. For adding tests to an existing node that already has an implementation, use `/ambler-test` instead.