claude-code-hooks-daemon / CLAUDE
CLAUDE.md4 starsChanged 16 days agoMITView on GitHub
This directory is the agent tree: verbose, information-dense documentation that owns the depth for every fact. The audience split (agent tree vs human docs/ tree) is defined in DocumentationStrategy.md — the canonical documentation-SSoT ruleset.
In this repository14 other files it gives its agents.
- .claude/agents/CLAUDE.mdCLAUDE.md
- CLAUDE.mdCLAUDE.md
- .claude/skills/CLAUDE.mdCLAUDE.md
- docs/CLAUDE.mdCLAUDE.md
- src/CLAUDE.mdCLAUDE.md
- tests/CLAUDE.mdCLAUDE.md
- acceptance-testSkill
- configureSkill
- docs-optimiseSkill
- docs-qaSkill
- hooks-daemonSkill
- issue-sdlcSkill
- modeSkill
- releaseSkill
The file
Files
CLAUDE Directory - LLM-Optimized Documentation
This directory is the agent tree: verbose, information-dense documentation
that owns the depth for every fact. The audience split (agent tree vs human
docs/ tree) is defined in DocumentationStrategy.md
— the canonical documentation-SSoT ruleset.
Routing Table
| File | Route here for |
| DocumentationStrategy.md | The documentation-SSoT rules: one canonical home per fact, satellite contracts |
| ARCHITECTURE.md | System architecture and design decisions |
| AgentTeam.md | Agent team execution workflow |
| ClaudeCodePlugins.md | Claude Code plugins alongside the daemon: scope, trust, plugin hooks, naming |
| DEBUGGING_HOOKS.md | Capturing event flows (debug_hooks.sh); probing a handler (hooks-daemon probe) |
| DEBUGGING_STOP_HOOK.md | Diagnosing stop-hook failures to block |
| DEBUGGING_TRANSCRIPTS.md | Post-mortem debugging via session transcripts |
| DirectoryRoles.md | Directory roles: what markdown belongs in each directory, and what enforces it |
| HANDLER_DEVELOPMENT.md | Creating new handlers: lifecycle, API, testing patterns |
| HANDLER_GROUPING_AND_EXPANSION.md | Handler grouping and language-specific expansion design |
| LLM-INSTALL.md | Fresh installation into a project |
| LLM-UPDATE.md | Updating an existing installation |
| PROJECT_HANDLERS.md | Project-level handler developer guide |
| PlanJournalling.md | Per-plan journalling reference |
| PlanWorkflow.md | Planning workflow, templates, and standards |
| QA.md | The QA pipeline — source of truth for QA workflow |
| RemoteDocs.md | Vendoring upstream documentation: the provenance schema and the fidelity rule |
| SELF_INSTALL.md | Self-install (dogfood) mode guide |
| SessionModes.md | Session modes (focus, manual-goals, BLOCKED, usage-paused): entry, exit, display |
| Worktree.md | Git worktree workflow |
| AcceptanceTests/ | Acceptance test generation and validation |
| Architecture/ | Component deep-dives (status line, operator signals) |
| Code/ | Hooks system internals |
| Code/StrategyPattern.md | Language-aware handler Strategy Pattern archetype |
| Code/WorkspaceResolution.md | Resolving which sub-tree (and toolchain) a file belongs to in a monorepo |
| CodeLifecycle/ | Mandatory lifecycles: features, bugs, general changes |
| Performance/ | Performance baselines and measurements |
| Plan/ | Numbered development plans (see Plan/CLAUDE.md for lifecycle) |
| Routine/ | Recurring work that never completes — a Plan finishes, a Routine recurs |
| Security/ | Defect classes found in this project, each naming the Defence that keeps finding it |
| UPGRADES/ | Version upgrade guides, truth-changes and config-changes manifests |
| development/ | Daemon-repo contributor docs (QA patterns, releasing, lessons, client-mode testing) |
Reporting a daemon defect upstream lives at the repo root: ../BUG_REPORTING.md — the whole procedure, including what to establish before filing and the one rule about private material. Troubleshooting is ../docs/guides/TROUBLESHOOTING.md.
What NOT to Put Here
- ❌ Human-focused guides (use README.md or docs/)
- ❌ API documentation (use docstrings)
- ❌ Configuration examples (use examples/)
- ❌ Internal development tracking
What TO Put Here
- ✅ Architecture decisions and rationale
- ✅ Design specifications
- ✅ LLM-specific installation/development guides
- ✅ Technical deep-dives for AI context
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.