Gabriel Brown
89761a7da3
Agent instructions, skills, SSH host aliases and expansion triggers are worth having identical on every machine one person owns, and belong in none of the shared configuration. They live in user/ now, with a manifest saying where each piece goes and a link-user stage that puts it there. That stage does nothing unless the machine said yes. Somebody who clones Panama to try the desktop keeps their own ~/.claude/CLAUDE.md exactly where it was; the question names the destinations and defaults to no. Anything displaced goes to config/old rather than being deleted. ~/.claude/CLAUDE.md and ~/.codex/AGENTS.md were byte-identical copies of one file, which is the drift this exists to prevent. Also adds the vitals toggles for the battery and Claude usage readouts, which had preferences and no way to reach them.
100 lines
1.7 KiB
Markdown
100 lines
1.7 KiB
Markdown
# Developer Instructions Template
|
||
|
||
## 1. Objective
|
||
|
||
<!--
|
||
What does success look like?
|
||
1–2 sentences. No technical detail.
|
||
-->
|
||
|
||
---
|
||
|
||
## 2. Current State
|
||
|
||
<!--
|
||
Describe existing behavior ONLY if this task changes something that already exists.
|
||
Bullet points only. Keep it factual and brief.
|
||
If this is net-new work, write "N/A".
|
||
-->
|
||
|
||
---
|
||
|
||
## 3. Desired State
|
||
|
||
<!--
|
||
What behavior should exist after this task is complete?
|
||
Focus on observable behavior, not implementation.
|
||
-->
|
||
|
||
---
|
||
|
||
## 4. Scope
|
||
|
||
<!--
|
||
Explicitly list what IS included in this task.
|
||
Use bullet points. Be concrete.
|
||
-->
|
||
|
||
---
|
||
|
||
## 5. Suggested Implementation
|
||
|
||
<!--
|
||
Guidance for how to approach this task.
|
||
May include:
|
||
- Architectural direction
|
||
- Known patterns to reuse
|
||
- Constraints or preferences
|
||
- Optional example code or pseudo-code
|
||
This is guidance, not strict requirements unless explicitly stated.
|
||
-->
|
||
|
||
---
|
||
|
||
## 6. Happy Path
|
||
|
||
<!--
|
||
Describe the normal, straight-through flow.
|
||
Think: "What is the expected sequence of actions when everything works?"
|
||
-->
|
||
|
||
---
|
||
|
||
## 7. Edge Cases to Consider (Provided)
|
||
|
||
<!--
|
||
Known edge cases identified by PM/Lead Dev.
|
||
These help define expectations but are not necessarily exhaustive.
|
||
-->
|
||
|
||
---
|
||
|
||
## 8. Acceptance Checklist
|
||
|
||
<!--
|
||
Clear, testable conditions that define "done".
|
||
Each item should be verifiable.
|
||
-->
|
||
|
||
---
|
||
|
||
## 9. Out of Scope / Guardrails
|
||
|
||
<!--
|
||
Explicitly list what should NOT be done in this task.
|
||
Prevents scope creep and unintended refactors.
|
||
-->
|
||
|
||
---
|
||
|
||
# Developer Responsibilities
|
||
|
||
## A. Edge Case Coverage (Required)
|
||
|
||
<!--
|
||
List additional edge cases you considered beyond those above.
|
||
For each:
|
||
- State the edge case
|
||
- Explain how it is handled, tested, or explicitly not covered (and why)
|
||
Limit to 3–5 meaningful items.
|
||
--> |