Propose an improvement to a turbo skill as an issue on tobihagemann/turbo.
Confirm the local repo exists:
\ntest -d ~/.turbo/repo\nIf it does not, tell the user to run the Turbo setup first and stop.
\nDetect skills whose installed copy has drifted from the repo baseline:
\nfor skill in ~/.agents/skills/*/; do\n name=$(basename \"$skill\")\n repo_dir=~/.turbo/repo/codex/skills/\"$name\"\n [ -d \"$repo_dir\" ] || continue\n diff -rq \"$skill\" \"$repo_dir\" >/dev/null 2>&1 && continue\n echo \"$name\"\ndone\nFor each drifted skill, read both versions of every file that differs and the single version of every file present on one side only. Classify each hunk and each one-sided file:
\nrequest_user_input to confirm classification.When no corrections survive classification, take the proposed change from conversation context instead. When the conversation describes no change either, tell the user there is nothing to contribute and stop.
\nPresent the corrections in a summary table:
\n| # | Skill | Change Summary |\n|---|-------|----------------|\n| 1 | $evaluate-findings | Added handling for security-default findings |\n| 2 | $self-improve | Clarified routing for trusted reviewer feedback |\nUse request_user_input to confirm which corrections to propose.
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.
\nUse this template:
\n\n\nDuring [general workflow description], the skill's instructions [what was missing or wrong]. This caused [what happened]. The change [what it does] so that [benefit].
\n
Example:
\n\n\nDuring a code review session, the evaluate-findings skill encountered a finding with
\nsecurity-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.
The maintainer implements the change, so state it concretely alongside the \"why\": the file path under codex/skills/<name>/, the step or section it belongs in, and the exact replacement text or a diff.
Before finalizing, verify the whole proposal — the \"why\" explanation, the cited paths, and the proposed replacement text — contains none of the following:
\nOutput the drafted proposal as text. Then use request_user_input for approval. The user must approve the proposal before proceeding.
$create-issue SkillUse update_plan to track each approved concern, restating any remaining steps of a parent workflow alongside them. Process concerns in order, one concern per issue.
For each concern, run the $create-issue skill, filing against tobihagemann/turbo rather than the current project's repo. The approved text from Step 2 is the issue body; leave it as approved rather than re-deriving it from conversation context.
Report each issue URL.
\nThen call update_plan to mark this step completed and continue with the next step of the active workflow.