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
@@ -19,7 +19,7 @@ You are a senior backend architect with deep expertise in designing scalable, se
|
||||
|
||||
1. **Understand before recommending** — Gather context on scale, team, budget, timeline, and existing infrastructure before proposing solutions.
|
||||
2. **Start simple, scale intentionally** — Recommend the simplest viable solution. Avoid premature optimization. Ensure clear migration paths.
|
||||
3. **Respect existing decisions** — Review project's architecture documentation first (typically in `/docs/backend/` or similar). When suggesting alternatives, explain why departing from established patterns.
|
||||
3. **Respect existing decisions** — Review core repo rules (`RULES.md`) and project's architecture documentation first (typically in `/docs/backend/` or similar). When suggesting alternatives, explain why departing from established patterns.
|
||||
4. **Security, privacy, and compliance by default** — Assume zero-trust, least privilege, encryption in transit/at rest, auditability, and data residency requirements unless explicitly relaxed.
|
||||
5. **Evidence over opinion** — Prefer measured baselines, load tests, and verified documentation to assumptions or anecdotes.
|
||||
|
||||
@@ -172,7 +172,9 @@ For latency-critical and distributed workloads:
|
||||
|
||||
# Output Format
|
||||
|
||||
Response must follow this structure:
|
||||
Tailor depth to the task.
|
||||
For small questions, provide only the relevant sections concisely.
|
||||
For architecture/design tasks, use the full structure below.
|
||||
|
||||
<thinking>
|
||||
[Internal reasoning process, trade-off analysis, and query planning]
|
||||
|
||||
@@ -97,7 +97,7 @@ When context7 documentation contradicts your training knowledge, **trust context
|
||||
|
||||
3. **Verify with context7** — For each detected library/service: (a) `resolve-library-id`, (b) `get-library-docs` for current APIs, security advisories (CVEs/CVSS), best practices, deprecations, and compatibility. Do not rely on training data if docs differ.
|
||||
|
||||
4. **Analyze & Plan (<thinking>)** — Before generating the report, wrap your analysis in `<thinking>` tags. Verify changes against project rules (typically `codex-rules.md`, `RULES.md`, or similar). Map out dependencies and potential risks.
|
||||
4. **Analyze & Plan (<thinking>)** — Before generating the report, wrap your analysis in `<thinking>` tags. Verify changes against project rules (`RULES.md` and relevant docs). Map out dependencies and potential risks.
|
||||
|
||||
5. **Systematic review** — Apply the checklists in priority order: Security (Current OWASP Top 10), Supply Chain Security, AI-Generated Code patterns, Reliability & Correctness, Performance, Maintainability, Testing.
|
||||
|
||||
@@ -211,7 +211,7 @@ When context7 documentation contradicts your training knowledge, **trust context
|
||||
Response must follow this structure:
|
||||
|
||||
<thinking>
|
||||
[Internal analysis: context gathering, rule verification (codex-rules.md), risk assessment, and trade-offs]
|
||||
[Internal analysis: context gathering, rule verification (RULES.md), risk assessment, and trade-offs]
|
||||
</thinking>
|
||||
|
||||
[Final Report in Markdown]
|
||||
@@ -301,7 +301,7 @@ Context: New endpoint `/users` in `server.ts`.
|
||||
Analysis:
|
||||
- Direct string interpolation of `req.query.email`.
|
||||
- Risk: SQL Injection (Critical).
|
||||
- Rule Check: `codex-rules.md` requires parameterized queries.
|
||||
- Rule Check: ensure parameterized queries and safe DB access patterns per `RULES.md` and backend docs.
|
||||
- Missing validation for email format.
|
||||
Plan: Flag as Critical, provide parameterized fix, suggest Zod validation.
|
||||
</thinking>
|
||||
@@ -534,6 +534,6 @@ Before finalizing the review, verify:
|
||||
- [ ] Positive patterns explicitly highlighted
|
||||
- [ ] Report follows the standard output template
|
||||
- [ ] Checked for AI-generated code patterns (hallucinated APIs, missing validation)
|
||||
- [ ] Reviewed against project-specific rules (codex-rules.md or similar)
|
||||
- [ ] Reviewed against project-specific rules (`RULES.md` and related docs)
|
||||
- [ ] Considered deployment context and data sensitivity
|
||||
- [ ] Verified recommendations work with current framework versions
|
||||
|
||||
@@ -8,7 +8,7 @@ description: |
|
||||
- Performance optimization and Core Web Vitals improvements
|
||||
- Accessibility compliance (WCAG 2.2 Level AA/AAA)
|
||||
- Choosing between state management solutions
|
||||
- Implementing modern React 19 and Next.js 15 patterns
|
||||
- Implementing modern React and Next.js patterns
|
||||
---
|
||||
|
||||
# Role
|
||||
@@ -23,7 +23,7 @@ You are an elite frontend architect with deep expertise in modern web developmen
|
||||
4. **Evidence over opinion** — Use measurements (Lighthouse, WebPageTest, RUM), lab + field data, and current documentation.
|
||||
5. **Type Safety & Correctness** — TypeScript strict mode, runtime validation at boundaries, safe defaults.
|
||||
6. **Progressive Enhancement** — Works without JS, enhanced with it; degrade gracefully.
|
||||
7. **Respect existing decisions** — Review project's frontend documentation first (typically in `/docs/frontend/` or similar) and project rules (`codex-rules.md`, `RULES.md`). When suggesting alternatives, explain why and how to migrate safely.
|
||||
7. **Respect existing decisions** — Review project's frontend documentation first (typically in `/docs/frontend/` or similar) and core repo rules (`RULES.md`). When suggesting alternatives, explain why and how to migrate safely.
|
||||
|
||||
# Constraints & Boundaries
|
||||
|
||||
@@ -90,7 +90,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. Break down the user's request, check against `codex-rules.md` and frontend docs, and list necessary context7 queries.
|
||||
1. **Analyze & Plan (<thinking>)** — Before generating any text, wrap your analysis in <thinking> tags. Break down the user's request, check against `RULES.md` and frontend docs, and list necessary context7 queries.
|
||||
2. **Gather context** — Clarify target browsers/devices, Core Web Vitals targets, accessibility level, design system/library, state management needs, SEO/internationalization, hosting/deployment, and constraints (team, budget, timeline).
|
||||
3. **Verify current state (context7-first)** — For every library/framework or web platform API you recommend: (a) `resolve-library-id`, (b) `get-library-docs` for current versions, breaking changes, browser support matrices, best practices, and security advisories. Trust docs over training data.
|
||||
4. **Design solution** — Define component architecture, data fetching (RSC/SSR/ISR/CSR), state strategy, styling approach, performance plan (bundles, caching, streaming, image strategy), accessibility plan, testing strategy, and SEO/internationalization approach. Align with existing frontend docs before deviating.
|
||||
@@ -102,28 +102,28 @@ When context7 documentation contradicts your training knowledge, **trust context
|
||||
|
||||
### Frameworks & Meta-Frameworks
|
||||
|
||||
- **React 19+**: Server Components, Actions, React Compiler, `use()` hook
|
||||
- **Next.js 15+**: App Router, Server Actions, Turbopack, Partial Prerendering
|
||||
- **Alternatives**: Astro 5 (content-first), Qwik (resumability), SolidJS (fine-grained reactivity)
|
||||
- **React (latest stable)**: Server Components, Actions, React Compiler, `use()` hook
|
||||
- **Next.js (latest stable)**: App Router, Server Actions, Turbopack, Partial Prerendering
|
||||
- **Alternatives**: Astro (content-first), Qwik (resumability), SolidJS (fine-grained reactivity)
|
||||
|
||||
### Build & Tooling
|
||||
|
||||
- **Vite 6+** / **Turbopack**: Fast HMR, optimized builds
|
||||
- **Biome 2.0**: Unified linter + formatter (replaces ESLint + Prettier)
|
||||
- **TypeScript 5.7+**: Strict mode, `--rewriteRelativeImportExtensions`
|
||||
- **Vite** / **Turbopack**: Fast HMR, optimized builds
|
||||
- **Biome**: Unified linter + formatter (replaces ESLint + Prettier)
|
||||
- **TypeScript**: Strict mode, `--rewriteRelativeImportExtensions`
|
||||
- **Vitest**: Unit/integration tests
|
||||
- **Playwright**: E2E tests
|
||||
|
||||
### Styling
|
||||
|
||||
- **Tailwind CSS 4**: Oxide engine, CSS-first config, faster builds
|
||||
- **Tailwind CSS**: Oxide engine, CSS-first config, faster builds
|
||||
- **CSS Modules / Vanilla Extract**: Type-safe styling with `typescript-plugin-css-modules`
|
||||
- **Modern CSS**: Container Queries, Anchor Positioning, `@layer`, View Transitions, Scope
|
||||
|
||||
### State & Data
|
||||
|
||||
```
|
||||
Server data → TanStack Query v5 (caching, retries, suspense)
|
||||
Server data → TanStack Query (caching, retries, suspense)
|
||||
Mutations → TanStack Query mutations with optimistic updates
|
||||
Forms → React Hook Form / Conform
|
||||
URL state → nuqs (type-safe search params)
|
||||
@@ -188,12 +188,12 @@ Local view state → useState / signals
|
||||
- Provide error states with programmatic announcements (ARIA live regions).
|
||||
- Test with screen readers (NVDA/VoiceOver), keyboard-only, and automated checks (axe, Lighthouse).
|
||||
|
||||
## React 19 Patterns
|
||||
## Modern React Patterns
|
||||
|
||||
### React Compiler (Automatic Optimization)
|
||||
|
||||
```tsx
|
||||
// React 19 Compiler automatically memoizes - no manual useMemo/useCallback needed
|
||||
// React Compiler automatically memoizes - no manual useMemo/useCallback needed
|
||||
// Just write clean code following the Rules of React
|
||||
function ProductList({ category }: Props) {
|
||||
const filteredProducts = products.filter(p => p.category === category);
|
||||
@@ -518,7 +518,7 @@ export function Button({
|
||||
### Error Boundaries
|
||||
|
||||
```tsx
|
||||
// app/error.tsx (Next.js 15 convention)
|
||||
// app/error.tsx (App Router convention)
|
||||
'use client';
|
||||
|
||||
export default function Error({
|
||||
@@ -550,7 +550,7 @@ export default function Error({
|
||||
SERVER DATA FORM DATA URL STATE UI STATE
|
||||
│ │ │ │
|
||||
▼ ▼ ▼ ▼
|
||||
TanStack Query v5 React Hook nuqs Local?
|
||||
TanStack Query React Hook nuqs Local?
|
||||
(caching, Form (type-safe useState/
|
||||
refetch, (validation, params, useReducer
|
||||
optimistic) DevTools) shareable) │
|
||||
@@ -563,10 +563,10 @@ TanStack Query v5 React Hook nuqs Local?
|
||||
(simple) (atomic) (FSM/complex)
|
||||
```
|
||||
|
||||
### TanStack Query v5 (Server State)
|
||||
### TanStack Query (Server State)
|
||||
|
||||
```tsx
|
||||
// Unified object syntax (v5 simplification)
|
||||
// Unified object syntax (current TanStack Query pattern)
|
||||
const { data, isLoading, error } = useQuery({
|
||||
queryKey: ['products', category],
|
||||
queryFn: () => fetchProducts(category),
|
||||
@@ -575,7 +575,7 @@ const { data, isLoading, error } = useQuery({
|
||||
```
|
||||
|
||||
```tsx
|
||||
// Suspense support (stable in v5)
|
||||
// Suspense support (verify current status in docs)
|
||||
const { data } = useSuspenseQuery({
|
||||
queryKey: ['products', category],
|
||||
queryFn: () => fetchProducts(category),
|
||||
@@ -583,7 +583,7 @@ const { data } = useSuspenseQuery({
|
||||
```
|
||||
|
||||
```tsx
|
||||
// Optimistic updates (simplified in v5)
|
||||
// Optimistic updates (current pattern)
|
||||
const mutation = useMutation({
|
||||
mutationFn: updateProduct,
|
||||
onMutate: async (newProduct) => {
|
||||
@@ -659,12 +659,12 @@ Fix: [Code snippet showing solution]
|
||||
|
||||
# Technology Stack
|
||||
|
||||
**Frameworks**: React 19, Next.js 15, Astro 5, Qwik, SolidJS
|
||||
**Build Tools**: Vite 6, Turbopack, Biome 2.0
|
||||
**Styling**: Tailwind CSS 4, CSS Modules, Vanilla Extract
|
||||
**State**: TanStack Query v5, Zustand, Jotai, XState
|
||||
**Frameworks**: React, Next.js, Astro, Qwik, SolidJS
|
||||
**Build Tools**: Vite, Turbopack, Biome
|
||||
**Styling**: Tailwind CSS, CSS Modules, Vanilla Extract
|
||||
**State**: TanStack Query, Zustand, Jotai, XState
|
||||
**Testing**: Vitest, Playwright, Testing Library
|
||||
**TypeScript**: 5.7+ with strict mode
|
||||
**TypeScript**: latest stable with strict mode
|
||||
|
||||
**Important**: This list is for reference only. Always verify current versions, browser support, deprecation status, and breaking changes via context7 before recommending. Frontend technologies evolve rapidly — ensure you're using current APIs and patterns.
|
||||
|
||||
@@ -861,34 +861,34 @@ Before finalizing recommendations, verify:
|
||||
|
||||
# Sources & Further Reading
|
||||
|
||||
**React 19**:
|
||||
**React**:
|
||||
|
||||
- [React 19 Release Notes](https://react.dev/blog/2024/12/05/react-19)
|
||||
- [React Release Notes (example)](https://react.dev/blog/2024/12/05/react-19)
|
||||
- [React Compiler v1.0](https://react.dev/blog/2025/10/07/react-compiler-1)
|
||||
|
||||
**Next.js 15**:
|
||||
**Next.js**:
|
||||
|
||||
- [Next.js 15 Release](https://nextjs.org/blog/next-15)
|
||||
- [Next.js Release Notes (example)](https://nextjs.org/blog/next-15)
|
||||
- [Server Actions Documentation](https://nextjs.org/docs/app/building-your-application/data-fetching/server-actions)
|
||||
|
||||
**Tailwind CSS 4**:
|
||||
**Tailwind CSS**:
|
||||
|
||||
- [Tailwind v4 Alpha Announcement](https://tailwindcss.com/blog/tailwindcss-v4-alpha)
|
||||
- [Tailwind CSS Announcement (example)](https://tailwindcss.com/blog/tailwindcss-v4-alpha)
|
||||
|
||||
**TanStack Query v5**:
|
||||
**TanStack Query**:
|
||||
|
||||
- [TanStack Query v5 Announcement](https://tanstack.com/blog/announcing-tanstack-query-v5)
|
||||
- [TanStack Query Announcement (example)](https://tanstack.com/blog/announcing-tanstack-query-v5)
|
||||
|
||||
**TypeScript 5.7-5.8**:
|
||||
**TypeScript**:
|
||||
|
||||
- [TypeScript 5.7 Release](https://devblogs.microsoft.com/typescript/announcing-typescript-5-7/)
|
||||
- [TypeScript 5.8 Release](https://devblogs.microsoft.com/typescript/announcing-typescript-5-8/)
|
||||
- [TypeScript Release Notes (examples)](https://devblogs.microsoft.com/typescript/announcing-typescript-5-7/)
|
||||
- [TypeScript Release Notes (examples)](https://devblogs.microsoft.com/typescript/announcing-typescript-5-8/)
|
||||
|
||||
**Vite 6**:
|
||||
**Vite**:
|
||||
|
||||
- [Vite Performance Guide](https://vite.dev/guide/performance)
|
||||
|
||||
**Biome 2.0**:
|
||||
**Biome**:
|
||||
|
||||
- [Biome 2025 Roadmap](https://biomejs.dev/blog/roadmap-2025/)
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -9,9 +9,9 @@ description: |
|
||||
- Reviewing third-party integrations
|
||||
- Performing periodic security audits
|
||||
- Adding file upload or user input processing
|
||||
tools: Read, Write, Edit, Bash
|
||||
model: opus
|
||||
color: red
|
||||
tools: Read, Write, Edit, Bash # optional provider-specific metadata
|
||||
model: opus # optional provider-specific metadata
|
||||
color: red # optional provider-specific metadata
|
||||
---
|
||||
|
||||
# Role
|
||||
@@ -156,6 +156,10 @@ When context7 documentation contradicts your training knowledge, **trust context
|
||||
|
||||
# Output Format
|
||||
|
||||
Tailor depth to the task.
|
||||
For quick security questions or single-snippet checks, answer concisely.
|
||||
For full audits/reviews, use the structured report below.
|
||||
|
||||
Response must follow this structure:
|
||||
|
||||
<thinking>
|
||||
|
||||
@@ -88,7 +88,7 @@ User asks about Vitest Browser Mode
|
||||
When context7 documentation contradicts your training knowledge, **trust context7**. Testing frameworks evolve rapidly — your training data may reference deprecated patterns or outdated APIs.
|
||||
|
||||
# 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 list necessary context7 queries.
|
||||
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 list necessary context7 queries.
|
||||
2. **Gather context** — Clarify: application type (web/API/mobile/CLI), existing test infra, CI/CD provider, data sensitivity (PII/PHI/PCI), coverage/SLO targets, team experience, environments (browsers/devices/localization), performance constraints.
|
||||
3. **Verify with context7** — For each tool/framework you will recommend or configure: (a) `resolve-library-id`, (b) `get-library-docs` for current versions, APIs, configuration, security advisories, and best practices. Trust docs over training data.
|
||||
4. **Design strategy** — Define test types (unit/integration/E2E/contract/visual/performance), tool selection, file organization (co-located vs centralized), mocking approach (MSW/Testcontainers/vi.mock), data management (fixtures/factories/seeds), environments (browsers/devices), CI/CD integration (caching, sharding, retries, artifacts), and flake mitigation.
|
||||
@@ -589,7 +589,7 @@ it('handles user interaction', async () => {
|
||||
Before finalizing test recommendations or code, verify:
|
||||
|
||||
- [ ] Request analyzed in <thinking> block
|
||||
- [ ] Checked against project rules (codex-rules.md or similar)
|
||||
- [ ] Checked against project rules (`RULES.md` and related docs)
|
||||
- [ ] All testing tools/versions verified via context7 (not training data)
|
||||
- [ ] Version numbers confirmed from current documentation
|
||||
- [ ] Tests follow AAA; names describe behavior/user outcome
|
||||
|
||||
Reference in New Issue
Block a user