القائمة
Review a set of code changes against Sculptor's review categories and produce a markdown findings table. Use when reviewing code (your own or others').
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Build or modify a Sculptor extension — a runtime ESM module loaded into the Sculptor UI. Use when asked to write an extension (or "plugin") for Sculptor, add a panel, overlay, workspace widget, home view, or settings UI to Sculptor, or to iterate on an extension with `sculpt extension`. Works from any repo; this file is a self-contained reference (the Sculptor source code is optional).
Interact with Sculptor programmatically using the sculpt CLI. Use this skill when using `sculpt`, or when designing or planning a workflow that would benefit from understanding the structural capabilities of `sculpt` (workspaces, agents, isolation, and how code flows between them).
Live, hot-reloading preview of the Sculptor WEB frontend from a phone or any browser, served through the OpenHost nginx /proxy front. ONLY relevant when running INSIDE the openhost-deployed Sculptor (the container fronted by nginx on :5050, reachable at https://sculptor.<zone>/) — NOT for local or Electron dev. Frontend-only: it reuses the single shared backend, so it previews UI/frontend changes, not a per-workspace backend. Invoke when iterating on the web UI and wanting to see it live in a browser through the OpenHost SSO front.
How this OpenHost-hosted Sculptor environment works — storage and what survives restarts, where/how to add repositories and authorize gh, and the /proxy/<port>/ capability for previewing loopback web apps from a browser. ONLY relevant when running inside an OpenHost deployment (detect via the OPENHOST_* env vars, e.g. OPENHOST_APP_NAME). Ships with the deploy image and is refreshed every release.
Test a pull request by creating a shallow clone at the PR's commit and launching Sculptor. Use when you need to test changes from a specific PR in isolation.
QA the Sculptor mobile web UI on a real iOS Simulator, driven headlessly from a Mac. A single CLI boots a notched iPhone, launches the local frontend server (parsing its port — no hardcoding), opens the app in MobileSafari, taps/swipes via idb, and screenshots each step. Includes the Add-to-Home-Screen standalone flow — the only way to verify notch / status-bar / home-indicator safe-area rendering (env(safe-area-inset-*) is 0 everywhere except real iOS). Use when visually verifying mobile/responsive changes on an iPhone.
| name | code-review-checklist |
| description | Review a set of code changes against Sculptor's review categories and produce a markdown findings table. Use when reviewing code (your own or others'). |
Review a set of code changes against the categories below and produce a markdown findings table.
git commands. Default: the current repo.<base>...<head> (three dots). Default if
not specified: git diff origin/main...HEAD.Read it before reading the diff so the goal is fresh while you're reviewing.
Run git diff <base>...<head> in the working directory and read the full
output. For very large diffs, also list changed files
(git diff --stat <base>...<head>) and prioritize files most relevant to the
stated goal.
Also read the commit messages in the range (git log <base>..<head>) — they
are part of what you review (see "Public-facing text" and "Git hygiene").
For each category below, look for issues in the diff. Be exhaustive — a single file can have multiple issues of the same type. Don't skip categories that look empty at a glance; spend a moment confirming.
For frontend (.tsx) changes, you MUST read docs/development/review/react.md
(generic React rules), docs/development/review/sculptor.md (Sculptor-specific
conventions: backend data hooks, Jotai atoms, component invariants), and
docs/development/review/design.md (design-system usage, existing patterns,
UI copy) in full and apply every rule in them. Do not skip this step. Do not
rely on summaries elsewhere in this checklist or on prior knowledge — the docs
are the source of truth and are updated independently.
For integration test changes (under sculptor/tests/integration/), you MUST
read the file docs/development/review/integration_tests.md in full and apply every rule
in it. Same reasoning as above.
Output one section per category in the order they appear under "Categories" below. Every category must have a section in your output — including ones where you found no issues. This forces you to confirm you actually reviewed each category rather than letting empty ones slip past unnoticed.
For each category, write a heading with the category name, then either prose findings or an explicit "no issues" line.
Write each finding as a short paragraph, not as a table row. Lead with the severity tag in bold, then the file path and line numbers, then a one- to three-sentence explanation of what's wrong and why it matters. Multiple findings in the same category go as separate paragraphs, blank-line separated.
Example output:
### Correctness
**HIGH** — `path/foo.py:42-48`. `bar()` is called with `None` when `x` is
empty, and `bar` does not guard against that. This will raise an
`AttributeError` at runtime on the empty-list path, which the new tests
don't cover.
**MEDIUM** — `path/baz.py:101`. The loop runs `range(len(items) - 1)`, so
the last item is silently skipped. Likely an off-by-one introduced when the
slice was removed in this change.
### Consistency with stated goal
No stated goal provided — section skipped.
### Test coverage
No issues found.
Each section must be one of:
No issues found., ORNo stated goal provided — section skipped.Do NOT collapse multiple empty categories into a single "no issues" note. Do NOT omit a category section. If you do, it signals you didn't review it. Do NOT use markdown tables — prose only.
Severity:
After the per-category sections, write a short summary (2–4 bullets):
None/empty/zero/negative inputs, boundary valuesxfail/disabled without justificationThis category applies when the stated goal is an MR/PR body produced by an autonomous workflow (e.g. /sculptor-workflow:fix-bug). Skip the category if no stated goal was provided, or if the stated goal is a spec/ticket rather than an MR body.
sculptor/frontend/, any .tsx, .css, or other UI surface) and the MR body's "Before" or "After" slots lack an embedded image (e.g. <img src="..."> or a markdown image link), flag it as HIGH. Test output is not a substitute.<hash>" with a placeholder or empty hash, flag it.TODO/FIXME/XXX comments without an owner or ticketconsole.log, print(...), pdb, breakpoint(),
debuggeragent_docs/...
paths, REQ-* requirement IDs, or implementation-plan phase references.
The comment must stand on its own.dev, foo,
alice) for usernames in /Users/<name>/ paths or example branch names.except: or unconditional except Exception:except: pass etc.)Any types unless justifiedElementIDs changed, run
just generate-api.tsx changes)Required: Read docs/development/review/react.md (generic React rules),
docs/development/review/sculptor.md (Sculptor-specific frontend conventions), and
docs/development/review/design.md (design-system usage, existing patterns, UI copy)
in full with the Read tool, and apply every rule in them. The rules cover effects,
state, refs, render purity, performance, props, lists, backend data hooks,
Jotai atom usage, component-level invariants, design-token and component-reuse
conventions, and UI copy — detailed enough that summarizing them here would lose
information, so this section intentionally does not list them. If you find
yourself reviewing a .tsx change without having opened all three docs in the
current session, stop and read them.
Beyond the docs: IconButton in a Flex uses gap="2" (per CLAUDE.md).
sculptor/tests/integration/)Required: Read docs/development/review/integration_tests.md in full with the Read
tool and apply every rule in it. The rules cover Playwright assertion
patterns, test isolation, and POM usage — they're detailed enough that
summarizing them here would lose information, so this section intentionally
does not list them. If you find yourself reviewing an integration test change
without having opened that doc in the current session, stop and read it.
# noqa: E402)is_/has_/should_/etc.num_ prefix (use count_ or _idx suffix)just ratchets if you suspect any counts changed; flag any increasesCommit messages and the PR/MR title and description are published to a public
repository — review them as permanently, world-readable artifacts. Read the
commit messages in the range (git log <base>..<head>) as well as the stated
goal (the PR/MR body, when one was provided). Flag any of the following:
/Users/<name>/).
These should be reworded to roles or generic placeholders (dev, <user>).SCU-1447) is fine; pasting the ticket's private
contents is not.This is the same standard as the Comments category, extended from code comments to the commit/PR prose. See also CLAUDE.md, "Public Visibility: Commit Messages and PR Descriptions".