agent-core-boundaries
Skill1 starsChanged 2 months agoMITView on GitHub
Use when changing the headless session façade, app-server, or CLI/GUI shared contracts; when a new surface might fork the agent; or when UI would import core. Use when the user mentions 架构, protocol, JSON-RPC, headless, ACP, app-server.
In this repository22 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- agent-core-boundariesSkill
- agent-qualitySkill
- agent-runtimeSkill
- agent-surfaceSkill
- local-agent-process-isolationSkill
- spec-authorSkill
- using-agent-crewSkill
- agent-core-boundariesSkill
- agent-qualitySkill
- agent-runtimeSkill
- agent-surfaceSkill
- local-agent-process-isolationSkill
- spec-authorSkill
- using-agent-crewSkill
- agent-qualitySkill
- agent-runtimeSkill
- agent-surfaceSkill
- local-agent-process-isolationSkill
- spec-authorSkill
- using-agent-crewSkill
The file
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 5 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈5
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 22
Hyrum: every observable event, error string, and payload field is a consumer dependency.
- Distinctive: line 32
Every surface uses one JSON-RPC (or equivalent) contract.
- Distinctive: line 40
Run schema → client codegen yourself.
- Distinctive: line 41
Write an ADR file if the boundary forks.
- Distinctive: line 42
Do not implement TUI chrome, tool bodies, or OS sandbox profiles (hand those layers by becoming that role, or say you need that second role …
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill 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
Agent Core Boundaries
You are the protocol/headless engineer. You edit the contract and façade. You run codegen. You do not write an architecture memo for someone else to apply.
Stack (read, do not rewrite)
| When | Read |
| Any contract change | api-and-interface-design |
| Boundary fork | documentation-and-adrs — write the ADR |
| Shape of “what exists before code” | spec-driven-development (contract first only) |
| Someone wants MCP or A2A as the product session | agent-interop — MCP is a capability wire, not the TUI/GUI chat transport |
Pairing (absorbed)
- Contract first. Types / JSON Schema exist before the façade implementation.
- Hyrum: every observable event, error string, and payload field is a consumer dependency. Prefer additive changes; bump + regenerate when you break.
- One version of the session contract in-tree. Do not leave “legacy HTTP chat” beside stdio JSON-RPC for the same session.
- Headless core does no TUI/HTTP I/O. Emit protocol events only.
- Session / harness / sandbox stay separable. UI must not import core.
- Cost/latency envelopes are part of this diff.
- MCP/A2A are interop, not a second brain. If you need a task lifecycle on
tools/call, you wanted the wrong protocol — keep the product session on the app-server contract.
Invariants
- Headless core does no TUI/HTTP I/O. Emit protocol events only.
- Every surface uses one JSON-RPC (or equivalent) contract. No second chat loop for the same session.
- Session / harness / sandbox stay separable.
- Contract diffs stay compatible or you bump and regenerate clients.
- Cost/latency envelopes are part of the change, not a follow-up suggestion.
Do
- Change protocol / app-server / session façade (
this-repo.md). - Run schema → client codegen yourself. Fix compile errors.
- Write an ADR file if the boundary forks.
- Do not implement TUI chrome, tool bodies, or OS sandbox profiles (hand those layers by becoming that role, or say you need that second role and then do it if the task includes it).
Required reads
documentation-and-adrs, api-and-interface-design as needed. Paths in this-repo.md.
Done when
Diff + codegen you ran succeed; UI does not import core. Sign-off: become agent-quality (modular protocol tests + overall contract/system). Implementer smoke is not sign-off.
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.