post-implementation-simplification

Remove dead code and consolidate duplicates in task-touched files.

Updated Apr 10, 2026
One-click install
npx skills add https://github.com/majedsiefalnasr/bunyan-app-cursor --skill post-implementation-simplification
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: post-implementation-simplification
Source: https://github.com/majedsiefalnasr/bunyan-app-cursor/tree/main/.agents/skills/post-implementation-simplification
Command: npx skills add https://github.com/majedsiefalnasr/bunyan-app-cursor --skill post-implementation-simplification

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Dead code and unclear naming undermine maintainability and slow feature delivery.

Core Features & Use Cases

  • Identify unused imports and dead branches
  • Consolidate duplicated logic into shared abstractions
  • Rename symbols for clarity while preserving behavior

Quick Start

Run the post-implementation simplification pass on the updated codebase to remove dead code, consolidate duplicates, and improve naming.

Frequently Asked Questions about post-implementation-simplification

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I remove dead code after implementing a new feature?

Run a post-implementation simplification pass to identify unused imports and dead branches, ensuring no behavioral changes and maintained test parity.

What is the best way to consolidate duplicated logic during a refactor?

Consolidating duplicated logic during a refactor involves grouping duplicates into shared abstractions, strictly limiting changes to files touched in the current task.

Does post-implementation refactoring preserve existing software behavior?

Post-implementation refactoring enforces behavior preservation by avoiding new features and maintaining test parity while improving readability and maintainability.

How do I clean up unused imports without breaking test parity?

Clean up unused imports by enforcing scope limitations to currently touched files, ensuring the cleanup process maintains test parity and introduces no new features.

When should I limit refactoring scope to files touched in the current task?

Limit refactoring scope to touched files during post-implementation cleanup to enforce behavior preservation, avoid unintended side effects, and maintain test parity.