finalize

Name: finalize
Author: tobihagemann

23installs29forks

How to install finalize?

tobihagemann/turbo/finalize

$npx -y skills add tobihagemann/turbo --skill finalize

Installs into the current project.

Summary

Run the post-implementation quality assurance workflow including tests, code polishing, review, and commit. Use when the user asks to \"finalize implementation\", \"finalize changes\", \"wrap up implementation\", \"finish up\", \"ready to commit\", or \"run QA workflow\".

Files · 1

View on GitHub

SKILL.md

1	# Finalize Implementation
2
3	Post-implementation QA workflow: tests, code polishing, commit, and self-improvement.
4
5	## Task Tracking
6
7	At the start, use `TaskCreate` to create a task for each phase:
8
9	1. Run `/polish-code` skill
10	2. Run `/simplify-docs` skill
11	3. Run `/update-changelog` skill
12	4. Run `/self-improve` skill
13	5. Ship It
14
15	## Phase 1: Run `/polish-code` Skill
16
17	Run the `/polish-code` skill for the current changes.
18
19	## Phase 2: Run `/simplify-docs` Skill
20
21	Run the `/simplify-docs` skill on the staged changes (`git diff --cached`). Stage any edits it makes before continuing.
22
23	## Phase 3: Run `/update-changelog` Skill
24
25	Run the `/update-changelog` skill.
26
27	## Phase 4: Run `/self-improve` Skill
28
29	Run the `/self-improve` skill for the current session. Always run this phase even if the session seemed routine.
30
31	## Phase 5: Ship It
32
33	### Step 1: Analyze Split
34
35	Examine the staged changes and evaluate whether they form a single reviewable unit or several independently reviewable units. This step decides only whether to split; the chosen ship skill owns all repository-state detection and the commit, push, branch, and PR intent.
36
37	Run `git diff --cached --stat` and `git diff --cached` to understand the scope. Categorize changes along three dimensions:
38
39	- Concern type: refactoring, bug fix, new feature, cleanup, dependency update
40	- Layer/domain: backend, frontend, database migrations, i18n, tests, configuration
41	- Logical unit: files that form a coherent, independently reviewable change
42
43	A split is warranted when the staged changes contain multiple reviewable units. Each unit should be independently understandable, testable, and revertable. When deciding group boundaries, consider whether a reviewer could evaluate each group without needing context from the others.
44
45	### Step 2: Present Analysis and Choose Path
46
47	Output the split analysis as text.
48
49	If changes form a single cohesive unit, note this and run the `/ship` skill.
50
51	If changes span multiple reviewable units, propose an ordered list of groups. For each group, specify:
52
53	- Name and one-line description
54	- File list (flag files with mixed-concern hunks)
55	- Dependencies: which earlier groups, if any, this group builds on
56
57	Use `AskUserQuestion` to let the user choose whether to ship the changes together or split them up.
58
59	- Ship together — ship all staged changes as one unit; run the `/ship` skill
60	- Split up — ship each group as its own unit; run the `/split-and-ship` skill
61
62	Then use the TaskList tool and proceed to any remaining task.
63
64	## Rules
65
66	- Diff size, number of files changed, passing tests, perceived user urgency, or context window concerns are not reasons to skip a phase. Each phase does work beyond what those signals cover. "The session was long" or "a prior phase was thorough" are never valid reasons to skip a later phase.
67	- Never stage or commit files containing secrets (`.env`, credentials, API keys). Warn if detected.
68	- Do not present diffs to the user — the user reviews diffs in an external git client. Use `git diff` internally as needed.
69	- If a non-test step fails (polish, review), stop and report the failure. Do not skip ahead.

People who liked this also viewed

6 picks

Type

finalize

23installs29forks

View on GitHub

How to install finalize?

tobihagemann/turbo/finalize

$npx -y skills add tobihagemann/turbo --skill finalize

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Finalize Implementation
2
3	Post-implementation QA workflow: tests, code polishing, commit, and self-improvement.
4
5	## Task Tracking
6
7	At the start, use `TaskCreate` to create a task for each phase:
8
9	1. Run `/polish-code` skill
10	2. Run `/simplify-docs` skill
11	3. Run `/update-changelog` skill
12	4. Run `/self-improve` skill
13	5. Ship It
14
15	## Phase 1: Run `/polish-code` Skill
16
17	Run the `/polish-code` skill for the current changes.
18
19	## Phase 2: Run `/simplify-docs` Skill
20
21	Run the `/simplify-docs` skill on the staged changes (`git diff --cached`). Stage any edits it makes before continuing.
22
23	## Phase 3: Run `/update-changelog` Skill
24
25	Run the `/update-changelog` skill.
26
27	## Phase 4: Run `/self-improve` Skill
28
29	Run the `/self-improve` skill for the current session. Always run this phase even if the session seemed routine.
30
31	## Phase 5: Ship It
32
33	### Step 1: Analyze Split
34
35	Examine the staged changes and evaluate whether they form a single reviewable unit or several independently reviewable units. This step decides only whether to split; the chosen ship skill owns all repository-state detection and the commit, push, branch, and PR intent.
36
37	Run `git diff --cached --stat` and `git diff --cached` to understand the scope. Categorize changes along three dimensions:
38
39	- Concern type: refactoring, bug fix, new feature, cleanup, dependency update
40	- Layer/domain: backend, frontend, database migrations, i18n, tests, configuration
41	- Logical unit: files that form a coherent, independently reviewable change
42
43	A split is warranted when the staged changes contain multiple reviewable units. Each unit should be independently understandable, testable, and revertable. When deciding group boundaries, consider whether a reviewer could evaluate each group without needing context from the others.
44
45	### Step 2: Present Analysis and Choose Path
46
47	Output the split analysis as text.
48
49	If changes form a single cohesive unit, note this and run the `/ship` skill.
50
51	If changes span multiple reviewable units, propose an ordered list of groups. For each group, specify:
52
53	- Name and one-line description
54	- File list (flag files with mixed-concern hunks)
55	- Dependencies: which earlier groups, if any, this group builds on
56
57	Use `AskUserQuestion` to let the user choose whether to ship the changes together or split them up.
58
59	- Ship together — ship all staged changes as one unit; run the `/ship` skill
60	- Split up — ship each group as its own unit; run the `/split-and-ship` skill
61
62	Then use the TaskList tool and proceed to any remaining task.
63
64	## Rules
65
66	- Diff size, number of files changed, passing tests, perceived user urgency, or context window concerns are not reasons to skip a phase. Each phase does work beyond what those signals cover. "The session was long" or "a prior phase was thorough" are never valid reasons to skip a later phase.
67	- Never stage or commit files containing secrets (`.env`, credentials, API keys). Warn if detected.
68	- Do not present diffs to the user — the user reviews diffs in an external git client. Use `git diff` internally as needed.
69	- If a non-test step fails (polish, review), stop and report the failure. Do not skip ahead.

People who liked this also viewed

6 picks

Type