メニュー
WHEN deciding whether a PR, branch, diff, or current code fulfills an issue or specification; NOT for general code review, explanation, or implementation; builds an acceptance contract, proves each criterion, and returns a verdict.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
WHEN checking what a meeting or transcript decided and whether specs, issues, PRs, and code carry it forward; NOT for summaries, glossaries, or implementation; preserves uncertainty across an evidence chain and reports current implementation status.
WHEN shipping finished local changes through a GitHub pull request and staying with it until the user merges; NOT for developing unfinished work or choosing substantial behavioral or conflict resolutions; commits with commit-messages, pushes, creates with gh, repairs minor CI or conflicts, and polls through merge.
WHEN designing or debugging App Intent-first iOS features for Siri, Shortcuts, widgets, Live Activities, or SwiftUI reuse; NOT UIKit-only flows; provides AppEntity, metadata, prompting, and view-reuse patterns.
WHEN reducing whole-system complexity—branches, state, dependencies, layers, or moving parts—in an existing system or feature; NOT for functionality cuts or unproven rewrites; derives the minimum mechanism from first principles and proves behavior and guarantees are conserved.
WHEN scraping iOS/macOS App Store data (apps, reviews, ratings, search); NOT for installing or testing apps; retrieves structured JSON data using iTunes/App Store APIs with curl and jq formatting
Comprehensive guide for implementing on-device AI models on iOS using Foundation Models and MLX Swift frameworks. Use WHEN building iOS apps with (1) Local LLM inference, (2) Vision Language Models (VLMs), (3) Text embeddings, (4) Image generation, (5) Tool/function calling, (6) Multi-turn conversations, (7) Custom model integration, or (8) Structured generation.
| name | acceptance-review |
| description | WHEN deciding whether a PR, branch, diff, or current code fulfills an issue or specification; NOT for general code review, explanation, or implementation; builds an acceptance contract, proves each criterion, and returns a verdict. |
Treat the authoritative requirement as a contract and prove it against the implementation. Keep the review read-only; hand requested fixes to an implementation workflow after the verdict.
Resolve the subject, comparison base, authoritative issue or specification, repository rules, linked decisions, and stated exclusions.
Map every normative statement to one independently decidable criterion. Preserve its source identifier and meaning; split combined statements when their outcomes can differ. Record the observable outcome, affected surfaces and edge cases, assumptions, and exclusions.
Complete when: every in-scope normative statement maps exactly once and every ambiguity or exclusion is visible.
For each criterion, trace the real production path from entry point through state, boundaries, errors, and observable outcome. Search every caller, implementation, and sibling surface that shares the behavior. Compare with the base only to establish regression.
Keep three evidence lanes:
| Lane | What counts |
|---|---|
| Implementation | Production wiring that can produce the outcome |
| Verification | Executed checks or runtime observations; name the command and result |
| Claim | Issue/PR prose, commits, names, and comments; intent only, never behavioral proof |
Cite the exact file and line for code, and the file and case name for tests. Test presence is not a passing result.
Complete when: every criterion has a complete traced path or a named break, and every citation directly supports its row.
Run the smallest check that exercises each observable outcome. Broaden only for shared code, cross-surface behavior, regression risk, or high-risk boundaries. Record what each result proves. Keep the subject unchanged; make unavailable checks explicit.
Complete when: every criterion has executed evidence, decisive static evidence, or a named verification gap.
| Status | Meaning |
|---|---|
| Covered | The complete production path supports the criterion and proportionate evidence passes |
| Partial | Some required outcomes, surfaces, or edge cases are unsupported |
| Missing | The production path is absent or disconnected |
| Regressed | Comparison evidence proves previously supported behavior broke |
| Unverified | Available implementation or execution evidence cannot decide the outcome |
Set the overall verdict:
Lead with the verdict, subject, base, and authoritative sources. Then provide:
| ID | Criterion | Status | Implementation evidence | Verification evidence |
|---|
List claims only when they clarify intent. Follow with gaps, unavailable checks, and the minimum evidence or implementation needed to close each row. Keep general code-review findings outside this report.
