review-all

name	review-all
description	Use this skill when the user asks for a full audit, batch review, review all components, overall health check, status overview, or wants a dashboard across all section components in a FastStore + Synerise project. Audits every component under src/components/sections/ against 5 architectural rules and produces a summary dashboard.
metadata	{"author":"synerise","version":"1.0.0","lastUpdated":"2026-05-04T00:00:00.000Z"}

Review All Section Components (FastStore + Synerise)

Batch audit across every section component in src/components/sections/. This skill iterates components and reuses per-rule logic from the review-component skill — it does NOT redefine the rules. Its unique role is the cross-component dashboard and aggregate views.

Step 0: Verify project context

This skill is only valid in a FastStore + Synerise project. Before running, confirm at least one of these signals:

• package.json lists @synerise/faststore-api as a dependency, OR
• src/components/sections/ directory exists, OR
• discovery.config.js file exists at the repo root.

If none are present, stop and tell the user:

This doesn't look like a FastStore + Synerise project (no @synerise/faststore-api dep, no src/components/sections/, no discovery.config.js). Skipping audit.

Step 1: List components

List every direct child directory under src/components/sections/. Each one is a component to review.

Step 2: Per-component review

For EACH component, apply the rule criteria defined in the review-component skill. Do NOT redefine them here — read that skill's Rule 1–5 sections and apply them in turn. The shared sub-skills readme-rules and design-tokens provide the canonical references for Rule 4 and Rule 5 respectively.

Quick rule reminder (full criteria live in review-component):

1. No Frontend API Calls — only useQuery / request for data fetching; no fetch, axios, or direct SDK client instantiation.
2. SDK Patterns — reuse existing syneriseAIRecommendations / syneriseAISearch resolvers; only build a custom resolver + typeDef + hook when the SDK has no equivalent.
3. Code Organization — shared types in src/types/, shared hooks in src/hooks/, no duplicate type defs.
4. README — present, follows readme-rules structure, listed in root README index.
5. SCSS Design Tokens — no hardcoded values that have a token equivalent in the merged token list (VTEX cache + project overrides).

Output one terse status row per component (NOT the full per-rule report from review-component — that is for single-component deep dives):

### [ComponentName]
- Rule 1 (No Direct API): [PASS/FAIL] — [brief reason if FAIL]
- Rule 2 (SDK Patterns): [PASS/FAIL/N/A] — [brief reason if FAIL]
- Rule 3 (Organization): [PASS/FAIL/WARN] — [brief reason if not PASS]
- Rule 4 (README): [PASS/FAIL/WARN] — [exists with all sections / missing sections / no README]
- Rule 5 (Design Tokens): [PASS/FAIL/N/A] — [brief reason if FAIL]

Status semantics (PASS / FAIL / WARN / N/A) and per-rule applicability are defined canonically in the review-component skill — see its "Status semantics" subsection. Apply them identically here.

Step 3: Aggregate dashboard

After all individual rows, produce a summary dashboard:

# Component Review Dashboard
Date: [today's date]

| Component | Rule 1: No Direct API | Rule 2: SDK Patterns | Rule 3: Organization | Rule 4: README | Rule 5: Design Tokens |
|---|---|---|---|---|---|
| [Name] | [PASS/FAIL] | [PASS/FAIL/N/A] | [PASS/FAIL/WARN] | [PASS/FAIL/WARN] | [PASS/FAIL/N/A] |
| ... | ... | ... | ... | ... | ... |

## Critical Violations (must fix)
[Rule 1 violations: components making direct API calls. Include specific file paths and what resolver/typeDef/hook needs to be created.]

## Warnings (should fix)
[Rule 3 organization issues, naming convention violations, missing barrel exports, README warnings.]

## Missing READMEs
[Components without README.md or with incomplete README. For each, suggest invoking the create-readme skill with the component path.]

## Root README Index Drift
[Components missing from the root README "Available Section Components" table, broken links, or descriptions that no longer match the component README intro.]

## Refactoring Candidates
[Rule 1 / Rule 2 violations needing full resolver + typeDef + hook refactoring. For each:]
1. [Component] — needs: [resolver file], [typeDef file], [hook refactoring]

Notes

• The 5 architectural rules and their application criteria are defined canonically in the review-component skill. This skill does not redefine them — when review-component evolves, the criteria automatically follow.
• Per-rule check details live in the review-component skill — keep them in sync there, not here.
• For a full per-rule report with violation snippets and fixes for ONE component, the user should invoke review-component directly.
• If a reference implementation is needed for comparison, identify a component in this repo that already passes all 5 rules (typically one with a complete README, SDK-resolver-backed hook, shared types in src/types/, and a .module.scss using only design tokens) and cite it in the report. Do not hardcode a specific component name — the canonical example varies per store.