AGENT-BEHAVIOR-TEMPLATE.md

gistfile1.txt

# Agent Behavior Template (Verbatim from AGENTS.md)

This file keeps the same section boundaries and copies bullets word-for-word from `AGENTS.md`.

## Git Workflow

- For trivial/small low-risk changes, auto-commit is okay after checks pass
- For medium/large changes (multi-file behavior changes, refactors, architecture work, risky edits), ask before committing
- If the user explicitly asks not to commit, do not commit
- If the user asks to commit, run project checks first when available (`just check`, `just test`, etc.)
- If unsure whether a change is trivial vs medium/large, ask before committing
- "commit" alone → commit, ask before push
- "commit push" / "ship it" → do both without asking
- PR body safety (especially with GPT-* models): do not use inline `gh pr create/edit --body "..."` for markdown with backticks or shell-sensitive content; use `--body-file` (or heredoc) and verify with `gh pr view --json body`.
- For small follow-ups after recent commit → prefer `git commit --amend`

## Planning & Implementation

- **Plan first**: For complex changes, discuss the approach before implementing
- Don't start coding until user confirms ("go for it", "sounds good", etc.)
- For trivial/low-risk tasks (fork/clone/install, small edits, routine setup), proceed without asking
- Don't be a fucking coward: default to one decisive path (no fallback/legacy/dual-mode).
- **No thread necromancy**: Don’t resurrect or re-litigate earlier side-topics or previously settled points. Treat past context as closed unless the user explicitly re-opens it or it’s required to unblock the current task.
- Only add fallback/compatibility if the user explicitly asks, or explicitly marks the change production/customer-facing or migration-critical.
- **Avoid recency bias in writeups**: For documentation, comments, PR summaries, and commit messages, review the full change set and prioritize by overall impact—not just the most recently touched files or recently discussed topics.

## Documentation

After structural changes (adding skills, extensions, reorganizing):
- Update `AGENTS.md` - detailed, for AI assistants
- Update `README.md` - clean, for human users
- Every repo should have `VISION.md` and `TODO.md`; use them to understand direction and next priorities before proposing changes.
- If `VISION.md` is missing, mention it and ask whether to add one.
- If `TODO.md` is missing, mention it and ask whether to add one.
- Treat `TODO.md` as stale when it no longer matches current execution reality (for example: completed work still listed as open, current agreed work missing, or no clear next actionable items).
- If `TODO.md` is stale, summarize the mismatch and ask whether to refresh it; wait for user confirmation before editing.
- For `AGENTS.md` and `README.md`, document current behavior only; avoid changelog-style "used to / no longer" commentary unless explicitly requested
- Historical context is fine in maintainer docs (for example `ARCH.md`/ADR/decision logs) when it helps explain decisions
- Don't wait to be asked—suggest the update proactively