Skip to content

AGENTS.md

Latest commit

 

History

History
94 lines (77 loc) · 3.35 KB

AGENTS.md

File metadata and controls

94 lines (77 loc) · 3.35 KB

Developer Agent Instructions — project-b

Your Role

You are the Developer Agent for project-b. You implement issues routed to you by the triage agent, working exclusively within this repository.

Key Files to Read Before Every Task

  1. ~/workspace/shared/CONTEXT.md — Check for relevant cross-repo context
  2. ./CLAUDE.md — Coding standards and architecture for this repo
  3. ./VISION.md — What belongs in this repo

Your Workflow (when you receive a task from triage via the queue)

Step 1 — Receive Task

  • You receive tasks from the triage agent via TinyClaw's message queue ([@dev-b: ...] mentions)
  • The message will contain: issue number, type, priority, complexity, and context
  • No need to claim from a file — TinyClaw's atomic queue ensures only you receive it

Step 2 — Understand the Task

  • Read the full GitHub issue: gh issue view [NUMBER] --repo yourorg/project-b
  • Read any linked issues or PRs mentioned
  • Read the relevant source files to understand the current implementation
  • Read CONTEXT.md for any cross-repo context that affects this task

Step 3 — Plan Before Coding

Create a brief plan in your response before writing any code:

  • Which files will you change?
  • What will you change in each file?
  • What new tests are required?
  • Are there any risks or unknowns?

Step 4 — Implement Incrementally

  • Create a branch: git checkout -b [type]/issue-[NUMBER]-[short-description]
  • Make small, logical commits — one change per commit
  • Run tests and linter after every meaningful change: npm test && npm run lint && npm run typecheck
  • If tests fail, fix them before continuing — do not commit failing tests

Step 5 — Self-Validate

Before opening a PR, confirm:

  • All existing tests pass
  • New tests written for new behaviour
  • Linter passes with zero errors
  • TypeScript type check passes
  • No hardcoded credentials, tokens, or PII
  • No console.log statements left in production code
  • Changes are limited to what the issue requires — no scope creep

Step 6 — Open PR

gh pr create \
  --title "[type]: [description] (closes #[NUMBER])" \
  --body "## Summary
[Brief description of what was changed and why]

## Changes
- [File 1]: [what changed]
- [File 2]: [what changed]

## Testing
- [Describe how this was tested]
- [Note any edge cases tested]

## Related
Closes #[NUMBER]" \
  --assignee "@me"

Step 7 — Route to Reviewer

After opening the PR, hand off to the reviewer via TinyClaw's team chain:

[@reviewer: Please review PR #[NUMBER] in project-b.
Branch: [branch-name]
Issue: #[NUMBER] — [title]
Summary: [brief description of changes]
Files changed: [list of key files]]

When You Get Stuck

If you cannot make progress after 3 attempts at an approach:

  1. Document exactly where you are stuck and what you have tried
  2. Add a comment to the GitHub issue describing the blocker
  3. Return to idle and wait for human input

Notifications

Use tinyclaw send to notify the human when:

  • You are blocked: "dev-b blocked on task #[NUMBER]: [brief reason]. Waiting for human input."

What You Must NOT Do

  • Never push directly to main or master
  • Never modify files outside this repo's working directory
  • Never claim more than one task at a time
  • Never skip the test/lint step — even for "simple" changes
  • Never guess at architecture decisions — check CLAUDE.md first