Agent Conduct

These rules apply to ALL agents regardless of skill.

Workspace Boundary

• Write only inside the repository, a designated Git worktree of the same repository, or a harness-provided scratchpad/temp directory. Actual harness restrictions still apply; this rule grants no extra filesystem access. Redirecting command output to /dev/null is fine.
• Before any file-writing command, confirm the target is within one of those locations. Create worktrees with normal Git commands, not clones or edits to .git/ internals.
• For PR branch work, the workflow owner creates one shared worktree before the first worker starts. Reuse it for implementor commits, reviewer reads, local gates, pushes, pr-resolver fixes, and rebases. Workers never create their own worktree for that branch; resume in the recorded worktree.

• Create new PR branches from the freshly fetched base, from the main clone:

  git fetch origin && git worktree add --no-track -b <topic>-<8 hex> ../<repo>-<topic> origin/<base>

  Use a short topic and eight random hex digits. Keep the worktree beside the main clone, never inside a clone. For an existing branch, reuse its worktree or attach that branch without -b. Dependent branches use the recorded SHA under routing.

• Reserve harness per-agent worktrees for throwaway experiments whose results are reported back, not retained as PR branches.
• Give every worker the worktree's absolute path and require branch work only there. Reviewers leave it unchanged; mutants and experiments belong in a scratch copy or scratchpad.
• Record the branch and worktree path in its branch-owned checklist's queue entry. In committed records, make the path relative to the main clone.
• Remove a merged PR worktree through post-merge cleanup, never when a worker finishes. Keep unmerged worktrees and branches until the user or caller authorizes deletion, then apply the Git Safety deletion checks.

Scratch Copies

A scratch copy is a temporary detached worktree in a scratchpad/temp directory:

git worktree add --detach <scratchpad-or-tmp path> <sha>

Include the branch's topic or checklist ID in the scratch copy's path. Workers may create these for read-only checks or throwaway edits (mutants, bisects, base comparisons). Never commit in them. Before reporting back, apply the Git Safety deletion checks, then git worktree remove --force <path>. Only their throwaway files and edits are authorized for discard.

Scratch Work

• Use language-appropriate test temp dirs (t.TempDir(), tmp_path, etc.).
• If a temp file is truly needed, prefer the harness-provided scratchpad directory; otherwise use .tmp/agent/ in the repo and clean up.
• Put every new source file in an existing package. A stray .go or .py outside one confuses tooling.

Terminal Safety

Avoid triggering VS Code modal confirmation prompts:

• No interactive commands (ssh, less, vi). Use git --no-pager, etc.
• No sudo. No broad rm -rf.
• No port-listening processes without background mode.

Git Safety

• NEVER push to master, main, or develop branches, including normal and force pushes. Check the destination ref, not just the checked-out branch.
• On the first authorized push, set the feature branch's own upstream with git push -u <remote> <branch>.
• Keep the task's feature branch rebased on the latest remote develop, unless the caller or PR specifies another base. If remote develop is confirmed absent, resolve the configured remote's default branch instead. A failed fetch is a blocker, not evidence that a branch is absent. Retain the resolved base throughout the task. Deferred branches with an unmerged dependency follow the base transition and publication hold in routing. Fetch before checking whether it is current. When that base has advanced, rebase onto it instead of merging it into the feature branch. Resolve conflicts and rerun the applicable quality gates on the rebased result.
• After those gates pass, push the rebased feature branch with --force-with-lease. The user gives standing authorization for this; no separate request or confirmation is needed. Deferred branches held for recording or dependency merge remain local under bugfix routing. Verify the remote feature-branch tip before rebasing and use it as the explicit expected SHA in the lease. If the lease fails, inspect and reconcile the intervening work before retrying; never use plain --force.
• Do not push other branches unless the user asks or the task is working on a PR and a push is needed to update the PR, rerun checks, or request review, or the push applies the standing rebase authorization above.
• Do NOT modify .git/ internals.
• Use targeted git add <file> over git add ..
• Before deleting a clone, worktree, or local branch, inspect the work that deletion puts at risk. For a clone, check all local branches with git log --branches --not --remotes and inspect detached HEADs too. Check at-risk uncommitted changes, untracked/ignored files, and stashes. Every at-risk commit or file must be verified preserved outside the deletion scope, verified integrated, or explicitly authorized for discard. For squash merges, verify the merged PR head and resulting integration diff; account for commits beyond that head too. Linked worktrees share branches and stashes; unrelated surviving work need not be cleaned. Report what was checked and how at-risk work was accounted for. Retain unaccounted-for work. These checks do not authorize deletion.
• After the hosting service confirms a task PR merged, apply post-merge cleanup. The user gives standing authorization to delete its verified local task branch, remove its clean disposable worktree, and prune stale remote-tracking refs without asking again. This does not authorize remote branch or clone deletion.

General

• Do NOT install system packages.
• Do NOT modify files outside the current task's scope.
• For heavy work on shared or quota-constrained machines, read shared resources.

Discovered Issues

When a distinct issue appears during implementation, review, or verification, read bugfix routing. Workers report the evidence to their caller before changing incidental code; the caller applies the routing rules. A directly invoked agent is its own caller.

Completion And Live Work

For delegated or background work, read completion and liveness.

Honesty About Blockers

Never paper over, work around, or hallucinate results to satisfy a request that is blocked by an outside constraint (e.g. a third-party API does not support the operation, required data is unavailable, the environment lacks needed capability, requirements contradict each other).

If you hit such a blocker:

• Stop work on the affected task immediately.
• Do NOT write code that fakes the capability, returns mock values to make tests pass, silently narrows scope, or pretends success.
• Revert partial changes that only exist to mask the blocker.
• Report to your caller: what was requested, what specifically makes it impossible, and 1-3 plausible alternatives or clarifications.

The orchestrating skill (bugfix, orchestrator, spec-writer) decides how to record and route the blocker - your job is to surface it cleanly, not to push past it.