@event4u/agent-config 5.10.1 → 6.1.0

package/.agent-src/skills/deep-reading-analyst/SKILL.md

@@ -1,198 +0,0 @@
----
-model_tier: high
-context: large
-name: deep-reading-analyst
-description: "Deep analysis of articles/long-form via thinking frameworks (SCQA, mental models, inversion) — 'analyze article', 'deep dive', 'extract insights', URL/text wanting depth not summary."
-status: active
-domain: discovery
-external_source: "https://github.com/ginobefun/deep-reading-analyst-skill/tree/26cd7dc9920e025d39751e396e707399022e49ef/src/deep-reading-analyst"
-refresh_trigger: "Upstream `ginobefun/deep-reading-analyst-skill` major rewrite (new framework added, dispatch table reshaped, or SHA pin invalidated by reference rename)."
-sunset_criterion: "Replace with a 50-line pointer skill if (a) all referenced modules are adopted as project-local guidelines (`docs/guidelines/agent-infra/{framework}.md`) AND (b) the dispatch logic moves into a project-native router."
-workspaces:
-  - engineering
-packs:
-  - engineering-base
----
-
-> **Pinned upstream:** `ginobefun/deep-reading-analyst-skill` @ SHA `26cd7dc9` (MIT). Re-verify per upstream major rewrite. Reference modules below link to the same SHA.
-
-# deep-reading-analyst
-
-Wing-1 deep-thinking skill for articles, papers, opinion pieces, case studies, and long-form decision documents. Routes the user's content through 8 thinking frameworks at four depth levels (Quick / Standard / Deep / Research) and returns insight tied to the user's **goal**, not framework completion.
-
-## When to use
-
-- User pastes an article URL, paper, or long text and wants depth ("analyze", "deep dive", "extract insights", "help me understand").
-- User asks for a specific framework ("apply SCQA to this", "use inversion thinking", "give me the mental models lens").
-- User is making a decision and wants pre-mortem / multi-lens analysis on a written proposal.
-- User is studying or note-taking on dense material (research papers, strategy memos, books).
-
-Do NOT use when:
-- User wants a 3-bullet TL;DR — use `agent-docs-writing` or write a direct summary.
-- Content is code or a diff — route to `judge-bug-hunter`, `judge-code-quality`, or `adversarial-review`.
-- User wants risk analysis on a code change — route to `adversarial-review` (diff-bound) or `threat-modeling`.
-- User wants debugging or incident analysis — route to `bug-analyzer` or `systematic-debugging`.
-
-## Framework Arsenal
-
-| Depth | Time | Frameworks | Reference module |
-|---|---|---|---|
-| **L1 — Quick** | ~15 min | SCQA, 5W2H | [`scqa-framework`](../../../docs/guidelines/agent-infra/scqa-framework.md), `5w2h_analysis.md` (upstream) |
-| **L2 — Standard** | ~30 min | L1 + Critical Thinking, Inversion | + [`inversion-thinking`](../../../docs/guidelines/agent-infra/inversion-thinking.md), `critical_thinking.md` (upstream) |
-| **L3 — Deep** | ~60 min | L2 + Mental Models, First Principles, Systems Thinking, Six Hats | + [`mental-models`](../../../docs/guidelines/agent-infra/mental-models.md), `first_principles.md`, `systems_thinking.md`, `six_hats.md` (upstream) |
-| **L4 — Research** | 120 min+ | L3 + Cross-source comparison via web search | + `comparison_matrix.md` (upstream) |
-
-Modules tagged `(upstream)` link to SHA-pinned files at the URL in `external_source` above; project-local modules are adopted as guidelines.
-
-## Procedure: deep-reading-analyst
-
-### Step 0: Inspect
-
-1. **Detect content type** — article, paper, opinion piece, case study, how-to, strategy memo. Drives auto-suggested frameworks (Step 1).
-2. **Detect goal signal** — problem-solving, learning, writing reference, decision-making, curiosity. Drives Step 4 output shape.
-3. **Skip if mismatched** — see "Do NOT use when" above; route to the named skill.
-
-### Step 1: Initialize Analysis
-
-Ask the user three things in **one** message (not three turns), per `ask-when-uncertain` Iron Law (one question per turn — these three are bundled into a single numbered-options block):
-
-1. **Goal** — problem-solving · learning · writing · decision-making · curiosity.
-2. **Depth** — L1 Quick (15 min) · L2 Standard (30 min) · L3 Deep (60 min) · L4 Research (120 min+).
-3. **Framework override** — defaults are auto-suggested by content type (table below); user may name specific frameworks.
-
-If the user does not answer, default to L2 Standard with auto-selected frameworks.
-
-**Auto-suggest matrix:**
-
-| Content type | Default frameworks |
-|---|---|
-| Strategy / business article | SCQA + Mental Models + Inversion |
-| Research paper | 5W2H + Critical Thinking + Systems Thinking |
-| How-to guide | SCQA + 5W2H + First Principles |
-| Opinion piece | Critical Thinking + Inversion + Six Hats |
-| Case study | SCQA + Mental Models + Systems Thinking |
-
-### Step 2: Structural Understanding (always run)
-
-Regardless of depth, open with two short blocks:
-
-**2A — Basic structure.**
-
-```markdown
-📄 Type: [article/paper/report]
-🎯 Core thesis: [one sentence]
-Structure:
-├─ Argument 1 → [key support]
-├─ Argument 2 → [key support]
-└─ Argument 3 → [key support]
-Key concepts: [3–5 terms with one-line definitions]
-```
-
-**2B — SCQA breakdown.** Apply the four-element decomposition from [`scqa-framework`](../../../docs/guidelines/agent-infra/scqa-framework.md):
-
-```markdown
-**S (Situation)**: [context the article establishes]
-**C (Complication)**: [problem identified]
-**Q (Question)**: [core question]
-**A (Answer)**: [main solution / conclusion]
-Structure quality — clarity / logic / completeness: [★★★☆☆]
-```
-
-**2C — 5W2H gap check** (L1+). Quick scan: which of *What, Why, Who, When, Where, How, How much* are well-covered, partial, or missing? Flag the 1–2 most critical gaps.
-
-### Step 3: Apply Frameworks (depth-gated)
-
-Load only the frameworks the user's depth bought. Each framework follows the same pattern: **load reference module → apply lens → produce one fixed-shape block**.
-
-**L2 additions:**
-
-- **Critical Thinking** (`critical_thinking.md`, upstream) — argument strength score (X/10), strengths, weaknesses, logical fallacies detected.
-- **Inversion** ([`inversion-thinking`](../../../docs/guidelines/agent-infra/inversion-thinking.md)) — pre-mortem on the article's recommendation: "how would this fail?", missing risk factors, mitigations.
-
-**L3 additions:**
-
-- **Mental Models** ([`mental-models`](../../../docs/guidelines/agent-infra/mental-models.md)) — pick 3–5 models from different disciplines (physics, biology, psychology, economics, math), apply each lens, surface cross-model patterns.
-- **First Principles** (`first_principles.md`, upstream) — strip to fundamental truths, validate each core assumption, rebuild from base.
-- **Systems Thinking** (`systems_thinking.md`, upstream) — map relationships, feedback loops, leverage points.
-- **Six Hats** (`six_hats.md`, upstream) — White (facts), Red (feelings), Black (cautions), Yellow (benefits), Green (creativity), Blue (process).
-
-**L4 addition:**
-
-- **Cross-source comparison** (`comparison_matrix.md`, upstream) — web-search 2–3 related sources, compare SCQA across sources, identify consensus vs divergence, synthesize integrated perspective.
-
-### Step 4: Synthesize by Goal
-
-Output shape is **driven by Step 0 goal**, not by frameworks applied. Pick exactly one of the four blocks below.
-
-**For problem-solving:** Applicable solutions (2–3 from content) → Application plan with timed action steps → Success metrics → Risk mitigations from Inversion.
-
-**For learning:** Core concepts (definition + example) → Mental models gained → Connections to prior knowledge → First Principles fundamental question → 3 verification questions (understanding / application / evaluation).
-
-**For writing reference:** Key arguments + evidence (with paragraph citations) → Quotable insights with context → Critical analysis (strengths for citing, limitations for balanced discussion) → Alternative perspectives from Mental Models → Gaps and counterfactuals.
-
-**For decision-making:** Options presented → Multi-model evaluation (economic + risk + systems lens) → Six Hats decision analysis → Scenario analysis (best / worst / most likely) → Synthesized recommendation.
-
-### Step 5: Knowledge Activation (always end here)
-
-Regardless of goal, close with three fixed blocks:
-
-```markdown
-## 🎯 Top 3 takeaways
-1. **[Insight]** — Why it matters: [...] · One action: [specific, time-bound]
-2. **[Insight]** — Why it matters: [...] · One action: [specific, time-bound]
-3. **[Insight]** — Why it matters: [...] · One action: [specific, time-bound]
-
-## 💡 Quick win — one tiny, specific action for the next 24 hours.
-
-## 🧭 Frameworks used
-✅ SCQA  ✅ 5W2H  ✅ Critical  ✅ Inversion
-□ Mental Models  □ First Principles  □ Systems  □ Six Hats
-```
-
-### Step 6: Validate
-
-1. Every claim is faithful to the source — no misrepresentation, facts distinguished from opinions.
-2. Frameworks applied **purposefully**, not force-fit — drop a framework that adds no insight rather than padding the output.
-3. Output ends with concrete, actionable steps — no analysis-without-application.
-4. Specific citations (paragraph numbers, quotes) where the source supports them.
-
-## Output format
-
-1. **Structural block (Step 2)** — type / thesis / structure tree / key concepts / SCQA / 5W2H gaps.
-2. **Framework blocks (Step 3)** — one fixed-shape block per framework the depth bought.
-3. **Goal-shaped synthesis (Step 4)** — problem-solving / learning / writing / decision-making.
-4. **Knowledge activation (Step 5)** — top 3 takeaways · quick win · frameworks-used checkboxes.
-
-## Gotcha
-
-- The model tends to **apply every framework** even at L1 — respect the depth budget; skip frameworks the user did not buy.
-- The model tends to **summarize** instead of analyze when the user pastes long text — go deep on 1–3 points, not shallow on all of them.
-- Inversion drifts into adversarial code review — this skill targets **decisions and arguments**, not diffs. Route diff stress-tests to `adversarial-review` / `judge-bug-hunter`.
-- Mental Models drifts into name-dropping — pick 3–5, apply each lens *concretely* to the article's claims, drop models that yield no new insight.
-- L4 cross-source comparison drifts into a literature review — keep it to 2–3 sources, focus on consensus / divergence / unique value.
-- Output without action steps is a failure mode — every Step-4 synthesis must end with timed, concrete actions tied to the user's goal.
-
-## Do NOT
-
-- Do NOT force-apply all frameworks at the user's chosen depth — drop ones that add no insight.
-- Do NOT copy text verbatim from the source — always reword for the user's understanding.
-- Do NOT use academic jargon without one-line definitions in the "key concepts" block.
-- Do NOT skip Step 5 — the takeaways + quick win are the load-bearing output, not optional decoration.
-- Do NOT route code reviews, diff stress-tests, or incident debugging through this skill.
-
-## Reference modules
-
-Project-local guidelines (full text adopted under the Reference-Guideline Sunset Policy):
-
-- [`scqa-framework`](../../../docs/guidelines/agent-infra/scqa-framework.md) — full 499-line authoritative-link adopt.
-- [`mental-models`](../../../docs/guidelines/agent-infra/mental-models.md) — pure adopt of Munger's multi-discipline toolkit.
-- [`inversion-thinking`](../../../docs/guidelines/agent-infra/inversion-thinking.md) — pre-mortem on decisions, distinct from `adversarial-review`.
-
-Upstream modules (loaded on demand from the SHA-pinned URL in `external_source`):
-
-- `5w2h_analysis.md` — completeness check (7 questions).
-- `critical_thinking.md` — argument quality / fallacy detection.
-- `first_principles.md` — fundamental-truth extraction.
-- `systems_thinking.md` — feedback loops + leverage points.
-- `six_hats.md` — White / Red / Black / Yellow / Green / Blue protocol.
-- `comparison_matrix.md` — cross-source synthesis (L4 only).

package/.agent-src/skills/defense-in-depth/SKILL.md

@@ -1,157 +0,0 @@
----
-model_tier: high
-name: defense-in-depth
-description: "Use when validation needs entry, business-logic, environment, and instrumentation guards so a bad value cannot reach the failure point — turns a local bug fix into a structural one."
-domain: quality
-workspaces:
-  - engineering
-packs:
-  - engineering-base
----
-
-# defense-in-depth
-
-Validate at every layer the value passes through. Fixing the bug at one layer is locally sufficient and globally fragile — the next refactor, code path, mock, or platform edge case will rediscover it. Four-layer validation makes the bug *structurally* impossible.
-
-## When to use
-
-- Bug fix where invalid data caused failure several frames deep.
-- New entry point that funnels external input into existing internals.
-- Refactor that adds a second caller to a previously single-caller routine.
-- Test setup that shortcuts production guards (mocks bypassing entry validation).
-
-Do NOT use when:
-
-- Pure formatting / style change — no data flow, no layers to defend.
-- Boundary validation alone is correct (e.g. immutable value object with constructor invariant) — route to [`laravel-validation`](../laravel-validation/SKILL.md).
-- The fix belongs at a single architectural seam — adding three more guards is over-engineering. Use the gate function below to stop early.
-
-## Procedure: Apply the four-layer pattern
-
-### Step 0: Analyze the data flow before adding guards
-
-1. Identify where the bad value originates (test fixture, request body, env var, config).
-2. List every function that receives the value before the failure point.
-3. Mark which functions are reachable from production paths and which only from tests.
-
-### Step 1: Layer 1 — Entry-point validation
-
-Reject obviously invalid input at the API / route / command boundary. In Laravel this is FormRequest rules; in pure PHP services it is the public method on the service.
-
-```php
-public function createProject(string $name, string $workingDirectory): Project
-{
-    if (trim($workingDirectory) === '') {
-        throw new InvalidArgumentException('workingDirectory cannot be empty');
-    }
-    if (! is_dir($workingDirectory)) {
-        throw new InvalidArgumentException("workingDirectory does not exist: {$workingDirectory}");
-    }
-    if (! is_writable($workingDirectory)) {
-        throw new InvalidArgumentException("workingDirectory is not writable: {$workingDirectory}");
-    }
-    // ... proceed
-}
-```
-
-### Step 2: Layer 2 — Business-logic validation
-
-Verify the value still makes sense for the operation that consumes it. Different code paths can reach the same internal — re-check rather than trust the caller.
-
-```php
-public function initializeWorkspace(string $projectDir, string $sessionId): Workspace
-{
-    if ($projectDir === '') {
-        throw new RuntimeException('projectDir required for workspace initialization');
-    }
-    // ... proceed
-}
-```
-
-### Step 3: Layer 3 — Environment guards
-
-Refuse dangerous operations in the wrong context — most often: running a destructive command outside a test temp dir while the test suite is active.
-
-```php
-public function gitInit(string $directory): void
-{
-    if (app()->environment('testing')) {
-        $normalized = realpath($directory) ?: $directory;
-        $tmp = realpath(sys_get_temp_dir());
-
-        if ($tmp === false || ! str_starts_with($normalized, $tmp)) {
-            throw new RuntimeException("refusing git init outside tmp during tests: {$directory}");
-        }
-    }
-    // ... proceed
-}
-```
-
-### Step 4: Layer 4 — Debug instrumentation
-
-Capture context for forensics so the next failure surfaces *why*, not just *that*. Log only when the call is about to hit an irreversible side effect.
-
-```php
-public function gitInit(string $directory): void
-{
-    Log::debug('about to git init', [
-        'directory' => $directory,
-        'cwd' => getcwd(),
-        'trace' => (new Exception)->getTraceAsString(),
-    ]);
-    // ... proceed
-}
-```
-
-### Step 5: Verify each layer in isolation
-
-Try to bypass Layer 1 (call the internal directly) and confirm Layer 2 catches it. Mock the production guard and confirm Layer 3 still refuses. The pattern only earns its name when each layer is independently provable.
-
-## Gate function — when to stop adding layers
-
-```
-BEFORE adding the 5th guard:
-  STOP — re-check the data flow.
-
-  IF the value crosses ≤ 1 module boundary:
-    Use a single boundary check + a value-object invariant. Two layers max.
-
-  IF every layer would re-implement the same predicate:
-    Hoist the predicate into a value object / type and inject. One check is enough.
-
-  Layers are for distinct concerns: input shape vs operation invariant
-  vs environment risk vs forensic visibility. Same concern repeated is duplication, not depth.
-```
-
-## Output format
-
-1. The four guards (or a documented subset, with the gate-function justification).
-2. Tests that bypass each layer to prove the next layer catches the failure.
-3. One-line note on the data flow that motivated the layering.
-
-## Gotcha
-
-- Layers 1 and 2 must reject with **distinct** errors — same error string makes the second guard look like a duplicate.
-- Layer 3 environment checks should fail closed: unknown environment treated as production.
-- Layer 4 instrumentation must not change behavior — no early returns, no mutated state.
-- Test bypasses (in-process mocks) often skip Layer 1 — Layer 2 catches them; do not weaken Layer 2 to silence the test.
-
-## Do NOT
-
-- Do NOT replicate Layer 1 inside private methods that only Layer 1 can reach.
-- Do NOT log secrets in Layer 4 — sanitize before `Log::debug`.
-- Do NOT use Layer 3 to gate business logic — environments change, business rules do not.
-- Do NOT add a layer without a failing test that proves the layer was needed.
-
-## Auto-trigger keywords
-
-- defense in depth
-- multiple validation layers
-- bug deep in execution
-- structurally impossible
-
-## Provenance
-
-- Adopted from: `Microck/ordinary-claude-skills@8f5c83174f7aa683b4ddc7433150471983b93131:skills_all/defense-in-depth/SKILL.md` (MIT, © 2025 Microck).
-- Provenance registry: `agents/settings/contexts/skills-provenance.yml` (entry: `defense-in-depth`).
-- Iron-Law floor: `non-destructive-by-default`, `verify-before-complete`, `skill-quality`.

package/.agent-src/skills/design-review/SKILL.md

@@ -1,233 +0,0 @@
----
-model_tier: high
-name: design-review
-description: "Use when the user says "review the design", "check the UI", or wants a comprehensive UI/UX review. Uses a 7-phase methodology covering interaction, responsiveness, accessibility, and more."
-domain: quality
-workspaces:
-  - engineering
-packs:
-  - engineering-base
----
-
-# design-review
-
-## When to use
-
-Use this skill when:
-- Reviewing pull requests with UI changes
-- Auditing frontend components for design quality
-- Verifying responsive design across viewports
-- Checking accessibility compliance (WCAG 2.1 AA)
-- Testing interaction flows and user experience
-- Conducting visual QA on new features
-
-Do NOT use when:
-- Creating new designs (use `fe-design` skill instead)
-- Reviewing backend/API code only
-- Quick syntax checks (use linters)
-
-## Prerequisites
-
-One of the following browser automation tools:
-- **Playwright MCP** (recommended) — browser automation, screenshots, viewport testing
-- **Chrome DevTools** — screenshot capture, performance analysis
-
-A **live preview URL** is required for testing.
-
-## Procedure: Design review
-
-### Phase 0: Preparation
-
-- Read PR description and git diff.
-- Identify changed components and affected pages.
-- Navigate to preview URL.
-- Take baseline screenshot.
-
-### Phase 1: Interaction
-
-- Test user flows end-to-end.
-- Verify hover, focus, active, and disabled states.
-- Test keyboard navigation (Tab, Enter, Escape, Arrow keys).
-- Check loading states and transitions.
-- Verify form submission and error recovery.
-
-### Phase 2: Responsiveness
-
-Test at three viewports:
-
-| Viewport | Width | Device |
-|---|---|---|
-| Desktop | 1440px | Standard monitor |
-| Tablet | 768px | iPad |
-| Mobile | 375px | iPhone SE |
-
-- Take screenshots at each viewport.
-- Check layout shifts, overflow, and content reflow.
-- Verify touch targets are at least 44x44px on mobile.
-
-### Phase 3: Visual Polish
-
-- **Typography:** Font sizes, weights, line heights, hierarchy.
-- **Spacing:** Consistent margins, padding, alignment.
-- **Colors:** Contrast ratios, brand consistency, dark mode.
-- **Alignment:** Grid alignment, visual balance.
-- **Icons:** Consistent size, style, and spacing.
-
-### Phase 4: Accessibility (WCAG 2.1 AA)
-
-| Criterion | Check |
-|---|---|
-| **1.1.1** | All images have meaningful alt text |
-| **1.3.1** | Semantic HTML (headings, landmarks, lists) |
-| **1.4.3** | Color contrast ≥ 4.5:1 (text), ≥ 3:1 (large text) |
-| **1.4.11** | Non-text contrast ≥ 3:1 (UI components, borders) |
-| **2.1.1** | All functionality available via keyboard |
-| **2.4.3** | Focus order is logical and predictable |
-| **2.4.7** | Focus indicator is visible |
-| **3.3.1** | Error messages identify the field and describe the error |
-| **3.3.2** | Labels and instructions for form inputs |
-| **4.1.2** | ARIA roles, states, and properties are correct |
-
-### Phase 5: Robustness
-
-- **Empty states:** What happens with no data?
-- **Error states:** What happens when things fail?
-- **Content overflow:** Long text, many items, large numbers.
-- **Loading states:** Skeleton screens, spinners, progressive loading.
-- **Boundary values:** Min/max inputs, special characters.
-
-### Phase 6: Code Health
-
-- Component reuse — are existing components used where possible?
-- Design tokens — are colors, spacing, fonts from the design system?
-- CSS patterns — utility classes vs. custom CSS, consistency.
-- Accessibility in code — semantic HTML, ARIA attributes.
-
-### Phase 7: Content & Console
-
-- Grammar and spelling in UI text.
-- Consistent terminology and tone.
-- No placeholder text left in production.
-- Check browser console for JavaScript errors or warnings.
-
-## Communication principles
-
-### Problems over prescriptions
-
-Describe **what's wrong and why it matters**, not how to fix it.
-
-```
-❌ "Change margin to 16px"
-✅ "Spacing feels inconsistent with adjacent elements, creating visual clutter near the CTA."
-```
-
-### Triage matrix
-
-Every issue gets a severity:
-
-| Severity | Meaning | Action |
-|---|---|---|
-| **Blocker** | Must fix before merge | Blocks PR |
-| **High** | Should fix before merge | Strong recommendation |
-| **Medium** | Consider for follow-up | Suggestion |
-| **Nitpick** | Optional polish | Prefix with "Nit:" |
-
-### Evidence-based
-
-Screenshots required for all visual issues. Reference specific viewport and state.
-
-### Start positive
-
-Acknowledge what works well before listing issues.
-
-## Report structure
-
-```markdown
-## Design Review Summary
-[Positive opening + overall assessment]
-
-### 🚫 Blockers
-[Critical issues — must fix]
-
-### ⚠️ High Priority
-[Significant issues — should fix]
-
-### 💡 Suggestions
-[Improvements for follow-up]
-
-### ✨ Nitpicks
-[Minor aesthetic details]
-
-### Testing Evidence
-[Screenshots: Desktop, Tablet, Mobile]
-
-### Next Steps
-1. [Fix blockers]
-2. [Address high-priority]
-
-**Overall: [Ready to merge | Needs revisions]**
-```
-
-
-## Visual QA with browser automation
-
-When Playwright MCP or browser tools are available, use them for automated visual verification:
-
-### Before/After comparison
-
-1. **Capture baseline** — screenshot before changes at all 3 viewports.
-2. **Apply changes** — deploy or hot-reload.
-3. **Capture after** — screenshot at the same viewports and states.
-4. **Compare** — visually diff the screenshots, flag regressions.
-
-### State-based verification
-
-Don't just screenshot the default state. Capture:
-
-| State | How to trigger |
-|---|---|
-| Empty | Remove data, check empty state UI |
-| Loading | Throttle network, capture skeleton/spinner |
-| Error | Force an error response, check error UI |
-| Overflow | Add very long text, many items |
-| Interactive | Hover, focus, open dropdowns |
-
-### Mockup-to-code verification
-
-When implementing from a design mockup or screenshot:
-
-1. **Open the mockup** — use the provided image/screenshot.
-2. **Implement** — build the UI component.
-3. **Side-by-side** — compare mockup vs. implementation at the same viewport.
-4. **Flag deviations** — spacing, colors, typography, alignment differences.
-
-This is especially useful when the user provides a screenshot or Figma export as a reference.
-
-## Output format
-
-1. Design review report following the Report structure section
-2. Severity-rated findings (blocker, suggestion, nit)
-3. Accessibility and responsive compliance summary
-
-## Auto-trigger keywords
-
-- design review
-- UI review
-- UX audit
-- accessibility
-- WCAG
-- responsive
-
-## Gotcha
-
-- Don't review design without understanding the user's constraints (time, resources, scope).
-- The model tends to suggest accessibility improvements that break the existing design system.
-- "Best practice" is not always the right choice — sometimes "good enough" ships faster.
-
-## Do NOT
-
-- Do NOT skip accessibility testing — it's not optional.
-- Do NOT report issues without evidence (screenshots, specific elements).
-- Do NOT prescribe solutions — describe problems and impact.
-- Do NOT block PRs on nitpicks.
-- Do NOT test only at desktop resolution.