| name | frontend-review-weekly |
| description | Use for the weekly AI review. Orchestrates all frontend-review-* skills in order, dispatches the 5 perspective sub-skills in parallel, diffs against last week's KPIs, and produces a weekly report that feeds the ratchet. |
Frontend Review — Weekly Orchestrator
You are running the weekly AI review. Your job is NOT to make new judgments — it's to:
- Re-run every
frontend-review-* skill in the correct order.
- Dispatch the 5 perspective sub-skills in parallel.
- Diff the KPIs against last week's baseline.
- File GitHub issues for repeat findings.
- Propose static-rule promotions for patterns that appear 3+ weeks in a row.
Procedure
Phase 1: raw data collection
Run, in this order:
frontend-review-triagefrontend-review-cifrontend-review-hygienefrontend-review-depsfrontend-review-testingfrontend-review-security
Each of these writes to <client-repo>/.frontend-review/report/latest/.
Phase 1.5: architecture review (run when findings are suspected)
Run these on-demand, or always for the first weekly of a new engagement:
frontend-review-statefrontend-review-performance
These write to <client-repo>/.frontend-review/report/latest/md/.
Phase 2: perspective review (parallel)
Dispatch the 5 perspective skills concurrently using the dispatching-parallel-agents skill. Each reads the raw JSON and produces a perspective-specific markdown report:
frontend-expertreact-expertperformance-expertsecurity-expertfrontend-ops-expert
Phase 3: KPI diff and ratchet
Compare <client-repo>/.frontend-review/report/latest/raw/*.json against <client-repo>/.frontend-review/kpi/baseline.json. Flag:
- Any regression (bad) — these must be fixed before the next weekly
- Any improvement (good) — these update the baseline (ratchet tightens)
Phase 4: repeat-finding detection
Compare this week's findings with the previous 2 report/weekly-*.md files. Any finding that appears in all three weeks is a candidate for static rule promotion: propose an eslint/biome custom rule, a codemod, or a CI gate that would make the check automatic. Write these proposals to <client-repo>/eslint-rules/proposals/<rule-name>.md (create the directory if needed) but do NOT implement them — that's a separate engineering task.
Phase 5: report
Write <client-repo>/.frontend-review/report/weekly-$(date +%Y-w%V).md with:
- KPI delta table (per category)
- Regressions (must fix)
- Improvements (ratchet updates)
- Perspective summaries (1 paragraph per perspective)
- Static rule promotions (pointer to proposals)
- Issues filed (
gh issue create output)
Trend Monitoring
Alongside KPI diffing, check the following external signals once per weekly cycle to detect ecosystem drift early.
Monitoring sources
| Source | Cadence | What to look for |
|---|
| jser.info | Weekly (Sunday publish) | Major releases, RFCs, breaking changes, security advisories affecting the project's dependencies |
| State of JS (yearly, ~Dec) | Annual | Usage/satisfaction trends; two consecutive years of satisfaction decline is a switch-trigger |
| State of CSS (yearly) | Annual | CSS adoption trends, Tailwind / CSS-in-JS sentiment |
| JavaScript Rising Stars (yearly, ~Jan) | Annual | GitHub star growth; early signal for emerging tools |
| Official release blogs | On release | Track the project's direct dependencies (framework, bundler, test runner, linter, TypeScript) for major releases |
For the weekly run, WebFetch https://jser.info/ and scan for any mention of packages listed in package.json. Flag anything relevant under an Ecosystem Signals heading.
Switch triggers
Recommend investigating a tool replacement when any two of these conditions are met:
- Satisfaction score has declined for 2 consecutive years in State of JS / State of CSS.
- No major release in the past 6 months and GitHub issue accumulation is trending up.
- A maintainer departure or deprecation notice was reported.
- A clear superior alternative exists: feature parity + significant performance or DX improvement + realistic migration path.
AI / Human Responsibility Split
AI can act on (without human pre-approval):
- Auto-fixable lint / typecheck errors
- Expanding test coverage for existing patterns
- Dependency version bumps (after lint + test pass)
Human must decide:
- Test failure triage: is the spec wrong, the implementation wrong, or the test wrong?
- New library additions or removals
- Architecture boundary changes (new state layer, new routing pattern, new async boundary)
- Any change that modifies what the app does, not just how it does it
Flag any AI-generated PRs in the weekly report that appear to cross into the human-decision zone.
Boundaries
- Do NOT skip any of the Phase 1 domain skills, even if time is short.
- Do NOT modify source code in the client repo.
- Do NOT silently update
kpi/baseline.json on a regression. Only update on improvement.
Reference
- Checklist:
11-ai-review.md, 13-kpi-tracking.md
- Phase:
week-4-ai-review.md, ongoing.md
- Related skills: all
frontend-review-* and sub-skills in review-perspectives/
- External skill:
superpowers:dispatching-parallel-agents
