| name | sdcorejs-review |
| description | Read-only review/audit skill across SDCoreJS tracks. Use for code, architecture, security, performance, accessibility, existing-site audits, scored/full audits, or auto review after an executor. Detects stack/profile/dimension, loads applicable refs only, emits review_context for repair-loop, and stays strict read-only by default. Applies to angular, nestjs, nextjs, general. Runtime-localized. |
Codex path resolution: Resolve ../_refs/... relative to this SKILL.md. Resolve another SDCoreJS skill by opening the sibling folder ../<skill-name>/SKILL.md.
Review (profile + dimension aware)
Purpose
One read-only review skill for code, architecture, security, performance, and
accessibility. It classifies both track and track_profile before loading
track-specific references so plain Angular, NestJS, Next.js, and general
projects are not reviewed against SDCoreJS framework conventions they do not
use.
sdcorejs-review must not edit source code. Direct user-requested review is
strict read-only by default and must not silently write .sdcorejs artifacts or
auto-run sdcorejs-repair-loop. Repair belongs to sdcorejs-repair-loop after
an explicit user or finish-gate choice.
Shared Protocols
Before executing this skill:
- Read and apply
../_refs/shared/tasklist.md for non-trivial execution tasks.
- Read and apply
../_refs/shared/persona.md if a project persona exists.
- Read and apply
../_refs/shared/project-context.md for project memory, resume checkpoints, summaries, specs/plans, tasks, and relevant memories.
- Current user request, current files, diffs, logs, failing tests, and command output override stored context.
- Before presenting user-facing choices, approval gates, yes/no questions, or mode selections, read and apply
../_refs/shared/user-choice-prompt.md so options are presented as sequential numbered choices.
When to use
- After a track executor finishes a batch and the finish gate selected review.
- Before merging a feature branch.
- User says "review code", "security review", "performance review",
"review a11y", "architecture review", "comprehensive audit", "full review",
"scored review", or localized equivalents.
Step 0 - Context and Scope Preflight
Before detecting profile/dimension or reading files under review, run
sdcorejs-explore (summary-read) through ../_refs/shared/project-context.md.
- For an existing target project, read
<target>/.sdcorejs/summary.md when it
exists so review scope, module boundaries, route conventions, stack profile,
and prior decisions are available before findings are classified.
- Keep direct review strict read-only. If the summary is missing, stale, dirty,
or unknown, do not refresh it from review; continue with targeted reads or
sdcorejs-explore (code-map-readonly) and report the context limitation.
- Use
summary-refresh only when the caller is a write-approved finish chain or
the user explicitly approves context artifact writes.
- Current diffs, failing tests, explicit review scope, and user corrections
override stored summary context.
Determine review scope in this order:
- explicit user-provided files or directories;
- current task, plan, or spec scope;
- git diff against the current branch/base if available;
- changed files in the working tree;
- inferred module from the request;
- ask the user for one numbered scope choice if the repo is too large and no
clear scope exists.
Exclude generated/vendor/build output by default: node_modules, dist,
build, coverage, .next, .turbo, .angular, generated clients,
lockfiles unless relevant, and generated Codex/Claude/plugin mirrors unless the
review is about skills/mirrors. "Read every file under review" means every file
inside the selected file_scope, not the entire repository by default.
Step 1 - Classify Track, Track Profile, Dimension, and Mode
Track and track_profile
Classify track_profile before loading any track-specific ref:
| track | track_profile | Required evidence |
|---|
| angular | core-ui-angular | Angular signals plus @sdcorejs/angular in package.json or strong existing imports/usages. |
| angular | legacy-core-ui-angular | Angular signals plus @sd-angular/core in package.json or strong existing imports/usages. |
| angular | plain-angular | Angular signals but neither Core UI package/convention is installed or used. |
| nestjs | sdcorejs-nestjs | NestJS signals plus @sdcorejs/nestjs or strong SDCoreJS NestJS conventions/libraries. |
| nestjs | plain-nestjs | NestJS signals without @sdcorejs/nestjs or SDCoreJS NestJS conventions. |
| nextjs | nextjs-build-website | Next.js signals plus build-website/public-site evidence such as src/app/[locale], typed i18n navigation, content/public-site structure, build-website summary/plan/spec/task context, or explicit public-site scope. |
| nextjs | plain-nextjs | Next.js signals without build-website/public-site evidence. |
| general | general | No known track can be confidently classified, or mixed/unknown stack where only shared rules are safe. |
Rules:
- Do not treat Angular as Core UI Angular merely because
angular.json or
@angular/core exists.
- Do not treat NestJS as SDCoreJS NestJS merely because
@nestjs/* exists.
- Do not treat Next.js as build-website merely because
next.config.* or
next exists.
- Do not enforce Zod, TypeORM, PostgreSQL,
@sdcorejs/nestjs, Core UI,
[locale], typed i18n navigation, or build-website caching/layout patterns
unless the classified profile or actual installed/used stack supports them.
- If the user explicitly asks to review a migration/install to an SDCoreJS
framework profile, classify the migration scope separately and review only the
approved migration evidence.
Dimensions
Dimension comes from user intent:
| Dimension | Use when |
|---|
code | "review code", "review", "audit module", per-file conventions. |
architecture | "architecture review", "module boundaries", "circular dependency", "layering". |
security | "security review", "SQL injection", "secrets", "CSP", "route guards". |
performance | "performance review", "Lighthouse", "N+1", "bundle size", "slow query". |
accessibility | "accessibility", "a11y", "WCAG", "aria", "keyboard nav", "contrast". |
ALL | "comprehensive audit", "full review", "enterprise readiness"; run every applicable dimension and mark non-applicable dimensions as N/A. |
site-audit | Next.js existing whole-site audit; only use build-website site audit when track_profile=nextjs-build-website, otherwise run table review and report site-audit N/A. |
Preserve dimensions. A security review remains security; do not relabel it as
generic code. Accessibility is N/A for backend-only profiles unless the user
asks for API usability/error-shape accessibility or a generated docs/UI review.
Review mode and scored support
- Default mode is
quick-table or table.
- Angular/NestJS code quick reviews may use table mode.
- Scored review is currently supported only for
core-ui-angular and
legacy-core-ui-angular using ../_refs/angular/review-code.md.
- For
plain-angular, sdcorejs-nestjs, plain-nestjs,
nextjs-build-website, plain-nextjs, and general, state that scored mode
is unavailable unless a repo-defined rubric exists, then run table mode
unless the user asks to stop.
Step 2 - Load Applicable References
Load track-specific refs only when track_profile matches the ref scope. Load
shared refs for shared dimensions when applicable. If a ref is absent or not
applicable, record it under refs_skipped with a reason; do not fabricate a
missing ref and do not silently fail.
| track_profile | code | security | performance | accessibility | architecture |
|---|
core-ui-angular | ../_refs/angular/review-code.md | ../_refs/shared/review-security.md + ../_refs/angular/review-security.md | ../_refs/shared/review-performance.md + ../_refs/angular/review-performance.md | ../_refs/shared/review-accessibility.md + ../_refs/angular/review-accessibility.md | ../_refs/shared/review-architecture.md |
legacy-core-ui-angular | ../_refs/angular/review-code.md | same as Core UI Angular | same as Core UI Angular | same as Core UI Angular | ../_refs/shared/review-architecture.md |
plain-angular | ../_refs/shared/review-code.md plus generic/local Angular checks only | ../_refs/shared/review-security.md | ../_refs/shared/review-performance.md | ../_refs/shared/review-accessibility.md for UI scope only | ../_refs/shared/review-architecture.md |
sdcorejs-nestjs | ../_refs/nestjs/review-code.md | ../_refs/shared/review-security.md + ../_refs/nestjs/review-security.md | ../_refs/shared/review-performance.md + ../_refs/nestjs/review-performance.md | N/A unless API usability/docs/UI scope requested | ../_refs/shared/review-architecture.md |
plain-nestjs | ../_refs/shared/review-code.md plus generic/local NestJS checks only | ../_refs/shared/review-security.md | ../_refs/shared/review-performance.md | N/A unless API usability/docs/UI scope requested | ../_refs/shared/review-architecture.md |
nextjs-build-website | ../_refs/nextjs/build-website/review-code.md | ../_refs/shared/review-security.md + ../_refs/nextjs/build-website/review-security.md | ../_refs/shared/review-performance.md + ../_refs/nextjs/build-website/review-performance.md | ../_refs/shared/review-accessibility.md + ../_refs/nextjs/build-website/review-accessibility.md | ../_refs/shared/review-architecture.md |
plain-nextjs | ../_refs/shared/review-code.md plus generic/local Next.js checks only | ../_refs/shared/review-security.md | ../_refs/shared/review-performance.md | ../_refs/shared/review-accessibility.md for UI scope only | ../_refs/shared/review-architecture.md |
general | ../_refs/shared/review-code.md | ../_refs/shared/review-security.md | ../_refs/shared/review-performance.md | ../_refs/shared/review-accessibility.md for UI scope only | ../_refs/shared/review-architecture.md |
Plain-profile guardrails:
plain-angular: must not flag missing Sd* components/services, Core UI
imports, autoId, Core UI style utilities, src/libs/**/features/**,
MockCrudStore, SdTable, SdNotifyService, forced admin screens, or Core
UI usage summaries unless the project already uses SDCoreJS Core UI.plain-nestjs: must not enforce @sdcorejs/nestjs, Zod, TypeORM,
PostgreSQL, base repositories/services, or a specific module layout unless
detected in the target project. If the project uses Prisma, class-validator,
Mongoose, Fastify, or another stack, review against that actual stack.plain-nextjs: must not enforce [locale], setRequestLocale, typed i18n
navigation, content/public-site folders, landing-site metadata conventions, or
build-website caching rules unless detected.
Step 3 - Probe Discipline and Secret Redaction
Discover review and verification commands from package manager, lockfile,
workspace configuration, package.json scripts, installed tools, and original
failing commands. Do not hardcode npm or tsc. Do not invent missing
scripts. Do not download probe tools with npx --yes or similar without
explicit approval.
Rules:
- Detect package manager from lockfiles and
package.json.
- Do not mix
npm, yarn, pnpm, and bun.
- Use existing
package.json scripts only.
- Prefer the project's own build, lint, typecheck, test, audit, Lighthouse,
pa11y, axe, load-test, and bundle-analysis scripts when present.
- Respect workspace scripts in monorepos when detectable.
- Do not assume
src/libs, src/app/[locale], src/modules, or any source
root unless the project evidence shows it.
- If a probe cannot run, add it to
probes_skipped with evidence, for example
no lint script found in package.json, tool not installed, network not allowed, not applicable to backend-only profile, or user approval required.
Security redaction is mandatory:
- Never echo secret values from
.env, local config, CI files, shell output, or
source files.
- Never print full lines that contain likely secret values.
- For secret findings, report only file path, line number when available,
key/category name, reason, and redacted evidence such as
API_KEY=[REDACTED].
- Do not run a command that would print secrets. Use safer file/path scanning or
ask for redacted manual inspection.
- Review artifacts and
review_context must not persist secrets.
Step 4 - Review
- Read every file inside the selected
file_scope.
- Run applicable probes using the command discipline above.
- Map each finding to the selected dimension and the loaded ref criteria.
- Assign stable IDs (
R1, R2, R3) and repair tier metadata.
- Emit the report with
review_context, human-readable findings, strengths,
N/A dimensions/refs, and explicit verification gaps.
If evidence is incomplete, mark the finding UNCLEAR or Needs verification
instead of presenting it as a definite blocker. Do not inflate style
preferences into blockers.
Post-review Behavior
When sdcorejs-review is called from a code-generation finish gate, return the
report to the caller. The caller owns repair-loop, acceptance verification,
branch-ready, documentation/task tracker artifacts, and memories. The caller may
invoke sdcorejs-repair-loop only when the finish-gate review choice was "Run
review and repair loop"; a skipped finish-gate review or direct read-only review
must not auto-edit.
The caller must complete any write-producing documentation, task tracker,
memory, changelog, or release-note steps before the final branch-ready gate. No
writes after branch-ready unless branch-ready is run again.
If a finding is a concrete single bug rather than a findings set, keep it in
review_context as evidence. Repair-loop may delegate that one item to
sdcorejs-debug, which returns debug_context before the caller continues the
tail chain.
When sdcorejs-review is invoked directly by the user:
- Stay strict read-only by default.
- Do not edit source code.
- Do not write
.sdcorejs docs, tasks, memories, or summaries by default.
- Do not auto-run
sdcorejs-repair-loop.
- Offer explicit next steps when useful:
Next step:
1. Run sdcorejs-repair-loop on blocking findings.
2. Persist this review summary as a .sdcorejs artifact.
3. Stop after review.
Reply with `1`, `2`, or `3`.
Only option 2 may write a review artifact, and only after the user explicitly
chooses it.
Output Format
Match the user's language at runtime. Keep identifiers, paths, env keys, route
paths, and permission codes exact. Include review_context in every report,
even summary reports.
# Review - <module/feature> - <track> - <track_profile> - <dimension(s)> - <date>
```yaml
review_context:
source: sdcorejs-review
track: angular | nestjs | nextjs | general
track_profile: core-ui-angular | legacy-core-ui-angular | plain-angular | sdcorejs-nestjs | plain-nestjs | nextjs-build-website | plain-nextjs | general
dimensions:
- code | architecture | security | performance | accessibility | ALL
review_mode: quick-table | table | scored | blocking | site-audit
file_scope:
- path/or/glob
refs_loaded:
- ../_refs/...
refs_skipped:
- ref: ../_refs/...
reason: not applicable to this track_profile
package_manager: npm | pnpm | yarn | bun | unknown
probes_run:
- command: command if actually run
exit: exit code if available
notes: redacted or summarized
probes_skipped:
- probe: lint/build/test/lighthouse/pa11y/axe/etc.
reason: no script found, tool not installed, network not allowed, not applicable, or user approval required
finding_ids:
- R1
- R2
repair_gate_mapping:
blocking: Critical/Important or BLOCKER/REQUIRED
confirm: semantic/non-mechanical fixes
user_decision: product/contract/security-policy decisions
```
## Findings
| ID | Severity/Gate | Dimension | File/Line or Scope | Issue | Evidence | Risk | Suggested fix | Repair tier | Gate |
|---|---|---|---|---|---|---|---|---|---|
| R1 | High/REQUIRED | security | src/auth.guard.ts:42 | Missing permission check | redacted/summarized evidence | Unauthorized access | Add resource permission guard | confirm | REQUIRED |
## Strengths
| File/Line or Scope | What's good | Reuse where |
|---|---|---|
## N/A And Skipped
| Item | Reason |
|---|---|
## Next Action
- Blocking findings -> `sdcorejs-repair-loop` only after explicit user/finish-gate choice.
- User-decision findings -> ask for the decision before editing.
- Probe gaps -> run skipped probes only after prerequisites/approval exist.
Findings rules:
- Cite
file:line for every file-level finding. If no file/line exists, mark
the finding as scope-level or architecture-level.
- Do not omit Suggested fix for blocking findings unless the finding is
user-decision or an architecture decision; in those cases, say what decision
is needed.
- Use
auto only for mechanical low-risk fixes. Use confirm for semantic or
non-mechanical fixes. Use user-decision for product, contract,
architecture, migration, security-policy, or UX decisions.
- In table mode, accepted gate values are
BLOCKER, REQUIRED, ADVISORY,
and N/A.
- In quick-table mode, a severity table with no rows must contain
_none_; do
not omit the heading.
Rules
MUST DO
- Classify
track_profile before loading refs.
- Load only applicable refs and record
refs_loaded/refs_skipped.
- Include
review_context in every report.
- Preserve requested dimensions and mode.
- Keep direct review strict read-only by default.
- Redact secrets and avoid commands that expose secret values.
- Use package-manager/script/tool discovery for probes.
- Mark backend-only accessibility as N/A unless explicitly scoped.
- Distinguish real bugs from style preferences.
MUST NOT
- Edit files.
- Silently write
.sdcorejs artifacts from direct review.
- Auto-run repair-loop from direct review.
- Apply SDCoreJS/Core UI/NestJS/build-website conventions to plain profiles.
- Invent missing dependencies, package managers, scripts, tools, source roots,
or monorepo layouts.
- Download probe tools without explicit approval.
- Print or persist secrets.
- Duplicate findings across dimensions.
Cross-references
- General fallback:
../_refs/shared/review-code.md
- Shared baselines:
../_refs/shared/review-{architecture,security,performance,accessibility}.md
- Angular Core UI refs:
../_refs/angular/review-{code,security,performance,accessibility}.md
- NestJS SDCoreJS refs:
../_refs/nestjs/review-{code,security,performance}.md
- Next.js build-website refs:
../_refs/nextjs/build-website/review-{code,security,performance,accessibility}.md
- Repair loop:
sdcorejs-repair-loop
- Single-bug root cause:
sdcorejs-debug
- Verification:
sdcorejs-ship (verify-before-done mode)
