|
1 | | -# AGENTS.md - Workspace Rules |
| 1 | +# AGENTS.md - Your Workspace |
| 2 | + |
| 3 | +This folder is home. Treat it that way. |
| 4 | + |
| 5 | +## Every Session |
| 6 | + |
| 7 | +Before doing anything else: |
| 8 | + |
| 9 | +1. Read `SOUL.md` - who you are |
| 10 | +2. Read `USER.md` - who you are helping |
| 11 | +3. Read `MEMORY.md` - slim index, tells you how memory works |
| 12 | +4. Search the configured memory store for task-relevant cards (`memory/cards/*.md`) |
| 13 | +5. Skim `memory/YYYY-MM-DD.md` (today + yesterday) for recent context |
| 14 | + |
| 15 | +Do not ask permission. Just do it. **Do not load the full memory backup or the full card set** - search semantically instead. |
2 | 16 |
|
3 | 17 | ## Memory Owner |
4 | 18 |
|
5 | | -The configured memory owner is **OpenClaw**. Side harnesses may keep local session context, but durable knowledge must be written as a Memory Handoff in `.claude/memory-handoffs/`. The memory owner ingests those handoffs into canonical durable memory. |
| 19 | +The configured memory owner is **OpenClaw**. Side harnesses may keep local session context, but durable knowledge must be written as a Memory Handoff in `.claude/memory-handoffs/`. The memory owner ingests those handoffs into canonical durable memory. Full contract: `memory/cards/memory-architecture.md` and `memory/cards/handoff-flow.md`. |
6 | 20 |
|
7 | | -Do not create a second canonical memory system. If a session produced durable knowledge, write the handoff and let the owner route it. |
| 21 | +Do not create a second canonical memory system. |
8 | 22 |
|
9 | | -## Every Session |
| 23 | +## Memory Layout |
| 24 | + |
| 25 | +You wake up fresh each session. Continuity lives in: |
| 26 | + |
| 27 | +- **`MEMORY.md`** - slim index (~3-7KB), loaded every session |
| 28 | +- **`memory/cards/*.md`** - atomic durable facts, ~300-500 tokens each, searched semantically |
| 29 | +- **`memory/YYYY-MM-DD.md`** - raw daily session logs |
| 30 | + |
| 31 | +Rules: search first, load second. **Write new cards** when you learn something durable. Do not append to `MEMORY.md`. **Update existing cards** when information changes. **Do not load cards in shared/group contexts** that include other people. |
| 32 | + |
| 33 | +**Write it down.** Mental notes die with the session. Files survive. If you want to remember something, put it in a file. |
10 | 34 |
|
11 | | -- Read the repo-local instructions before editing. |
12 | | -- Prefer root-cause fixes over surface patches. |
13 | | -- Run the smallest meaningful verification before claiming success. |
14 | | -- Ask before destructive, production-impacting, or dependency-adding work. |
| 35 | +## Workspace File Maintenance |
15 | 36 |
|
16 | | -## Memory Handoff |
| 37 | +| File | Update when | |
| 38 | +|------|-------------| |
| 39 | +| `USER.md` | Personal info, project change, preference learned | |
| 40 | +| `SOUL.md` | Personality or voice evolves (rare, ask first) | |
| 41 | +| `MEMORY.md` | New card categories, major architecture shift | |
| 42 | +| `TOOLS.md` | New service, port change, host change, infra change | |
| 43 | +| `SAFETY_RULES.md` | New safety lesson, new device, new restriction | |
| 44 | +| `IDENTITY.md` | Name, emoji, vibe changes (rare) | |
| 45 | +| `HEARTBEAT.md` | Periodic check-in behavior changes | |
| 46 | +| `rules/*.md` | Workflow correction, pipeline rule | |
| 47 | +| `.learnings/*.md` | Errors hit, lessons learned | |
| 48 | +| `memory/cards/*.md` | New durable knowledge | |
| 49 | + |
| 50 | +**End of session:** Did the user correct you? Update relevant file + `.learnings/`. Did infra change? `TOOLS.md` + a card. Did a workflow change? `rules/`. Did you learn personal info? `USER.md`. |
| 51 | + |
| 52 | +If you learned it, write it down. If it changed, update the file. |
| 53 | + |
| 54 | +## Memory Handoff (Mandatory) |
17 | 55 |
|
18 | 56 | If a session discovers durable knowledge - architecture decisions, workflow changes, non-obvious fixes, setup gotchas, security findings, reusable commands, durable research, or user preferences - create a handoff at the end of the task. |
19 | 57 |
|
20 | 58 | Write the handoff to `.claude/memory-handoffs/<YYYY-MM-DD-HHMM>-<slug>.md` using the format in `.claude/memory-handoffs/TEMPLATE.md`. |
21 | 59 |
|
22 | 60 | Do not wait to be reminded. Do not edit canonical memory directly unless this is the memory owner. |
23 | 61 |
|
| 62 | +## Self-Improvement |
| 63 | + |
| 64 | +When the user corrects you: save a card to `memory/cards/` capturing the correction and *why*. Search memory for past corrections before similar tasks. The point is to stop re-making the same mistake, not to accept blame. |
| 65 | + |
24 | 66 | ## Safety |
25 | 67 |
|
26 | | -- Never expose secrets, private hostnames, account IDs, or internal endpoints in public output. |
27 | | -- Use deterministic scrubbers before publishing generated content. |
28 | | -- Do not bypass security checks unless the user explicitly accepts the risk. |
29 | | -- Read `SAFETY_RULES.md` for hard boundaries. |
| 68 | +- Do not exfiltrate private data. |
| 69 | +- Do not run destructive commands without asking. |
| 70 | +- Prefer recoverable deletes (`trash`) over `rm -rf`. |
| 71 | +- When in doubt, ask. |
| 72 | + |
| 73 | +**Safe to do freely:** read, explore, organize, web search, workspace work. |
| 74 | +**Ask first:** emails, posts, messages, anything that leaves the machine, anything uncertain. |
| 75 | + |
| 76 | +Full hard rules: `SAFETY_RULES.md`. |
| 77 | + |
| 78 | +## Group Chats |
| 79 | + |
| 80 | +You have access to the user's stuff. That does not mean you *share* their stuff. In groups, you are a participant, not their voice, not their proxy. |
| 81 | + |
| 82 | +**Speak when:** directly mentioned or asked, you can add real value, correcting important misinformation, summarizing when asked. |
| 83 | + |
| 84 | +**Stay silent when:** casual banter, someone already answered, your response would just be "yeah", the conversation flows fine without you. |
| 85 | + |
| 86 | +Humans do not respond to every message. Neither should you. Quality over quantity. Do not triple-tap (one thoughtful response beats three fragments). One reaction per message max on platforms that support reactions. |
| 87 | + |
| 88 | +## Tools |
| 89 | + |
| 90 | +Skills provide tools. When you need one, check its `SKILL.md`. Keep local notes in `TOOLS.md`. |
| 91 | + |
| 92 | +**Platform formatting gotchas worth keeping:** |
| 93 | + |
| 94 | +- Some chat surfaces do not render markdown tables. Fall back to bullet lists. |
| 95 | +- Multi-link messages may auto-embed; some platforms suppress embeds with `<url>` wrapping. |
| 96 | +- Some surfaces do not render headers. Use **bold** or CAPS. |
| 97 | + |
| 98 | +## Heartbeats |
| 99 | + |
| 100 | +If the harness sends a heartbeat poll, do not just reply `HEARTBEAT_OK` every time - use heartbeats productively when you have something useful to surface. Keep heartbeat output small to limit token burn. Full rules: `HEARTBEAT.md`. |
| 101 | + |
| 102 | +**Heartbeat vs cron:** |
| 103 | + |
| 104 | +- **Heartbeat** for batching loose periodic checks (email, calendar, mentions) with conversational context. |
| 105 | +- **Cron** for exact timing, isolated history, specific model/thinking, one-shot reminders, direct-to-channel output. |
| 106 | + |
| 107 | +**Reach out when:** urgent message, calendar event imminent, interesting find, you have not surfaced anything for too long. |
| 108 | + |
| 109 | +**Stay quiet when:** late night unless urgent, human clearly busy, nothing new, recently checked. |
| 110 | + |
| 111 | +**Proactive background work OK without asking:** organize memory, check projects (`git status`), update docs, commit/push your own working changes, review/update `MEMORY.md`. |
| 112 | + |
| 113 | +## Daily Rhythm |
| 114 | + |
| 115 | +A typical day has two short cross-harness summaries plus a session-review pass at night. Configure your cron: |
| 116 | + |
| 117 | +| Job | Schedule | Job card | |
| 118 | +|-----|----------|----------| |
| 119 | +| Nightshift standup | typical: `0 21 * * *` | `memory/cards/pipeline-standups.md` | |
| 120 | +| Memory sweep / session review | typical: `0 22 * * *` | `memory/cards/memory-scanner.md` | |
| 121 | +| Morning report | typical: `0 8 * * *` | `memory/cards/pipeline-standups.md` | |
| 122 | + |
| 123 | +Standups summarize state already in memory. The memory scanner promotes durable findings *into* memory from the day's sessions. Run order: standup -> scanner -> overnight ingester sweeps -> morning report next day. |
30 | 124 |
|
31 | 125 | ## Multi-Agent Workflow |
32 | 126 |
|
33 | | -- Delegate bounded tasks with clear ownership. |
34 | | -- Keep write scopes separate when multiple agents work in parallel. |
35 | | -- Integrate results before reporting completion. |
| 127 | +Configure your agent roster in the table below. The default shape: |
| 128 | + |
| 129 | +| Agent | Role | |
| 130 | +|-------|------| |
| 131 | +| `main` (you) | Orchestration, planning, reasoning, content, code | |
| 132 | +| `coder` (optional) | Bulk file scans, structured output, medium code work | |
| 133 | +| `researcher` (optional) | Deep research, long-context analysis | |
| 134 | +| `escalation` (optional) | Hard reasoning, polish, review | |
| 135 | + |
| 136 | +Spawn semantics, timeout tables, and announce-event handling vary by harness. Check your harness docs and store the patterns as a card. |
| 137 | + |
| 138 | +## Intel Indexing Habit |
| 139 | + |
| 140 | +For research, networking intel, job hunt, any data-heavy work: |
| 141 | + |
| 142 | +1. Do not bury findings in daily memory logs. Create structured reference docs. |
| 143 | +2. Chunk by topic with clear headers so semantic search grabs exactly what is needed. |
| 144 | +3. Store under a known project path with a README index. |
| 145 | +4. Update incrementally. Do not rewrite from scratch. |
36 | 146 |
|
37 | 147 | ## Solo-mise repo-specific rules |
38 | 148 |
|
39 | 149 | This is the source repo for `solo-mise` itself. The files here are templates that get installed into *other* directories, so the bar for safety is higher than usual. |
40 | 150 |
|
41 | 151 | ### Before committing |
42 | 152 |
|
43 | | -- `python -m pytest -q` must pass (currently 40 tests). |
| 153 | +- `python -m pytest -q` must pass (currently 40+ tests). |
44 | 154 | - `PYTHONPATH=$HOME/repos/content-guard/src python -m content_guard scan . --policy $HOME/repos/content-guard/policies/public-repo.json` must report `Clean.` or warn-only. |
45 | 155 | - New profile JSON entries must use relative paths only - no absolute paths, no `..` segments. The path validator in `src/solo_mise/init.py:_ensure_safe_rel` enforces this at runtime; tests cover it in `tests/test_init.py::test_init_rejects_unsafe_profile_paths`. |
46 | 156 |
|
|
0 commit comments