Critical Thinking & Adaptation Rules for NgRx Copilot Agent

⚠️ This section is mandatory and overrides stylistic preferences

The Copilot agent must adapt to the existing NgRx implementation in the project.
Best practices are important, but consistency with the current codebase is more important.

This prevents:

• •Fragmented architectures
• •Mixed paradigms
• •Hard‑to‑maintain state layers

Core Principle

Extend the existing NgRx style — do not introduce a new one.

The agent must observe first, then act.

Step 1: Inspect the Existing NgRx Style

Before generating or modifying code, the agent must check:

✅ Actions

• •Are actions created with:
  • •createAction
  • •Action classes (implements Action)
  • •Plain objects

✅ Reducers

• •Are reducers defined with:
  • •createReducer
  • •switch (action.type)
• •Are entity adapters used?

✅ Effects

• •Are effects present?
• •Do they return actions or manually dispatch?
• •Are they class‑based or function‑based?

✅ Selectors

• •Are selectors:
  • •Centralized in selector files?
  • •Inline in components?
• •Are feature selectors used?

✅ Facades

• •Is there a facade layer?
• •Do components inject Store directly?

Step 2: Match the Existing Pattern

Actions — Adapt, Don’t Migrate

❌ Do NOT auto‑convert action classes to creators
❌ Do NOT introduce action creators into a class‑based codebase

Reducers — Preserve Style

❌ Do NOT refactor reducers unless explicitly asked

Facades — Never Introduce Implicitly

✅ If facades exist:

• •Components must not inject Store
• •Actions/selectors stay hidden

❌ If facades do not exist:

• •Components may use Store directly
• •Agent should not suggest facades unless asked

Selectors — Match Existing Access Style

✅ Prefer selectors when they already exist
❌ Do not introduce selectors just to “clean up” code

Effects — Follow Established Flow

❌ Do not normalize effects unless requested

Step 3: Apply Best Practices Within the Existing Style

Even when adapting, the agent must still:

✅ Keep reducers pure
✅ Avoid side effects in reducers
✅ Avoid cyclic effects
✅ Avoid duplicated logic
✅ Keep action naming consistent
✅ Preserve action → effect → reducer flow

Best practices should be applied subtly, not disruptively

Anti‑Pattern Detection (Warn, Don’t Rewrite)

If the agent detects:

• •Multiple actions dispatched for one intent
• •Business logic in components
• •Side effects in reducers

✅ The agent may:

• •Add comments
• •Suggest improvements
• •Ask before refactoring

❌ The agent must not rewrite architecture unprompted

Decision Hierarchy (Most Important First)

1. •✅ Match existing project conventions
2. •✅ Preserve architectural consistency
3. •✅ Avoid breaking changes
4. •✅ Apply NgRx best practices
5. •✅ Suggest improvements only when safe

Agent Self‑Check (Before Responding)

[ ] Did I inspect existing NgRx patterns first?
[ ] Did I avoid introducing new paradigms?
[ ] Did I match action/reducer/effect style?
[ ] Did I preserve architectural consistency?
[ ] Did I avoid unsolicited refactors?

If any answer is NO, the agent must revise its response.

Final Contract

The Copilot agent is an architectural collaborator, not a refactoring tool.

Consistency beats perfection.
Incremental improvement beats sweeping change.

✅ Safe for NgRx v7+
✅ Safe for legacy codebases
✅ Safe to embed in nested Markdown