메뉴
Convert vague product or engineering requests into executable repo-local specs before coding. Use when a task is ambiguous, feature-sized, risky, cross-cutting, or needs acceptance criteria, non-goals, testing plan, rollout notes, or architecture impact.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Diagnose failed or unreliable agent workflows by classifying bad assumptions, missing observations, tool misuse, wrapper failures, hidden repair loops, incomplete validation, handoff gaps, and repeated failure patterns. Use after a failed harness run, flaky agent output, or confusing validation loop.
Review agent-generated changes against project rules. Use when asked for a review, before opening a PR, after large Codex edits, or when checking diffs for correctness, security, architecture, tests, docs drift, dependencies, migrations, and release risk.
Generate or maintain a minimal high-signal AGENTS.md for coding agents. Use whenever a repo needs agent instructions, an existing AGENTS.md is too long or vague, or project docs/scripts need a concise routing map for Codex.
Define and mechanically enforce architecture boundaries for a repo. Use when a project needs allowed dependency rules, forbidden imports, layer documentation, dependency maps, circular dependency checks, or protection against agent-created architectural drift.
Scaffold a new TypeScript web, mobile, API, or full-stack project with Better-T-Stack, then harden it with the Pax Fullstack Harness. Use whenever the user wants a new TypeScript app scaffold, mentions Better-T-Stack, asks for a modern type-safe stack, or wants Codex to start a repo that is agent-ready from day one.
Use guided Chrome DevTools MCP setup and workflows for browser runtime debugging. Use when a web app needs console, network, DOM, accessibility, Lighthouse, performance, responsive, or live-browser investigation beyond normal tests.
| name | prompt-to-spec-converter |
| description | Convert vague product or engineering requests into executable repo-local specs before coding. Use when a task is ambiguous, feature-sized, risky, cross-cutting, or needs acceptance criteria, non-goals, testing plan, rollout notes, or architecture impact. |
Turn a user request into a decision-complete spec that an agent or engineer can implement without guessing.
Use openspec-sdd instead when the user wants formal spec-driven development, OpenSpec artifacts, proposal/design/tasks, delta specs, or archiveable feature history.
AGENTS.md and validation scriptsSeparate facts from assumptions.
$research-first-change when the spec depends on current external APIs, package behavior, standards, or security guidance.Draft the spec.
Save the spec.
docs/specs/YYYY-MM-DD-feature-name.md.Link follow-on work.
task-planning-and-pr-protocol when the spec is ready for implementation planning.openspec-sdd when the lightweight spec should become a formal OpenSpec change.feature-state-machine when the spec becomes multi-step implementation work with WIP state and evidence.