القائمة
Finish a completed piece of work and integrate it cleanly — verify, then decide how to merge, PR, or set it aside. Use when implementation is done and tests pass, and you need to land the work and clean up.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Query forge's live, always-fresh code map — a dependency graph of the repo with god-nodes, modules, and neighbors/impact (blast-radius) queries. Use before editing to know what depends on a file, to find the most-depended-on hotspots, to map an unfamiliar codebase's architecture, or whenever you need current structural context instead of guessing.
Build an accurate mental map of unfamiliar code before changing it. Use when starting work in a codebase or area you don't know well, before editing code whose ripple effects you can't predict, or when the user asks how something works or where something lives.
Design the shape of a non-trivial module, API, or system before implementing it. Use when a design decision has more than one reasonable answer, when introducing a new abstraction or interface, or when getting the shape wrong would be expensive to undo.
Turn a vague idea into an approved, written spec before any code is written. Use before building a feature, adding functionality, or changing behavior — whenever the work is more than a trivial mechanical edit and the requirements aren't already pinned down.
Find the root cause of a bug, test failure, or performance regression before proposing any fix. Use the moment something is broken, throwing, failing, flaky, or slower than expected — and resist the urge to patch first.
Build or redesign frontend UI that doesn't look templated or AI-generated. Use when creating components, pages, landing pages, or restyling existing UI — before writing CSS/markup, and before shipping any visual work.
| name | ship |
| description | Finish a completed piece of work and integrate it cleanly — verify, then decide how to merge, PR, or set it aside. Use when implementation is done and tests pass, and you need to land the work and clean up. |
███████╗██╗ ██╗██╗██████╗
██╔════╝██║ ██║██║██╔══██╗
███████╗███████║██║██████╔╝
╚════██║██╔══██║██║██╔═══╝
███████║██║ ██║██║██║
╚══════╝╚═╝ ╚═╝╚═╝╚═╝
The end of a task is where state gets messy — half-merged branches, orphaned worktrees, premature pushes. This closes work out cleanly.
Do not start shipping until forge:verify is green with this-turn evidence. Re-run the verify command(s) now and read the exit code / summary line in this same turn — "it passed earlier" is not evidence. If you can't show the output from this turn, stop and go verify. If anything is red or unverified, you're not finishing; you're still working.
Establish where you are before acting: Are you in a git worktree or the main checkout? On a feature branch, main, or detached HEAD? Is the tree clean? This determines which options are even valid.
main and create a fat diff)(On detached HEAD, drop option 1.) Don't assume — integration choices are the user's.
git status inside it shows nothing to commit) — removing a dirty worktree loses work and is forbidden. After deleting a worktree directory, run git worktree prune.git log --oneline -20; if most subjects follow Conventional Commits (type(scope): subject), use that form, otherwise mirror the dominant style — and state which you detected before committing. Do not add AI/Claude co-author attribution or "generated with" trailers unless the user explicitly asks — match the user's own commit style.push or force-push without an explicit request. Landing locally and pushing are separate decisions; the second is the user's to make.Work landed (or deliberately parked) with a clean tree and no orphaned state.