kramme-cc-workflow/skills/kramme:siw:remove/SKILL.md
Delete SIW workflow files from the current directory. Destructive; use kramme:siw:close first if you want to preserve documentation.
npx skillsauth add abildtoft/kramme-cc-workflow kramme:siw:removeInstall 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.
Delete SIW-related files from the siw/ folder in the current working directory. This is the destructive cleanup path for SIW workflow documents after implementation is complete.
If you want to preserve accumulated knowledge as permanent documentation, use /kramme:siw:close instead. If you want to start a fresh iteration on the same project, use /kramme:siw:reset.
Temporary (always candidates for deletion):
siw/LOG.md — Session progress and decisionssiw/OPEN_ISSUES_OVERVIEW.md — Issue tracking tablesiw/AUDIT_IMPLEMENTATION_REPORT.md — Spec compliance audit reportsiw/AUDIT_SPEC_REPORT.md — Spec quality audit reportsiw/PRODUCT_AUDIT.md — Product audit reportsiw/SIW_*.md — Other temporary SIW artifactssiw/SPEC_STRENGTHENING_PLAN.md — Refinement discovery output (this command deletes it, unlike /kramme:siw:close)siw/DISCOVERY_BRIEF.md — Greenfield discovery outputsiw/issues/ — Individual issue filessiw/qa-intake/ — QA intake parent summariesPermanent (optional, requires explicit confirmation):
siw/ matching *SPEC*.md, *SPECIFICATION*.md, *PLAN*.md, or *DESIGN*.md, excluding SPEC_STRENGTHENING_PLAN.md, DISCOVERY_BRIEF.md, AUDIT_*.md, PRODUCT_AUDIT.md, and SIW_*.mdsiw/supporting-specs/ — Numbered supporting specsOnly files discovered in Step 1 are deleted, listed in the confirmation prompt, or reported as deleted. Items in the lists above that do not exist on disk are ignored.
Discover what exists. Record two lists from the output:
found_temporary — temp files and directoriesfound_permanent — spec/permanent files plus siw/supporting-specs/ if presentls -d siw/LOG.md siw/OPEN_ISSUES_OVERVIEW.md siw/AUDIT_IMPLEMENTATION_REPORT.md siw/AUDIT_SPEC_REPORT.md siw/PRODUCT_AUDIT.md siw/SIW_*.md siw/SPEC_STRENGTHENING_PLAN.md siw/DISCOVERY_BRIEF.md siw/issues siw/qa-intake 2> /dev/null
find siw -maxdepth 1 -type f \( -name "*SPEC*.md" -o -name "*SPECIFICATION*.md" -o -name "*PLAN*.md" -o -name "*DESIGN*.md" \) \
! -name "SPEC_STRENGTHENING_PLAN.md" \
! -name "DISCOVERY_BRIEF.md" \
! -name "AUDIT_*.md" \
! -name "PRODUCT_AUDIT.md" \
! -name "SIW_*.md" \
2> /dev/null
ls -d siw/supporting-specs 2> /dev/null
If both lists are empty:
No SIW workflow files found in this directory.
Stop.
git status --porcelain -- siw/ 2> /dev/null
If any output exists, warn the user before proceeding to confirmation:
Warning: There are uncommitted changes to SIW files:
{paths from porcelain output, one per line}
If `trash` is available, these will be recoverable from the system Trash. Otherwise they will be permanently lost.
If the working tree is clean or not a git repo, skip the warning. Continue to Step 3 either way.
Use AskUserQuestion. Build option descriptions from the actual contents of found_temporary and found_permanent — do not list files that were not found in Step 1.
header: "Delete SIW Files"
question: "Found {len(found_temporary)} temporary item(s){, plus {len(found_permanent)} permanent item(s) if non-empty}. Which should I delete?"
options:
- label: "Temporary files only"
description: "Delete: {comma-separated paths in found_temporary}. Keep permanent files."
- label: "All SIW files"
description: "Delete the temporary items plus: {comma-separated paths in found_permanent}."
- label: "Abort"
description: "Cancel and keep all files"
If found_permanent is empty, omit the "All SIW files" option.
Determine the deletion set from the user's selection:
delete_set = found_temporarydelete_set = found_temporary + found_permanentPrefer trash for recoverability. Build delete_set from paths that were discovered in Step 1 and selected in Step 3. Expand any globs before deletion so unmatched patterns are never reported as deleted. If delete_set is empty after filtering to existing paths, skip the deletion command and report that nothing matched the selection.
Delete directories by passing them to trash as normal path arguments; do not pass recursive flags to trash. Do not suppress deletion errors. Capture stderr/stdout so any failure can be reported.
trash <each path in delete_set>
If trash is not installed, warn and fall back to rm:
Warning: 'trash' command not found. Files will be permanently deleted.
Install with `brew install trash` (macOS) or your distro's `trash-cli` package (Linux).
# Ask for explicit confirmation after the permanent-deletion warning, then run:
rm -rf <each path in delete_set>
After deletion, verify every target with [ ! -e "$path" ]. Record only verified-absent paths in deleted_paths. Record any surviving paths in failed_delete_paths with the captured error output; these must be reported as failures instead of "Deleted".
siw/After deletion, remove leftover .gitkeep placeholders only from directories included in the confirmed delete_set. Do not remove .gitkeep files from directories the user chose to keep. rmdir only succeeds on empty directories, so it is safe to call for directories in the confirmed delete set and their now-empty parents.
rm -f <.gitkeep files inside directory paths in delete_set> 2> /dev/null
rmdir <directory paths in delete_set> siw 2> /dev/null
Record whether siw/ itself was removed for the report.
Report only paths that were actually in delete_set:
SIW Cleanup Complete
Deleted:
{each path in deleted_paths, one per line}
Failed to delete:
{each path in failed_delete_paths with error, one per line; omit section if empty}
{If using trash: Files moved to Trash and can be restored if needed.}
{If siw/ was removed: siw/ directory removed.}
trash keeps deletions recoverable — prefer it over rm whenever it is installed.siw/supporting-specs/./kramme:siw:init — the workflow can be re-initialized after cleanup.development
Runs kramme:pr:code-review as a closeout review loop for local or PR branch changes before commit, ship, or final response. Use when the user asks for autoreview, second-model review, or a final code-review pass after non-trivial edits. Not for UX, visual, accessibility, or product review.
development
Guides topic-level understanding verification for a PR, branch, feature, document, spec, design decision, bug fix, or other concrete subject. Use when the user asks to confirm, quiz, drill, teach-and-check, or verify that they understand a topic. Maintains a topic-specific checklist artifact and requires demonstrated understanding before marking the topic complete. Not for ordinary explanations without verification, end-of-session summaries, or code/test correctness checks.
testing
Design a CI/CD pipeline with quality gates, a <10-minute budget, feature-flag lifecycle, and an exit checklist. Use when adding a new CI pipeline, changing gate configuration, or planning a rollout for a new service. Complementary to kramme:pr:fix-ci (which fixes failures in an existing pipeline). Covers gate ordering, secrets storage, branch protection, rollback mechanism, and staged-rollout guardrails — not a rollout-execution runbook.
tools
--- name: kramme:visual:demo-reel description: Capture local demo evidence for observable product behavior: screenshots, before/after image sets, browser reels, terminal recordings, and short GIF/video proof. Use when shipping UI changes, CLI features, or any change where PR reviewers would benefit from visual or behavioral evidence. argument-hint: "[what to capture] [--url <url>|auto] [--tier static|before-after|browser-reel|terminal-recording]" disable-model-invocation: true user-invocable: tr