acstack
Agentic coding stack with first-class Claude Code and pi support: skills, orchestrator instructions, and verification agents.
Package details
Install acstack from npm and Pi will load the resources declared by the package manifest.
$ pi install npm:acstack- Package
acstack- Version
0.50.4- Published
- Oct 18, 2026
- Downloads
- 272/mo · 272/wk
- Author
- ac8318740
- License
- MIT
- Types
- extension
- Size
- 7.8 MB
- Dependencies
- 0 dependencies · 1 peer
Pi manifest JSON
{
"subagents": {
"agents": [
"./pi/agents"
]
},
"extensions": [
"./pi/extension.ts",
"./assets/terminal-workspace/pi/acstack-question-blocked.ts"
]
}Security note
Pi packages can execute code and influence agent behavior. Review the source before installing third-party packages.
README
ACStack
ACStack is an agentic coding stack. It helps coding agents clarify requirements, test meaningful behavior, and keep docs matching the code.
- ACStack aims to solve two common failure modes coding agents introduce
- The agent starts building before the requirements are clear
- The agent writes code, then creates tests that pass against that code
- ACStack has first-class support for Claude Code and pi
- Claude Code installs it as a plugin
- pi installs it as an npm package
- ACStack introduces structure around how your agent works
- Verification fits the change under a shared policy in
orchestrator/AGENTS.md - Every commit updates your specs from the diff
- Verification fits the change under a shared policy in
- Straightforward work can stay with one agent, including investigation, tests, implementation, and verification
flowchart TD
Q{"What kind of<br/>request is this?"} -->|"clear enough to build"| IM["Build it<br/>(/acstack:implement)"]
Q -->|"something stopped working"| QF["Find the root cause first<br/>(/acstack:quick-fix)"]
Q -->|"still has open questions"| MP["Answer them first<br/>(/acstack:map)"]
MP -->|"once the questions are answered"| IM
IM --> C["Commit, and update the docs<br/>(/acstack:commit)"]
QF --> C
Every box above is section 2. The rest of this file is reference.
| What you want | Where |
|---|---|
| Quickstart | section 1 |
| The three commands, and which one to use | section 2 |
| Configure a project and a machine | section 3 |
| The CLI | section 4 |
| Every skill | section 5 |
| Every agent | section 6 |
| Output style | section 7 |
| Terminal workspace | section 8 |
| Design principles | section 9 |
| Licence and credits | section 10 |
1. Quickstart
ACStack has first-class support for Claude Code and pi.
1.1. Install on Claude Code
You need the Claude Code CLI and Node.js 20 or later.
Install the plugin:
/plugin marketplace add ac8318740/ac-agentic-coding
/plugin install acstack@ac-agentic-coding
Then, in your project:
/acstack:setup
/acstack:setupdetects the project type, then writesacstack/project.yamlwith workflow settings- The SessionStart hook loads the orchestrator instructions whenever it detects an ACStack project
- Your CLAUDE.md stays clean for project-specific content
- Upgrading from a version before 0.8.0 means deleting one stale
@importline (see docs/migrate-0.8.md)
1.2. Install on pi
The same project installs as a pi package with @tintinweb/pi-subagents or pi-subagents for delegation.
pi install npm:@tintinweb/pi-subagents
pi install npm:acstack
Then, in your project, run /acstack:setup.
Every skill runs under the same name as on Claude Code, e.g.
/acstack:map/acstack mapdoes the same- Both always run the ACStack skill, even when another pi package has a skill called
map
ACStack's skills deliberately don't appear as
/skill:<name>commands- The package gives pi no skills, so
/skill:mapnever runs ACStack's map - The extension lists the skills in the system prompt instead, so the model still reads one when the task matches
- The package gives pi no skills, so
pi/extension.tsdoes what the Claude Code hooks do- It links the CLI at
~/.claude/acstack/bin/acstack - It adds the orchestrator instructions to the system prompt in an ACStack project
- It lists ACStack's skills in the system prompt in every session
- It re-injects a handoff after a compaction
- It nudges with a continuity-versus-freshness checkpoint as the context fills
- Continuity keeps useful working context in the same session, using billion-context or host ACP compression when available
- Freshness uses
/acstack:handoffwhen a fresh window or independent read helps more - With no thresholds set, the first nudge comes at 200k tokens or half the window, whichever is lower
- The urgent nudge comes at 500k tokens or 80% of the window, whichever is lower
- It links the CLI at
ACStack includes the question-status bridge automatically
- With
@juicesharp/rpiv-ask-user-questionand Herdr's Pi integration installed, Herdr shows blocked while Pi waits for an answer - Existing setup-installed bridges can stay installed without counting the same wait twice
- With
Both subagent packages find the four agents through the
pi.subagentsfield inpackage.json@tintinweb/pi-subagentsexposesAgent;pi-subagentsexposessubagent- The agents use your subagent package's default model
- ACStack warns at session start when pi lists neither tool
Allow delegation in
~/.pi/agent/AGENTS.md:When an ACStack skill or the ACStack orchestrator says to launch a subagent, you may delegate to it.- For
pi-subagents, set"toolActivation": "eager"in~/.pi/agent/extensions/subagent/config.jsonto offersubagentfrom the first turn (restart pi after)
- For
pi gets the ACStack writing style from the extension by default
- Run
/acstack-writing-style defaultto use the bundled style again - Run
/acstack-writing-style offto disable style injection - Run
/acstack-writing-style custom <path>to use a user-owned style file
- Run
2. The three commands, and which one to use
Pick by what is in your way: nothing, a bug, or an unanswered question.
Two words first, because the third command below uses them.
- A map is a to-do graph ACStack keeps for one piece of work
- A node is one entry on that graph: one question to answer, or one piece of work to do
The three commands:
- The request is clear enough to build – run
/acstack:implement- It runs the four agents of section 6 on your request
- A one-line change stays a one-line change
- Something already built stopped working – run
/acstack:quick-fix- It makes the agent find the root cause before it edits anything
- The request still has open questions – run
/acstack:map- The agent interviews you one round at a time
- Each round asks every question it can answer next
- Each question comes with the agent's recommended answer
- You provide feedback on the agent's recommended answer instead of prompting from scratch
- Some requests only need one question
- The agent writes that decision down as a short note under
docs/adr/ - A big feature may need dozens of questions
- The agent stores those questions as a map
- You work through the map across several sessions
2.1. What a map holds
/acstack:map builds a map only when a single conversation cannot settle every question.
Each node carries one of five statuses.
| Status | Meaning |
|---|---|
fog |
anything you cannot yet articulate clearly |
open |
ready to answer or build |
claimed |
someone is working on it now |
resolved |
done |
out-of-scope |
dropped on purpose |
Each node also records six things.
- Which earlier answer led to this question
- You can read the decisions back in the order you made them
- Which other nodes have to finish before this one starts
- ACStack uses that to tell you what is ready to start
- Who answers it: you, or the agent working alone
- What kind it is: a destination, a standing note, a decision, research, or work
- A short name, which labels the node in a diagram
- Where it lives: a GitHub issue by default, or a markdown file under
acstack/maps/with no GitHub remote
Almost every node explains itself with a diagram.
- The entry node draws the whole map, and collapses the parts you have finished
- Every other node draws its own question or its own change
- A legend sits under each diagram, showing only the symbols that diagram uses
- On GitHub you click a node in the diagram to open its issue
Two things ACStack does with a finished map.
- It works through the nodes that are ready to start, meaning the open ones with nothing unfinished blocking them
- ACStack calls that set the frontier
- It packs the whole map into a single brief
- A fresh agent session picks up where the last one stopped
Every rule in ACStack exists because something went wrong without it, over months of real product development with coding agents.
For the full picture of each step and how they connect, read docs/workflows.md.
3. Configure a project and a machine
The project states what to run. The machine states what it can do.
acstack/project.yamlholds every project-scoped setting- docs/config-reference.md gives each key, its values, its default and what changes
~/.config/acstack/config.jsonholds the ninehost.*axes/acstack:hostwrites eight of them once per machine, and/acstack:setupwrites the ninth- docs/dev-setups.md gives every axis, what reads it, and how to describe a fresh machine
/acstack:setupcopies the commands and directories from one of three language profiles- python – pytest, ruff, mypy
- node-typescript – npm test, eslint, tsc
- fullstack-python – Python backend, plus a Node or TypeScript frontend
acstack config checkaudits the project and the machine- It exits 2 when a required host axis has no value
4. The CLI
Four storage operations carry the whole map. One fixed path makes the CLI reachable from any agent session.
ACStack ships a Node.js CLI: acstack config, acstack list, acstack node ..., and acstack archive.
- The storage behind a map provides four operations and nothing more: create, read, update, list
- GitHub issues are the default
- The first line of every issue body carries all of that node's edges
- One call therefore reads the whole map
- A sub-issue and an issue dependency mirror those edges, so GitHub's own interface draws the map
- Markdown files are the fallback, one per node under
acstack/maps/<name>/
- GitHub issues are the default
- The CLI builds everything else on those four operations
acstack node frontierlists what is ready to start now, closest to the original goal firstacstack node walkpacks the whole map into one brief for a fresh session, in the order the decisions happened- The brief always includes the original goal, plus any node you marked as worth carrying along
acstack node diagramdraws a map, or any part of one, as a mermaid diagram with a legend under it- The skills claim and resolve a node with
updatecalls
Two symlinks reach the CLI. The SessionStart hook maintains both.
~/.claude/acstack/bin/acstackis the fixed path every skill and agent calls- Agents therefore do not depend on your shell
PATH - The CLI keeps working across plugin version bumps, non-interactive subshells and fresh agent contexts
- Agents therefore do not depend on your shell
~/.local/bin/acstackis for typingacstackat a terminal yourself- Add
~/.local/binto yourPATHto use it - The hook prints a one-line reminder when it is absent
- Nothing in the plugin breaks without it
- Add
If acstack does not run after a Claude Code install, read TROUBLESHOOTING.md. A Claude Code session can read it and apply the fix directly.
5. Every skill
Four groups, ordered by when you reach for them.
5.1. Implementation
| Skill | Description |
|---|---|
/acstack:implement |
Build what is ready to start, running the four agents of section 6, whether or not a map exists |
For work with open decisions, chart it with /acstack:map first.
5.2. Planning
| Skill | Description |
|---|---|
/acstack:map |
Answer the open questions first, building the to-do graph on the first run and working through it after |
grilling |
The interview itself, asking every question it can answer next per round, each with a recommended answer (the agent invokes it) |
record-context |
Writes a decision down when one lands: a short note, a glossary term, both, or neither (the agent invokes it) |
5.3. Operations
| Skill | Description |
|---|---|
/acstack:commit |
Commit, and update the specs under acstack/specs/ from the diff first |
/acstack:archive |
Close a finished map, after checking the decisions reached your specs and notes, then delete the nodes |
/acstack:sync |
Update the specs from code changes, outside a commit |
/acstack:handoff |
Hand work to a visible agent, a new one in its own pane or one already running, with acknowledgement |
/acstack:compact-and-continue |
Anchor the session's load-bearing state to survive compaction, then continue in place |
What an effort leaves behind is what matters: updated specs, decision notes, and glossary entries. ACStack throws the nodes away.
5.4. Setup and supporting
| Skill | Description |
|---|---|
/acstack:setup |
Set up ACStack in a project, and change how a project already set up is configured |
/acstack:host |
Declare this machine's dev setup once, as the host.* axes |
/acstack:bootstrap |
Write the first set of specs by reading your existing code |
/acstack:explore |
Thinking partner mode, read-only |
/acstack:quick-fix |
Structured bug fix workflow with root cause analysis |
/acstack:pre-commit-review |
Deep quality review of all changes since last commit |
/acstack:test-conventions |
Test placement rules and naming conventions |
/acstack:code-review |
Linus Torvalds code philosophy for reviews |
/acstack:browser-verify |
agent-browser command reference, CDP troubleshooting, and selector strategy |
/acstack:bridge |
Set up and operate the Playwriter cross-device browser bridge |
/acstack:visual-docs |
Write docs that lead with a diagram and derive structure from it (Minto pyramid) |
/acstack:new-worktree |
Create a git worktree off the remote base branch and continue the task inside it |
/acstack:teardown-worktree |
Retire finished worktrees and delete their merged local and remote branches |
/acstack:terminal-workspace |
Set up a keyboard-only terminal for driving agents on a dev machine |
6. Every agent
Use agents when independent interpretation, review, or parallel scopes improve confidence.
| Agent | Role |
|---|---|
test-writer |
Optional independent tests from requirements and interfaces |
task-executor |
Implements source and tests unless tests have a separate owner |
task-checker |
Independent review of behavior, coverage, regressions, and integration |
frontend-verifier |
Configured real-browser verification on final frontend code |
orchestrator/AGENTS.mdowns the shared Implementation discipline- Require independent review for security boundaries, money, irreversible data changes, or unresolved correctness or impact uncertainty
- Separate test ownership stays separate when chosen
- Configured frontend gates still apply without a delegated checker
7. Output style
The plugin ships one output style. It applies the house standard to every chat reply.
- Claude Code shows the style as
acstack:ac-writing-style - It applies the
writingskill's plain-language rules and thevisual-docsskill's Minto pyramid and bullet discipline - A reply leads with the answer and puts 90% or more of what follows in bullets
- Each bullet holds one sentence and ends without a period
- Sub-bullets nest as far as the point needs, indented four spaces per level
- Every word has to earn its place: no em dash, no emoji, no puffery, and no contrast clause that does no work
How to turn it on:
/acstack:setupoffers the style on both paths- On a new project it comes late
- It is optional there
- On a project already set up it is a health-check row
- The skill writes
outputStylefor you - It asks first
- Use
~/.claude/settings.jsonfor every project, or.claude/settings.local.jsonfor this one - A project value overrides the global one
- The style applies after
/clear, or in a new session - The plugin never forces it on
The style also ships a per-turn reminder:
hooks/ac-writing-style-reminder.shruns on every prompt and re-injects the style's own words- A built-in style carries a
turnReminderfield, and a file-based style cannot, so the hook supplies the equivalent - It emits two sections lifted straight out of
output-styles/ac-writing-style.md- "Who you are", top-level lines only, which is the persona
- "Before you send", in full, which is the nine-item checklist
- It reads those sections at run time, so the reminder can never drift from the style
- It stays silent under any other output style, and it writes nothing to the transcript
8. Terminal workspace for driving several agents
An optional keyboard-only setup for running several agents on a remote machine. ACStack works fine without it.
/acstack:terminal-workspaceinstalls every tool and writes every config- docs/terminal-workspace.md gives the exact config, every key, and the traps worth knowing
- The setup builds on herdr, a terminal multiplexer that keeps each agent's terminal running after you disconnect
- You attach from your own machine with
herdr --remote - Your own clipboard and browser then reach the session
- Each agent can get its own git worktree, meaning its own checkout on its own branch
- You attach from your own machine with
- gh-dash then triages pull requests and diffnav reads diffs, both without leaving the terminal
9. Design principles
Meaningful evidence matters more than a fixed agent sequence.
- Prefer practical tests-first work to expose mistakes before implementation
- Require tests for meaningful changed behavior when existing coverage cannot catch mistakes
- Reuse adequate coverage for refactors and skip new tests for nonbehavioral edits
- Explain impractical testing and disclose missing regression protection
- Keep docs current through commit-time spec sync
- Build no more planning structure than the unanswered questions need
- Preserve explicit requests for stronger process
- The deprecated
workflow.tdd.strictandworkflow.tdd.orchestrator_strictbooleans no longer control sequencing or delegation, including explicittrue- Neither key has an effective default
- ACStack removes the former strict guarantee
- ACStack does not automatically rewrite existing configuration
- New setup does not offer or generate these keys
10. Licence and credits
MIT. Four projects shaped the design.
- OpenSpec – ACStack forks its CLI from OpenSpec
- OpenSpec was the core spec engine under the original workflow
- The map-based concepts all originate there: proposals, designs, tasks, living specs, change management, and archiving
- Taskmaster AI – Taskmaster's task management model inspired the orchestrator pattern and the agent coordination approach
- Skills for Real Engineers by Matt Pocock – the Wayfinder map, the round-by-round interview, and the durability rule for agent briefs
- ACStack's node graph is a direct adaptation of Wayfinder
- MIT licensed, and recorded in THIRD_PARTY_NOTICES
- Additional inspiration comes from Superpowers, GSD and Spec Kit
The optional terminal workspace installs, but does not bundle, the five tools you drive and the five behind them. Each one keeps its own licence.
- herdr
- tuicr by agavra, which reviews a pull request inside the terminal
- gh-dash and diffnav by dlvhdr
- delta by dandavison
- lazygit by jesseduffield, which stages, commits and pushes on one key
- harlequin by tconbeer, the SQL editor this setup opens on one key
- yazi by sxyazi, the file manager that previews whatever the cursor sits on
- mermaid-ascii by AlexanderGrooff
- glow by charmbracelet
The optional fork build of tuicr compiles agavra/tuicr#607 by antonio2368. It also compiles agavra/tuicr#633 and one counts fix not yet submitted upstream, both written for this fork. That build is off by default and temporary.