# Agent Recipes Source: https://acai.sh/agents Make the most of acai.sh and agentic development by leveraging LLM skills and roles We've prepared some example skills and roles so your LLMs and AI agent harness can make the most of acai.sh. ## Acai Skill The Acai CLI can output a premade acai skill to `.agents/skills/acai/SKILL.md`. The skill teaches your agent the basics of `feature.yaml` and spec-driven development. It consumes \~950 tokens of context. Omit `--install` and it will write to `stdout`. ```sh theme={null} acai skill --install ``` If you don't have the cli yet, you can fetch the skill directly using `npx` or a similar command. ```sh theme={null} npx @acai.sh/cli skill --install ``` Just hand off your spec and watch them work! ## Spec-driven Software Factory With custom agent and sub-agent roles, and a well-written spec, you can ship ambitious software with very little intervention. All you need are 4 role files, and [OpenCode](https://opencode.ai/). Write a spec, hand it to the `supervise` agent, and let them handle the rest. It performs a planning, execution, and self-review loop until it believes the project is complete and high-quality. ```mermaid theme={null} sequenceDiagram participant U as You participant S as 🤖 Supervise participant T as 🤖 Prepare-Tasks participant D as 🤖 Implement participant R as 🤖 Review-Task U->>S: Spec S->>T: Plan tasks T-->>S: Task files loop Until project is complete S->>D: Implement next task D-->>S: Ready for review S->>R: Review task alt Changes rejected R-->>S: Rejected with feedback S->>D: Rework task else Changes accepted R-->>S: ACCEPTED S->>S: Integrate task work S->>T: Next task? T-->>S: More tasks or done end end ``` ### Factory Agent Roles The following agent roles are compatible with **OpenCode's [custom agents](https://opencode.ai/docs/agents/).** For planning roles, we recommend using more expensive frontier models. Configure the target model to fit your budget or existing subscriptions. ```md theme={null} --- name: supervise description: "The supervisor's only job is to coordinate and delegate other agents for task definition, implementation, and review." mode: primary model: openai/gpt-5.4 variant: low permission: edit: allow bash: "*": allow webfetch: allow --- You are a Project Supervisor. Your job is to coordinate handoff between agents. We work with the `prepare-tasks` agent, the `implement` agent, and the `review-task` agents. ## Before you start (MANDATORY) * [ ] Check your git status. If needed, prepare a root integration branch e.g. `feat/{feature_name}`. Avoid committing to main. ## Process Oversee project completion of a project beginning to end, following this sequential process. 1. Dispatch `prepare-tasks` agent. - `prepare-tasks` agent plans the entire project and breaks the work up into one or more tasks, and writes these to a temporary folder 2. Dispatch `implement` agent to a task. - `implement` agent will read the task file, makes code changes, and write tests. 3. Dispatch `review-task` agent. - They will determine if the changes on the working task branch are ACCEPTED, or REJECTED. - If accepted, they will notify you and invite you to integrate the work. - If rejected, they will append their review findings to the existing task.md file and notify you. 5. (IF REJECTED) Go to 2. Dispatch a new `implement` agent and invite them to respond to new action items appended to the task.md file 6. (IF ACCEPTED) Commit and/or merge the work. Assign the next task file (if already prepared) or invite another `prepare-task` agent to prepare more tasks. Repeat this process until the `prepare-task` agent tells you that the project has been completed. You are responsible for git ops - create and integrate branches as you see fit, ideally to a central feature or impl. branch. Do not touch `main`. ### Prompt templates for agent dispatch Please follow these templates. In some cases, you do not need to add any additional information. If there is a relevant feature.yaml file, feel free to reference it. **prepare-tasks** > Proceed with task planning and creation. Details are provided below. In response, provide me the task file paths so I can assign them. Or, halt and notify me when the project has reached completion to your satisfaction. Details: You can find the task assignment file at path: ``. It should contain everything you need to proceed with implementation. **implement - handle review feedback** > Work was done to implement a task, but the work did not pass review and could not be merged. Please pick up where they left off and proceed by resolving issues in the task file ``. Respond when all items have been addressed. **review-task** > Code changes are ready for review. You can find the implementation at . The relevant changes for review are: . Record your findings into the task.md file, and report back. Task file is located at ``. If during your review you stumble on important follow-up or ancillary work that is out of scope for the current task, you may choose to write additional task .md files to the .tasks directory, and let me know about them. ### Other constraints Don't get hands on, don't read task files, don't read code. Your job is just to coordinate with the other agents, and coordinate git commits and merges. This is how we keep your context window small to keep costs down. ``` ```md theme={null} --- name: prepare-tasks description: "Plan and prepare the next batch of work tasks" mode: subagent model: openai/gpt-5.4 variant: high permission: edit: allow bash: "*": allow webfetch: allow --- Your job is to research, plan and prepare a discrete, well-packaged task (or tasks) that can be assigned to a developer for sequential implementation. ## Before you start * [ ] Identify the current branch, should be `main` or a `feat/` feature branch. We use task `.md` files to plan and assigning chunks of work to engineers. The resulting task files must be comprehensive and complete, the developer who reads it should not need any outside resources, and will not need to read the spec themselves. **What makes a good task assignment?** - Comprehensive research and exploration of the current codebase. Points the developer to existing tools and components that may be useful for this task - Considers dependant and prerequisite work - Includes clear action items / todo boxes to check - Excludes irrelevant and unrelated details - Doesn't micromanage: avoid deciding new variable names, new components, new file paths, etc. unless taken from spec. Only demonstrate critical concepts and patterns. - Always stay true to the spec # Requirements * [ ] Read the acai skill * [ ] If you determine the feature is still blocked or needs prerequisite work that is out of scope for this task, halt and notify the supervisor. * [ ] Output 1 or more task files. If the work is complex, break it into phases - 1 phase per task file. * [ ] Task file is always in `tmp/tasks` dir (from git repo root) and is not git tracked * [ ] Timestamp mandatory e.g. `tmp/tasks/YYYYMMDDHHMMSS_align_my-feature-name_to_spec.md` * [ ] Report back to the supervisor: "I have prepared the following task files, which should be implemented in this order: . Feel free to assign the next task and begin implementation." **If no acceptance criteria remain & you believe implementation is already complete, report back to the supervisor: "I believe this project is complete, and I do not have any more tasks to prepare"** ``` ```md theme={null} --- name: implement description: "My job is to develop and implement code to complete predefined task files." mode: all model: openai/gpt-5.4 permission: edit: allow bash: "*": allow webfetch: allow --- You are a Developer who has been dispatched to implement code and complete a task, or respond to feedback on previous work. Either: A) Starting work on a fresh task, defined in a task .md file B) Resolving feedback or incomplete items (QA, code review etc.), appended to the bottom of an existing task .md file. ## Prerequisites * [ ] Read the relevant task .md file before proceeding ## Process * [ ] Completion is only reached when all tests are passing, all assigned acceptance criteria are implemented, and your work is committed. * [ ] Upon completion, respond back to the supervisor " has been implemented and is ready for (re-)review." If you find that you've been going in circles or have a major question, it's OK to stop early and invite the reviewer for feedback. They can tell you what to do next. ``` ```md theme={null} --- name: review-task description: "My job is to review code implementations and decide if they are mergable and satisfy the assigned task" model: openai/gpt-5.4 permission: edit: allow bash: "*": allow webfetch: allow --- # Before you start * [ ] Find and read the task file which defined the goals and acceptance criteria for this batch of work. ## Process Assume the role of an experienced, high-ranking, high-standards engineer. Your job is to perform code & review of an implementation, feature or task. * [ ] Identify relevant changes and files for review, and review the work. * [ ] Validate that **all the assigned acceptance criteria in the task have been met and tested** * [ ] Validate that test coverage is sufficient. * [ ] Validate that code quality is of the highest standards for readability, elegance, and simplicity. * [ ] Evaluate performance, and ensure the implementation is well-optimized with regards to data fetching, queries, async operations, and memory. * [ ] Confirm the chosen patterns and tools are readable, concise, idiomatic. * [ ] Perform a security assessment Generally, you have high standards, and are not afraid to reject the first pass if you find a major issues, or if the number of nitpicks is very high. 1. Identify excess assigns or large data structures loaded into socket/conn assigns. 2. Identify redundant fetching or repeated lookups during mount/render/handle_event. 3. Identify serialized queries that could be consolidated, batched, or moved into a single context call/transaction. 4. Identify likely N+1 query risks, including lazy preloads, per-item lookups in templates/helpers, or repeated context calls in loops. 5. Distinguish initial page-load costs from interaction/event costs. 6. Prefer concrete observations from code over general advice. # Output After review completion, based on the results of the review, you must follow 1 of these 3 paths: Always append feedback at the bottom of the task file A) The work is ACCEPTED. No major feedback remains unaddressed. In this case, you must: * [ ] Update the task file to note the work as accepted * [ ] Notify the supervisor: "The code for has passed review and can be merged." B) The work is REJECTED * [ ] Add your feedback to the end of the task file, including discrete action items in a todo list. * [ ] Respond by notifying the supervisor "The work was rejected, my feedback has been added to ." C) The task is STUCK, meaning it has been reviewed and rejected more than 4 times (abort) * [ ] Respond by notifying the engineer that the work is STUCK and REJECTED, and they must stop until they receive further instructions from the CTO. ``` A system like this is empowered by acai.sh. Give your agent access to `acai` CLI and use the acai.sh dashboard to track their progress. Agents can use the CLI to read and write implementation progress, or even kick off automated tasks. *** View our quickstart page to install the CLI and play around. # Acai JSON API Source: https://acai.sh/api Overview of the Acai API and how to access it. ## What is the Acai API? The Acai JSON API is the server interface that powers the `acai` CLI. Most users will interact with Acai through the CLI, but the API is available if you want to build your own integrations or automate workflows directly. ## Authentication The API uses access tokens for authentication. You can create access tokens from your Team Home Dashboard. ## Reference Docs View endpoint-level details, request and response formats, and example payloads. An openapi.json spec is also available for generating type-safe client code. ## Self-Hosting The Acai server can also be self-hosted. For setup details and source code, visit `github.com/acai-sh/cli`. ## Next Steps Learn how to manage and sync requirements locally from your terminal. View your project's realtime operations dashboard and track acceptance coverage. # List implementation features Source: https://acai.sh/api-reference/actions/list-implementation-features /openapi.json get /implementation-features Return a summary list of Features that are visible to a given Implementation. These features may be defined in specs that were pushed directly to that Implementation, or inherited from a parent Implementation. The response is a summary list of features, containing some metadata and a summary of code references. This is useful to quickly identify features that may have changed or are missing references. # List implementations Source: https://acai.sh/api-reference/actions/list-implementations /openapi.json get /implementations Discover which Implementations exist for a Product. Filter by Repo + Branch name, and by Feature name. This is the orientation endpoint: when you know the current repo and branch, and need to identify the relevant Implementations that track it. # Push from branch Source: https://acai.sh/api-reference/actions/push-from-branch /openapi.json post /push Sync data from your current git branch to the server. - Upload specs (feature.yaml files) and the requirements and metadata defined in them. - Upload code references (ACID tags) found in source code, and their file paths. This endpoint can create or link implementations while syncing specs and refs, but it does not accept feature-state writes or configure implementation settings directly. Use this when source code or specs have changed on a branch. This endpoint is primarily intended to serve the `acai push` CLI command. # Read canonical feature context Source: https://acai.sh/api-reference/actions/read-canonical-feature-context /openapi.json get /feature-context Return the complete context for one feature in one implementation. This is the main read endpoint for spec-driven work. It returns the complete list of acceptance criteria, including the requirement definitions, lists of existing references in code, and additional metadata. Agents should call this before making additional code changes so they work from the same inherited source of truth that reviewers and dashboards use. # Write feature states Source: https://acai.sh/api-reference/actions/write-feature-states /openapi.json patch /feature-states Record implementation-specific progress for one feature in one implementation. State writes do not change requirement text or code refs; they only capture how this implementation currently evaluates each requirement, for example assigned, blocked, completed, or accepted. On first write, local state starts from the parent implementation when one exists, then applies the incoming changes. Use this after analysis, coding, review, or QA to record progress without changing branch-derived truth. # Blog Source: https://acai.sh/blog/index Experiments in agentic spec-driven development. ## Specsmaxxing Pushing spec-writing too far, then stumbling on a workflow I actually love (and open-sourcing it for you to try). [Read the post →](/blog/specsmaxxing) # Acai.sh CLI Source: https://acai.sh/cli Overview of the Acai.sh Command Line Interface. The CLI facilitates spec-driven development for humans, AI agents, and CI/CD automations. ## What is the Acai CLI? It is primarily used to `push` the state of your local specs and code to the server, where they can be reviewed and annotated. It is also used to `pull` data and states from the server to facilitate coordination and delegation of work. ## Commands at a Glance Use these commands to move between local spec work and shared project context: | Command | What it is for | | ------------------------ | ---------------------------------------------------------------------------------------- | | `push` | Sync local specs and ACID references from your repository to the server. | | `features` | See the known features for an implementation, along with status and reference counts. | | `feature ` | Inspect one feature in detail, including ACIDs, statuses, comments, and code references. | | `set-status ` | Send status updates or issues for a batch of requirements back to the server. | | `skill` | Print or install guidance for spec-driven development with Acai. | ## Next Steps View our quickstart page to install the CLI and play around. Introduction to acai specs, and best practices for spec-first software. Query the API directly, self-host, or build your own client. # Acai Dashboard Source: https://acai.sh/dashboard A shared view of your team's specs, implementation status, and requirement coverage. ## What is the Dashboard? The Acai Dashboard is the shared, server-side view of the work your team is tracking with Acai. Dashboard showing status updates for the Staging implementation of the form-editor feature. It helps you understand: * which products, features, and implementations exist * how acceptance criteria are progressing * where requirements are already referenced in code * what needs attention next As your team pushes specs and code references with the CLI, the dashboard turns that data into a browsable view of project status. ## Try It The best way to understand the dashboard is to use it with your own project: 1. Log in to [https://app.acai.sh](https://app.acai.sh). 2. Create a team and an Access Token. 3. Push a spec with the CLI. *** ## Next Steps Write your first spec, push it, and see it in the dashboard. Learn the ideas and workflow behind writing software from specs. # feature.yaml Specification Source: https://acai.sh/feature-yaml This is the formal specification for the feature.yaml document format (written as a compliant feature.yaml!) ```yaml theme={null} feature: name: feature-yaml description: A formal specification for compliant feature.yaml files. A self-referential spec-for-the-spec. version: 1.0.0-beta.3 product: my-product.example.com version: 1.0.0-beta.3 draft: true description: | This document formally specifies how a compliant feature.yaml file can be written. feature.yaml files are intended to be used as structured, stable lists of acceptance criteria defining the functionality of a software feature, but they could be used for other specifications as well. This document is also a compliant feature.yaml, making it a self-referential spec-for-the-spec. prerequisites: - The acai.sh CLI and server are highly recommended for annotating and syncing your spec files. components: FILE: name: Top level file format requirements: 1: The file must be called `.feature.yaml` 2: The file must begin with the `feature` top-level property (see FEATURE below) 3: The file may contain a `components` top-level property, with unique component keys 4: The file may contain a `constraints` top-level property, with unique constraint keys FEATURE: name: Feature metadata description: Feature metadata is defined under the top-level `feature` key requirements: # feature.name 1: Feature metadata must have a `name` field 1-1: The `name` must be unique within the product 1-2: The `name` must only contain lowercase chars, numbers, dashes, and underscores e.g. `my-feature_123` # feature.description 2: Feature metadata may have an optional `description` string # feature.version 3: Feature metadata may have an optional `version` string 3-1: If present, version should follow SemVer # feature.product 4: Feature metadata must contain a `product` string 4-1: The `product` must only contain upper- and lower-case chars, numbers, underscores, dashes, and periods e.g. `my-product.example.com` 5: Feature metadata may have an optional `prerequisites` list of strings, which help identify external dependencies that live outside the scope of the spec. COMPONENTS: name: Component groupings, defined under the top level `components` property as unique keys. requirements: 1: The `components` object contains only unique component keys, which are groupings of component requirements. 1-1: Component key must only contain upper-case chars, numbers, or underscores e.g. `MY_COMPONENT1` 1-2: Must be unique within the feature; may not clash with any other group key, neither `component` nor `constraint` key. 2: Each component group must have a `requirements` field, containing a list of requirements (defined below). 3: Each component group can have an optional `name` string 4: Each component group can have an optional `description` string CONSTRAINT: name: Constraint groupings, defined under the top level `constraints` property as unique keys. description: The goal of the `constraints` property is to organize cross-cutting requirements, or criteria that don't fit within a single component. requirements: 1: The `constraints` object contains only unique constraint keys, which are groupings of constraint requirements. 1-1: Constraint group key must only contain upper-case chars, numbers, or underscores e.g. `MY_CONSTRAINT2` 1-2: Constraint group key must be unique within the feature; must not clash with any other `component` nor `constraint` key. 2: Each constraint group must have a `requirements` field, containing a list of requirements (defined below). 3: Each constraint group can have an optional `name` string 4: Each constraint group can have an optional `description` string REQUIREMENT: name: Requirement definitions, defined under the constraint.requirements or component.requirements property. description: | Requirements are numbered acceptance criteria that live under a component group key or a constraint group key. The goal of a requirement is to define a behavior or functionality. requirements: 1: Requirement keys must be integer keys (e.g. `1:`, `2:`, `3:`) 2: Sub-requirement must associate to a parent requirement's number, using integer-dash keys (e.g., `1-1`, `1-2`) 2-note: A sub-requirement may be parentless (e.g. `2-1` is present but parent `2` is not present). 3: Sub-requirement keys must never include `-0` as the parent requirement is implicitly the 0th item. 4: Requirements may be written as any yaml compatible string, including multi-line blocks with markdown, gherkin, etc. 5: Requirements and sub-requirements can be defined as either key-string pairs or key-object pairs 6: requirement: When defined as an object, it must contain a `requirement` property with the requirement definition string note: This is an example of object notation, with a requirement and a note, as opposed to the key-string pairs above. 6-1: The object may contain a `note` property with a string value 6-2: The object may contain a `deprecated` property with a boolean value 6-3: The object may contain a `replaced_by` property with a list of ACID strings 7: Alternatively, notes may be defined in-line and attached to parent using `-note` suffix, (e.g. `1-note`, `2-1-note`) 7-note: This is an example of the simple note syntax, which is often preferred to nested `note` keys 8: Sub-requirements may not be nested more than 1 level deep. E.g. `1-1` is allowed, `1-1-1` is forbidden. ACID: name: Requirement ID references / Acceptance Criteria IDs (ACIDs) requirements: 1: A requirement can be referenced anywhere in the product via its unique ACID 2: ACIDs follow the format `..` for example `my-feature.MY_COMPONENT.1-1` or `my-feature.MY_CONSTRAINT.2` ``` # Acai.sh Source: https://acai.sh/index A toolkit for spec-driven software development. Stop writing prompts, start writing specs. Ship better quality software and minimize slop. **ACAI** - **A**cceptance **C**riteria for **AI** *** ## What is it? Open-source tools to assist with spec-driven software development. * A **simple spec format** called `feature.yaml`, that keeps your requirements organized and traceable. * A **CLI** for you or your LLM to push and pull specs, requirements, coverage, status and comments. * A **server and dashboard** to facilitate QA, code review, and collaboration. * A **process and convention** for identifying spec requirements from within your code comments and tests, to create a searchable, greppable connection between the two. *** ## Very Quick Start Acai can be incrementally adopted into any existing project. ```sh theme={null} npx @acai.sh/cli --help ``` Write requirements and acceptance criteria in `feature.yaml` spec files. Run `acai push` to extract the specs and push them to an Acai Server. Give your agents access to the cli so they can implement, review, self-assign and share status updates. Dear Claude, I hope this email finds you well. Please run \`npx @acai.sh/cli skill\`. This will teach you everything you need to know about our process for spec-driven development. Then, proceed to plan and implement the features specified in the spec I wrote. Love,\ \[your-name] This unlocks a spec-oriented workflow that **can replace GitHub and Linear tickets**. You, your agent swarm, and your product manager can stay in-sync while rapidly iterating on specs and their implementations. *** Dashboard screenshot showing progress on implementation of a feature spec *** # Key Features ### Go beyond test coverage Have all requirements been implemented?\ Do all implementations have tests?\ Have humans QA'd and accepted the implementation? ### Collaborative & multiplayer Invite your team to a shared Acai dashboard, or create access tokens for AI agents and CLI access to the server. Example of a comment and a rejected requirement status Track progress from spec, to implementation, to agent review, to human acceptance: `No status` -> `Assigned` -> `Completed` -> `Accepted` ```md Agent Code Reviewer theme={null} I've reviewed profile.MENU.2 and profile.AUTH.1 I see no issues. Unit tests are satisfactory. I am marking the requirement as `COMPLETED`... I am merging the changes to the feature branch... ``` ### Any git workflow Acai works with monorepos and polyrepos or any combination. * Monorepos containing many products with many specs and many branches (`main`, `dev` etc.) * Polyrepos where a feature may touch several branches on several git repos (frontend, backend, microservice etc.) Example dashboard showing details about a specific feature requirement ### Grab context Acai introduces the ACID system for referencing your spec from anywhere in your repo. This makes it easy to see exactly where a requirement has been implemented or tested, so you (or your agent) can improve test coverage, QA, and react to ever-changing requirements. ```sh theme={null} acai feature my-feature-name --json --include-refs ``` ### Review code more effectively Stop trying to read huge diffs from top to bottom. Instead, use the acai dashboard and jump straight to the functions, tests or comments that reference each requirement in your spec. Start by reviewing the requirements that matter most; auth, security, performance, and user happiness. *** ## Simple example At the top of the page you can see a fun terminal animation we created as a demo of Acai in action. Below you can see the spec, code, and tests for that animation. ```yaml feature.yaml theme={null} feature: name: animated-terminal product: docs description: | A mock terminal animation for our docs site. It demonstrates how an AI agent uses the acai toolkit to work on a software project. 🥚 In the example, it is self-referentially building itself, from this very same spec. components: FRAME: name: Terminal frame and container description: UI container that looks like a terminal window on a Mac with a TUI instance running inside it requirements: 1: Renders scrollable mock chat history 1-1: Does not auto-scroll unless user is already at the bottom of scroll container 2: Renders mock text input 2-1: Does not accept actual user inputs (no typing, no buttons) STORY: name: Rough storyboard for the animation requirements: 1: Animation starts with user typing "I've made some changes to the spec @animated-terminal.feature.yaml - please run `acai skill` to learn spec-driven development." 2: Shows the agent run `acai skill`. Agent says "Got it. I will look to see what changed, then re-align the code to spec." 3: Concludes with user typing "Nice job. I'm looking at it right now. It's flawless. Go ahead and mark all requirements as accepted." 3-1: Agent runs `acai set-status` and marks all requirements as accepted. 4: The animation stops after the final step and does not loop. constraints: DEV: requirements: 1: Must be a single, self-contained standalone react component (a single export, with no imports) ``` ```tsx animated-terminal.jsx theme={null} // animated-terminal.DEV.1 - No imports export const AnimatedTerminal = () => { const chatRef = useRef(null); useEffect(() => { // animated-terminal.FRAME.1-1 - autoscroll const el = chatRef.current; if (el) { // Use a threshold to detect if the user is "near" the bottom const isNearBottom = el.scrollHeight - el.scrollTop - el.clientHeight < 100; if (isNearBottom) el.scrollTop = el.scrollHeight; } }, [messages]); return ( {/* animated-terminal.FRAME.1 */}
{messages.map((msg, i) => renderMessage(msg, i))}
); }; ``` ```ts animated-terminal.test.ts theme={null} // When we tag tests with requirement IDs, the acai.sh dashboard automatically tracks coverage! describe("Constraints", () => { // animated-terminal.DEV.1 - Dev constraint it("self-contained standalone component (no imports)", () => {}); }); describe("UI rendering", () => { // animated-terminal.FRAME.1 it("renders scrollable mock chat history", () => {}); // animated-terminal.FRAME.1-1 it("auto-scrolls ONLY if user is at bottom threshold", () => {}); // animated-terminal.FRAME.2 it("renders mock text input", () => {}); // animated-terminal.FRAME.2-1 it("ignores user typing and button interactions", () => {}); }); ```
As shown above, acai gives each requirement an ID that is unique, stable, and readable. These IDs should be referenced liberally (in tests, comments, and other specs), and are extracted from code with a single command. The idea is when your spec changes, your code must change too. ## Why acai? LLM agents love Acai IDs. They make it easy to pull in context, find references, and trace the *intent* of an implementation or test. Stop losing progress when agents go off the rails. Your spec is the source of truth, even as complexity grows and requirements evolve. Quickly prototype, try throwaway implementations, and solidify the spec before touching production code. The result is less time prompting, and a better end result. In the past, this level of specification rigour was painful for human teams. Today, for an LLM with access to Acai, it's painless. *** ## Next steps Get up and running. Write and implement your first spec. Introduction to acai specs, and best practices for spec-first software. # Quickstart Tutorial Source: https://acai.sh/quickstart Write your first feature spec and push it to the Acai.sh dashboard. Equip your LLM agents with the `acai` CLI and teach them to follow a spec-first workflow. ## Quickest Quickstart Just ask an agent show you around. Dear Claude, I'm learning how to use acai to write my very first feature spec. Run \`npx @acai.sh/cli skill\` to learn about it. Think of a simple new feature to add to this app, as an example. Draft a \`feature.yaml\` spec for me to read. ## Add to an existing project **Prerequisites**\ You only need `git` and a software project to work on.\ Claude, Opencode, Codex or a similar agent harness is highly recommended. ### 1. Install CLI ```sh npm theme={null} npm i --save-dev @acai.sh/cli ``` ```sh pnpm theme={null} pnpm add --save-dev @acai.sh/cli ``` ```sh bun theme={null} bun add --dev @acai.sh/cli ``` ```sh yarn theme={null} yarn add --dev @acai.sh/cli ``` If you don't have a JavaScript runtime, you can download Mac and Linux releases on our [GitHub](https://github.com/acai-sh/cli/releases). Confirm that it's installed properly: ```sh theme={null} acai --help ``` ### 2. Authenticate the CLI You need to create a team at [https://app.acai.sh](https://app.acai.sh) (or on your self-hosted server). From the Team Home page, create an access token. Save the token to .env: ```.env theme={null} ACAI_API_TOKEN=at_my_secret_team_access_token ``` ### 3. Install SKILL.md ```sh theme={null} acai skill --install # writes to .agents/skills/acai/SKILL.md ``` ### 4. Write a spec Read our [spec-writing tutorial](./writing-specs) for a slightly more detailed introduction to writing specs the Acai way. In short, the spec is just an organized list of acceptance criteria. ```yaml theme={null} # features/my-feature.feature.yaml feature: name: user-auth product: enterprise-api components: LOGIN: requirements: 1: Shows an email and password input 2: Includes a "Forgot Password" link 3: On success, navigates to the team overview constraints: AUTH: 1: Does not leak information about existence or absence of a user's email ``` Spec files **must** be named `.feature.yaml` and **must** be somewhere under the `features/` directory in the root of your git project. AI can help you draft specs, but nothing beats an organic, pasture-raised, hand-written spec. Spec-writing is where the act of *software engineering* really happens. ### 5. Annotate code and tests with ACIDs By writing specs in structured yaml, we can refer to each requirement with a unique and stable identifier. For example, `user-auth.LOGIN.3`. We call these IDs "ACIDs" (Acceptance Criteria Identifier). The Acai CLI scans your repo to find ACIDs in comments and in tests. These simple refs help guide AI agents during implementation, assists code review and QA, and helps you enforce strong E2E test coverage. ```ts animated-terminal.test.ts theme={null} // When we tag tests with requirement IDs, the acai.sh dashboard automatically tracks coverage! describe("Constraints", () => { // animated-terminal.DEV.1 - Dev constraint it("self-contained standalone component (no imports)", () => {}); }); describe("UI rendering", () => { // animated-terminal.FRAME.1 it("renders scrollable mock chat history", () => {}); // animated-terminal.FRAME.1-1 it("auto-scrolls ONLY if user is at bottom threshold", () => {}); // animated-terminal.FRAME.2 it("renders mock text input", () => {}); // animated-terminal.FRAME.2-1 it("ignores user typing and button interactions", () => {}); }); ``` Typically, LLMs are very good at annotating their work as they go, and are good at re-aligning it when the spec changes. Just make sure they have read the `acai skill`. ### 6. Push & review ```sh theme={null} acai push --all ``` Acai scans the repo and pushes all specs and any references to specs / ACIDs. Log in to acai.sh to see an overview of your products, features and implementations. It is a helpful place to review coverage, flag issues, and to track specs and their implementations from PR to production. You (human or robot) can mark requirements as Completed when they are ready for review, Accepted when they pass your review, or Rejected if something was missed. ## Self-host The acai server is open-source and containerized. You can host it yourself and point your CLI at it using an environment variable. See [GitHub](https://github.com/acai-sh) for more info. ```sh theme={null} # Example override, e.g. a local docker network ACAI_API_BASE_URL=http://caddy:80/api/v1 # defaults to https://acai.sh/api/v1 ``` ## Next Steps Introduction to acai specs, and best practices for spec-first software. Make the most of acai.sh and agentic development by leveraging LLM skills and roles # Spec-driven Development Source: https://acai.sh/spec-driven-development Introduction to `feature.yaml` specs, and best practices for spec-first software development. Spec-driven development balances the speed of "vibe coding" with the professional rigor required to ship high-quality applications. It is essential for developers and teams who wish to leverage agentic software development tools like Claude and OpenCode in complex projects. ## What is a spec? In Acai.sh, every spec is a 'Functional Requirements Doc' for a single feature in your product. It is written as a `feature.yaml` file. Primarily, the spec is written as a **list of acceptance criteria**. It defines how your feature should *behave*, functionally. It also includes additional constraints or requirements that are neccesary for success. Here is a minimalist example: ```yaml theme={null} feature: name: user-authentication product: enterprise-api components: LOGIN: description: The login UI and journey requirements: 1: Shows an email and password input 2: Includes a "Forgot Password" link 3: On success, navigates to the team overview 4: On success, issues secure session token to client constraints: AUTH: description: Additional eng. constraints requirements: 1: Does not leak information about existence or absence of a user's email 2: Session expires after 5 minutes of inactivity 3: Session expires 12 hours after last login ``` ## Where is the spec? In Acai, specs are committed to git repositories as `.yaml` files. Specs must be located in a `features/` directory.\ The file name must include the name of the feature. ## The Feature.yaml Document All acai specs are yaml. Yaml has a few key benefits over markdown, but remains lightweight and flexible. ### Basic format As shown in the example spec above, the document has three main sections: 1. feature: Metadata about the feature, such as its name, version, product and description. 2. components: Functional requirements, organized into component groups. 3. constraints: Cross-cutting or plumbing requirements (like performance, authorization, data privacy) To be compatible with the acai.sh dashboard and CLI, your feature.yaml **must** have a `feature.name` and `feature.product` defined. ### Advanced Tips Feature.yaml supports some useful patterns for adding additional notes and context in a structured way. You can attach **notes** directly to requirements. These are passed along to the acai.sh server and included in CLI / API response payloads. There are two ways to add notes. ```yaml theme={null} # Concise syntax 1-1: Hides exact location of the building 1-1-note: This was a customer request (April 2026) # Verbose syntax 1-2: requirement: Hides exact location of the building note: This was a customer request (April 2026) ``` Your `components` and `constraint` groups support arbitrary `name` and `description` fields, which is a good place to add additional context. ```yaml theme={null} components: LOGIN: name: Login Form description: A standard login UI component requirements: 1: ... constraints: AUTH: name: Authentication description: Additional eng. constraints around auth and security requirements: 1: ... ``` You can associate a sub-requirement to a parent (up to 1 level of depth). This makes it easy to insert more requirements without needed to renumber existing ones. ```yaml theme={null} components: MAP: requirements: 1: Clicking a property opens the details panel 1-1: Highlights the selected property on the map 1-2: Sends an analytics event ``` If one requirement relates to another, you can reference it using its complete ID (known as the ACID) like `my-feature.COMPONENT.1-1`. ```yaml theme={null} 1: Opens the Panel (see property-map.PANEL.1) 1-1: Also zooms the map, similar to property-map.MAP.4 ``` Instead of deleting them, you may want to flag them as `deprecated` to maintain a living history. ```yaml theme={null} requirements: 1-1: deprecated: true requirement: Shows a tutorial on first load note: Removed due to negative user feedback 1-2: skipped: true requirement: Shows location search box note: Blocked by geolocation service issue #1234 1-3: replaced_by: ["property-map.MAP.1-4", "property-map.MAP.1-5"] requirement: Fly to searched location note: Replaced by better UX ``` ## What makes a good spec? There are some important best practices to follow. * Focus on the **functional behavior**, and key engineering constraints, and ideally only things that can be tested with a pass/fail. Feel free to use `-note` and `description` to provide soft or higher level guidance. * **Avoid superficial requirements** (design, layout, aesthetics, copywriting, etc.) unless they are mission-critical. Otherwise your spec will grow too large and your product will grow too rigid. * **Omit obvious requirements**. Have faith your developers can fill in the gaps! * **Be descriptive, not prescriptive**. Say what needs to be implemented, avoid prescribing how it gets implemented. * If you find yourself duplicating requirements in many specs, consider creating a `core.feature.yaml` or just putting guard rails in `AGENTS.md` and other docs. * The feature boundary is up to you, but smaller features are more maintainable. A small feature spec is easy to read and review, easy to ship and QA, easier to feature-flag and roll-back. *** ## The Spec Lifecycle Specs add the most value to teams working on complex, high-stakes projects. So how do we think about specs when working on a project with many services, many git repos, long-lived branches, and multiple QA cycles? ### Mental model / data model Acai abstracts this complexity by breaking your project into **4 core concepts**. | Entity | Example | | ----------------------------- | --------------------------------------------------- | | Product | `mobile-app` `CLI` `web-app` | | Implementation | `Prod` `dev` `maintenence` | | Feature | `carbon-calculator` `support-chat` `users-endpoint` | | States | `Assigned` `Completed` `Accepted` `Rejected` | Let's use an example to understand this better. Imagine a spec for a carbon calculator in a travel app. 1. carbon-calculator.feature.yaml lives in your repo, on git branch called `backend/main`. 2. The git branches `backend/main` and `frontend/main` are both tracked by the Production implementation.\ This happens automatically, the first time you run `acai push --all --target Production` 3. Production is an implementation of the mobile-app product. 4. When QA is done, all of the requirements defined in carbon-calculator.feature.yaml are marked as Accepted on Production This simple model also works great for more complex monorepos and polyrepo projects. In any case, a team can have many products, and a product can have many features and many implementations, which track many git branches on many repos. Example dashboard showing a list of implementations of the map-settings feature. ### Spec journey So the lifecycle of a feature from draft spec to production may differ from team to team, but the simplest example is this; Create a branch like `feat/carbon-calculator` and draft your `feature.yaml` Run `acai push` to extract the specs and push them to an Acai Server. This creates a new implementation, which is named after your branch by default. Invite your team to review by sending them a link to the Acai.sh dashboard for your new feature + implementation. When the spec and code passes QA, merge the code, delete the old implementation. When the feature is merged (e.g. to `main`), push again from the `main` branch so that the dashboard reflects the current state of your app. CI / GitHub actions are useful here. Some teams prefer to review and merge specs to the main branch before even starting implementation. Other teams might even maintain a standalone `specs` repo. Acai.sh should work for all the common git workflows.