jb/harness-tools
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

chore(agent): refine global behavior guidance

Browse Source
This commit is contained in:
jb
2026-08-26 19:14:06 -04:00
parent 419414c4c3
commit 645c38d43c
1 changed files with 2 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/global.AGENTS.md
+2 -2
View File
@@ -78,7 +78,7 @@ Below you will find my preferences so that we can be more aligned as we work tog
- ADRs should be functionally immutable, but not read-only. If a new decision invalidates a previous decisions, update that ADR with a link to the new ADR. - ADRs should be functionally immutable, but not read-only. If a new decision invalidates a previous decisions, update that ADR with a link to the new ADR.
- Follow the guidelines in the [`writing-for-agents`](../skills/document/writing-for-agents/SKILL.md) skill when creating documentation. - Follow the guidelines in the [`writing-for-agents`](../skills/document/writing-for-agents/SKILL.md) skill when creating documentation.
## Visual & Design Work ## Visual & Design Work
- Do not edit real components first. If the work is non-trivial UI changes, layout, or copy, build a few distinct static mocks, and ready them for manual review and wait for my feedback before implementing. - Do not edit real components first. If the work is non-trivial UI changes, layout, or copy, build a few distinct static mocks, and ready them for manual review and wait for my feedback before implementing.
- I prefer dark mode first. Minimal copy. Minimal chrome. No em dashes. Don't add meaningless text and measurements, everything should have a purpose. - I prefer dark mode first. Minimal copy. Minimal chrome. No em dashes. Don't add meaningless text and measurements, everything should have a purpose.
@@ -94,9 +94,9 @@ Below you will find my preferences so that we can be more aligned as we work tog
- Prototype or create PoCs for large features first. If we can identify if something will or will not work early, that will save time in the long run. - Prototype or create PoCs for large features first. If we can identify if something will or will not work early, that will save time in the long run.
- Do not touch production or live databases unless explicitly instructed to do so. - Do not touch production or live databases unless explicitly instructed to do so.
- When presenting any single local file for my review, or a structured long-form report, plan, ADR, review, or summary, load the [`artifact-presenter`](../skills/document/artifact-presenter/SKILL.md) skill and open the complete file with mcat in its reusable Herdr pane instead of returning the full artifact inline. - When presenting any single local file for my review, or a structured long-form report, plan, ADR, review, or summary, load the [`artifact-presenter`](../skills/document/artifact-presenter/SKILL.md) skill and open the complete file with mcat in its reusable Herdr pane instead of returning the full artifact inline.
- After reporting status, if there is no input required from me, continue work on the task.
## Subagents and Parallel work ## Subagents and Parallel work
- Not every ask needs a subagent. Do not spawn up subagents or multi-agent workflows for something a single agent can finish in a single pass. Delegate appropriately for adversarial review, or specialized parallel work.
- When we have several agents working together on a feature, state file ownership up front so they do not collide. - When we have several agents working together on a feature, state file ownership up front so they do not collide.