AGENTS.md@examples/sample-project · git:20260402.53994ff · 2026-04-02 · sha256 0f5e68be8232c426
AGENTS.md@examples/sample-project git:20260402.53994ffA
Immutable. This exact content never changes and is served at /api/v1/blob/0f5e68be8232c426.
# Existing Repo Guidance This file is intentionally unmanaged. Human-authored guidance should be preserved. <!-- SHREY-JUNIOR:START codex --> # Project Agent Routing This repository uses Shrey Junior as the repo-local control plane. Profile: `product-build` Execution mode: `assisted` Read in this order before non-trivial work: 1. existing trusted repo authority files already present in the repo 2. promoted canonical docs explicitly referenced by those authority files 3. `.agent/project.yaml` 4. `.agent/checks.yaml` 5. `.agent/state/current-phase.json` when present 6. latest handoff and latest reconcile artifacts when present 7. `.agent/context/architecture.md` 8. `.agent/context/conventions.md` 9. `.agent/context/runbooks.md` 10. `.agent/tasks/` packets when present Authority rules: - existing repo authority wins over generated overlays unless the repo explicitly delegates control - promoted canonical docs explicitly referenced by repo authority must be read early - generated repo artifacts are supporting control-plane outputs and may be regenerated - machine-local files and editor state are reference-only Safety rules: - never store raw secrets in repo files - do not treat `~/.codex`, `~/.claude`, `.claude/settings.local.json`, `.vscode/*`, or workspace storage as portable repo memory - prefer additive changes and managed markers - escalate when authority files disagree Workflow thresholds: - trivial work may stay direct when it is a typo, wording fix, one-line local change, or low-risk formatting with no contract, auth, data, security, release, or multi-file impact - non-trivial work should use Shrey Junior framing when it touches multiple files, changes interfaces or stable contracts, is guarded or cross-cutting, affects auth/data/security/release behavior, or benefits from reviewer/tester separation Use the control plane like this: - use `run` for a single-owner non-trivial task that still needs repo-aware framing - use `fanout` when planner / implementer / reviewer / tester separation is useful - use `dispatch` when multiple small roles may work in parallel and outputs need later collection and reconciliation - use `collect` and `reconcile` before trusting multi-role work - use `checkpoint` at meaningful phase boundaries and before cross-tool handoff - use `handoff` when Codex, Claude, Copilot, or another tool is continuing the next phase - use `push-check` before recommending push for non-trivial, guarded, contract-sensitive, or release-sensitive work - use `release-check` and `phase-close` when the phase is nearing review, release, or a clean handoff boundary Escalate instead of proceeding directly when: - the task stops being trivial - the change becomes multi-file or cross-cutting - stable contracts or boundary files may change - reviewer or tester separation becomes necessary - current phase, handoff, or reconcile state shows unresolved blockers Specialist guidance: - prefer specialist-aware routing over generic freeform work when the task clearly maps to `python-specialist`, `qa-specialist`, `push-specialist`, `security-specialist`, `refactor-specialist`, or `docs-specialist` - specialists refine validation expectations, handoff guidance, risk posture, and MCP eligibility; they do not replace repo authority MCP guidance: - MCP usage is policy-driven, not improvisational - only use MCP capabilities that match the active profile, selected specialist, trust level, and approval expectations - never call an MCP just because it exists <!-- SHREY-JUNIOR:END codex -->