polish-code

Name: polish-code
Author: tobihagemann

4installs29forks

How to install polish-code?

tobihagemann/turbo/polish-code

$npx -y skills add tobihagemann/turbo --skill polish-code

Installs into the current project.

Summary

Stage, format, lint, test, review, smoke test, and re-run itself until stable. Use when the user asks to \"polish code\", \"refine code\", \"iterate on code quality\", \"review loop\", \"clean up, test, and review loop\", or \"run the polish loop\".

Files · 1

View on GitHub

SKILL.md

1	# Polish Code
2
3	## Task Tracking
4
5	At the start of every invocation (including re-runs from Step 7), use `TaskCreate` to create a task for each step:
6
7	1. Run `/stage` skill
8	2. Deterministic cleanup
9	3. Run `/review-code` skill
10	4. Run `/evaluate-findings` skill
11	5. Run `/apply-findings` skill
12	6. Run `/smoke-test` skill
13	7. Re-run `/polish-code` skill if changed
14
15	## Step 1: Run `/stage` Skill
16
17	Run the `/stage` skill.
18
19	## Step 2: Deterministic Cleanup
20
21	Run the project's full verification gate: every check it defines as a pass/fail condition. The goal is that passing this step means the project's own checks (and CI, where it exists) pass. Build the gate by combining every source below that the project declares (sources 1-3); run the baseline (source 4) only when the project declares none of them:
22
23	1. CI config — where present, it is the authoritative gate; run the checks it enforces.
24	2. Check scripts — package-manager scripts (`check`, `verify`, `lint`, `typecheck`), Makefile or Taskfile targets, or a combined format+lint script.
25	3. Configured tools — any tool with a config committed to the repo, such as a dead-code or unused-dependency gate. A committed config means the project treats the tool as a gate; run it even when no script or CI invokes it. Do not run such a tool when the project has not configured it; unconfigured runs are discovery, which belongs to `/find-dead-code`.
26	4. Baseline — when the project declares nothing more, run the formatter, then the linter, then the test suite.
27
28	Run the formatter first so later checks see formatted code, then the rest. Fix any failure the tools do not auto-resolve. For test failures, run the `/investigate` skill to diagnose the root cause, apply the suggested fix, and re-run; if investigation finds no root cause, stop and report with its findings.
29
30	Stage all changes made in this step before continuing.
31
32	## Step 3: Run `/review-code` Skill
33
34	Run the `/review-code` skill on the staged changes. The diff command is `git diff --cached`.
35
36	## Step 4: Run `/evaluate-findings` Skill
37
38	Run the `/evaluate-findings` skill on the results from Step 3.
39
40	## Step 5: Run `/apply-findings` Skill
41
42	Run the `/apply-findings` skill on the evaluated results.
43
44	Stage all changes made in this step before continuing.
45
46	## Step 6: Run `/smoke-test` Skill
47
48	Run the `/smoke-test` skill to produce the smoke test plan. Delegate test execution to a subagent using the Agent tool in the foreground (`model: "opus"`). Pass the plan and the diff command (`git diff --cached`) to the subagent.
49
50	If any test fails, fix the issues and stage the fixes.
51
52	## Step 7: Re-run `/polish-code` Skill if Changed
53
54	Check whether any file was edited during Steps 5-6. Any edit counts.
55
56	The iteration number below refers to the `/polish-code` run currently executing Step 7. It is not the iteration number of a prospective re-run. Iteration 1 is the initial run; iteration 2 is the first auto-re-run; iteration 3 is the second auto-re-run; iteration 4 and beyond exist only when the user opts in at the hard-cap ask. Iterations 1 and 2 always follow the classification gate (they never trigger the hard cap at their own Step 7, even when the auto-re-run they spawn would be iteration 3). The hard cap fires at the end of iteration 3 and every iteration thereafter.
57
58	Iterations 1 and 2, if changes were made, classify what Steps 5-6 edited:
59
60	- Structural edits (fixed bugs, new or removed functions, changed function signatures, moved code between files, changed control flow, added or removed dependencies, corrected a stale or wrong comment that was itself a documentation bug) — run `/polish-code` again using the Skill tool. Scope the diff command to only the files modified in Steps 5-6: use `git diff --cached -- <file1> <file2> ...` as the diff command for `/review-code`. Smoke test scope remains unchanged (full feature scope, not file-narrowed). If the round contains both structural and in-place edits, treat it as structural and re-run automatically.
61	- In-place edits only (renamed local variables without changing behavior, reformatted, adjusted whitespace, edited neutral comments) — output a summary of what changed, then use `AskUserQuestion` to ask whether to run one more round or stop here. Do not silently continue or silently stop.
62
63	Iterations 1 and 2, if changes were made but you believe re-running is unnecessary, use `AskUserQuestion` to ask for skip permission. Do not skip silently.
64
65	Iteration 3 or later, if Steps 5-6 of this run made changes, the hard cap is reached. This replaces the classification gate above for iteration 3 and every iteration after it. Output a summary of what is still changing and whether it is struc

People who liked this also viewed

6 picks

Type

polish-code

4installs29forks

View on GitHub

How to install polish-code?

tobihagemann/turbo/polish-code

$npx -y skills add tobihagemann/turbo --skill polish-code

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Polish Code
2
3	## Task Tracking
4
5	At the start of every invocation (including re-runs from Step 7), use `TaskCreate` to create a task for each step:
6
7	1. Run `/stage` skill
8	2. Deterministic cleanup
9	3. Run `/review-code` skill
10	4. Run `/evaluate-findings` skill
11	5. Run `/apply-findings` skill
12	6. Run `/smoke-test` skill
13	7. Re-run `/polish-code` skill if changed
14
15	## Step 1: Run `/stage` Skill
16
17	Run the `/stage` skill.
18
19	## Step 2: Deterministic Cleanup
20
21	Run the project's full verification gate: every check it defines as a pass/fail condition. The goal is that passing this step means the project's own checks (and CI, where it exists) pass. Build the gate by combining every source below that the project declares (sources 1-3); run the baseline (source 4) only when the project declares none of them:
22
23	1. CI config — where present, it is the authoritative gate; run the checks it enforces.
24	2. Check scripts — package-manager scripts (`check`, `verify`, `lint`, `typecheck`), Makefile or Taskfile targets, or a combined format+lint script.
25	3. Configured tools — any tool with a config committed to the repo, such as a dead-code or unused-dependency gate. A committed config means the project treats the tool as a gate; run it even when no script or CI invokes it. Do not run such a tool when the project has not configured it; unconfigured runs are discovery, which belongs to `/find-dead-code`.
26	4. Baseline — when the project declares nothing more, run the formatter, then the linter, then the test suite.
27
28	Run the formatter first so later checks see formatted code, then the rest. Fix any failure the tools do not auto-resolve. For test failures, run the `/investigate` skill to diagnose the root cause, apply the suggested fix, and re-run; if investigation finds no root cause, stop and report with its findings.
29
30	Stage all changes made in this step before continuing.
31
32	## Step 3: Run `/review-code` Skill
33
34	Run the `/review-code` skill on the staged changes. The diff command is `git diff --cached`.
35
36	## Step 4: Run `/evaluate-findings` Skill
37
38	Run the `/evaluate-findings` skill on the results from Step 3.
39
40	## Step 5: Run `/apply-findings` Skill
41
42	Run the `/apply-findings` skill on the evaluated results.
43
44	Stage all changes made in this step before continuing.
45
46	## Step 6: Run `/smoke-test` Skill
47
48	Run the `/smoke-test` skill to produce the smoke test plan. Delegate test execution to a subagent using the Agent tool in the foreground (`model: "opus"`). Pass the plan and the diff command (`git diff --cached`) to the subagent.
49
50	If any test fails, fix the issues and stage the fixes.
51
52	## Step 7: Re-run `/polish-code` Skill if Changed
53
54	Check whether any file was edited during Steps 5-6. Any edit counts.
55
56	The iteration number below refers to the `/polish-code` run currently executing Step 7. It is not the iteration number of a prospective re-run. Iteration 1 is the initial run; iteration 2 is the first auto-re-run; iteration 3 is the second auto-re-run; iteration 4 and beyond exist only when the user opts in at the hard-cap ask. Iterations 1 and 2 always follow the classification gate (they never trigger the hard cap at their own Step 7, even when the auto-re-run they spawn would be iteration 3). The hard cap fires at the end of iteration 3 and every iteration thereafter.
57
58	Iterations 1 and 2, if changes were made, classify what Steps 5-6 edited:
59
60	- Structural edits (fixed bugs, new or removed functions, changed function signatures, moved code between files, changed control flow, added or removed dependencies, corrected a stale or wrong comment that was itself a documentation bug) — run `/polish-code` again using the Skill tool. Scope the diff command to only the files modified in Steps 5-6: use `git diff --cached -- <file1> <file2> ...` as the diff command for `/review-code`. Smoke test scope remains unchanged (full feature scope, not file-narrowed). If the round contains both structural and in-place edits, treat it as structural and re-run automatically.
61	- In-place edits only (renamed local variables without changing behavior, reformatted, adjusted whitespace, edited neutral comments) — output a summary of what changed, then use `AskUserQuestion` to ask whether to run one more round or stop here. Do not silently continue or silently stop.
62
63	Iterations 1 and 2, if changes were made but you believe re-running is unnecessary, use `AskUserQuestion` to ask for skip permission. Do not skip silently.
64
65	Iteration 3 or later, if Steps 5-6 of this run made changes, the hard cap is reached. This replaces the classification gate above for iteration 3 and every iteration after it. Output a summary of what is still changing and whether it is struc

People who liked this also viewed

6 picks

Type