菜单
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.