Remove codex-rules.md and integrate relevant details into RULES.md and agent-specific documentation to streamline and centralize repository guidelines. Refine security-auditor.md, test-engineer.md, backend-architect.md, frontend-architect.md, and code-reviewer.md for better clarity and alignment with updated rules.

This commit is contained in:
olekhondera
2025-12-12 01:26:33 +02:00
parent e45952077a
commit 85d30af57f
9 changed files with 123 additions and 314 deletions

View File

@@ -88,7 +88,7 @@ When context7 documentation contradicts your training knowledge, **trust context
# Workflow
1. **Analyze & Plan (<thinking>)** — Before generating any text, wrap your analysis in <thinking> tags. Review the request, check against project rules (typically `codex-rules.md`, `RULES.md`, or similar), and identify missing context or constraints.
1. **Analyze & Plan (<thinking>)** — Before generating any text, wrap your analysis in <thinking> tags. Review the request, check against project rules (`RULES.md` and relevant docs), and identify missing context or constraints.
2. **Gather context** — Clarify: target model and version, API/provider, use case, expected inputs/outputs, success criteria, constraints (privacy/compliance, safety), latency/token budget, tooling/agents/functions availability, and target format.
3. **Diagnose (if improving)** — Identify failure modes: ambiguity, inconsistent format, hallucinations, missing refusals, verbosity, lack of edge-case handling. Collect bad outputs to target fixes.
4. **Design the prompt** — Structure with: role/task, constraints/refusals, required output format (schema), examples (few-shot), edge cases and error handling, reasoning instructions (cot/step-by-step when needed), API/tool call requirements, and parameter guidance (temperature/top_p, max tokens, stop sequences).
@@ -307,7 +307,7 @@ Warn proactively about:
Before delivering a prompt, verify:
- [ ] Request analyzed in <thinking> block
- [ ] Checked against project rules (codex-rules.md or similar)
- [ ] Checked against project rules (`RULES.md` and related docs)
- [ ] No ambiguous pronouns or references
- [ ] Every instruction is testable/observable
- [ ] Output format/schema is explicitly defined with required fields