loongclaw
CLAUDE.md640 starsChanged 7 months agoMITView on GitHub
This document is intentionally mirrored in CLAUDE.md and AGENTS.md. This file is the map — keep it short (~100 lines). Deeper repo-native context lives in docs/, while the public reader-facing docs surface lives in site/. The workspace currently has 13 crates across two connected families: Non-negotiable: no dependency cycles. See Core Beliefs. Current tracked deviations: none. loong-cli remains transitional; the shipped product entrypoint is still the loong binary in crates/daemon. Taskfile.yml provides optional convenience wrappers through the task CLI. If…
We split this CLAUDE.md into the rules it gives an agent
7 rules. About 0 are common, 2 are distinctive, and 5 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
5
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- could be automatic: a setting could enforce it
- Very specific: line 50
If task is unavailable, run the underlying cargo and scripts/* commands directly.
- Very specific: line 57
Test all features: ./scripts/cargo-local-toolchain.sh test --workspace --all-features
- Very specific: line 64
All execution paths route through kernel capability/policy/audit.
- Distinctive: line 66
Never commit credentials, tokens, or private endpoints.
- Distinctive: line 67
Keep CLAUDE.md and AGENTS.md mirrored in the same change.
- Very specific: line 69
Every released version must map to docs/releases/vX.Y.Z.md with process log and detail links.
- Very specific: line 88
Use task verify when the task CLI is installed.
≈ “Common” is an estimate: at least 1 in 5 of the 25,680 CLAUDE.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
Loong Agent Guide
This document is intentionally mirrored in CLAUDE.md and AGENTS.md.
This file is the map — keep it short (~100 lines). Deeper repo-native
context lives in docs/, while the public reader-facing docs surface lives in
site/.
1. Start Here
- Repository Docs Map — audience routing for
site/vsdocs/ - Core Beliefs — kernel and engineering principles
- Layered Kernel Design — layered model and boundary rules
- Roadmap — stage-based milestones and acceptance criteria
- Reliability — invariants and operating expectations
- Code Standards — maintainability, test layout, and review checks
- Product specs and implementation plans now live in
eastreams/knowledge-base(seedocs/README.mdfor routing) - Contributing Guide — contributor workflow and recipes
2. Architecture Contract
The workspace currently has 13 crates across two connected families:
additive spine
loong-core (leaf)
├── loong-plugin-sdk → loong-core
├── loong-runtime → loong-core
├── loong-app-protocol → loong-runtime
└── loong-cli → loong-app-protocol
governed runtime
contracts (leaf)
├── kernel → contracts, loong-plugin-sdk
├── protocol (independent leaf)
├── bridge-runtime → contracts, kernel, protocol
├── app → contracts, kernel
├── spec → contracts, kernel, protocol, bridge-runtime
├── bench → kernel, spec
└── daemon (`loong`) → app, loong-app-protocol, bench, bridge-runtime, contracts, kernel, protocol, specNon-negotiable: no dependency cycles. See Core Beliefs.
Current tracked deviations: none. loong-cli remains transitional; the shipped
product entrypoint is still the loong binary in crates/daemon.
3. Commands
Taskfile.yml provides optional convenience wrappers through the task CLI.
If task is unavailable, run the underlying cargo and scripts/* commands
directly.
- Format check:
./scripts/cargo-local-toolchain.sh fmt --all -- --check - Strict lint:
./scripts/cargo-local-toolchain.sh clippy --workspace --all-targets --all-features -- -D warnings - Architecture check:
./scripts/check_architecture_boundaries.shortask check:architecture - Convention check:
task check:conventions(optional wrapper; requires Go + convention-engineering skill) - Test all features:
./scripts/cargo-local-toolchain.sh test --workspace --all-features - Canonical verify:
task verify(optional wrapper around repo verification steps) - Extended verify:
task verify:full(optional wrapper around the extended local gate)
4. Non-Negotiable Rules
- Kernel contracts are backward-compatible. No breaking changes without documented decision.
- All execution paths route through kernel capability/policy/audit. No shadow paths.
- Strict lint and all-feature tests pass at every commit.
- Never commit credentials, tokens, or private endpoints.
- Keep
CLAUDE.mdandAGENTS.mdmirrored in the same change. - Before every commit, run CI-parity checks. Any manual edit after fmt must be re-checked.
- Every released version must map to
docs/releases/vX.Y.Z.mdwith process log and detail links. - Local agent debug context for a release should be recorded in
.docs/releases/vX.Y.Z-debug.md. - Public-repo issues, PRs, and public-doc wording should stay Loong-centric; keep detailed external project comparisons in
eastreams/knowledge-baseunless naming an external project is strictly necessary.
5. Verification Gates
CI enforces:
./scripts/cargo-local-toolchain.sh fmt --all -- --check./scripts/cargo-local-toolchain.sh clippy --workspace --all-targets --all-features -- -D warnings./scripts/cargo-local-toolchain.sh test --workspace./scripts/cargo-local-toolchain.sh test --workspace --all-features
6. Pre-Commit Hook
cp scripts/pre-commit .git/hooks/pre-commit && chmod +x .git/hooks/pre-commitRuns CI-parity cargo checks before each commit.
Use task verify when the task CLI is installed. Otherwise run the
underlying scripts/cargo-local-toolchain.sh and scripts/* verification
commands directly.
7. Where to Look Next
| Need | Go to |
| Architecture overview & crate DAG | ARCHITECTURE.md |
| Repository docs layering | docs/README.md |
| Core principles | docs/design-docs/core-beliefs.md |
| Layered architecture | docs/design-docs/layered-kernel-design.md |
| Design decisions, patterns & catalog | docs/design-docs/index.md |
| Harness engineering | docs/design-docs/harness-engineering.md |
| Code standards, test layout & review checks | docs/design-docs/code-standards.md |
| Roadmap | docs/ROADMAP.md |
| Reliability invariants | docs/RELIABILITY.md |
| Security model & gaps | docs/SECURITY.md |
| Product sense & principles | docs/PRODUCT_SENSE.md |
| Release process conventions | docs/releases/README.md |
| Product requirements / implementation plans | eastreams/knowledge-base |
| Repository support references | docs/references/README.md |
| Contributing recipes | CONTRIBUTING.md |
In this repository38 other files it gives its agents.
- AGENTS.mdAGENTS.md
- agent-browserSkill
- docxSkill
- pdfSkill
- pptxSkill
- xlsxSkill
- byted-web-searchSkill
- design-mdSkill
- find-skillsSkill
- github-issuesSkill
- lark-approvalSkill
- lark-baseSkill
- lark-calendarSkill
- lark-contactSkill
- lark-docSkill
- lark-driveSkill
- lark-eventSkill
- lark-imSkill
- lark-mailSkill
- lark-minutesSkill
- lark-openapi-explorerSkill
- lark-sharedSkill
- lark-sheetsSkill
- lark-skill-makerSkill
- lark-taskSkill
- lark-vcSkill
- lark-whiteboardSkill
- lark-wikiSkill
- lark-workflow-meeting-summarySkill
- lark-workflow-standup-reportSkill
- mcporterSkill
- minimax-docxSkill
- minimax-pdfSkill
- minimax-xlsxSkill
- native-mcpSkill
- planSkill
- skill-creatorSkill
- systematic-debuggingSkill
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.

