claw-installer
CLAUDE.md0 starsChanged 6 months agoApache-2.0View on GitHub
See AGENTS.md for project facts shared across agents (stack, layout, commands, versioning, architecture, conventions, traps, glossary). This file holds only Claude Code-specific preferences and the subagent registry — it does not repeat AGENTS.md. - Op/step names are an untyped contract across Rust + Bash + PowerShell + filenames. After touching an op (e.g. pair-agentlink) or install step, verify commands.rs, shell/claw-op.sh, shell/windows/bootstrap.ps1, and the shell/agents|steps/*.sh filename all agree, then smoke-test. - Bump the app version in gui/src-tauri/Cargo.toml only (see AGENTS.md →…
In this repository12 other files it gives its agents.
- AGENTS.mdAGENTS.md
- openspec-apply-changeSkill
- openspec-archive-changeSkill
- openspec-bulk-archive-changeSkill
- openspec-continue-changeSkill
- openspec-exploreSkill
- openspec-ff-changeSkill
- openspec-new-changeSkill
- openspec-onboardSkill
- openspec-proposeSkill
- openspec-sync-specsSkill
- openspec-verify-changeSkill
The file
We split this CLAUDE.md into the rules it gives an agent
3 rules. About 0 are common, 1 is distinctive, and 2 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.
2
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 19
Prefer make targets over ad-hoc commands.
- Distinctive: line 21
Do not commit or push unless asked.
- Very specific: line 66
Before merging into dev → code-reviewer (incremental) ∥ e2e-runner (acceptance), in one message.
≈ “Common” is an estimate: at least 1 in 5 of the 26,980 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
CLAUDE.md
See AGENTS.md for project facts shared across agents (stack, layout, commands, versioning, architecture, conventions, traps, glossary). This file holds only Claude Code-specific preferences and the subagent registry — it does not repeat AGENTS.md.
Output language
- To the user (explanations, answers, summaries): Chinese, plain and low-jargon.
- Durable artifacts (code, comments, commit messages, OpenSpec specs, these docs): English.
Project-specific reminders for Claude
- Op/step names are an untyped contract across Rust + Bash + PowerShell + filenames. After
touching an op (e.g.
pair-agentlink) or install step, verifycommands.rs,shell/claw-op.sh,shell/windows/bootstrap.ps1, and theshell/agents|steps/*.shfilename all agree, then smoke-test. - Bump the app version in
gui/src-tauri/Cargo.tomlonly (see AGENTS.md → Versioning). - Bash in
shell/must stay 3.2-compatible; never break thebootstrap.ps1UTF-8 BOM. - Prefer
maketargets over ad-hoc commands. Runmake typecheck+make testbefore declaring a GUI change done;cargo check/cargo testfor Rust. - Do not commit or push unless asked; never commit directly to
main(branch first — see AGENTS.md).
Subagents
The table lists subagents available in this project. When a scenario matches, delegate via the
Agent tool instead of doing it inline. Capabilities are summarized; each agent's own definition is
authoritative. (No user-level or project-level custom agents are defined; all below are plugin/built-in.)
| Name | Source | Use when | Don't use for |
| researcher | plugin (gen-ai-development) | Execution unit dispatched by research-pipeline; a quick scoped lookup | User-facing research entry (use research-pipeline); broad web fan-out (use deep-research) |
| planner | plugin (gen-ai-development) | Propose a new feature / large refactor via OpenSpec (four-contract spec) | Single-file fixes; writing implementation code |
| arch-reviewer | plugin (gen-ai-development) | Pre-implementation design review when a spec has DDL / new interface / cross-module change | Small pure-logic specs; reviewing implemented code (that's code-reviewer) |
| developer | plugin (gen-ai-development) | TDD implementation of a ready spec (product code + unit tests) | When no spec exists; e2e test code |
| qa-author | plugin (gen-ai-development) | Author e2e test code from a spec's scenarios (parallel with developer) | Product code; agent-driven-only scenarios |
| code-reviewer | plugin (gen-ai-development) | Pre-merge incremental review (gate, two verdicts); full sweep only on request | One-off scripts; design review (that's arch-reviewer) |
| e2e-runner | plugin (gen-ai-development) | E2E acceptance after dev + QA deliver (brings the app up first) | Unit-test verification; writing/editing any code |
| debugger | plugin (gen-ai-development) | Hypothesis-driven debugging when a bug / failure / stack trace appears | Spec creation; feature work with no bug (it only diagnoses + writes a RED regression test) |
| release-coordinator | plugin (gen-ai-development) | Release prep (SemVer decision, version-sync verification, release-notes draft) | Performing merge/push/publish (the main agent does that with user consent) |
| Explore | built-in | Locating code / "where is X defined" across many files | Reading a file at a known path |
| Plan | built-in | Designing an implementation strategy | Single-line edits |
| general-purpose | built-in | Multi-step open-ended search / investigation | A single, well-specified lookup |
| code-simplifier | plugin | Simplifying/refining recently-changed code without changing behavior | Bug hunting (use code-reviewer) |
Delegation rules
- Parallelize: fire multiple
Agentcalls in one message when subtasks are independent. - Don't outsource understanding: the main agent must read the key files and synthesize — don't hand the "decide what to fix from the results" judgment entirely to a subagent.
- Development work is orchestrated by the
gen-ai-development:autonomy-controllerskill (signal classification, autonomy tier, track assembly, gates-by-tier, verify-by-strength,PIPELINE.mdstate). This file only points at it; the skill is authoritative. - Research requests are orchestrated by the
gen-ai-development:research-pipelineskill — all user interaction (clarify, confirm, follow-up) stays in the main agent;researcheris a pure executor. - Authoring skills / agents / commands / prompts / docs is not "development" and does not go through the pipeline above (skill-creator is the authoritative track for those).
Scenario matches (this project)
- Change spans ≥3 files with unclear blast radius →
Explorefirst. - Research / comparison / feasibility →
research-pipelineskill (researcher only as executor). - Propose a new module / large refactor →
plannervia OpenSpec. - Spec carries DDL / a new interface / cross-module decomposition →
arch-reviewerbefore implementing. - Implementing a confirmed spec →
developer(TDD) ∥qa-author(e2e test code). - Renaming an op/step, or any failing pairing/install run, or a stack trace →
debugger. - Before merging into
dev→code-reviewer(incremental) ∥e2e-runner(acceptance), in one message. - Preparing a release →
release-coordinator(prepares only; the main agent merges/publishes on consent).</content>
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.