القائمة
Land a finished product task — prune the working files (keep spec.md), then finalize the draft PR into ready-for-review.
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/blockscout/frontend --skill finalize-taskيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
عرض SKILL.md
| name | finalize-task |
| description | Land a finished product task — prune the working files (keep spec.md), then finalize the draft PR into ready-for-review. |
| disable-model-invocation | true |
Land a task whose every progress.md box is checked. Two steps: prune the disposable working files, then
finalize the PR. Why only spec.md survives — the decomposition is preserved in git history, one commit per
ticket — is in ../../tasks/concepts.md.
Confirm the task is done: every box in progress.md is checked. If any is unchecked, stop and report which
ticket is unfinished — there is nothing to land yet.
Then delete the disposable files, keeping only spec.md in the task folder:
tickets/ — the whole directory, review files included.progress.md.questions.md.review.md / review-<tag>.md, if a task-level review ran in md mode.Commit the deletions on the feature branch as the task's final commit — a plain descriptive subject, the
repo's Co-Authored-By trailer, no #issue reference. Pruning before the PR is finalized is what lets
the whole-task review read the spec and the diff without any ticket files.
Hand off to the create-pr skill in finalize-draft mode (Mode B).
Step-by-step checklist for adding a new NEXT_PUBLIC_* environment variable. Use when introducing any new runtime env var.
Close out review findings — adjudicate each one, fix what deserves fixing, then reply on the PR threads or in the task's review file.
Review a change on three axes — spec compliance, repo standards, correctness — then publish the findings as inline PR comments or into a review file in the task folder.