skills/contribute-turbo/SKILL.md
Submit turbo skill improvements back to the upstream repo. Adapts to repo mode: fork mode creates a PR, source mode pushes directly. Use when the user asks to "contribute to turbo", "submit turbo changes", "PR my skill changes", "contribute back", or "upstream my changes".
npx skillsauth add tobihagemann/turbo contribute-turboInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Submit staged turbo skill improvements from ~/.turbo/repo/ back to the upstream repo. The workflow adapts based on repoMode in ~/.turbo/config.json.
Read ~/.turbo/config.json and check repoMode:
"fork" or "source" — proceed"clone" — tell the user that contributions require a fork. Offer to help convert their clone to a fork (add their fork as origin, rename current origin to upstream). Stop.Verify the repo exists and has the expected remotes:
git -C ~/.turbo/repo remote -v
Port session corrections from ~/.claude/skills/<name>/ (where edits land first) into ~/.turbo/repo/skills/<name>/ (the basis for the contribution), leaving any persistent local customizations in the installed copy untouched.
Detect drifted skills:
for skill in ~/.claude/skills/*/; do
name=$(basename "$skill")
repo_dir=~/.turbo/repo/skills/"$name"
[ -d "$repo_dir" ] || continue
diff -rq "$skill" "$repo_dir" >/dev/null 2>&1 && continue
echo "$name"
done
For each drifted skill, first check whether the repo copy already has unstaged changes for it (git -C ~/.turbo/repo status --porcelain skills/<name>/). If it does, use AskUserQuestion to ask the user how to proceed before mirroring — those changes will conflate with mirrored corrections in Step 3 if not resolved.
Then read both versions of every changed file and classify each hunk:
rm.AskUserQuestion to confirm classification before applying.Check what changes exist in the local repo:
git -C ~/.turbo/repo diff --name-only
git -C ~/.turbo/repo diff --cached --name-only
If there are unstaged changes to skill files, stage the specific skill directories that changed:
git -C ~/.turbo/repo add skills/<name>/
If there are no changes at all, tell the user there is nothing to contribute and stop.
Present the changes in a summary table:
| # | Skill | Change Summary |
|---|-------|----------------|
| 1 | /evaluate-findings | Added handling for security-default findings |
| 2 | /self-improve | Clarified routing for trusted reviewer feedback |
Use AskUserQuestion to confirm which changes to include. If the user deselects some, unstage those files.
Read ~/.turbo/repo/SKILL-CONVENTIONS.md for the turbo project's skill conventions. These conventions supplement /create-skill's general best practices with turbo-specific patterns.
For each confirmed skill, if /create-skill has not been invoked for it in this session, run /create-skill to review and refine the skill. Any improvements from the review become part of the contribution.
For each change, construct a "why" explanation. The goal: the turbo maintainer should understand what happened and why the existing instructions were insufficient, without learning anything about the contributor's project.
Use this template:
During [general workflow description], the skill's instructions [what was missing or wrong]. This caused [what happened]. The change [what it does] so that [benefit].
Example:
During a code review session, the evaluate-findings skill encountered a finding with
security-defaultseverity. The existing instructions only handledcritical,high,medium, andlowseverities, causing the finding to be silently dropped. The change addssecurity-defaultto the severity handling table so these findings are properly triaged.
Before finalizing, verify each "why" description contains none of the following:
Output the drafted context as text. Then use AskUserQuestion for approval. The user must approve the contribution message before proceeding.
Run /commit-rules to load commit message rules and technical constraints.
When multiple skills were changed, batch related changes into a single branch and commit. Create separate branches only when changes are independent and unrelated.
Create a feature branch:
git -C ~/.turbo/repo checkout -b improve/<skill-name>-<short-desc>
Commit with a message matching the turbo repo style (check git -C ~/.turbo/repo log -n 10 --oneline). Incorporate the "why" context in the commit message.
Stay on main. Commit directly with the same message style.
Run /github-voice to load writing style rules.
Push and create a PR:
git -C ~/.turbo/repo push -u origin improve/<skill-name>-<short-desc>
Create the PR against the upstream repo:
gh pr create --repo tobihagemann/turbo --head <user>:improve/<skill-name>-<short-desc> --title "..." --body "..."
PR body format:
## Summary
- [1-3 bullet points]
## Context
[The crafted "why" explanation from Step 5]
Return to main after creating the PR:
git -C ~/.turbo/repo checkout main
Report the PR URL.
Pull and rebase before pushing to incorporate any upstream changes:
git -C ~/.turbo/repo pull --rebase origin main
If the rebase pulled in new commits, run /update-turbo to apply upstream changes (skill updates, migrations, config changes) to the local installation before pushing.
Then push:
git -C ~/.turbo/repo push origin main
Report the pushed commit hash.
In source mode, update ~/.turbo/config.json so the next /update-turbo does not re-surface the just-pushed changes:
~/.turbo/config.jsonlastUpdateHead (add the key if it does not exist) to the current HEAD: git -C ~/.turbo/repo rev-parse HEADReport that the contribution is complete.
Skip this step in fork mode (the upstream has not changed until the PR is merged).
development
Apply a UX lens to a user-facing change: whether it serves the user's real goal and whether the path through it holds together, using the Understanding, Bridging, and Flowing contexts. Use when scoping, planning, or assessing any change that affects what a user sees or does. Loaded as a lens during planning and assessment.
development
Apply a UX lens to a user-facing change: whether it serves the user's real goal and whether the path through it holds together, using the Understanding, Bridging, and Flowing contexts. Use when scoping, planning, or assessing any change that affects what a user sees or does. Loaded as a lens during planning and assessment.
development
Assess project-wide structural technical debt: complexity hotspots, deprecated API usage, duplication clusters, and architecture rot. Ranks findings by impact and refactor effort into a report at .turbo/technical-debt.md. Use when the user asks to "assess technical debt", "find technical debt", "review technical debt", "what should we refactor", "find refactoring candidates", "where is the code rot", or "what's our worst code". Analysis-only — does not modify code.
development
Run a multi-agent review of code comments and markdown documentation for unnecessary content, then fix the issues. Covers what-restating comments, name-mirroring doc comments, status-update prose, and other documentation noise. Use when the user asks to "simplify docs", "simplify documentation", "clean up comments", "clean up docs", "review documentation", "strip unnecessary comments", "reduce doc noise", or "run simplify-docs".