78 lines
3.6 KiB
Markdown
78 lines
3.6 KiB
Markdown
# Personal agent instructions
|
|
|
|
These instructions apply to every Zed project. A project instruction file, such as `AGENTS.md`, takes precedence when it conflicts with this file.
|
|
|
|
## Skills
|
|
|
|
Skills provide task-specific guidance. Before planning work, identify every skill applicable to the task and read its `SKILL.md` plus relevant supporting documentation.
|
|
|
|
Multiple skills can apply. Select them from the actual task scope, not merely because a subject is mentioned incidentally. Skills supplement project instructions; they never replace them.
|
|
|
|
## Persistent project memory
|
|
|
|
At the start of a new conversation, read project instructions and any repository-provided memory or handoff files, such as `.agents/MEMORY.md`, along with task-relevant runbooks. Use the global `agent-memory` skill when a project maintains durable handoff notes.
|
|
|
|
When a project provides these files, update them after significant work with decisions, blockers, and other concise state that a future conversation needs. Verify their claims against the current code and Git state.
|
|
|
|
## Workflow for significant implementation work
|
|
|
|
### 1. Understand
|
|
|
|
Before changing files:
|
|
|
|
- read project instructions and all applicable skills;
|
|
- inspect the existing implementation and relevant tests;
|
|
- identify dependencies, integration points, and existing mechanisms; and
|
|
- confirm the requested behavior and any unresolved risks.
|
|
|
|
Do not modify files during this phase.
|
|
|
|
### 2. Plan
|
|
|
|
For non-trivial work, present a concise plan covering:
|
|
|
|
- the requirement and current behavior;
|
|
- relevant existing functionality;
|
|
- likely files or components to change;
|
|
- the proposed implementation;
|
|
- data, security, or compatibility implications where applicable;
|
|
- tests to add or modify; and
|
|
- risks or unresolved questions.
|
|
|
|
### 3. Approval
|
|
|
|
Stop after presenting the plan unless the user has explicitly requested immediate implementation or a project workflow says otherwise. Do not silently expand a materially incorrect or incomplete approved plan; explain the discrepancy first.
|
|
|
|
### 4. Implement
|
|
|
|
After approval, keep the change focused, reuse existing functionality, and avoid unrelated refactoring. Follow project coding and Git conventions.
|
|
|
|
### 5. Validate and review
|
|
|
|
Run the most relevant available tests, static checks, and format or configuration validation. Before declaring completion, review for correctness, integration, maintainability, security and access control, compatibility, and regression risk.
|
|
|
|
## Verify before assuming
|
|
|
|
Never invent or assume an API, dependency, model, field, method, configuration key, external service, or package exists. Verify it in the current source tree, installed environment, or declared dependencies before using it.
|
|
|
|
Do not infer availability from naming conventions, documentation alone, another version, training knowledge, or a similarly named component. If availability cannot be verified, report the uncertainty rather than guessing.
|
|
|
|
## Prefer existing functionality
|
|
|
|
Before adding custom code, search the project and its relevant framework or platform for an existing mechanism. Prefer, in order:
|
|
|
|
1. existing functionality that fulfills the requirement;
|
|
2. extending an existing mechanism;
|
|
3. composing existing mechanisms; then
|
|
4. a small custom implementation when the above are insufficient.
|
|
|
|
When choosing custom behavior instead of an existing mechanism, explain why.
|
|
|
|
## Git hygiene
|
|
|
|
- Keep commits focused and logically coherent.
|
|
- Do not mix unrelated changes.
|
|
- Review the staged diff before committing.
|
|
- Never commit secrets, credentials, private data, local configuration, or unrelated generated artifacts.
|
|
- Do not commit unless the user explicitly asks or the task explicitly requires it.
|