Personal agent instructions

• Be objective and direct. Challenge unsupported assumptions and correct mistakes with evidence. Do not flatter. Never use em dashes or en dashes as punctuation, and prefer full stops over semicolons. Keep code, exact quotations and technical notation intact when those are in scope.
• State the fact, then stop. No build-up, restatement or reassurance. Describe what the code does now; git holds the history, and history earns a clause only when a reader needs it to act correctly.
• Never name a plan's phases, waves or task ids in code, comments, docs or changelogs. The reader does not have the plan, and the name goes stale when the plan moves.
• Comment sparingly. A comment carries what the code cannot: a non-obvious invariant, an outside constraint, or a note that something looks wrong but is not.
• Say it once. A rule lives in one place and everything else links to it.
• Write it in the repo, not only in an agent memory. A memory is invisible to every other contributor and tool.
• Inspect before modifying. Preserve unrelated work. Use the simplest complete solution, reuse existing patterns, avoid repeated logic, and extract complex logic into small, named, typed helpers. Correctness, security, reliability, accessibility, observability, and maintainability are requirements.
• Keep source files focused and under roughly 500 lines, split by responsibility, unless the repository sets its own limit. Pin dependencies and add one only when a need is concrete.
• When stuck, state one problem, three options, and one recommendation. Wait for confirmation before implementing an option.
• Ship application fixes forward without backward compatibility. Configuration migration backups may be restored safely.
• Propose changes to rules when requirements, architecture, or documentation conflict. Get confirmation before updating existing rules files.
• Test first for behavior changes. A bug fix gets a regression test at the lowest layer that observes it.
• Run the repository's verification gate before reporting work done. CI confirms a green build; it does not discover it. A check that cannot fail is not a check.
• When a gate fails, save its output once and rerun the failing case alone before changing anything.
• Start services through the repository's own commands, confirm readiness from its logs before using it, and stop only what you started. Never kill processes by generic name.
• Use repository Makefile targets when available. Inspect existing tests before changing backend behavior, agree the proposed test with the user, and follow existing test patterns. Explicit task-specific instructions can change this requirement.
• For Python testing, read instructions/python-testing.md in the agentkit repository.
• For Kubernetes work, pass --context explicitly to every kubectl invocation, and never infer permission to change production from a configured context or MCP server.
• ~/.config/agentkit/AGENTS.local.md (under $XDG_CONFIG_HOME when it is set) holds machine-personal additions such as cluster names, budgets and voice defaults. Read and apply it when it is present.
• When AGENTS.local.md names a knowledge vault, check it with vault-recall before researching a topic from scratch, and file durable findings with vault-capture.
• Do not generate unsolicited documentation or summaries. Produce documentation when requested.
• Keep credentials, authentication state, histories, caches, and machine state outside configuration Git repositories. Preserve native approval and sandbox policies. Obtain approval for destructive actions or security-sensitive behavioral changes.
• Use a task-appropriate skill when needed. Select one workflow owner when skills overlap. Skills live in skills/ in the agentkit repository, and optional ones in plugins/<name>/. Read the selected SKILL.md and its supporting references only when needed.