메뉴
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:
