{
  "markdown": "# Agentic Intent Model (AIM) v5.6\n\n*Formerly \"Application Intent Model\" — renamed when the language generalized beyond software.*\n\nAIM is a specification language for humans and AI agents. It captures the **intent** of a system — an application's behavior, a business process, an organization's commitments — in structured `.aim` files that agents read once, realize, review against, and repair over time — replacing the sprawl of PRDs, SOPs, design notes, and plan files that otherwise hold intent hostage in prose. Software was AIM's first domain and remains its most worked example; nothing in the language is specific to it.\n\n**This repository is the specification itself** — the language, its reference examples, and the role prompts. Tooling, the package catalog, and publishing live in separate repositories.\n\n---\n\n## Why AIM\n\n- **Ground agents in explicit, versioned intent** instead of loose chat context that evaporates between sessions.\n- **A reviewable contract between intent and reality.** `.aim` files are normally agent-authored from a human's narration, but a small model is something a human can read, correct, and diff — and a Reviewer can check reality against (code, configurations, execution logs) — far more cheaply than inspecting the realization itself.\n- **A relation graph, not just a tree.** AIM treats every `.aim` file as a projection of a node-and-edge graph: a View *exposes* a Contract, a Flow *mutates* a Record and *emits* an Event. That graph is derived, traversable, and checkable.\n- **Drift as graph-diff.** With optional intent↔realization bindings, review becomes a diff between the declared graph and the realized graph — recovered from code for software, from logs and configurations for processes.\n\nAIM pays off when reading the model is meaningfully easier than inspecting the realization. For trivially small or throwaway work, acting directly is the right call.\n\n---\n\n## The graph foundation (the v4 break)\n\nv4 was the breaking change from v3.1 that founded the language on a graph; v5 generalizes it beyond software and finishes the naming (spec §13.3). The three shifts:\n\n1. **Graph-founded model.** The `.aim` Markdown file is a *projection* of an underlying node-and-edge graph. Every heading is an addressable node.\n2. **Typed edge taxonomy.** One CommonMark-native token — `[verb](aim:<address>)` — replaces v3.1's inconsistent prose cross-references. Dangling references, orphan nodes, and impact sets fall out for free, and the traceability chain becomes *computable* rather than aspirational.\n3. **Intent↔realization binding layer.** An inline `### Bindings` property on each node (with its own `provenance`; deprecated `kind: binding` sidecars still accepted) maps intent nodes to their realization sites — in code, in systems, in automations — turning drift detection into a graph-diff.\n\nMigrating from v3.1: see Section 13 of [specification.md](./specification.md).\n\n---\n\n## File format at a glance\n\n```markdown\n---\naim: nemicko.demo.todo\nkind: intent\n---\n\n# TaskManager\n\n## Summary\n\nA personal task manager.\n\n## Requirements\n\n- Users can create and complete tasks.\n\n## View: TodoDashboard\n\n### Summary\n\nThe owner's task-list surface.\n\n### Actions\n\n- Submitting the \"New Task\" form — [exposes](aim:#Contract:CreateTodo)\n```\n\nThe `[exposes](aim:#Contract:CreateTodo)` token is a typed edge: `View → exposes → Contract:CreateTodo`. Collect every such token across a project and you have the relation graph.\n\nTwo worked examples ship with the spec:\n- [examples/nemicko.demo.todo.aim](./examples/nemicko.demo.todo.aim) — a complete intent in a single file.\n- [examples/helpdesk/](./examples/helpdesk/) — a multi-file app (an intent tree, a mapping, and a binding file) whose graph spans files, exercising **every** facet and the closed verb set end to end. Start with its [README](./examples/helpdesk/README.md) for the rendered graph.\n\n---\n\n## The roles\n\n1. **Architect** designs the intent graph from a human's narration and serializes it as `.aim` files.\n2. **Realizer** makes reality match the model — a development team, an automation, an agent performing a process — and keeps bindings current. (In software this role is the **Developer**, and the shipped prompt templates use that name.)\n3. **Reviewer** diffs reality against the declared graph and reports drift — explicitly routed to a realization fix (Realizer) or an intent revision (Architect).\n\n---\n\n## Render `.aim` files as Markdown on GitHub\n\nDrop a `.gitattributes` file at your repo root:\n\n```gitattributes\n*.aim linguist-language=Markdown\n*.aim linguist-detectable=true\n```\n\nGitHub will render `.aim` files as Markdown — frontmatter, headings, lists, and the edge tokens as clickable links.\n\n---\n\n## Repository contents\n\n- **[specification.md](./specification.md)** — the authoritative AIM v5.6 language spec.\n- **[AGENTS.md](./AGENTS.md)** — the reference project-bootstrap file (cold-start entry point for any AI coding agent).\n- **[PROMPT.md](./PROMPT.md)** — role-based prompts for any AI assistant.\n- **[agents/](./agents/)** — Architect, Developer, Reviewer, and Encoder persona files.\n- **[brain/](./brain/)** — the shared and per-role operating-brain instructions.\n- **[examples/](./examples/)** — conformance examples: a single-file intent and the multi-file [helpdesk](./examples/helpdesk/) app.\n- **[.claude-plugin/](./.claude-plugin/)** + **[skills/amy/](./skills/amy/)** — Claude Code plugin **Amy**: one auto-invoked skill that reads the task and enters the right mode, plus the mode subagents from [agents/](./agents/).\n- **[GEMINI.md](./GEMINI.md)** + **[gemini-extension.json](./gemini-extension.json)** — Gemini CLI extension **Amy**: one assistant that reads the request and enters the right mode (Architect / Developer / Reviewer / Encoder).\n- **[codex/prompts/amy.md](./codex/prompts/amy.md)** — OpenAI Codex `/amy` prompt; Codex also reads [AGENTS.md](./AGENTS.md) automatically, so an AIM project self-bootstraps with no install.\n\n---\n\n## Meet Amy\n\n**AIM is the language; Amy is the assistant who speaks it.** You don't pick a role from a menu — you talk to Amy and she enters the right mode herself: design the intent, build code from it, review code against it, or reverse-engineer an existing codebase into an intent model.\n\n- **Claude Code** — add this repo as a plugin marketplace, then install Amy:\n  ```\n  /plugin marketplace add juicejs/application-intent-model\n  /plugin install amy@intentmodel\n  ```\n  Amy auto-invokes whenever you work with `.aim` files or ask to model, build, review, or capture a system.\n- **Gemini CLI** — install the extension from this repo:\n  ```\n  gemini extensions install https://github.com/juicejs/application-intent-model\n  ```\n- **OpenAI Codex** — drop [codex/prompts/amy.md](./codex/prompts/amy.md) into `~/.codex/prompts/` for a `/amy` command. In any project with an `AGENTS.md` (AIM ships one), Codex picks up the model automatically even without it.\n\nAny other agent: point it at [AGENTS.md](./AGENTS.md) and the spec at <https://intentmodel.dev/spec.md>.\n\n---\n\nCurrent spec: **AIM v5.6**  \nBuilt by **[Juice d.o.o.](https://juice.com.hr)** · MIT License\n",
  "bytes": 7146,
  "sha": "d1a14f4a1e234eea7274520169bb0f88e5ef735e6912e4ce77c0ceeefe1903dd",
  "repo_slug": "juicejs/application-intent-model",
  "fonte": "repo",
  "truncated": false,
  "api": "https://agentalog.com/api/listings/plg_juicejs_application_intent_model_a590e84f/readme"
}