spec-finish · diff
git:20260727.3faefd4 to git:20260801.96f6fe8
35 added, 47 removed. Audit A to A.
---
name: spec-finish
description: >
- Post-implementation completion workflow for Inline Plans and Spec-backed Plans. Use after
- spec-implement completes to validate, review, create stacked commits, and open a PR via
- code-pull-request. Triggers when implementation is done or the user says "finish", "done",
- or "complete".
+ Post-implementation completion workflow for Spec-backed Plans. Use after spec-implement
+ completes to validate, review, create stacked commits, and open a PR via code-pull-request.
+ Triggers only with an active Spec-backed Plan after spec-implement completes, including when
+ the user says "finish", "done", or "complete" in that context.
user-invocable: true
---
# Spec Finish
- Post-implementation workflow: validate → review → stack commits → prepare PR.
+ Post-implementation workflow: synchronize docs → validate → review → prepare PR.
## Prerequisites
Before starting, verify:
- 1. All Inline Plan changes and validation items are complete, or all Spec-backed Plan tasks are complete
- 2. Working directory is clean (committed or staged)
+ 1. All Spec-backed Plan tasks are complete
+ 2. Working directory has no unresolved staged or unstaged changes
3. Tests pass
- If not complete, go back to `spec-implement` in the active planning mode.
+ If not complete, go back to `spec-implement`.
---
- ## Step 1: Validate
+ ## Step 1: Update Documentation
+ Check whether README, API documentation, or changelog updates are needed. Make and commit any
+ necessary documentation changes through **code-commit** before final validation.
+
+ ---
+
+ ## Step 2: Validate
+
Run validation checks.
### Test Suite
```bash
npm test
# or
pytest
# or
cargo test
```
### Type Check
```bash
npm run typecheck
# or
python -m mypy
# or
cargo check
```
### Lint
```bash
npm run lint
# or
ruff check .
# or
cargo clippy
```
### Build
```bash
npm run build
# or
go build ./...
```
- **If any fail:** Return to `spec-implement` in the active planning mode to fix.
+ **If any fail:** Return to `spec-implement` to fix.
**If all pass:** Proceed.
---
- ## Step 2: Review
+ ## Step 3: Review
- Use the Skill tool to invoke code-review skill for comprehensive code review.
+ Invoke the installed **code-review** skill through the harness's skill mechanism for one
+ comprehensive review of the final change.
### What to Review
- - All changed files since feature branch
+ - All changed files since the intended base branch's merge base
- Test coverage
- Documentation updates
- No debug code left
### If code-review finds issues
- - Fix or note for follow-up
- - Re-validate
-
- ---
-
- ## Step 3: Stack Commits
-
- ### Workflow
- 1. Review current commits: `git log --oneline`
- 2. Ensure commits are organized logically
- 3. Rebase if needed: `git rebase -i <base-branch>`
- 4. Ensure each commit is clean and functional
-
- ### Commit Guidelines
- - Each commit should pass tests
- - Use conventional commit format
- - Meaningful commit messages
+ - Minor fixes may be made here, then re-validated and reviewed.
+ - Blocking or scope-changing fixes return to `spec-implement`.
---
- ## Step 4: Update Documentation
-
- ### Check for Updates
- - README changes needed?
- - API documentation updated?
- - Changelog updated?
+ ## Step 4: Prepare Commits
- ### If documentation needed
- - Update relevant docs
- - Commit with docs
+ Review current commits with `git log --oneline`. Use **code-commit** for any uncommitted work.
+ Do not rewrite history by default. If a rebase would materially improve an unpublished stack,
+ show the affected range and ask for separate approval before rebasing.
---
- ## Step 5: Open the PR
+ ## Step 5: Prepare the PR
- Steps 1-4 (validate, review, stack commits, update docs) must all be complete
- before proceeding. **If code-review found blocking issues, stop and return to
- spec-implement in the active planning mode to fix them. Do not proceed to Step 5b.**
+ Steps 1-4 (documentation, validation, review, commits) must all be complete
+ before proceeding. **If code-review found blocking or scope-changing issues, stop and return
+ to spec-implement to fix them. Do not proceed to Step 5b.**
### Step 5a: Present Completion Summary
Before creating the PR, present a summary to the human:
```
## Completion Summary
**Feature:** [name]
**Tests:** [passed/failed]
**Type Check:** [passed/failed]
**Lint:** [passed/failed]
**Review:** [passed/issues found]
**Commits:** [N commits in stack]
**Ready for PR:** [yes/no]
```
### Step 5b: Invoke code-pull-request
Only when the summary shows **Ready for PR: yes**, invoke the
[code-pull-request](../code-pull-request/SKILL.md) skill to create the PR. It
detects the platform (GitHub/GitLab), checks for an existing PR, finds a
template, generates the body from commits, and opens the PR via `gh` or `glab`.
### Handoff
- > "Implementation complete. [N] commits stacked. Opening PR now."
+ > "Implementation complete. [N] commits are ready. PR package ready for approval."
---
## Integration
This skill orchestrates other skills:
- Invokes code-review for quality check
- Invokes code-pull-request as the final step to open the PR
---
## When NOT to Use
- - If implementation still in progress, use spec-implement in the active planning mode
- - If tests are failing, go back to spec-implement in the active planning mode
- - If review found blocking issues, go back to spec-implement in the active planning mode
+ - If implementation is still in progress, use spec-implement
+ - If tests are failing, go back to spec-implement
+ - If review found blocking or scope-changing issues, go back to spec-implement