kata
AGENTS.md67 starsChanged 3 months agoMITView on GitHub
pnpm monorepo (pnpm@10.6.2) with Turborepo orchestration. Rust app (Symphony) included. This mono-repo is comprised of the following primary applications: Tasks defined in turbo.json: lint, typecheck (topological), test, build (topological), dev (no cache). Inputs include .ts, .tsx, .js, .cjs, .mjs, .rs, and Cargo.toml so both JS/TS and Rust changes invalidate the cache correctly. Turborepo orchestrates package-local test scripts via turbo run test. Pre-push hook runs pnpm exec turbo run lint typecheck test --affected, same command as CI. ci.yml on pull_request to…
- Deletes or force-pushes
- Installs packages
- Commits and pushes
1 other project uses a version of this.
Adopted by
Most recently taken up by
- gannonh/kata-symphonyword for word, first seen Aug 4, 2026
Other versions1 project uses a version of this.
Word for word · 1
- gannonh/kata-symphony★ 63100% same
Edited · 0
None found.
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
Where files are headingNew AGENTS.md files have more rules about keeping secrets out of the code, and fewer about code style.
Of the AGENTS.md files we read, the 31,439 first seen in the last six months, against the older ones: the kind of rule that gained most share, and the kind that lost most. About files like this in general, not this one, and an estimate, since a kind is a pattern in the words.
In this repository6 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- debug-symphonySkill
- mintlifySkill
- okfSkill
- plan-build-verify-githubSkill
- releasing-kataSkill
The file
We split this AGENTS.md into the rules it gives an agent
7 rules. About 0 are common, 1 is distinctive, and 6 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
6
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 85
Never use git push --no-verify or git commit --no-verify.
- Very specific: line 131
Read the roadmap with gh issue list --label kind:spec --state open.
- Very specific: line 132
Read a spec with gh issue view <N>.
- Very specific: line 133
Do not create spec files under docs/specs/.
- Very specific: line 134
Never build an issue that is not labeled status:approved without explicit maintainer approval.
- Very specific: line 150
Use cargo build (debug) for faster iteration.
- Very specific: line 151
Do NOT run the committed .symphony/WORKFLOW.md directly — it points at maintainer-local /Volumes/EVO paths and the pi agent (not installed).
≈ “Common” is an estimate: at least 1 in 5 of the 40,246 AGENTS.md files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
kata-mono
pnpm monorepo (pnpm@10.6.2) with Turborepo orchestration. Rust app (Symphony) included.
App Context
This mono-repo is comprised of the following primary applications:
- Kata Symphony:
apps/symphony- @kata/symphony - Rust binary (Cargo scripts via package.json). Project-local Symphony config lives in.symphony/. - Kata CLI:
apps/cli- @kata-sh/cli - portable Kata Skills runtime and backend contract bridge
Commands
pnpm install # Install all workspace dependencies
pnpm run validate # Lint + typecheck + test (all packages, via Turborepo)
pnpm run validate:affected # Same but only changed packages
pnpm run lint # ESLint across all packages
pnpm run typecheck # TypeScript across all packages
pnpm run test # Test runner across all packages
pnpm run test:watch # Watch mode
pnpm run test:coverage # Coverage summary
pnpm run print:system-prompt # Debug: print the agent system promptStructure
apps/
├── cli/ # @kata-sh/cli - Kata Skills runtime and backend contract bridge
├── cli/skills-src/ # Source of truth for Kata Agent Skills
└── symphony/ # @kata/symphony - Rust binary (Cargo scripts via package.json)
packages/
├── core/ # Shared TypeScript types
├── shared/ # Shared business logic (agent, auth, config, MCP, channels, daemon)
├── ui/ # Shared React components (chat, markdown)
└── mermaid/ # Mermaid diagram rendererTurborepo
Tasks defined in turbo.json: lint, typecheck (topological), test, build (topological), dev (no cache).
turbo run typecheck --affected # Only changed packages
turbo run lint typecheck test # Full validation pipelineInputs include .ts, .tsx, .js, .cjs, .mjs, .rs, and Cargo.toml so both JS/TS and Rust changes invalidate the cache correctly.
Testing
Turborepo orchestrates package-local test scripts via turbo run test.
| Package | Runner / command | Notes |
| cli | pnpm test | Vitest suite for CLI domain, backend adapters, skill bundle, and golden-path contract |
| symphony | cargo test | Rust binary |
| shared | Vitest | Package-local vitest run |
Pre-push hook runs pnpm exec turbo run lint typecheck test --affected, same command as CI.
CI
ci.yml on pull_request to main:
validate:turbo run lint typecheck test --affected(JS/TS + Rust via Turborepo)gate: aggregates results, sole required branch protection check
Release workflows are manually dispatched (Symphony also has a scheduled nightly):
symphony-release.yml (Symphony binary + Pi extension, shared version), cli-release.yml (CLI only).
Tech Stack
- Runtime: Bun (scripts, tests, subprocess execution)
- UI: React 18 + Vite + Tailwind CSS v4 + Radix UI
- State: Jotai atoms
- AI: @anthropic-ai/claude-agent-sdk + @anthropic-ai/sdk + @modelcontextprotocol/sdk
- Build: esbuild, Vite, and Turborepo
- Rust: Cargo (Symphony)
Hard Rules
- Never use
git push --no-verifyorgit commit --no-verify. If the gate fails, fix the problem. git push --forceto main/master is forbidden( unless explcitly approved by an admin).
Gotchas
.symphony/WORKFLOW.mdis the mono repo's active Symphony workflow.symphonywithout a workflow path resolves.symphony/WORKFLOW.mdfirst, thenWORKFLOW.md.- Symphony prompt and hook paths are relative to the active
WORKFLOW.mddirectory. Hooks receiveSYMPHONY_WORKSPACE_PATHfor workspace access. CLAUDE.mdfiles in this repo are symlinks toAGENTS.md. Always editAGENTS.md.- Asset paths: use
getBundledAssetsDir(subfolder)for bundled assets, neverimport.meta.dir.
Skills
Project agent skills live under .agents/skills/. Bootstrap the shared skills with:
./scripts/install-skills.shOr equivalently:
npx skills add gannonh/skills --skill plan-build-verify --skill address-pr-comments -yInstall only those skills — do not add the full gannonh/skills pack or okf. Cursor engineering execution uses the pstack plugin; do not npx-install a ps skill.
Issue tracker
Issues are tracked in GitHub Issues for gannonh/kata; external PRs are not a triage surface. See docs/agents/issue-tracker.md.
Triage labels
Triage uses the default five-label vocabulary. See docs/agents/triage-labels.md.
Domain docs
Domain docs use a single-context layout. See docs/agents/domain.md.
Documentation
Project docs live under ./docs (guides, ADRs, runbooks, historical archives). Specs are GitHub Issues — see below. Do not treat docs/specs/index.md as the live roadmap; use gh issue list --label kind:spec --state open. Historical Superpowers plans/specs remain under ./docs/superpowers/. Add or update ADRs in docs/adrs/ for durable architecture decisions.
Specs live in GitHub Issues
Specs for this repository are GitHub Issues, not files. docs/specs/ holds only an index pointer and an archive of pre-migration specs.
- Read the roadmap with
gh issue list --label kind:spec --state open. - Read a spec with
gh issue view <N>; read an epic's phases withgh sub-issue list <N>. - Do not create spec files under
docs/specs/. Use theplan-build-verifyskill, which publishes specs as issues. - Never build an issue that is not labeled
status:approvedwithout explicit maintainer approval. - Post build reports and acceptance evidence as comments on the spec issue.
- ADRs remain files under
docs/adrs/. Cross-link them with the issues they constrain.
Cursor Cloud specific instructions
Standard commands live in the ## Commands/## Testing sections above; the notes below are only non-obvious caveats for this environment. The startup update script runs pnpm install.
Toolchain
- The VM's default
nodeis/exec-daemon/node(Node 22, injected first onPATH); it satisfies the CLIengines >=20.6sopnpm/tests run fine on it. Node24.15.0(from.node-version) is installed vianvmfor CI/pre-push parity — the pre-push hook auto-selects it from~/.nvm. pnpmis provided by corepack (pnpm@10.6.2). Bun1.3.8(~/.bun/bin, added to~/.bashrc) is only needed fortest:coverage/test:watchscripts and CI; the mainturbo run testpath uses Vitest, not Bun.- Symphony needs Rust stable ≥1.85 (a transitive dep requires the
edition2024Cargo feature); the pinned image's Rust 1.83 fails to build.rustupdefault is set to current stable. Building Symphony also requires system OpenSSL headers (libssl-dev+pkg-config), already installed.
Kata Symphony (Rust)
- Use
cargo build(debug) for faster iteration; binary isapps/symphony/target/debug/symphony. First build/cargo testare slow (~30s+ each). - Do NOT run the committed
.symphony/WORKFLOW.mddirectly — it points at maintainer-local/Volumes/EVOpaths and thepiagent (not installed). Insteadsymphony inita scratch dir, pointtrackerat a real project, and runsymphony <workflow> --no-tui --port 8080. Dashboard ishttp://127.0.0.1:8080/, JSON state at/api/v1/state. - To bring up the dashboard without dispatching agents (no
pi/codexon PATH), settracker.active_statesto a placeholder that no board column matches — the orchestrator polls the real backend but dispatches nothing.
Kata CLI
- Build with
pnpm --dir apps/cli run build, then runnode apps/cli/dist/loader.js <cmd>.health.checkis offline-safe; read ops (e.g.issue.listOpen) andkata doctorhit the live backend. GH_TOKENis present in the environment (authenticates as the repo owner against the realgannonh/kataGitHub Projects v2 board). Avoid write operations (*.create,*.updateStatus,issue.updateStatus) to keep the live board clean.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

