olemd/tilt-shift-camera
1
0
Fork 0
Code Issues Pull requests Projects Releases 11 Packages Wiki Activity Actions
tilt-shift-camera/AGENTS.md
Ole-Morten Duesund fc64081712 Add dcat issue tracking setup 
Introduce AGENTS.md with dcat workflow, .gitattributes merge driver for
dcat JSONL files, and .dogcats/ config + empty issue store. Update
CLAUDE.md to point agents at AGENTS.md and avoid the TodoWrite tool, and
ignore local-only dcat files (config.local.toml, .issues.lock).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-11 13:50:39 +02:00

1.9 KiB
Raw Permalink Blame History

Agent Instructions

Issue tracking

This project uses dcat for issue tracking. You MUST run dcat prime --opinionated for instructions. Then run dcat list --agent-only to see the list of issues. Generally we work on bugs first, and always on high priority issues first.

When running multiple dcat commands, make separate parallel Bash tool calls instead of chaining them with && and echo separators.

Mark each issue in_progress right when you start working on it — not before. Set in_review when work on that issue is done before moving on. The status should reflect what you are actually working on right now.

It is okay to work on multiple related issues at the same time, but do NOT batch-mark an entire backlog as in_progress upfront. If there is a priority conflict, ask the user which to focus on first.

If the user brings up a new bug, feature or anything else that warrants changes to the code, ALWAYS ask if we should create an issue for it before you start working on the code. When creating issues, set appropriate labels using --labels based on the issue content (e.g. cli, tui, api, docs, testing, refactor, ux, performance, etc.).

When research or discussion produces findings relevant to an existing issue, ask these as separate questions in order:

  1. First ask: "Should I update issue [id] with these findings?"
  2. Only after that, separately ask: "Should I start working on the implementation?" Do NOT combine these into one question. The user may want to update the issue without starting work.

Closing Issues - IMPORTANT

NEVER close issues without explicit user approval. When work is complete:

  1. Set status to in_review: dcat update --status in_review $issueId
  2. Ask the user to test
  3. Ask if we can close it: "Can I close issue [id] '[title]'?"
  4. Only run dcat close after user confirms
  5. Ask: "Should I add this to CHANGELOG.md?" — update if yes