菜单
Fourth stage of the LAD feature workflow. Runs final quality validation, checks that what was delivered matches what was planned, updates documentation, and prepares the commit or pull request. Use when a feature's implementation is complete and ready to be reviewed or merged.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/chrisfoulon/LAD --skill finalize-feature命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Final stage of the LAD feature workflow, run after a feature is merged. Condenses the working plan and context files into a durable record — appended to the project's existing ADR where one exists, or a new decision record where none does — harvests any new guardrails, and prunes the working files. Use after merging a feature, or when asked to write up what was done and why.
Assess whether the codebase still matches what the project says about itself — decision records, ADRs, documentation and unfinished plans. Reports drift and leftover work without fixing it. Use when picking up a project after time away, when you suspect the docs no longer describe reality, or when asked what state a codebase is actually in.
First stage of the LAD feature workflow. Clarifies the request, searches the codebase for work that already does the job, decides whether to integrate/enhance/rebuild, locates the relevant code and documentation as concrete references, and records a quality baseline before any code is written. Use at the start of any non-trivial feature, or when asked to add functionality to an existing Python project.
基于 SOC 职业分类
正在显示 SKILL.md
| name | finalize-feature |
| description | Fourth stage of the LAD feature workflow. Runs final quality validation, checks that what was delivered matches what was planned, updates documentation, and prepares the commit or pull request. Use when a feature's implementation is complete and ready to be reviewed or merged. |
| argument-hint | ["feature slug"] |
The purpose of this stage is to find the gap between what you believe you built and what is actually in the diff. Assume there is one.
pytest -q --tb=short 2>&1 | tail -n 100
pytest --cov=<module> --cov-report=term-missing 2>&1 | tail -n 40
flake8 --statistics
Against the kickoff baseline:
Walk the plan and verify each ticked box against the code, not against memory:
TODO, pass, NotImplementedError or placeholder left in the diff?Read the actual diff: git diff --stat then review the substantive files. Reviewing your own work
from memory finds nothing.
lad-standardsUpdate what the kickoff stage identified as needing it — that list exists precisely so this step is not guesswork:
Verify examples actually run. A documentation example that was never executed is usually wrong.
If implementation surfaced issues you deliberately left alone — pre-existing violations, adjacent
technical debt, refactors that were out of scope — record them rather than dropping them. Append to
MAINTENANCE_REGISTRY.md if the project has one, and mention them in your report so the user can
decide whether to spend time on them via /lad:maintenance-session.
Conventional Commit, describing what changed and why:
feat(<slug>): <what it does now that it did not before>
- <change>
- <change>
Tests: <N> passing (<M> new). Coverage: <X>% on new code.
Do not put invented figures in commit messages. If you cannot measure something, leave it out.
Open the PR only if asked. Never merge without being asked.
State plainly: what was built, quality numbers, anything deferred or dropped, and known limitations. If something is incomplete, say it here — a finalization report that claims completeness while the diff disagrees is worse than no report.
After the feature is merged, run /lad:consolidate-feature to condense the working files into a
durable record.