ambler-spec

Étoiles7

Forks0

Mis à jour19 mai 2026 à 18:14

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.

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Source

argenkiwi

argenkiwi/ambler-ts

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Métiers associésSOC

Basé sur la classification professionnelle SOC

Rédacteurs techniquesArts, design, divertissement, sports et médias·SOC 27-3042

SKILL.md

readonly

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"}

Ambler Specification

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.

Instructions

1. Identify the Walk's Name and Purpose

If not provided, ask the user for the name and a brief description of the walk.
The file should be named specs/<name>.md.

2. Map the Nodes and Edges

Identify all Nodes in the walk (the discrete states or steps).
For each node, identify its Edges (the possible transitions to other nodes).
For each node, create a ### <Node Name> subsection under ## Nodes.
Describe:
- Its role (e.g., "Initial node").
- Its logic (what it does).
- Its edges (what conditions lead to which next node).

3. Determine the Shared State

Aggregating the inputs required and outputs produced by all nodes.
Identify the data structure that must be maintained throughout the walk to satisfy these node requirements.
Describe it under a ## Shared State heading.

4. Format the Markdown

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.>

5. Write the File

Use the Write tool to create specs/<name>.md.

Guidelines

Consistency: Browse specs/*.md before starting to identify reusable nodes and ensure the new specification follows the established style and formatting.
Node name casing: Use Title Case for headings (### Count) and backtick-quoted ALL_CAPS for references in edge descriptions (`COUNT`).
Clarity: Describe what the program does, not how the code implements it.
Implementation Alignment: If walks/<name>.ts already exists, ensure the spec reflects the implementation. If it doesn't, treat the spec as a blueprint.
No extra sections: Stick to # Program Specifications, ## Nodes, and ## Shared State — no additional top-level sections unless the walk clearly requires them.
Pragmatic State: Don't guess the state first; look at what each node needs to know or change, and then define the state.

Example Specification

# 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.

Plus depuis ce dépôt

même dépôt

azk-reference

argenkiwi/ambler-ts

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.

2026-07-107

azk-install

argenkiwi/ambler-ts

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.

2026-07-107

azk-reference

argenkiwi/ambler-ts

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.

2026-07-107

azk-init

argenkiwi/ambler-ts

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.

2026-07-107

ambler-walk

argenkiwi/ambler-ts

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.

2026-05-277

ambler-node

argenkiwi/ambler-ts

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.

2026-05-227

Ambler Specification

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.

Instructions

1. Identify the Walk's Name and Purpose

If not provided, ask the user for the name and a brief description of the walk.

The file should be named specs/<name>.md.

2. Map the Nodes and Edges

Identify all Nodes in the walk (the discrete states or steps).

For each node, identify its Edges (the possible transitions to other nodes).

For each node, create a ### <Node Name> subsection under ## Nodes.

Describe:

Its role (e.g., "Initial node").
Its logic (what it does).
Its edges (what conditions lead to which next node).

3. Determine the Shared State

Aggregating the inputs required and outputs produced by all nodes.

Identify the data structure that must be maintained throughout the walk to satisfy these node requirements.

Describe it under a ## Shared State heading.

4. Format the Markdown

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.>

5. Write the File

Use the Write tool to create specs/<name>.md.

Guidelines

Consistency: Browse specs/*.md before starting to identify reusable nodes and ensure the new specification follows the established style and formatting.

Node name casing: Use Title Case for headings (### Count) and backtick-quoted ALL_CAPS for references in edge descriptions (`COUNT`).

Clarity: Describe what the program does, not how the code implements it.

Implementation Alignment: If walks/<name>.ts already exists, ensure the spec reflects the implementation. If it doesn't, treat the spec as a blueprint.

No extra sections: Stick to # Program Specifications, ## Nodes, and ## Shared State — no additional top-level sections unless the walk clearly requires them.

Pragmatic State: Don't guess the state first; look at what each node needs to know or change, and then define the state.

Example Specification

# 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.