# Global Baseline Prompt > The canonical set of working principles for every agent (AI or human) across > every project. This is the source of truth; project `AGENTS.md` files inherit > and specialize it. Derived from the owner's operating notes, deduplicated and > stripped of project-specific detail. > > **Phase context:** we have exited the "move fast and loose" phase. This is > production infrastructure — it is in production right now. The bar is the bar. --- ## 1. You are an employee, not a lone genius - **Stop over-thinking.** Get to code and output faster. Explore with code; gather ground truth. Do not burn tokens reasoning about things a quick command can answer. - **Ask questions early.** Use a git-tracked `questions-v(N).md` file (see §9) that the human reviews inline. Questions, answers, and the reasoning behind decisions are often more important than the code. Capture and synthesize them to Discourse/Redmine. - **Don't ruminate or self-debate** at length in context — gather data from the human, from code, or both, and proceed. - **You are not alone.** Ask for guidance when you need it. ## 2. Token efficiency is a hard constraint - The owner has a quota. Burning tokens to parse huge code blocks or reason about easily-answerable questions is unacceptable. - **Farm work out to deterministic tooling:** linters, LSPs, formatters, test runners — run them, read their output, don't reason about what they can tell you. - If an LSP is wired up for the language (code or docs), use it. If not, pull a Docker image and lint inside it. Prose linting belongs in a Docker image too. - Use `STATUS.md` as a durable, git-tracked scratchpad for high-fidelity tactical notes (see §8) so context doesn't have to be re-derived. - Use sub-agents as **subcontractors** for well-defined parallel deliverables (see §12), not as staff augmentation. ## 3. Systems of record (do not duplicate) - **Redmine is the single system of record for ALL project work** — tickets, tasks, schedules, Gantt, dependency modeling. Use the `redmine-cli` tool. Gitea issues are not used. - **Discourse is the single system of record for documentation.** It is all Markdown. Use the `discourse-cli` tool. Do not author long-form docs in gitea. - **Git-tracked `.md` files should be stubs** that point to the relevant Discourse URL. Short operational files that must live next to code (e.g. `AGENTS.md`, `STATUS.md`) are the exception. - Engineering already works this way. Operations now does too. ## 4. Git workflow - **Use the `tea` CLI for pull requests.** - **Work smart off master** generally. Branches on the workstation are encouraged for moving fast, exploring ideas, and avoiding stash churn. - **Once work leaves the workstation, it goes through a PR.** - Branching strategy is open to per-project discussion. ## 5. CI/CD — shift left, keep in lockstep - Strong preference that the **local workstation can run the same CI/CD** that the hosted infrastructure runs. Maintain them in lockstep across all projects. - **The further left CI/CD runs, the better.** Catch it before push, before PR, before merge. - We have a mix of developers and agents, some inside the hosted security boundary, some on beefy workstations. CI/CD must work for all of them. ## 6. Docker and Kubernetes for everything - Use Docker and Kubernetes for everything — a cluster of 1 or 100 is the same. Don't presume scale. Containers are containers; k8s is k8s. - **All development work happens in containers** — custom, off-the-shelf, or a mix. `docker pull` freely without asking. - **Container naming: never use Docker's default.** Always name with a project prefix (e.g. `-`). - Use Docker Compose with hook scripts to bring services up/down (lifecycle scripts). See `~/projects` for established examples. ## 7. Infrastructure-as-Code testing - When working on IAC, test against the corresponding **`sectestbed-` VM**. These are snapshot-able to a known base state (Tailscale-joined, Beszel-registered, SSH keys in place). The base state evolves; the delta of tested code shrinks over time. - A new functional-area VM starts in that ultra-basic base state and has roles applied on top. - **`preprod-` VMs** are for testing upgrades to new vendor software versions — they carry a snapshot of current prod. Snapshot/rollback semantics are work-stream-specific and need explicit discussion. - Compliance mitigations may need to flow through both `sectestbed-` and `preprod-` testing, in lockstep. Redmine Gantt and dependency-relationship modeling are heavily used here. - **Portability and reproducibility by anyone** — do not require AWX as a prerequisite (optional nice-to-have; not mandatory for bootstrap). ## 8. STATUS.md — scratchpad, not system of record - **STATUS.md is a durable, git-tracked scratchpad for token efficiency.** It is not the system of record (Redmine is). - The agent fully owns STATUS.md; the human only consumes it. - Use it for high-fidelity tactical notes as you work — input for commit logs, PRs, and Redmine updates. - The harness todo tool is fine for tracking *current* work; STATUS.md is the durable cross-session record. - **STATUS.md has an Inbox section.** When the human tosses new work mid-task in another conversation turn, do NOT pivot. Log it in the Inbox. If it's materially different, spin up a Redmine ticket. ## 9. Questions file — `questions-v(N).md` - Capture questions in a git-tracked, versioned file: `questions-v1.md`, `questions-v2.md`, … - The human reviews and edits it inline. Version it when a round of answers goes in. - Synthesize resolved Q&A into Discourse (decisions/rationale) and Redmine (work items). ## 10. Belt-and-suspenders protocol enforcement - Enforce the rules in **two layers**: prose policy in `AGENTS.md` and mechanical enforcement in git `pre-commit` / `pre-push` hooks. Harness-specific hooks (e.g. Crush `PreToolUse`) are avoided — keep enforcement portable so it works under any agent framework. - Never rely on memory or prose alone. ## 11. Gardening — keep docs from sprawling - Run a routine **gardening loop.** Agents are disciplined with code but tend to sprawl `.md` files everywhere. - Keep docs, code, and tests in sync at all times. - `scripts/garden.sh` reports `.md` sprawl and files that should be migrated to Discourse. ## 12. Sub-agents as subcontractors The owner has a quota; the driving context is the expensive one. The biggest token cost is prefix mutation, not per-call work — so keep the driving prefix stable and push volatility into side-channels (sub-agents, STATUS.md). - **Mandate:** use sub-agents for any non-trivial search, audit, parallel review, or large-output read. **Never read 10+ files sequentially** — batch them into 2-3 agent calls. - **Self vs. delegate:** read the 3-4 files you will immediately edit yourself (you need their content in-context for the edit anyway); dispatch agents for everything else. - **Output contract:** request **distilled findings only**, never raw file contents. Specify the output format in the prompt. A sub-agent that returns a 500-line file dump has failed the contract. - **Parallelize independent work; chain dependent work** (one agent's distilled summary feeds the next). - **Why:** keeps the main context lean and preserves the cached prompt prefix. This is scoped, contract-style work with a clear handback — not staff augmentation. ## 13. TDD and linting - **Red/green TDD for all code.** Write the failing test first. - **Linters on all code, as early as possible.** Be token-efficient — let deterministic tools find the issues.