メニュー
Compare an existing architecture/solution against a specific reference and decide KEEP, PARTIAL ADOPT, or REPLACE with explicit migration steps. Use only when both current-state material and a concrete reference are provided.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Review a target app or project's feature specs, proof plans, proof evidence, successful tests, evaluator results, and user corrections to suggest app-specific improvements, new features, proof hardening, and reusable harness lessons without applying changes. Use when Codex should manually analyze whether features, proofs, and successful checks make sense and produce suggestions for the app/project or for dot-codex harness evolution.
Turn an overall app description into a sharper app brief, bootstrap repo-level docs, create a series of features, executable proof packages, and the feature queue. Use for greenfield work when the user has an app idea and wants Codex to initialize the project before returning to feature execution. Use the `research` skill when assumptions need external evidence.
Execute a feature queue, one feature, or a stubborn issue fix through a Codex Goal with explicit PROOF.md verification, evaluator judgment, bounded repair, and queue progress updates. Use when the user asks for autonomous execution, keep-going-until-done behavior, queue completion, or repeated repair after coding-feature-execute or coding-repair.
Evaluate whether a completed feature or issue fix is actually done using a read-only skeptical review of FEATURE.md, PROOF.md, primary proof results, gate results, architecture fit, and anti-gaming risks. This is the done judge, not the test runner. Use after coding-feature-execute, coding-repair, or coding-autonomous-execute before marking work complete.
Implement one feature end-to-end in Codex App using FEATURE.md for desired behavior, PROOF.md for done criteria, existing repo skills, red/green proof-first work, deterministic validation, mandatory backend/frontend/WordPress domain-skill handoff, and bounded repair. Use when a feature contract and proof contract are ready or need to be made ready before delivery.
Review FEATURE_DIR/FEATURE.md and FEATURE_DIR/PROOF.md before non-trivial implementation for ambiguity, edge cases, testability, proof quality, and architecture conflicts without adding framework phases.
| name | coding-compare-architectures |
| description | Compare an existing architecture/solution against a specific reference and decide KEEP, PARTIAL ADOPT, or REPLACE with explicit migration steps. Use only when both current-state material and a concrete reference are provided. |
| metadata | {"short-description":"Compare current architecture with a reference"} |
Purpose: compare the current architecture or solution with a concrete reference and decide whether to keep it, partially adopt the reference, or replace it.
If inputs are incomplete, ask only blocking questions (max 3).
Normalize both designs into the same model:
Diff:
Decide:
If decision ≠ KEEP, produce a spec:
