メニュー
Use when a GitHub issue receives new comments during autonomous work — decides whether to update the spec and re-decompose, or just make the change inline
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
Audit repository test suites for low-value, brittle, duplicative, or AI-generated tests. Use when Codex needs to review tests across a single project or monorepo, identify tests to delete or merge, upgrade weak tests, consolidate repeated setup into helpers, or produce a precise test quality cleanup plan.
Use when you have a plan directory from decomposing-specs and need to execute it — loads phases on demand, dispatches phase-elaborator for sketched phases, runs implementers with size-scaled phase reviews, and validates the full spec at the end
Use when you have a design spec from writing-specs and need to break it into an implementable, phased task plan with behavior-focused verification before writing any code
Use when given a GitHub issue URL to autonomously implement — forks the repo, writes a spec if needed, decomposes into tasks, implements, and opens a PR
Use when given a GitHub issue URL to autonomously implement — forks the repo, writes a spec if needed, decomposes into tasks, implements, and opens a PR
Use when configuring a repository to run with Code Factory — creates `.code-factory/config.toml`, sets up a devcontainer if missing, and validates that build/lint/test work inside it. Triggers on "setup code factory", "configure code factory", "onboard this repo to code factory".
SOC 職業分類に基づく
| name | receiving-feedback |
| description | Use when a GitHub issue receives new comments during autonomous work — decides whether to update the spec and re-decompose, or just make the change inline |
Handle new comments that arrive on the issue or PR during code-factory Steps 6–8 or after the PR is open. Be selective: only re-run decomposing-specs when the change meaningfully alters EARS requirements.
Automated / bot (CI status, approvability, merge-conflict warnings, etc.) → react with 👍 and stop.
Trivial change — renames, wording, typos, narrow bug fixes the reviewer spotted in the diff, added test cases, cleanup, or any behavior tweak that does not add/remove/alter an EARS requirement (WHEN/IF/WHILE/WHERE … SHALL …):
Meaningful requirement change — adds/removes/alters an EARS requirement, new user story, changes data model / API / integration boundaries, or invalidates a completed task:
docs/plans/YYYY-MM-DD-issue-${ISSUE_NUMBER}-design.md.decomposing-specs to regenerate the plan directory. The decomposer will rewrite plan.md, standards.md, and phase files. Already-completed phases stay on disk; the new plan should preserve their structure where the requirements still hold.executing-plans from the earliest affected phase. If a downstream phase was a sketch, the phase-elaborator will pick up the new requirements when its turn comes — no manual rework needed for sketched phases.Won't fix — suggestion is impossible, incorrect, or conflicts with the spec's intent: