shredder code (hy3 model) | https://github.com/skorotkiewicz/Skills

shredder.md

Use the Shredder skill now.

Invoke the behavior of /skill:shredder.

Treat the current codebase as legacy behavior documentation and rebuild it from scratch while preserving intended functionality. Create or update SHREDDER_REPORT.md, preserve the original state before destructive changes, rewrite the implementation cleanly, update tests and docs, and finish with install, run, test, and build instructions.

User-provided mode or extra instructions:

{{args}}

SKILL.md

---

name: shredder description: This skill is more aggressive than refactoring. Refactoring improves existing code. Shredding treats the current implementation as legacy reference material and rebuilds the project cleanly while preserving intended product behavior.

Shredder

Use this skill when the user wants to completely rewrite, replace, rebuild, re-architect, or “shred” an existing codebase from scratch.

This skill is more aggressive than refactoring. Refactoring improves existing code. Shredding treats the current implementation as legacy reference material and rebuilds the project cleanly while preserving intended product behavior.

Invocation

Primary Pi skill invocation:

/skill:shredder

Recommended prompt-template alias:

/shredder

Goal

Completely rewrite the current codebase from scratch while preserving the intended functionality, external behavior, public APIs, tests, build process, and user-facing features unless the user explicitly requests breaking changes.

The old codebase is not the thing to preserve. The product behavior is the thing to preserve.

First Response

When this skill activates, say:

Shredder mode activated. I’ll treat the current codebase as legacy behavior documentation and rebuild it from scratch while preserving intended functionality. I’ll first map the existing behavior, then replace the implementation with a clean architecture, updated tests, docs, and run instructions.

Then begin work immediately.

Operating Rules

1. Do not merely tidy or polish the existing code.
2. Do not blindly delete files.
3. Do not silently destroy user work.
4. Preserve the original state before replacing anything.
5. Use the existing codebase as behavioral evidence, not as architecture to copy.
6. Prefer simple, boring, maintainable code.
7. Preserve public contracts unless the user requests otherwise.
8. Keep the project runnable.
9. Update tests, scripts, docs, and configuration.
10. Produce code, not only advice.

Safety Checkpoint

Before destructive edits, create one of these:

• A new Git branch.
• A backup directory.
• A new rewrite directory.
• A commit or patch representing the original state.

Prefer this sequence:

git status
git checkout -b shredder/rewrite

If Git is unavailable, create:

_shredder_backup/

Do not remove the backup during the task.

Phase 1: Map the Current Project

Inspect the repository and identify:

• Languages.
• Frameworks.
• Package manager.
• Entry points.
• Build commands.
• Test commands.
• Lint commands.
• Runtime commands.
• Environment variables.
• Database or storage usage.
• External services.
• API routes.
• CLI commands.
• UI routes and screens.
• Data models.
• Authentication and authorization behavior.
• Error handling.
• Important business rules.
• Existing tests.
• Deployment assumptions.

Write a short behavior map before rewriting.

Create or update:

SHREDDER_REPORT.md

Start it with:

# Shredder Report

## Existing Behavior Map

## Public Contracts to Preserve

## Rewrite Plan

## Verification Commands

## Final Summary

Phase 2: Decide What Must Be Preserved

Preserve by default:

• Public API routes and response shapes.
• CLI flags and command names.
• Environment variable names.
• Database schema.
• User-facing behavior.
• Existing test expectations.
• Build and start workflow.
• UI layout and copy unless modernization is requested.

Allowed to change by default:

• Internal architecture.
• File layout.
• Naming of private modules.
• Internal abstractions.
• Dependency choices.
• Formatting.
• Test organization.
• Dead code.
• Duplicated code.
• Unused config.
• Obsolete compatibility layers.

Do not change without explicit user request:

• Database schema.
• Authentication behavior.
• Public API contracts.
• External integration behavior.
• Payment, billing, or permission logic.
• User data format.
• Deployment target.

Phase 3: Design the Replacement

Design a clean implementation with:

• Clear module boundaries.
• Minimal dependency set.
• Strong typing where available.
• Predictable naming.
• Explicit configuration.
• Centralized error handling.
• Testable business logic.
• Small files where practical.
• No accidental complexity.
• No dead abstractions.
• No hidden global state unless framework-required.

Prefer boring structure over clever architecture.

Phase 4: Rewrite the Codebase

Rewrite the implementation from scratch.

During the rewrite:

• Replace legacy modules with clean equivalents.
• Remove unused files.
• Remove unused dependencies.
• Collapse duplicate logic.
• Separate domain logic from framework glue.
• Keep I/O boundaries explicit.
• Add or update tests around preserved behavior.
• Update package scripts.
• Update README or run instructions.
• Keep configuration readable.
• Keep generated artifacts out of source unless required.

When unsure whether behavior is intentional, preserve it and document the uncertainty in SHREDDER_REPORT.md.

Phase 5: Verify

Run the project’s verification commands when available:

npm test
npm run lint
npm run build
npm start

Adapt commands to the actual project.

If commands cannot be run, document why in SHREDDER_REPORT.md and provide the exact commands the user should run.

Phase 6: Final Report

At the end, update SHREDDER_REPORT.md with:

• What was rewritten.
• New architecture.
• Files added.
• Files removed.
• Dependencies added.
• Dependencies removed.
• Behavior preserved.
• Behavior intentionally changed.
• Tests added or updated.
• Commands run.
• Commands that failed.
• Known limitations.
• Suggested follow-up work.

Then summarize for the user:

Shredder complete.

Include:

• New project structure.
• How to install.
• How to run.
• How to test.
• Important behavior notes.
• Any remaining risks.

Modes

The user may add mode text after invoking the skill.

keep-api

Preserve all public APIs exactly.

/skill:shredder keep-api

preserve-ui

Preserve the UI visually while rewriting internals.

/skill:shredder preserve-ui

modernize

Use current best practices for the project’s language, framework, and tooling.

/skill:shredder modernize

simplify

Prioritize deleting complexity, reducing files, and reducing dependencies.

/skill:shredder simplify

max-clean

Be aggressive. Rename, restructure, remove legacy patterns, and produce the cleanest maintainable codebase. Document all breaking changes.

/skill:shredder max-clean

migrate-to TARGET

Rewrite into a requested target language, framework, or architecture.

/skill:shredder migrate-to typescript
/skill:shredder migrate-to nextjs
/skill:shredder migrate-to fastapi
/skill:shredder migrate-to rust

Definition of Done

The shredder task is complete only when the repository has:

• A preserved original state.
• A rewritten implementation.
• Updated tests or a clear test plan.
• Updated run/build instructions.
• Updated dependencies.
• A completed SHREDDER_REPORT.md.
• A clear final summary for the user.

Hard Constraint

Shredder does not mean “delete everything.”

Shredder means:

Rebuild the whole codebase from scratch using the old codebase as the behavioral specification.