bcherb2
e1332c67d8
Phase 3 excluded all of dot_claude/, but the plan always intended CLAUDE.md to be the one agent file that ships publicly. Adds it plus the codex and pi AGENTS.md, so a throwaway VM gets sane agent behaviour with no credential. Specialized agents, skills, hooks and the language rule sets are deliberately absent -- they live in a separate repository now. The Active Rule Sets section is rewritten to say so rather than dangle a reference to a rules/ tree this repo does not carry. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
26 lines
2.0 KiB
Markdown
26 lines
2.0 KiB
Markdown
# Global Pi Configuration
|
|
|
|
Global instructions for the Pi coding agent, shared with the Claude Code and
|
|
Codex setups on this machine. Project-level `AGENTS.md` / `CLAUDE.md` files take
|
|
precedence for project-specific work.
|
|
|
|
## Shell
|
|
- Use zsh-compatible syntax when writing shell commands or scripts.
|
|
- Assume `~/.zshrc` can affect shell behavior.
|
|
|
|
## System Knowledge Journal (Obsidian)
|
|
|
|
Maintain a running journal of **host/environment** changes in the Obsidian vault at `Tech/Infrastructure/`, using the shared `sysjournal` helper (on PATH). This is for *system administration*, NOT ordinary work inside a code repo.
|
|
|
|
**Trigger — the task changes the machine/environment, not just repo code:** system config; services/daemons (systemd/launchd/cron); networking/DNS/VPN/firewall; VMs & host-level containers; drivers/kernel/boot; disks/mounts; build toolchains & global/system package installs; or **wiring an app into the host** (a systemd unit, cron job, opened port, service account).
|
|
|
|
**Do NOT journal** feature work, bug fixes, refactors, or tests *inside* a project repo. Discriminator: *does it change state outside the repo, on the host?* If no → skip. **Straddle case** (you build an app **and** install it as a service): journal only the **host-wiring** part (the unit/cron/port), not the app code.
|
|
|
|
1. **Recall first.** Before diagnosing or acting on such a task, search the journal and read relevant hits:
|
|
`sysjournal search <keywords>` (e.g. `sysjournal search systemd relay port`)
|
|
2. **Journal after.** Once the change is made or the problem resolved:
|
|
`sysjournal new "Short Descriptive Title" --type change --status deployed --tags systemd,relay`
|
|
Then fill in the created note (its path is printed): **Why**, **What changed**, **Design decisions / gotchas**, **Verify** (command + observed result), **Status / follow-ups**. Link related notes with `[[wikilinks]]`.
|
|
|
|
Keep it a real record — what changed, why, the gotcha you hit, how you verified. `sysjournal help` for the frontmatter schema (the `System Log MOC.md` Dataview index depends on it).
|