القائمة
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 ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
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".
| 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: