@cubis/foundry 0.3.70 → 0.3.72

package/workflows/powers/prompt-engineer/POWER.md

@@ -1,45 +1,62 @@
 ````markdown
 ---
 inclusion: manual
-name: "prompt-engineer"
-displayName: "Prompt Engineer"
-description: "Design and optimize LLM prompts with chain-of-thought, few-shot learning, and evaluation frameworks"
-keywords: ["prompt", "llm", "ai", "chain-of-thought", "few-shot", "evaluation", "gpt", "claude"]
+name: prompt-engineer
+description: "Use when a prompt, instruction set, or agent/system message needs quality review: ambiguity, missing format constraints, unsafe assumptions, injection exposure, weak trigger wording, or brittle task framing."
+license: MIT
+metadata:
+  author: cubis-foundry
+  version: "1.0"
+compatibility: Claude Code, Codex, GitHub Copilot
 ---
 
 # Prompt Engineer
 
-## When to Load Steering Files
+## Purpose
 
-- Prompt patterns (zero-shot, few-shot, CoT) → `prompt-patterns.md`
-- Optimization techniques → `prompt-optimization.md`
-- Evaluation frameworks → `evaluation-frameworks.md`
-- Structured outputs (JSON, function calling) → `structured-outputs.md`
-- System prompt design → `system-prompts.md`
+You are the specialist for prompt and instruction quality.
 
-## Core Workflow
+Your job is to catch ambiguity, missing constraints, unsafe prompt surfaces, and fragile output framing before they turn into agent failures.
 
-1. **Understand** - Define task, success criteria, constraints
-2. **Design** - Choose pattern, write clear instructions
-3. **Test** - Run diverse test cases
-4. **Iterate** - Refine based on failures
-5. **Document** - Version and monitor
+## When to Use
 
-## Prompt Format
+- Reviewing or rewriting prompts, agent instructions, rules, or skill descriptions.
+- The prompt output shape is brittle, vague, or unsafe.
+- The task needs clearer formatting constraints, boundaries, or injection resistance.
 
-```
-<role/persona>
-<task description>
-<constraints>
-<output format>
-<examples if few-shot>
-```
+## Instructions
 
-## Rules
+### STANDARD OPERATING PROCEDURE (SOP)
 
-- Test with diverse inputs including edge cases
-- Measure with quantitative metrics
-- Version prompts and track changes
-- Consider token costs and latency
-- Don't deploy without evaluation
+1. Identify the actual task, output contract, and failure mode.
+2. Check for ambiguity, hidden assumptions, and missing constraints.
+3. Tighten boundaries, structure, and formatting expectations.
+4. Flag injection or context-poisoning risks when external text is involved.
+5. Keep the final wording short, explicit, and testable.
+
+### Constraints
+
+- Do not drift into generic copywriting advice.
+- Do not treat evaluation or prompt review as the same skill.
+- Do not add complexity when the real fix is clearer task framing.
+- Do not ignore prompt-injection and boundary language when tool use or browsing is involved.
+
+## Output Format
+
+Provide implementation guidance, code examples, and configuration as appropriate to the task.
+
+## References
+
+| File                                    | Load when                                                                                               |
+| --------------------------------------- | ------------------------------------------------------------------------------------------------------- |
+| `references/prompt-review-checklist.md` | You need a systematic checklist for ambiguity, output constraints, injection risk, and trigger wording. |
+
+## Scripts
+
+No helper scripts are required for this skill right now. Keep execution in `SKILL.md` and `references/` unless repeated automation becomes necessary.
+
+## Examples
+
+- "Help me with prompt engineer best practices in this project"
+- "Review my prompt engineer implementation for issues"
 ````

package/workflows/powers/prompt-engineer/SKILL.md

@@ -1,42 +1,59 @@
 ---
-name: "prompt-engineer"
-displayName: "Prompt Engineer"
-description: "Design and optimize LLM prompts with chain-of-thought, few-shot learning, and evaluation frameworks"
-keywords: ["prompt", "llm", "ai", "chain-of-thought", "few-shot", "evaluation", "gpt", "claude"]
+name: prompt-engineer
+description: "Use when a prompt, instruction set, or agent/system message needs quality review: ambiguity, missing format constraints, unsafe assumptions, injection exposure, weak trigger wording, or brittle task framing."
+license: MIT
+metadata:
+  author: cubis-foundry
+  version: "1.0"
+compatibility: Claude Code, Codex, GitHub Copilot
 ---
 
 # Prompt Engineer
 
-## When to Load Steering Files
+## Purpose
 
-- Prompt patterns (zero-shot, few-shot, CoT) → `prompt-patterns.md`
-- Optimization techniques → `prompt-optimization.md`
-- Evaluation frameworks → `evaluation-frameworks.md`
-- Structured outputs (JSON, function calling) → `structured-outputs.md`
-- System prompt design → `system-prompts.md`
+You are the specialist for prompt and instruction quality.
 
-## Core Workflow
+Your job is to catch ambiguity, missing constraints, unsafe prompt surfaces, and fragile output framing before they turn into agent failures.
 
-1. **Understand** - Define task, success criteria, constraints
-2. **Design** - Choose pattern, write clear instructions
-3. **Test** - Run diverse test cases
-4. **Iterate** - Refine based on failures
-5. **Document** - Version and monitor
+## When to Use
 
-## Prompt Format
+- Reviewing or rewriting prompts, agent instructions, rules, or skill descriptions.
+- The prompt output shape is brittle, vague, or unsafe.
+- The task needs clearer formatting constraints, boundaries, or injection resistance.
 
-```
-<role/persona>
-<task description>
-<constraints>
-<output format>
-<examples if few-shot>
-```
+## Instructions
 
-## Rules
+### STANDARD OPERATING PROCEDURE (SOP)
 
-- Test with diverse inputs including edge cases
-- Measure with quantitative metrics
-- Version prompts and track changes
-- Consider token costs and latency
-- Don't deploy without evaluation
+1. Identify the actual task, output contract, and failure mode.
+2. Check for ambiguity, hidden assumptions, and missing constraints.
+3. Tighten boundaries, structure, and formatting expectations.
+4. Flag injection or context-poisoning risks when external text is involved.
+5. Keep the final wording short, explicit, and testable.
+
+### Constraints
+
+- Do not drift into generic copywriting advice.
+- Do not treat evaluation or prompt review as the same skill.
+- Do not add complexity when the real fix is clearer task framing.
+- Do not ignore prompt-injection and boundary language when tool use or browsing is involved.
+
+## Output Format
+
+Provide implementation guidance, code examples, and configuration as appropriate to the task.
+
+## References
+
+| File                                    | Load when                                                                                               |
+| --------------------------------------- | ------------------------------------------------------------------------------------------------------- |
+| `references/prompt-review-checklist.md` | You need a systematic checklist for ambiguity, output constraints, injection risk, and trigger wording. |
+
+## Scripts
+
+No helper scripts are required for this skill right now. Keep execution in `SKILL.md` and `references/` unless repeated automation becomes necessary.
+
+## Examples
+
+- "Help me with prompt engineer best practices in this project"
+- "Review my prompt engineer implementation for issues"

package/workflows/powers/python-pro/POWER.md

@@ -1,59 +1,70 @@
 ````markdown
 ---
 inclusion: manual
-name: "python-pro"
-description: "Use for production Python with 3.14-era typing, async, packaging, and testing standards."
+name: python-pro
+description: "Use for production Python with 3.14-era typing, async, packaging, and testing standards. Use when building Python backend services, migrating legacy Python to typed architecture, implementing async I/O, or setting up pytest and packaging workflows."
 license: MIT
 metadata:
-  version: "2.0.0"
-  domain: "language"
-  role: "specialist"
-  stack: "python"
-  baseline: "Python 3.14"
+  author: cubis-foundry
+  version: "3.0"
+compatibility: Claude Code, Codex, GitHub Copilot
 ---
 
 # Python Pro
 
-## When to use
+## Purpose
+
+Provide language-layer guidance for production Python — type annotations, async patterns, packaging, testing, and ecosystem tooling. Acts as the foundation before framework skills like `fastapi-expert` are loaded.
+
+## When to Use
 
 - Building backend services, automation, or data pipelines in Python.
 - Migrating legacy Python to typed and testable architecture.
-- Implementing async I/O with predictable behavior.
+- Implementing async I/O with structured concurrency.
+- Setting up pytest, packaging, or toolchain workflows.
+- Serving as the language-layer baseline before loading framework-specific skills.
 
-## Core workflow
+## Instructions
 
-1. Establish interpreter/runtime constraints.
-2. Define typed interfaces and domain models.
-3. Implement sync/async boundaries explicitly.
-4. Validate with tests, type checks, and linting.
+1. Establish interpreter and runtime constraints before writing code, because Python version determines which typing and async features are available.
+2. Type annotate public functions and critical internal APIs using `Protocol` for structural subtyping and `TypeVar`/`ParamSpec` for generic boundaries. Use `object` over `Any` at public boundaries because `Any` silences the type checker.
+3. Use `pyproject.toml`-first packaging with `hatchling`, `setuptools`, or `flit` as build backend. Do not use `setup.py` for new projects because `pyproject.toml` is the current standard.
+4. Use `dataclass(frozen=True, slots=True)` for plain value objects and Pydantic `BaseModel` for external data validation (API input, config files) because Pydantic provides runtime schema enforcement.
+5. Use `TaskGroup` (3.11+) for structured concurrency — child tasks are automatically cancelled if any raises. Use `asyncio.timeout` instead of `asyncio.wait_for` for cleaner timeout handling.
+6. Keep sync and async call paths separate. Do not call `asyncio.run()` inside an already-running loop. Use `asyncio.to_thread()` to bridge sync-blocking code into async context.
+7. Set explicit timeout and concurrency limits on external I/O because unbounded fan-out is the most common async performance bug.
+8. Use `pytest` for tests with `@pytest.mark.parametrize` for edge cases. Use `hypothesis` for property-based testing when input domains are large.
+9. Use `ruff` for all-in-one linting and formatting. Use `mypy` for strict type checking in CI and `pyright` for IDE feedback.
+10. Use `uv` for fast dependency resolution and virtual environment management. Fall back to `pip` + `venv` when `uv` is unavailable.
+11. Preserve exception context at service boundaries — do not swallow root causes. Keep business logic separate from framework glue.
+12. Do not use untyped public APIs in shared modules because they propagate type uncertainty to consumers.
+13. Do not use hidden global state in request paths because it creates unpredictable concurrency behavior.
+14. Do not mix sync and async call graphs without clear adapters because it leads to blocking the event loop.
 
-## Baseline standards
+## Output Format
 
-- Type annotate public functions and critical internal APIs.
-- Use `pyproject.toml`-first packaging and tooling.
-- Use `pytest` for tests and parametrize edge cases.
-- Keep business logic separate from framework glue.
-- Prefer stdlib clarity before adding dependencies.
+- Python source files with type annotations on public APIs.
+- `pyproject.toml` for packaging configuration.
+- Test files under `tests/` using pytest conventions.
+- Structured as modules with explicit `__init__.py` exports.
 
-## Implementation guidance
+## References
 
-- Use `dataclass`/Pydantic models for domain boundaries.
-- Use `TaskGroup`-style structured concurrency where possible.
-- Preserve exception context; do not swallow root causes.
-- Keep I/O async and CPU work isolated where needed.
-- Treat free-threaded mode as opt-in until dependencies are validated.
+| File                             | Load when                                                               |
+| -------------------------------- | ----------------------------------------------------------------------- |
+| `references/type-system.md`      | Typing strategy, protocols, generics, or boundary models need detail.   |
+| `references/async-patterns.md`   | Async I/O, task groups, or cancellation semantics need detail.          |
+| `references/testing.md`          | Pytest strategy, fixtures, or concurrency-safe tests are needed.        |
+| `references/packaging.md`        | Packaging, dependency layout, or toolchain reproducibility is in scope. |
+| `references/standard-library.md` | Standard-library-first options need review before adding dependencies.  |
 
-## Avoid
+## Scripts
 
-- Untyped public APIs in shared modules.
-- Hidden global state in request paths.
-- Mixed sync/async call graphs without clear adapters.
+No helper scripts are required for this skill right now. Keep execution in `SKILL.md` and `references/` unless repeated automation becomes necessary.
 
-## Reference files
+## Examples
 
-- `references/type-system.md`
-- `references/async-patterns.md`
-- `references/testing.md`
-- `references/packaging.md`
-- `references/standard-library.md`
+- "Set up a Python FastAPI project with proper typing and async patterns"
+- "Migrate this legacy Python module to use dataclasses and type annotations"
+- "Configure pytest with parametrize for this validation function"
 ````

package/workflows/powers/python-pro/SKILL.md

@@ -1,56 +1,67 @@
 ---
-name: "python-pro"
-description: "Use for production Python with 3.14-era typing, async, packaging, and testing standards."
+name: python-pro
+description: "Use for production Python with 3.14-era typing, async, packaging, and testing standards. Use when building Python backend services, migrating legacy Python to typed architecture, implementing async I/O, or setting up pytest and packaging workflows."
 license: MIT
 metadata:
-  version: "2.0.0"
-  domain: "language"
-  role: "specialist"
-  stack: "python"
-  baseline: "Python 3.14"
+  author: cubis-foundry
+  version: "3.0"
+compatibility: Claude Code, Codex, GitHub Copilot
 ---
 
 # Python Pro
 
-## When to use
+## Purpose
+
+Provide language-layer guidance for production Python — type annotations, async patterns, packaging, testing, and ecosystem tooling. Acts as the foundation before framework skills like `fastapi-expert` are loaded.
+
+## When to Use
 
 - Building backend services, automation, or data pipelines in Python.
 - Migrating legacy Python to typed and testable architecture.
-- Implementing async I/O with predictable behavior.
+- Implementing async I/O with structured concurrency.
+- Setting up pytest, packaging, or toolchain workflows.
+- Serving as the language-layer baseline before loading framework-specific skills.
 
-## Core workflow
+## Instructions
 
-1. Establish interpreter/runtime constraints.
-2. Define typed interfaces and domain models.
-3. Implement sync/async boundaries explicitly.
-4. Validate with tests, type checks, and linting.
+1. Establish interpreter and runtime constraints before writing code, because Python version determines which typing and async features are available.
+2. Type annotate public functions and critical internal APIs using `Protocol` for structural subtyping and `TypeVar`/`ParamSpec` for generic boundaries. Use `object` over `Any` at public boundaries because `Any` silences the type checker.
+3. Use `pyproject.toml`-first packaging with `hatchling`, `setuptools`, or `flit` as build backend. Do not use `setup.py` for new projects because `pyproject.toml` is the current standard.
+4. Use `dataclass(frozen=True, slots=True)` for plain value objects and Pydantic `BaseModel` for external data validation (API input, config files) because Pydantic provides runtime schema enforcement.
+5. Use `TaskGroup` (3.11+) for structured concurrency — child tasks are automatically cancelled if any raises. Use `asyncio.timeout` instead of `asyncio.wait_for` for cleaner timeout handling.
+6. Keep sync and async call paths separate. Do not call `asyncio.run()` inside an already-running loop. Use `asyncio.to_thread()` to bridge sync-blocking code into async context.
+7. Set explicit timeout and concurrency limits on external I/O because unbounded fan-out is the most common async performance bug.
+8. Use `pytest` for tests with `@pytest.mark.parametrize` for edge cases. Use `hypothesis` for property-based testing when input domains are large.
+9. Use `ruff` for all-in-one linting and formatting. Use `mypy` for strict type checking in CI and `pyright` for IDE feedback.
+10. Use `uv` for fast dependency resolution and virtual environment management. Fall back to `pip` + `venv` when `uv` is unavailable.
+11. Preserve exception context at service boundaries — do not swallow root causes. Keep business logic separate from framework glue.
+12. Do not use untyped public APIs in shared modules because they propagate type uncertainty to consumers.
+13. Do not use hidden global state in request paths because it creates unpredictable concurrency behavior.
+14. Do not mix sync and async call graphs without clear adapters because it leads to blocking the event loop.
 
-## Baseline standards
+## Output Format
 
-- Type annotate public functions and critical internal APIs.
-- Use `pyproject.toml`-first packaging and tooling.
-- Use `pytest` for tests and parametrize edge cases.
-- Keep business logic separate from framework glue.
-- Prefer stdlib clarity before adding dependencies.
+- Python source files with type annotations on public APIs.
+- `pyproject.toml` for packaging configuration.
+- Test files under `tests/` using pytest conventions.
+- Structured as modules with explicit `__init__.py` exports.
 
-## Implementation guidance
+## References
 
-- Use `dataclass`/Pydantic models for domain boundaries.
-- Use `TaskGroup`-style structured concurrency where possible.
-- Preserve exception context; do not swallow root causes.
-- Keep I/O async and CPU work isolated where needed.
-- Treat free-threaded mode as opt-in until dependencies are validated.
+| File                             | Load when                                                               |
+| -------------------------------- | ----------------------------------------------------------------------- |
+| `references/type-system.md`      | Typing strategy, protocols, generics, or boundary models need detail.   |
+| `references/async-patterns.md`   | Async I/O, task groups, or cancellation semantics need detail.          |
+| `references/testing.md`          | Pytest strategy, fixtures, or concurrency-safe tests are needed.        |
+| `references/packaging.md`        | Packaging, dependency layout, or toolchain reproducibility is in scope. |
+| `references/standard-library.md` | Standard-library-first options need review before adding dependencies.  |
 
-## Avoid
+## Scripts
 
-- Untyped public APIs in shared modules.
-- Hidden global state in request paths.
-- Mixed sync/async call graphs without clear adapters.
+No helper scripts are required for this skill right now. Keep execution in `SKILL.md` and `references/` unless repeated automation becomes necessary.
 
-## Reference files
+## Examples
 
-- `references/type-system.md`
-- `references/async-patterns.md`
-- `references/testing.md`
-- `references/packaging.md`
-- `references/standard-library.md`
+- "Set up a Python FastAPI project with proper typing and async patterns"
+- "Migrate this legacy Python module to use dataclasses and type annotations"
+- "Configure pytest with parametrize for this validation function"

package/workflows/powers/react-best-practices/POWER.md

@@ -1,56 +1,79 @@
 ````markdown
 ---
 inclusion: manual
-name: "react-best-practices"
-description: "Performance-focused React/Next.js review checklist. Use for audits and optimization passes, not as primary implementation skill."
+name: react-best-practices
+description: "Use for performance-focused React and Next.js optimization audits, rerender analysis, bundle reduction, and server-rendering efficiency reviews."
 license: MIT
 metadata:
-  author: vercel
+  author: cubis-foundry
   version: "2.0.0"
-  domain: "frontend"
-  role: "review-checklist"
+compatibility: Claude Code, Codex, GitHub Copilot
 ---
 
 # React Best Practices
 
 ## Purpose
 
-Use this skill to run structured optimization reviews on React/Next.js code. Pair it with implementation skills (`react-expert`, `nextjs-developer`) when code changes are required.
+Structured optimization review checklist for React and Next.js code. Pair with implementation skills (`react-expert`, `nextjs-developer`) when code changes are required — this skill focuses on identifying performance issues and recommending minimal safe fixes.
 
-## Review order
+## When to Use
 
-1. Async waterfalls and request parallelization.
-2. Bundle and hydration footprint.
-3. Server rendering and serialization overhead.
-4. Client data-fetching and rerender churn.
-5. JS/runtime hot paths.
+- Running structured performance audits on React or Next.js applications.
+- Identifying async waterfalls, bundle bloat, or hydration overhead.
+- Reviewing rerender churn, unstable props, or server-to-client payload size.
+- Prioritizing optimization work by measurable impact.
+- Validating that recent changes haven't introduced rendering regressions.
 
-## High-impact checks
+## Instructions
 
-- Parallelize independent async work.
-- Eliminate unnecessary client components.
-- Remove heavy modules from critical path.
-- Avoid unstable props that trigger deep rerenders.
-- Keep server-to-client payloads minimal.
+1. **Start with async waterfalls and request parallelization.** Identify sequential data fetches that could run in parallel. Async waterfalls are usually the highest-impact performance issue.
 
-## Output format
+2. **Audit bundle and hydration footprint.** Identify unnecessary client components, heavy modules in the critical path, and components that could remain server-rendered. Eliminate unnecessary client hydration.
 
-Return prioritized findings with:
+3. **Review server rendering and serialization overhead.** Check for oversized server-to-client payloads, redundant data serialization, and components that fetch more data than they render.
 
-1. Issue and impact.
-2. Minimal safe change.
-3. Verification method (profile metric or test).
+4. **Analyze client data-fetching and rerender churn.** Look for unstable props that trigger deep rerenders, derived-state duplication, and effect-driven state loops. Verify that memoization is applied only where profiling shows benefit.
 
-## Rule catalog
+5. **Profile JS/runtime hot paths.** Identify expensive computations in render paths, unnecessary object/array allocations per render, and heavy event handlers that block the main thread.
 
-Detailed rules are under `rules/` and grouped by prefix:
+6. **For each finding, assess impact before recommending a fix.** Prioritize by user-visible latency and interaction responsiveness. Small measured gains on hot paths outweigh large theoretical gains on cold paths.
 
-- `async-*`
-- `bundle-*`
-- `server-*`
-- `client-*`
-- `rerender-*`
-- `rendering-*`
-- `js-*`
-- `advanced-*`
+7. **Recommend minimal safe changes.** Each fix should be the smallest change that addresses the issue. Avoid cascading refactors when a targeted fix suffices.
+
+8. **Specify a verification method for every recommendation.** Each finding needs a concrete way to confirm the fix worked — a profile metric, a bundle-size diff, a Lighthouse score change, or a specific test.
+
+## Output Format
+
+Return a prioritized list of findings. Each finding includes:
+
+1. **Issue** — what the problem is and its performance impact.
+2. **Fix** — the minimal safe change to resolve it.
+3. **Verification** — the profile metric, test, or measurement that confirms the fix.
+
+Group findings by category: async/network, bundle/hydration, server rendering, client rerenders, runtime hot paths.
+
+## References
+
+Detailed rules are organized under `rules/` by prefix:
+
+| Prefix        | Coverage                                     |
+| ------------- | -------------------------------------------- |
+| `async-*`     | Async waterfalls and request parallelization |
+| `bundle-*`    | Bundle size and tree-shaking                 |
+| `server-*`    | Server rendering and serialization           |
+| `client-*`    | Client data-fetching patterns                |
+| `rerender-*`  | Rerender churn and prop stability            |
+| `rendering-*` | Rendering pipeline efficiency                |
+| `js-*`        | JavaScript runtime hot paths                 |
+| `advanced-*`  | Advanced optimization patterns               |
+
+## Scripts
+
+No helper scripts are required for this skill right now. Keep execution in `SKILL.md` and `references/` unless repeated automation becomes necessary.
+
+## Examples
+
+- "Run a performance audit on this Next.js app — focus on async waterfalls and bundle size."
+- "Review this component tree for rerender churn and unstable prop patterns."
+- "Identify server-to-client serialization overhead in these Server Components."
 ````

package/workflows/powers/react-best-practices/SKILL.md

@@ -1,53 +1,76 @@
 ---
-name: "react-best-practices"
-description: "Performance-focused React/Next.js review checklist. Use for audits and optimization passes, not as primary implementation skill."
+name: react-best-practices
+description: "Use for performance-focused React and Next.js optimization audits, rerender analysis, bundle reduction, and server-rendering efficiency reviews."
 license: MIT
 metadata:
-  author: vercel
+  author: cubis-foundry
   version: "2.0.0"
-  domain: "frontend"
-  role: "review-checklist"
+compatibility: Claude Code, Codex, GitHub Copilot
 ---
 
 # React Best Practices
 
 ## Purpose
 
-Use this skill to run structured optimization reviews on React/Next.js code. Pair it with implementation skills (`react-expert`, `nextjs-developer`) when code changes are required.
+Structured optimization review checklist for React and Next.js code. Pair with implementation skills (`react-expert`, `nextjs-developer`) when code changes are required — this skill focuses on identifying performance issues and recommending minimal safe fixes.
 
-## Review order
+## When to Use
 
-1. Async waterfalls and request parallelization.
-2. Bundle and hydration footprint.
-3. Server rendering and serialization overhead.
-4. Client data-fetching and rerender churn.
-5. JS/runtime hot paths.
+- Running structured performance audits on React or Next.js applications.
+- Identifying async waterfalls, bundle bloat, or hydration overhead.
+- Reviewing rerender churn, unstable props, or server-to-client payload size.
+- Prioritizing optimization work by measurable impact.
+- Validating that recent changes haven't introduced rendering regressions.
 
-## High-impact checks
+## Instructions
 
-- Parallelize independent async work.
-- Eliminate unnecessary client components.
-- Remove heavy modules from critical path.
-- Avoid unstable props that trigger deep rerenders.
-- Keep server-to-client payloads minimal.
+1. **Start with async waterfalls and request parallelization.** Identify sequential data fetches that could run in parallel. Async waterfalls are usually the highest-impact performance issue.
 
-## Output format
+2. **Audit bundle and hydration footprint.** Identify unnecessary client components, heavy modules in the critical path, and components that could remain server-rendered. Eliminate unnecessary client hydration.
 
-Return prioritized findings with:
+3. **Review server rendering and serialization overhead.** Check for oversized server-to-client payloads, redundant data serialization, and components that fetch more data than they render.
 
-1. Issue and impact.
-2. Minimal safe change.
-3. Verification method (profile metric or test).
+4. **Analyze client data-fetching and rerender churn.** Look for unstable props that trigger deep rerenders, derived-state duplication, and effect-driven state loops. Verify that memoization is applied only where profiling shows benefit.
 
-## Rule catalog
+5. **Profile JS/runtime hot paths.** Identify expensive computations in render paths, unnecessary object/array allocations per render, and heavy event handlers that block the main thread.
 
-Detailed rules are under `rules/` and grouped by prefix:
+6. **For each finding, assess impact before recommending a fix.** Prioritize by user-visible latency and interaction responsiveness. Small measured gains on hot paths outweigh large theoretical gains on cold paths.
 
-- `async-*`
-- `bundle-*`
-- `server-*`
-- `client-*`
-- `rerender-*`
-- `rendering-*`
-- `js-*`
-- `advanced-*`
+7. **Recommend minimal safe changes.** Each fix should be the smallest change that addresses the issue. Avoid cascading refactors when a targeted fix suffices.
+
+8. **Specify a verification method for every recommendation.** Each finding needs a concrete way to confirm the fix worked — a profile metric, a bundle-size diff, a Lighthouse score change, or a specific test.
+
+## Output Format
+
+Return a prioritized list of findings. Each finding includes:
+
+1. **Issue** — what the problem is and its performance impact.
+2. **Fix** — the minimal safe change to resolve it.
+3. **Verification** — the profile metric, test, or measurement that confirms the fix.
+
+Group findings by category: async/network, bundle/hydration, server rendering, client rerenders, runtime hot paths.
+
+## References
+
+Detailed rules are organized under `rules/` by prefix:
+
+| Prefix        | Coverage                                     |
+| ------------- | -------------------------------------------- |
+| `async-*`     | Async waterfalls and request parallelization |
+| `bundle-*`    | Bundle size and tree-shaking                 |
+| `server-*`    | Server rendering and serialization           |
+| `client-*`    | Client data-fetching patterns                |
+| `rerender-*`  | Rerender churn and prop stability            |
+| `rendering-*` | Rendering pipeline efficiency                |
+| `js-*`        | JavaScript runtime hot paths                 |
+| `advanced-*`  | Advanced optimization patterns               |
+
+## Scripts
+
+No helper scripts are required for this skill right now. Keep execution in `SKILL.md` and `references/` unless repeated automation becomes necessary.
+
+## Examples
+
+- "Run a performance audit on this Next.js app — focus on async waterfalls and bundle size."
+- "Review this component tree for rerender churn and unstable prop patterns."
+- "Identify server-to-client serialization overhead in these Server Components."