refactor(skills): remove workflows covered by Superpowers

Drop the debugging, implementation-planner, code-review, and
regression-verification skills so Superpowers owns these triggers without
competing descriptions. Focused domain skills remain.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
Julian lechnerandClaude Opus 5.5 committed 2026-10-01 10:21:59 +02:00
1 parent b4aa484f1a
commit e237d07441
6 files changed
+3 -82

No files matched your search

+1 -1
View File
@@ -48,7 +48,7 @@ foreach ($shell in @('powershell','bash')) {
if ($client -eq 'claude' -and (Get-Content (Join-Path $package 'agents/reviewer.md') -Raw) -notmatch "(?m)^tools: Read,Grep,Glob,$expectedReviewerShellTool\r?`$") { throw "Reviewer capability profile is missing in $package" } if ($client -eq 'claude' -and (Get-Content (Join-Path $package 'agents/reviewer.md') -Raw) -notmatch "(?m)^tools: Read,Grep,Glob,$expectedReviewerShellTool\r?`$") { throw "Reviewer capability profile is missing in $package" }
$expectedSkillCount = if ($client -eq 'claude') { $sourceSkillCount + $ruleSkillCount } else { $sourceSkillCount } $expectedSkillCount = if ($client -eq 'claude') { $sourceSkillCount + $ruleSkillCount } else { $sourceSkillCount }
if (@(Get-ChildItem "$package/skills" -Filter SKILL.md -Recurse).Count -ne $expectedSkillCount) { throw "Missing skills in $package" } if (@(Get-ChildItem "$package/skills" -Filter SKILL.md -Recurse).Count -ne $expectedSkillCount) { throw "Missing skills in $package" }
if (-not (Test-Path "$package/skills/debugging/SKILL.md") -or -not (Test-Path "$package/skills/copywriting/SKILL.md") -or -not (Test-Path "$package/skills/marketing-psychology/SKILL.md") -or -not (Test-Path "$package/skills/image/SKILL.md") -or (Test-Path "$package/skills/marketing-plan/SKILL.md") -or (Test-Path "$package/skills/social/SKILL.md")) { throw "Incorrect skill catalog in $package" } if ((Test-Path "$package/skills/debugging/SKILL.md") -or -not (Test-Path "$package/skills/reviews/security-review/SKILL.md") -or -not (Test-Path "$package/skills/copywriting/SKILL.md") -or -not (Test-Path "$package/skills/marketing-psychology/SKILL.md") -or -not (Test-Path "$package/skills/image/SKILL.md") -or (Test-Path "$package/skills/marketing-plan/SKILL.md") -or (Test-Path "$package/skills/social/SKILL.md")) { throw "Incorrect skill catalog in $package" }
$expected = if ($shell -eq 'powershell') { '__POWERSHELL_COMMAND__ .*flashbang.ps1' } else { 'bash .*flashbang.sh' } $expected = if ($shell -eq 'powershell') { '__POWERSHELL_COMMAND__ .*flashbang.ps1' } else { 'bash .*flashbang.sh' }
if ($content -notmatch $expected -or $content -match '__HOOK_|__POWERSHELL_HOOK_') { throw "Incorrect shell command in $package" } if ($content -notmatch $expected -or $content -match '__HOOK_|__POWERSHELL_HOOK_') { throw "Incorrect shell command in $package" }
if ($shell -eq 'powershell' -and $content -match 'WindowStyle\s+Hidden') { throw "PowerShell hook hides the terminal in $package" } if ($shell -eq 'powershell' -and $content -match 'WindowStyle\s+Hidden') { throw "PowerShell hook hides the terminal in $package" }
+2 -1
View File
@@ -55,7 +55,8 @@ for shell in powershell bash; do
expected_skill_count=$source_skill_count expected_skill_count=$source_skill_count
[ "$client" != claude ] || expected_skill_count=$((source_skill_count + rule_skill_count)) [ "$client" != claude ] || expected_skill_count=$((source_skill_count + rule_skill_count))
test "$(find "$package/skills" -name SKILL.md | wc -l)" -eq "$expected_skill_count" test "$(find "$package/skills" -name SKILL.md | wc -l)" -eq "$expected_skill_count"
test -f "$package/skills/debugging/SKILL.md" test ! -e "$package/skills/debugging/SKILL.md"
test -f "$package/skills/reviews/security-review/SKILL.md"
test -f "$package/skills/copywriting/SKILL.md" test -f "$package/skills/copywriting/SKILL.md"
test -f "$package/skills/marketing-psychology/SKILL.md" test -f "$package/skills/marketing-psychology/SKILL.md"
test -f "$package/skills/image/SKILL.md" test -f "$package/skills/image/SKILL.md"
-23
View File
@@ -1,23 +0,0 @@
---
name: debugging
description: Use when code, tests, commands, integrations, or user-visible behavior fail unexpectedly; reproduce the failure, trace the cause, and verify a focused fix.
---
# Debugging
Use when a command, test, integration, or user-visible behavior fails or behaves unexpectedly.
## Workflow
1. State expected and observed behavior. Capture the exact error, input, environment, and reproduction steps that matter.
2. Reproduce the failure with the smallest relevant command or scenario. If it cannot be reproduced, inspect logs, recent changes, callers, configuration, and environment differences before changing code.
3. Trace the failing path through its callers and dependencies. Compare a failing case with a successful one and identify the earliest point where behavior diverges.
4. Form a root-cause explanation supported by evidence. If several causes remain plausible, gather the cheapest evidence that distinguishes them.
5. Fix the cause at the narrowest shared boundary that covers affected callers. Preserve unrelated behavior and keep error handling intact.
6. Run the smallest check that would fail if the defect returned, then add broader regression checks when the change affects connected paths or data.
Do not hide the failure with retries, broad exception handling, suppressed diagnostics, or caller-specific guards unless evidence shows that is the actual cause.
## Report
Summarize the cause, evidence, change, checks run, and any remaining uncertainty. Separate environment failures from product failures. Never claim a check passed if it did not run.
@@ -1,19 +0,0 @@
---
name: implementation-planner
description: Use when requirements are understood but implementation needs multiple dependent steps, affected areas, risk handling, or coordinated verification. Produce a plan without making the changes.
---
# Implementation Planner
Use when an understood change has multiple dependent steps or meaningful coordination risk.
## Workflow
1. Restate the intended outcome and acceptance conditions without expanding the request.
2. Identify the files, components, data contracts, or workflows likely to change. Confirm the repository's existing patterns before proposing new structure.
3. Order work by dependency. Keep steps small enough to review and verify independently where possible.
4. Call out decisions that affect compatibility, data, permissions, or external systems. Resolve routine reversible choices using repository conventions.
5. Pair each substantial step with the cheapest useful verification.
6. Keep the plan concise and omit speculative scaffolding, unrelated cleanup, and work that can safely wait.
Return an actionable sequence with affected areas, risks, and checks. This skill plans only; do not implement the change.
@@ -1,20 +0,0 @@
---
name: code-review
description: Use for a general review of a code diff when looking for concrete defects, regressions, compatibility issues, and maintainability risks. For focused API, security, performance, UI, WPF, or EF Core reviews, use the matching review skill.
---
# Code Review
Review the requested diff independently for defects and material regression risk.
## Workflow
1. Read the diff and the surrounding code, then identify the behavior and contracts the change intends to affect.
2. Trace callers and data flow through relevant shared helpers. Check normal, boundary, and failure paths rather than reviewing changed lines in isolation.
3. Look for incorrect behavior, compatibility breaks, unsafe input or data handling, resource leaks, concurrency problems, and avoidable complexity where relevant.
4. Check whether the change has focused verification and whether stated results match the evidence. Do not run broad checks by default.
5. Ignore style preferences unless they make the code error-prone or conflict with a repository rule.
## Findings
List only actionable issues, ordered by severity. Include file and line, condition, concrete impact, and the smallest practical fix. Do not modify code unless explicitly asked. If no defect is found, say so and note important unverified risks.
@@ -1,18 +0,0 @@
---
name: regression-verification
description: Use after a code or configuration change when adjacent existing behavior may have regressed; select and run focused checks, then report results and gaps.
---
# Regression Verification
Use after a change when existing behavior may have been affected.
## Workflow
1. List the user-visible behaviors and contracts adjacent to the change, including sibling callers that share modified logic.
2. Select existing tests or short scenarios that exercise those behaviors and their important boundaries.
3. Run checks at the narrowest useful level. Expand only when shared components, persisted data, security boundaries, or integration paths justify it.
4. Compare failures with the baseline and distinguish regressions from pre-existing or environment-specific failures.
5. Check generated output or compatibility artifacts when the source change feeds them.
Report behaviors checked, exact checks run, results, and any gaps. Never imply that unrun tests passed.