- Treat evidence-led KISS and YAGNI as equal primary system design heuristics.
- Consider SOLID for every system design decision, and prefer composition over inheritance.
- Design functionality and tests around standard usage and feasible failures reachable through production inputs, dependencies, or execution paths. Failures possible only through test-only construction are outside scope.
- Ask one question at a time through the question harness tool, and wait for the answer before the next. Provide concrete answer options, with the recommended option first. This sequence replaces any skill's batched-round format.
- Before you examine or change the repository, read
GLOSSARY.mdfor the project terms andMEMORY.mdfor the applicable entries. Before you change a part of the project, read the ADRs indocs/adr/that are related to that part. Obey these ADRs, because each ADR records a decision that the code does not show. - Prototypes:
prototypes/holds throwaway work. Take facts and decisions from the rest of the repo, and openprototypes/only when the human's current prompt asks for it.
- Branches: Before creating a branch, opening or merging a pull request, follow Git Flow strictly. Open pull requests into
mainonly fromrelease/<semver>orhotfix/<name>. Send every other change, includingfeature/<name>andbugfix/<name>, through a pull request intodevelop. Changemainanddeveloponly through pull requests with merge commits, because users install skills frommain. - Merging: Merge a pull request into
developyourself once every required check passes. Leave pull requests intomainfor the human to merge. GitHub deletes the remote branch of a merged pull request, but your local branch stays. After you merge a pull request from afeature/<name>orbugfix/<name>branch intodevelop, do these steps:- Run
git switch develop. - Run
git pull. - Run
git fetch --prune. - CAUTION: Delete a local branch only with
git branch -d, notgit branch -D.git branch -Ddeletes commits that no other branch contains. - Delete the local branch of that pull request with
git branch -d <branch>.
- Run
- Commits: Before creating a commit or proposing or using a commit message, read and follow
docs/agents/commit-policy.md. - Checks: Before each commit, run
docker compose run --rm bun run check. Done when it exits 0; fix every error it reports. To fix formatting, rundocker compose run --rm bun run fix. - Back-merges: After the user merges a pull request into
main,release.ymlopens the back-merge pull request frommainintodevelop. If theback-mergejob stops because Git cannot mergemainintodevelop, do not change that pull request. If you change that pull request, you push commits tomain. Rungit fetch. Then do these steps:- Make the branch
bugfix/back-merge-v<semver>fromorigin/develop. The title of the back-merge pull request gives<semver>. - On that branch, run
git merge origin/mainand correct the files that Git cannot merge. - Open a pull request from that branch into
develop. - Close the back-merge pull request, because the new pull request replaces it.
- Make the branch
GitHub Issues on a1exk-dev/agent-context, tracked in the private "agent-context" project. See docs/agents/issue-tracker.md.
Default labels: needs-triage, needs-info, ready-for-agent, ready-for-human, wontfix. See docs/agents/triage-labels.md.
Before you write or edit AGENTS.md, GLOSSARY.md, MEMORY.md, or an ADR, and when you complete a task, obey docs/agents/domain.md.