codingetandClaude
9914bd07a8
Node Tests / node-tests (push) Has been cancelled
Browser Tests / browser-tests (push) Has been cancelled
Checks / lint (push) Has been cancelled
Checks / format (push) Has been cancelled
Checks / typecheck (push) Has been cancelled
Checks / typetest (push) Has been cancelled
Checks / build (push) Has been cancelled
Node Tests / node-tests (pull_request) Has been cancelled
Browser Tests / browser-tests (pull_request) Has been cancelled
Checks / lint (pull_request) Successful in 3m34s
Checks / format (pull_request) Successful in 3m1s
Checks / typetest (pull_request) Successful in 9m17s
Checks / typecheck (pull_request) Successful in 9m45s
Checks / build (pull_request) Successful in 9m42s
Add instructions for agents to apply `Agentic` + `Agent/<model-line>` labels to every PR they open (creating the labels via `tea labels create` if absent), and to auto-finalise PRs without user prompting when the work is trivial or was fully specified upfront. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
4.6 KiB
4.6 KiB
Agent instructions
Guidelines for AI agents (Claude Code, etc.) working in this repository.
Pull requests
- Open PRs with the
teaCLI (tea pr create). - Always prefix PR titles with
WIP:when opening them. - Always base PRs against
origin/main: fetch and pullorigin/mainbefore branching unless a different base is specified. - Keep the PR description up to date: update it after each push to reflect the current state of the branch, not just the initial intent.
- Apply the org-level
Agenticlabel and the appropriate org-levelAgent/<model-line>label (e.g.Agent/Opus,Agent/Sonnet,Agent/Haikufor the Claude lineup) to every PR you open. These labels already exist at the organisation level — do not create repo-level duplicates. TheAgent/*labels are exclusive (only one may be set at a time). Usetea api(thetealabel flags are unreliable): look up the label IDs withtea api orgs/webnet/labels, then apply them withtea api repos/{owner}/{repo}/issues/<pr>/labels -d '{"labels":[<id1>,<id2>]}'. - After pushing to the PR branch or opening the PR, watch the CI results (e.g. via the
teaCLI or available harness tools) and address any errors before proceeding. - When the PR work appears complete (typically after push and CI passes): if the harness provides a tool for spawning a new thread or agent, spawn an autonomous code review using a medium-size model (e.g. Sonnet for the Claude lineup). Watch the review output and address findings as appropriate.
- When everything has settled, or if you need the user to unblock you: if the harness or other instructions provide a push notification tool, send the user a push notification with a short summary; include the full details in the main conversation thread.
- When asked to finalise a PR: run all relevant tests, typechecks, lints, and formatters; ensure the AI disclosure in
AI_CHANGES.mdand the PR description are up to date; then remove theWIP:prefix from the PR title to mark it ready for merging. - Auto-finalise the PR (without waiting to be asked) if you are confident the user will not request changes — for example, if the work is trivial, mechanical, or was fully specified upfront with no ambiguity. In that case, run the finalise steps above immediately after CI passes and the review is clean.
Reviewing pull requests
- Always use the
teaCLI to read PR details and post comments — usetea prsubcommands, notgh. - If the user asked for an interactive review: pause after gathering initial findings and validate key assumptions or ambiguous judgements with the user before writing up conclusions.
- If the user asked for an autonomous review: post the review feedback directly on the PR (e.g.
tea pr review) without stopping to ask — do not just report findings back in the conversation.
Commits
- Always include a
Co-Authored-Bytrailer in every commit message for work assisted or authored by an AI agent, using the actual model that did the work:For example:Co-Authored-By: <Model Name> <noreply@provider.example>Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>orCo-Authored-By: GPT-5.5 <noreply@openai.com>. Do not hardcode a model name — use whichever model is actually running.
Worktrees
- When working inside a git worktree, always work on a feature branch — never commit directly to
webnetormainunless explicitly directed. - The repository has a
tailscalesubmodule. If you need to read or edit it while in a worktree, initialize and use the copy inside the worktree (git submodule update --initfrom the worktree root), not the one in the main repo checkout. Work on the main repo's submodule may be ongoing and must not be disturbed.
Coding style
Follow the existing style of the codebase. Use packages/http as the primary reference: no comments unless the reason is non-obvious, no unnecessary abstractions, no speculative error handling, no trailing summaries in commit messages or PR descriptions.
Dependencies
Do not add new dependencies without first asking the user, unless the intent to do so is unambiguously implied by the task (e.g. initialising a React app, adding a Postgres client when the task is explicitly about connecting to Postgres). When in doubt, ask.
AI disclosure
AI_CHANGES.md contains the full AI disclosure log and must be kept up to date. README.md links to it but does not contain the disclosure itself.
At the end of every branch, review the commits (e.g. git log main..HEAD --oneline) and append entries to AI_CHANGES.md for any new work that was assisted or authored by an AI agent.