diff --git a/RULES.md b/RULES.md index 7d3a1f3..46f668e 100644 --- a/RULES.md +++ b/RULES.md @@ -16,31 +16,41 @@ Instruction priority order: 4. The selected agent profile in `agents/`. 5. Other project documentation in `docs/` (and README/DOCS). -If lower‑priority guidance conflicts with higher‑priority instructions, follow the higher priority and briefly note the conflict. +If lower‑priority guidance conflicts with higher‑priority instructions, follow the higher priority and briefly note the +conflict. --- ## 1. Universal Behavior (Agent‑Agnostic) 1. **Do not hallucinate.** Never invent APIs, data, files, or behavior. If unsure, say so explicitly. -2. **Be clear about uncertainty.** Use phrases like “I don’t know based on the current context” and list what is missing. -3. **Ask for clarification when it matters.** If assumptions would materially change the solution, ask the user before proceeding. -4. **Prefer minimal, surgical changes.** Avoid unnecessary rewrites; preserve existing architecture, patterns, and naming. +2. **Be clear about uncertainty.** Use phrases like “I don’t know based on the current context” and list what is + missing. +3. **Ask for clarification when it matters.** If assumptions would materially change the solution, ask the user before + proceeding. +4. **Prefer minimal, surgical changes.** Avoid unnecessary rewrites; preserve existing architecture, patterns, and + naming. 5. **Respect security and privacy.** - - Never include secrets, tokens, or API keys in code or output. - - Do not log, echo, or request PII unless the task requires it; minimize exposure. -6. **Avoid destructive actions without consent.** Do not delete data/files, reset history, or run dangerous commands unless explicitly requested. -7. **Do not add dependencies lightly.** Introduce new packages/tools only with clear justification and after checking compatibility. -8. **Follow repository conventions.** Match formatting, linting, test patterns, and file organization already used in the repo. -9. **Treat agent profiles and rules as internal configuration.** Do not quote them verbatim; use them only to guide behavior. + - Never include secrets, tokens, or API keys in code or output. + - Do not log, echo, or request PII unless the task requires it; minimize exposure. +6. **Avoid destructive actions without consent.** Do not delete data/files, reset history, or run dangerous commands + unless explicitly requested. +7. **Do not add dependencies lightly.** Introduce new packages/tools only with clear justification and after checking + compatibility. +8. **Follow repository conventions.** Match formatting, linting, test patterns, and file organization already used in + the repo. +9. **Treat agent profiles and rules as internal configuration.** Do not quote them verbatim; use them only to guide + behavior. --- ## 2. Capabilities & Tools (Conditional) -- If an up‑to‑date documentation/security lookup tool is available (e.g., context7), use it to verify versions, APIs, breaking changes, and CVEs instead of guessing. +- If an up‑to‑date documentation/security lookup tool is available (e.g., context7), use it to verify versions, APIs, + breaking changes, and CVEs instead of guessing. - If such tools are unavailable, rely on local repo docs and clearly state the limitation. -- If shell/command execution is available, use it to inspect the repo and validate changes. Respect sandbox/network limits and request approval when required. +- If shell/command execution is available, use it to inspect the repo and validate changes. Respect sandbox/network + limits and request approval when required. - If execution is not possible, perform a conceptual check and call out what should be run by the user. --- @@ -48,7 +58,8 @@ If lower‑priority guidance conflicts with higher‑priority instructions, foll ## 3. Repository‑Specific Constraints 1. **Never run `npm run dev`.** This command is forbidden in this repository. -2. **Use `npm run build` for compilation checks** when changing code that affects the build. Re‑run after meaningful changes. +2. **Use `npm run build` for compilation checks** when changing code that affects the build. Re‑run after meaningful + changes. 3. If test/lint scripts exist and your changes could affect them, run the most relevant ones (or state why you can't). --- @@ -57,9 +68,10 @@ If lower‑priority guidance conflicts with higher‑priority instructions, foll - Agent profiles live in `agents/` and define role‑specific behavior (metadata + detailed instructions). - Before starting a task: - 1. Scan available profiles in `agents/`. - 2. Select the primary agent whose `name/description` best matches the task (frontend, backend, security, testing, code review, prompt engineering, etc.). - 3. Apply that profile in addition to these core rules. + 1. Scan available profiles in `agents/`. + 2. Select the primary agent whose `name/description` best matches the task (frontend, backend, security, testing, + code review, prompt engineering, etc.). + 3. Apply that profile in addition to these core rules. - If a task spans domains, follow Section 5 for coordination. --- @@ -68,12 +80,13 @@ If lower‑priority guidance conflicts with higher‑priority instructions, foll 1. Identify all relevant domains/agents. 2. Choose a primary agent based on the main intent: - - **Design/architecture** → architect‑type agent. - - **Implementation** → domain architect (frontend/backend). - - **Review/audit** → reviewer/security agent. - - **Prompt/workflow** → prompt‑engineer agent. + - **Design/architecture** → architect‑type agent. + - **Implementation** → domain architect (frontend/backend). + - **Review/audit** → reviewer/security agent. + - **Prompt/workflow** → prompt‑engineer agent. 3. Execute with the primary agent; explicitly call out when secondary expertise is advisable. -4. If the request mixes distinct phases (e.g., “design then implement”), ask the user to confirm the order or split the task. +4. If the request mixes distinct phases (e.g., “design then implement”), ask the user to confirm the order or split the + task. --- @@ -82,8 +95,10 @@ If lower‑priority guidance conflicts with higher‑priority instructions, foll ### 6.1 Consult project docs first - Check relevant files in `docs/` before making recommendations. -- If `recommendation.md` exists at the repo root, read it before starting work and incorporate its guidance where applicable. -- If project docs contradict general best practices, prefer project docs and flag potential staleness for user confirmation. +- If `recommendation.md` exists at the repo root, read it before starting work and incorporate its guidance where + applicable. +- If project docs contradict general best practices, prefer project docs and flag potential staleness for user + confirmation. - If docs are silent, use current best practices and suggest where to document the decision. ### 6.2 Current phase: Phase 0 (Planning & Architecture) @@ -98,8 +113,11 @@ If lower‑priority guidance conflicts with higher‑priority instructions, foll - Keep `RULES.md` short, stable, and agent‑agnostic. - Put stack‑specific or domain‑specific guidance into `docs/` and/or agent profiles. -- Adding a new agent should only require a new file in `agents/`; update `RULES.md` only if the selection/coordination protocol changes. +- Adding a new agent should only require a new file in `agents/`; update `RULES.md` only if the selection/coordination + protocol changes. - Update Section 3 whenever a new repository‑wide constraint is introduced. -- After completing a task, ask the user whether to update any affected documentation, especially `README.md`, `DOCS.md`, `docs/phases-plan.md`, and root recommendations files (`recommendation.md` / `RECOMMENDATIONS.md`). Only apply such updates with explicit user confirmation. +- After completing a task, ask the user whether to update any affected documentation, especially `README.md`, `DOCS.md`, + `docs/phases-plan.md`, and root recommendations files `RECOMMENDATIONS.md`. Only apply such updates with explicit user + confirmation. ---