@robosoft/skillhub-cli 0.1.1 → 0.3.2

package/skillhub-registry/skills/react/SKILL.md

@@ -0,0 +1,224 @@
+---
+name: react
+description: Comprehensive React development standards including component structure, hooks usage, state management, rendering patterns, event handling, and React-specific anti-patterns. Use this skill whenever the user works with React, JSX, TSX, React components, hooks (useState, useEffect, useMemo, useCallback, custom hooks), Next.js, Remix, Vite+React, or any React-related library. Apply when reviewing React code, building React components, debugging React rendering issues, refactoring React applications, writing React tests, or discussing React architecture decisions. Trigger even when React is implied by file extensions (.jsx, .tsx) or component-style code, even if the user does not explicitly mention "React".
+---
+
+# React Frontend Skill
+
+This skill applies the org's React standards. It loads when the task involves React, JSX/TSX, hooks, or React-adjacent libraries.
+
+These rules layer on top of `rules/general.md`, `rules/code-standards.md`, and `rules/anti-patterns.md` — which still apply. This file adds React-specific guidance.
+
+---
+
+## Components
+
+- Use **functional components only**. No class components in new code.
+- Components must do **one thing**. If a component file exceeds ~150 lines or has more than ~5 hooks, split it.
+- **Props are the contract.** Type them explicitly. No untyped `any` props.
+- **Props should be flat where possible** — avoid deeply nested object props that obscure the API.
+- **Default exports only for the primary component** of a file. Use named exports for helpers, sub-components, and types.
+
+## Hooks
+
+- **`useState`** — local component state only. For shared state, lift to parent or use a state library.
+- **`useEffect`** — side effects only (fetching, subscriptions, manual DOM). Never use `useEffect` to derive state from props/state — compute it directly during render.
+- **`useMemo` / `useCallback`** — only when (a) the value is passed to a memoized child, (b) it's a dependency of another hook, or (c) profiling shows a measurable gain. **Never wrap primitives.**
+- **Custom hooks** — extract reusable logic when used in 3+ places. Name with `use` prefix.
+- **Dependency arrays must be exhaustive.** No suppressing the linter unless documented why.
+
+## State Management
+
+- **Default to local state.** Lift only when needed by a sibling.
+- **Context** for genuinely global app state (theme, auth, locale) — not a substitute for prop drilling that's only 2-3 levels.
+- **External state library** (Zustand, Redux Toolkit, Jotai) when state is shared across many distant components, or when state changes need to be observed outside the React tree.
+- **Server state** belongs in a server-state library (TanStack Query, SWR), not in `useState`.
+
+## Rendering
+
+- **Conditional rendering** uses simple expressions:
+  - `condition && <Component />` for show/hide
+  - `condition ? <A /> : <B />` for either/or
+  - Extract to a variable or early return for anything more complex
+- **Lists must use stable keys.** Never use array index as key when the list can reorder, filter, or have items inserted/removed.
+- **No inline complex logic in JSX.** Extract to a named variable or helper function above the return.
+
+```jsx
+// ❌ Bad — complex inline logic
+return (
+  <div>
+    {users.filter(u => u.active && u.role === 'admin' && !u.banned)
+      .sort((a, b) => b.lastLogin - a.lastLogin)
+      .slice(0, 5)
+      .map(u => <UserCard key={u.id} user={u} />)}
+  </div>
+);
+
+// ✅ Good — named, testable, readable
+const topActiveAdmins = getTopActiveAdmins(users, 5);
+
+return (
+  <div>
+    {topActiveAdmins.map(u => <UserCard key={u.id} user={u} />)}
+  </div>
+);
+```
+
+## Events
+
+- **Named handlers, not inline functions** for non-trivial logic.
+- **Handler naming convention:** `handle<Event>` for the function, `on<Event>` for the prop.
+  - `handleSubmit` is the function inside the component
+  - `onSubmit` is what the prop is called
+
+```jsx
+// ✅ Good
+function ContactForm({ onSubmit }) {
+  const handleSubmit = (e) => {
+    e.preventDefault();
+    onSubmit(formData);
+  };
+
+  return <form onSubmit={handleSubmit}>...</form>;
+}
+```
+
+## Data Flow
+
+- **One-way data flow:** parent → child via props.
+- **Children communicate up via callbacks** passed as props.
+- **No prop mutation.** Treat props as read-only.
+- **Avoid prop drilling beyond 3 levels.** Lift state, use context, or restructure components.
+
+## Service Layer Separation
+
+- **Components should not call APIs directly.** The pattern is: services → hooks → components.
+  - **Services** own the network call (axios, fetch, GraphQL client). One file per domain: `userService.ts`, `orderService.ts`, etc.
+  - **Hooks** wrap services with state, caching, and side-effect concerns (`useUser`, `useOrders`). This is where TanStack Query or SWR typically lives.
+  - **Components** consume hooks. They read state and render UI. They should not be aware of HTTP details.
+
+```ts
+// userService.ts
+export const fetchUser = (id: string) => fetch(`/api/users/${id}`).then(r => r.json());
+
+// useUser.ts
+export const useUser = (id: string) => {
+  const { data, isLoading, error } = useQuery(['user', id], () => fetchUser(id));
+  return { user: data, isLoading, error };
+};
+
+// UserProfile.tsx
+export function UserProfile({ userId }: Props) {
+  const { user, isLoading } = useUser(userId);
+  return isLoading ? <Spinner /> : <div>{user.name}</div>;
+}
+```
+
+> **Why:** Keeping API details out of components makes them easier to test (no mocking fetch), easier to swap (REST → GraphQL doesn't ripple into UI), and easier to reuse (the same hook works across multiple components).
+
+## Forms
+
+- **Controlled components** are the default for forms with validation, conditional fields, or external state binding.
+- **Uncontrolled with refs** is acceptable only for trivial isolated inputs (a search box, a single toggle).
+- **Every form needs three handled states:** idle, submitting, error/success.
+- **Validation:** validate on the boundary that matters (on blur for fields, on submit for the form). Show errors near the field they apply to. Disable submit while submitting.
+- **Use a form library** (React Hook Form, Formik) for non-trivial forms — don't reinvent state, validation, and error handling.
+
+```jsx
+// Controlled form with state management
+function LoginForm() {
+  const [email, setEmail] = useState('');
+  const [isSubmitting, setIsSubmitting] = useState(false);
+  const [error, setError] = useState(null);
+
+  const handleSubmit = async (e) => {
+    e.preventDefault();
+    setIsSubmitting(true);
+    setError(null);
+    try {
+      await login(email);
+    } catch (err) {
+      setError(err.message);
+    } finally {
+      setIsSubmitting(false);
+    }
+  };
+
+  return (
+    <form onSubmit={handleSubmit}>
+      <input value={email} onChange={(e) => setEmail(e.target.value)} />
+      {error && <span>{error}</span>}
+      <button disabled={isSubmitting}>{isSubmitting ? 'Logging in...' : 'Log In'}</button>
+    </form>
+  );
+}
+```
+
+> **Why:** Forms without these states create silent failures (user clicks submit, nothing happens, no feedback) — one of the most common React UX bugs.
+
+## Accessibility
+
+- **Semantic HTML by default** — use `<button>`, `<a>`, `<nav>`, `<main>`, `<form>` for what they're for.
+- **Never use `<div>` or `<span>` as a clickable element.** If it's clickable, it's a `<button>` (or `<a>` if it navigates).
+- **Every `<img>` needs an `alt` attribute.** Decorative images use `alt=""`.
+- **Every form input needs a `<label>`** (visible or `aria-label`).
+- **Keyboard accessibility is not optional.** Users must be able to tab through, activate, and escape every interactive element.
+- **Avoid `tabindex` values other than `0` and `-1`** (positive values break tab order).
+- **Color is not the only signal.** Never use color alone to convey meaning (red text for errors needs an icon or label too).
+
+> **Why:** Accessibility is not a special case — it's how the web is supposed to work. Semantic HTML gets you most of the way there for free, while custom divs require recreating browser behavior poorly.
+
+## Responsive Design
+
+- **Mobile-first by default.** Design and write CSS for the smallest screen first, then add styles for larger breakpoints.
+- **Use relative units:** `rem`, `em`, `%`, `vw/vh` — avoid pixel widths for layout.
+- **Avoid fixed widths on layout containers.** Use `max-width` instead so content can shrink.
+- **Layouts use flexbox or CSS grid;** absolute positioning only for overlays and edge cases.
+- **Test for:** ~320px (small phone), ~768px (tablet), ~1024px+ (desktop).
+- **Horizontal overflow on mobile is a bug,** not an accepted state.
+
+> **Why:** Most users access the web on mobile or constrained viewports. Desktop-only design is no longer the default — it's a regression.
+
+## React-Specific Anti-Patterns
+
+These are React-specific additions to `rules/anti-patterns.md`:
+
+### Overuse of `useEffect`
+
+`useEffect` should be a last resort, not a first instinct. Common misuses:
+
+- **Deriving state from props** — compute it during render instead.
+- **Resetting state on prop change** — use a `key` on the component or compute during render.
+- **Chaining state updates** — usually means state should be derived, not stored.
+- **Fetching on mount when a server-state library would do it better** — use TanStack Query / SWR.
+
+### Premature memoization
+
+Wrapping every function in `useCallback` and every value in `useMemo` adds cost without benefit. Memoize only when there's a measured reason. Profile first.
+
+### Massive `useEffect` with many dependencies
+
+If a `useEffect` has 5+ dependencies, it's doing too much. Split it into multiple effects with focused responsibilities.
+
+### Inline object/array props that defeat memoization
+
+```jsx
+// ❌ Bad — new object every render breaks <MemoChild>'s memoization
+<MemoChild config={{ option: true }} />
+
+// ✅ Good
+const config = useMemo(() => ({ option: true }), []);
+<MemoChild config={config} />
+```
+
+### `key={index}` in dynamic lists
+
+Causes wrong components to update when items are reordered, inserted, or filtered. Use a stable, unique field from the data (`id`, `slug`, etc.).
+
+---
+
+## When You're Unsure
+
+- For React 18+ features (Suspense, transitions, server components): confirm the project's React version before assuming.
+- For Next.js / Remix specifics: check whether App Router or Pages Router is in use before suggesting routing patterns.
+- For state libraries: confirm which one the project uses (Zustand vs Redux vs Jotai vs none) before suggesting code.

package/skillhub-registry/skills/refactor/SKILL.md

@@ -0,0 +1,149 @@
+---
+name: refactor
+description: Restructure existing code without changing behavior. Use this skill whenever the user invokes /refactor, asks to "refactor", "restructure", "clean up", "tidy up", "simplify", "improve readability", "extract", "consolidate", "deduplicate", "rename", "reorganize", or "modernize" code. Apply when the user wants better internal structure but the same external behavior — same inputs, same outputs, same side effects, same API. Do NOT trigger when the user wants new functionality (use /build) or wants critique without changes (use /review). Do NOT trigger when the user asks to fix a bug or change behavior — that's a behavior change, not a refactor.
+---
+
+# Refactor Skill
+
+This skill restructures existing code while preserving its behavior. It loads when the user wants improvements to *how* code is written, not *what* it does.
+
+These rules layer on top of `rules/general.md`, `rules/code-standards.md`, and `rules/anti-patterns.md`.
+
+---
+
+## The Iron Rule of Refactoring
+
+**Behavior must not change.** Same inputs produce same outputs. Same side effects. Same errors. Same observable performance characteristics (within reason).
+
+If the user asks you to "refactor and also fix this bug" — that's two tasks. Do them as separate steps with separate commits. Don't mix behavior changes into a refactor.
+
+This rule is non-negotiable. A refactor that "accidentally" changes behavior is a regression, not a refactor.
+
+---
+
+## What Refactoring Is
+
+Refactoring improves **internal structure** without changing **external behavior**:
+
+- ✅ Renaming variables for clarity
+- ✅ Extracting a function from inline code
+- ✅ Inlining a function used only once
+- ✅ Splitting a god function into smaller ones
+- ✅ Replacing nested conditionals with early returns
+- ✅ Extracting magic values to named constants
+- ✅ Removing dead code
+- ✅ Deduplicating logic (3+ copies)
+- ✅ Reordering for readability
+- ✅ Replacing manual loops with built-in methods (when equivalent)
+
+## What Refactoring Is NOT
+
+These are *not* refactors, even if they look similar:
+
+- ❌ Fixing a bug (behavior change)
+- ❌ Adding a feature (behavior change)
+- ❌ Changing an API signature (interface change — affects callers)
+- ❌ "Improving" performance via different algorithms (behavior may differ at edge cases)
+- ❌ Updating a dependency version (could change behavior subtly)
+- ❌ Changing error messages or types (callers may depend on these)
+- ❌ Modifying logging or telemetry (observable change)
+
+If the user asks for any of these alongside a refactor, **separate them**:
+
+- Phase 1: Pure refactor (preserves behavior)
+- Phase 2: Behavior change (separate diff, separate commit)
+
+## The Refactor Workflow
+
+### Step 1: Understand the Existing Behavior
+
+Before changing anything, understand what the code currently does:
+
+- What are its inputs?
+- What does it return?
+- What side effects does it have (network, DB, filesystem, mutations)?
+- What errors can it throw?
+- Are there existing tests? Read them — they document expected behavior.
+
+If the existing behavior is unclear, **ask before refactoring**. You cannot preserve what you don't understand.
+
+### Step 2: Identify the Problem
+
+State *specifically* what's wrong with the current code. Not vague — concrete:
+
+- ✅ "This function is 80 lines and has 5 distinct responsibilities"
+- ✅ "These three blocks duplicate the same validation logic"
+- ✅ "This nested ternary has 4 levels and is unreadable"
+- ❌ "This code could be cleaner"
+- ❌ "This needs improvement"
+
+If you can't name the problem specifically, the code probably doesn't need refactoring.
+
+### Step 3: Plan the Refactor
+
+State the approach in 1-3 bullets:
+
+- What you're changing
+- What you're preserving (the contract)
+- How a future reader will benefit
+
+For non-trivial refactors, also note: **what could go wrong?**
+
+### Step 4: Make ONE Change Per Step
+
+Refactor in small, mechanical steps. Examples:
+
+- Step A: Extract this block into a named function (no behavior change)
+- Step B: Rename `x` to `customerEmail` everywhere (no behavior change)
+- Step C: Replace nested `if` with early returns (no behavior change)
+
+Each step should be reviewable in isolation. Avoid sweeping changes that touch many things at once.
+
+### Step 5: Verify Behavior Preserved
+
+After each step, confirm behavior is unchanged:
+
+- ✅ **Tests still pass?** Run them.
+- ✅ **No tests exist?** Mention this — it's a risk for refactoring.
+- ✅ **Manually trace a few inputs through old vs. new code?** Match.
+
+If you can't verify behavior is preserved, **say so explicitly** and let the user decide whether to proceed.
+
+## Risk-Adjusted Behavior
+
+Match the rigor to the risk:
+
+| Risk level | Behavior |
+|---|---|
+| Pure local refactor (rename, reorder, extract) | Proceed; mention briefly |
+| Refactor crossing function boundaries | Verify against tests; flag any test gaps |
+| Refactor changing module interfaces | **Stop** — this is an API change, not a refactor |
+| Refactor in untested code | Flag the lack of tests; offer to add them first |
+| Refactor in security-sensitive code (auth, payments) | Highest care; recommend pair review |
+
+## Output Format
+
+For refactor tasks, structure the response as:
+
+What's changing: [1-2 sentences]
+What's preserved: [the contract — inputs, outputs, side effects][Optional: list of refactoring steps if multi-step][The refactored code][Optional: any behavior preservation concerns, test gaps, or follow-ups]
+
+Don't pad with explanation of what refactoring is. The user knows.
+
+## When to Push Back
+
+If the user asks for a refactor that:
+
+- **Has no tests covering the existing behavior** → Flag it. Suggest writing characterization tests first.
+- **Crosses into bug-fix territory** → Separate the concerns. Refactor first, fix second.
+- **Changes an API used by other code** → That's not a refactor; it's an interface migration.
+- **Is actually a rewrite, not a refactor** → Say so. A rewrite needs different planning.
+
+Don't silently expand scope. The user asked for a refactor — give them a refactor.
+
+## What This Skill Does NOT Cover
+
+- **New code** → use `/build`
+- **Critique without changes** → use `/review`
+- **Bug fixes** → those are behavior changes; separate task
+- **Architecture-level redesigns** → those need design discussion, not skill-driven mechanical refactoring

package/skillhub-registry/skills/review/SKILL.md

@@ -0,0 +1,199 @@
+---
+name: review
+description: Critique existing code without changing it — identify bugs, issues, smells, anti-patterns, and improvement opportunities. Use this skill whenever the user invokes /review, asks to "review", "critique", "audit", "check", "look at", "evaluate", "assess", "give feedback on", or "what do you think of" their code. Apply when the user shares code and wants analysis rather than modification — they want to know what's wrong, what could be better, and what's good. Do NOT trigger when the user wants the code modified (use /refactor or /build) or wants new code written. Trigger when the user asks "is this code good?", "any issues with this?", "code review please", "PR review", or shares a diff for feedback.
+---
+
+# Review Skill
+
+This skill critiques existing code without modifying it. It loads when the user wants analysis, not changes.
+
+These rules layer on top of `rules/general.md`, `rules/code-standards.md`, and `rules/anti-patterns.md`.
+
+If `/strict` mode is also active, apply maximum rigor — flag every violation, however minor.
+
+---
+
+## What Review Is
+
+Review produces **prioritized feedback** on existing code:
+
+- ✅ Identify bugs, race conditions, logic errors
+- ✅ Identify security vulnerabilities
+- ✅ Identify violations of `rules/` and `anti-patterns.md`
+- ✅ Identify maintainability concerns (clarity, naming, structure)
+- ✅ Identify missing tests / edge cases
+- ✅ Acknowledge what's well done
+
+## What Review Is NOT
+
+- ❌ **Rewriting the code.** Only suggest changes; don't make them. (User can ask for `/refactor` after.)
+- ❌ **Style nitpicking** that doesn't affect correctness or maintainability — unless `/strict` is on.
+- ❌ **Personal preference disguised as a rule.** If a rule exists, cite it. If not, don't pretend.
+- ❌ **Approval theater.** "Looks great!" responses aren't reviews. If there's nothing to flag, say so honestly — but actually look first.
+
+---
+
+## The Review Workflow
+
+### Step 1: Understand the Code's Purpose
+
+Before critiquing, understand what the code is *trying* to do:
+
+- What's the input/output contract?
+- What context is it operating in (production endpoint? internal script? test helper?)
+- What does the surrounding codebase do?
+
+If purpose is unclear, ask before reviewing. You can't fairly critique code whose intent you don't understand.
+
+### Step 2: Run the Review Checklist
+
+Walk through these categories systematically. Don't skip any.
+
+#### Correctness
+- Are there logic errors?
+- Are edge cases handled (empty, null, max/min, boundary)?
+- Are error paths handled or silently swallowed?
+- Are there race conditions or concurrency bugs?
+- Off-by-one errors?
+- Is the happy path actually correct?
+
+#### Security
+- Is user input validated at the boundary?
+- Are there injection risks (SQL, XSS, command injection, path traversal)?
+- Are secrets exposed (in logs, error messages, responses)?
+- Are auth/authorization checks present where needed?
+- Are timing attacks possible (e.g., string comparison on tokens)?
+
+#### Performance
+- Any obvious N+1 queries?
+- Any unbounded loops or recursion?
+- Any expensive operations in hot paths?
+- Any memory leaks (event listeners, subscriptions, timers not cleaned up)?
+- (Note: don't critique performance speculatively without evidence — see `skills/performance`)
+
+#### Standards Compliance
+- Does it violate any rule in `rules/code-standards.md`? (function size, nesting, naming, magic values, error handling)
+- Does it match any anti-pattern in `rules/anti-patterns.md`?
+- If a domain skill applies (`react`, `testing`, etc.), does it follow those conventions?
+
+#### Maintainability
+- Will another developer understand this in 6 months?
+- Are names accurate and meaningful?
+- Is the code doing one thing or many?
+- Is there comment debt (out-of-date comments, commented-out code)?
+- Is the file/module organization clear?
+
+#### Tests
+- Is the new code tested?
+- Do tests cover edge cases or just happy paths?
+- Are tests deterministic?
+- Any flaky test smells (timing dependencies, shared state, real network calls)?
+
+### Step 3: Categorize Findings
+
+Sort every finding into one of three buckets:
+
+- **Critical** — must fix before merge. Bugs, security issues, broken behavior, missing critical edge cases.
+- **Improvement** — should fix. Standards violations, maintainability problems, missing tests for non-trivial logic.
+- **Minor** — nice to have. Style nudges, alternative approaches, very small clarity wins.
+
+If something doesn't fit a bucket clearly, it's probably a Minor.
+
+### Step 4: Acknowledge What's Good
+
+Genuinely look for things done well. This is not flattery — it's signal:
+
+- Tells the author what to keep doing
+- Calibrates the reviewer (a review with only criticism is suspicious)
+- Builds trust that the criticism is fair
+
+If the code is genuinely poor throughout, say so honestly — but in measured terms.
+
+---
+
+## Output Format
+
+Review responses always use this structure:
+
+Summary: [1-2 sentence overall take]
+Critical Issues
+[Numbered list. Each item: file:line reference, what's wrong, why it matters, suggested direction.]
+[If none: "None found."]
+Improvements
+[Numbered list. Same format.]
+[If none: "None."]
+Minor Suggestions
+[Numbered list. Same format.]
+[If none: "None."]
+What's Good
+[2-4 specific things done well. Be concrete — "uses early returns to flatten control flow" beats "good code style".]
+
+Each finding includes:
+- **Where** — file path and line number if available
+- **What** — the specific issue
+- **Why** — why it matters (cite a rule when relevant: "violates `rules/code-standards.md` magic values")
+- **How** — the direction to fix (don't write the fix; describe it)
+
+## Severity Discipline
+
+Don't inflate severity. The categories must mean something:
+
+- A magic number is **not** Critical.
+- A missing edge case **is** Critical if the case can occur in production.
+- A naming nit is **Minor**, not Improvement.
+- An unhandled error path **is** Critical.
+- A long function with otherwise correct logic is Improvement, not Critical.
+
+If everything is Critical, nothing is. Reserve the label for things that genuinely block merge.
+
+## When to Ask Before Reviewing
+
+Ask before reviewing when:
+
+- The code's purpose is unclear
+- You can't see the surrounding context (the diff is partial, the file is partial)
+- The user asks "what do you think?" about something where the answer depends on intent
+
+Don't ask when:
+
+- The code is self-explanatory
+- The user asked for review on a self-contained piece
+
+## When `/strict` Is Active
+
+If `/strict` mode is also loaded:
+
+- Lower the threshold for Critical (any bug-risk pattern is Critical)
+- Lower the threshold for Improvement (any standards deviation is Improvement)
+- Be pedantic about anti-patterns
+- Don't accept "this works" as good enough — flag fragility
+
+Without `/strict`:
+
+- Apply rules pragmatically
+- Don't critique stylistic choices that don't affect correctness or maintainability
+- Treat code review as collaborative, not adversarial
+
+## When You're Uncertain
+
+- **Don't fabricate issues to seem thorough.** "Looks fine to me" is a valid review for code that's fine.
+- **Don't pretend to know things you don't.** If you can't tell whether `await` is needed without seeing the calling code, say so.
+- **Cite rules, not opinions.** If you call out a violation, name the rule. If you have a stylistic preference, label it as such.
+
+## What This Skill Does NOT Cover
+
+- **Modifying the code** → use `/refactor`
+- **Writing new code** → use `/build`
+- **Architecture review at a system level** → review covers code; system design needs discussion
+
+---
+
+## Honest Calibration
+
+A good review is one the author would actually act on. Calibrate accordingly:
+
+- Too soft → issues slip through, the review adds no value
+- Too harsh → the author defends instead of improving, the review damages trust
+- Too long → the author skims, the important findings get lost
+
+Aim for: **fair, specific, prioritized, actionable.** Cite the rule. Note the line. Suggest the direction. Move on.

package/skillhub-registry/skills/strict/SKILL.md

@@ -0,0 +1,74 @@
+---
+name: strict
+description: Activates Strict Mode for production-ready, high-rigor code review and authoring. Use this skill whenever the user invokes /strict, says "strict mode", "production-ready", "robust", "harden this", "no shortcuts", "review thoroughly", "be picky", "be critical", "battle-tested", "enterprise-grade", or otherwise signals they want maximum rigor. Apply when the user is preparing code for production, security review, audit, or critical paths. Do NOT trigger when the user wants speed, prototypes, or quick iterations — see /fast for that.
+---
+
+# Strict Mode
+
+This skill switches Claude into maximum-rigor mode. All `rules/` apply with full strength, and the bar for "good enough" rises significantly.
+
+This is the right mode for production code, security-sensitive paths, and code that will outlive the current sprint.
+
+---
+
+## What Strict Mode Demands
+
+### Code Quality
+- 🔒 **Every rule in `rules/code-standards.md` enforced strictly.** No exceptions without explicit reasoning.
+- 🔒 **Every anti-pattern in `rules/anti-patterns.md` flagged.** Even minor instances.
+- 🔒 **No magic values.** Every constant named.
+- 🔒 **Every function < 40 lines.** No "but this one needs to be longer."
+- 🔒 **Nesting < 3 levels.** No exceptions.
+
+### Edge Cases
+- 🔒 **Enumerate edge cases before writing code.** Empty / null / max / min / concurrent / boundary / invalid type.
+- 🔒 **Each edge case must have a test or an explicit comment justifying why it's not tested.**
+- 🔒 **Failure paths get equal weight to happy paths.**
+
+### Errors
+- 🔒 **No silent failures.** Every catch logs, transforms, retries, or propagates.
+- 🔒 **Every error carries enough context to debug from logs alone.**
+- 🔒 **Every external call has a timeout.**
+- 🔒 **Every async operation handles cancellation.**
+
+### Security
+- 🔒 **Validate all inputs at boundaries.** Trust nothing from the user, the network, or the database.
+- 🔒 **No secrets in code.** No tokens, passwords, API keys — even in tests.
+- 🔒 **Output encoding** for any user-controlled string rendered to a client.
+- 🔒 **Authorization checks** on every protected operation, not just at the route level.
+
+### Tests
+- 🔒 **New code must come with tests.** No "I'll add tests later."
+- 🔒 **Tests cover edge cases, not just happy paths.**
+- 🔒 **No flaky tests merge.** Determinism enforced.
+
+## Behavior
+
+- **Be critical.** Call out every violation, even if it's not in the user's request.
+- **Don't accept mediocre patterns.** If something can be cleaner, say so.
+- **Prefer robust over clever.** Boring code that handles edge cases beats clever code that doesn't.
+- **Slow down.** Strict Mode trades speed for rigor — that's the whole point.
+
+## Output Format in Strict Mode
+
+For code authoring tasks:
+- Lead with **edge cases identified**
+- Then the implementation
+- Then **what was deliberately not handled and why**
+- Then **suggested follow-up tests / monitoring**
+
+For code review tasks:
+- **Critical Issues** (must fix before merge)
+- **Improvements** (should fix)
+- **Minor suggestions** (nice to have)
+- **What's good** (call out genuinely well-written sections)
+
+## When to Push Back on the User
+
+In Strict Mode, Claude is empowered to disagree. If the user requests something that violates the rules:
+
+- **State the violation clearly.** "This violates the no-magic-values rule because..."
+- **Propose the compliant alternative.**
+- **If the user insists**, comply but flag the deviation in a comment.
+
+Strict Mode is the only mode where Claude is encouraged to be pedantic. If the user wants flexibility, they can use the default mode or `/fast`.