Skip to content
skillsafebeta
← Report library
Purpose / Development

Refactor Skill Security Audit

What the author says it does (original text)

Surgical code refactoring to improve maintainability without changing behavior. Covers extracting functions, renaming variables, breaking down god functions, improving type safety, eliminating code smells, and applying design patterns. Less drastic than repo-rebuilder; use for gradual improvements.

Independent security check

Security risks found

Files checked
1
Risks found
2
Could it run dangerous commands?Looks for programs run straight after downloading, remote control of your computer, and hidden commands.No risks found
Could it expose your files or keys?Looks for uploads of files containing passwords or keys, and keys written directly in the code.No risks found
Could it delete files or keep running?Looks for broad file deletion, disk overwrites, and programs set to start automatically.Risks found: 1
Medium risk

The workflow may create branches and multiple Git commits without separate confirmation

Source references: 5
What we found

The guide presents “commit current state,” “create feature branch,” “commit if tests pass,” and “final commit” as default refactoring steps rather than optional actions requiring explicit user consent.

Why this matters

Even when a user only requests review, suggestions, or working-tree changes, the agent could alter branch state and create persistent commits. Writing missing tests and deleting code classified as dead also expands the file-change scope.

The workflow presents creating a feature branch and making multiple Git commits as routine steps, without requiring user approval. If followed, it would alter repository history and branch state, potentially disrupting the user's workflow or creating unwanted commits. Users can ask the author to make these actions opt-in, or restrict the skill from creating branches and commits.

SKILL.md:563In the instructionsOpen original file
```1. PREPARE   - Ensure tests exist (write them if missing)   - Commit current state   - Create feature branch2. IDENTIFY   - Find the code smell to address   - Understand what the code does   - Plan the refactoring3. REFACTOR (small steps)   - Make one small change   - Run tests   - Commit if tests pass   - Repeat
Show 4 other places
SKILL.md:585In the instructionsOpen original file
5. CLEAN UP   - Update comments   - Update documentation   - Final commit```
SKILL.md:310In the instructionsOpen original file
### 9. Dead Code```diff# BAD: Unused code lingers- function oldImplementation() { /* ... */ }- const DEPRECATED_VALUE = 5;- import { unusedThing } from './somewhere';- // Commented out code- // function oldCode() { /* ... */ }# GOOD: Remove it+ // Delete unused functions, imports, and commented code+ // If you need it again, git history has it```
SKILL.md:564In the instructionsOpen original file
```1. PREPARE   - Ensure tests exist (write them if missing)   - Commit current state   - Create feature branch
SKILL.md:574In the instructionsOpen original file
3. REFACTOR (small steps)   - Make one small change   - Run tests   - Commit if tests pass   - Repeat
Could it bypass safety checks?Looks for skipped website security checks, excessive file access, or actions that skip your approval.No risks found
Could it mislead the AI or hide text?Checks the skill instructions for requests to ignore you, influence the report, or hide text in invisible characters.No risks found
Could it change links or payment recipients without asking?Looks for forced referral or payment changes combined with instructions to hide the change.Risks found: 1
Medium risk

The “type safety” example changes discount policy despite the behavior-preservation promise

Source references: 5
What we found

The original gives gold members 25% on Friday, 20% otherwise, and all other memberships 10%. The purported refactor introduces a 15% silver discount and reads user.membership instead of the separately supplied membership argument. Those are pricing-policy changes, not merely added types.

Why this matters

If an agent follows this example in real checkout code, silver customers could be charged less and a membership value supplied by the caller could be ignored, affecting revenue, invoices, or promotion policy. Passing tests may not reveal this if expectations are changed at the same time.

The example conflicts with the skill's own behavior-preservation rule: the original distinguishes only gold from all other members, while the refactored version adds a 15% silver discount and changes the source of membership from a separate parameter to user.membership. In real pricing code, this could change charges for silver users or when the two membership values differ. Users can require equivalence tests and prohibit pricing-rule changes without business approval.

SKILL.md:27In the instructionsOpen original file
### The Golden Rules1. **Behavior is preserved** - Refactoring doesn't change what the code does, only how2. **Small steps** - Make tiny changes, test after each3. **Version control is your friend** - Commit before and after each safe state4. **Tests are essential** - Without tests, you're not refactoring, you're editing5. **One thing at a time** - Don't mix refactoring with feature changes
Show 4 other places
SKILL.md:409In the instructionsOpen original file
```diff# Before: No types- function calculateDiscount(user, total, membership, date) {-   if (membership === 'gold' && date.getDay() === 5) {-     return total * 0.25;-   }-   if (membership === 'gold') return total * 0.2;-   return total * 0.1;- }
SKILL.md:435In the instructionsOpen original file
++ function calculateDiscount(+   user: User,+   total: number,+   date: Date = new Date()+ ): DiscountResult {+   if (total < 0) throw new Error('Total cannot be negative');++   let rate = 0.1; // Default bronze++   if (user.membership === 'gold' && date.getDay() === 5) {+     rate = 0.25; // Friday bonus for gold+   } else if (user.membership === 'gold') {+     rate = 0.2;+   } else if (user.membership === 'silver') {+     rate = 0.15;+   }+
SKILL.md:29In the instructionsOpen original file
1. **Behavior is preserved** - Refactoring doesn't change what the code does, only how2. **Small steps** - Make tiny changes, test after each
SKILL.md:411In the instructionsOpen original file
# Before: No types- function calculateDiscount(user, total, membership, date) {-   if (membership === 'gold' && date.getDay() === 5) {-     return total * 0.25;-   }-   if (membership === 'gold') return total * 0.2;-   return total * 0.1;- }

Inside this skill

8 instruction sections

This Skill is a refactoring guide that claims to improve the structure and readability of existing code without changing external behavior. The supplied material contains only SKILL.md, with no scripts, installation steps, or external references.

View source
SKILL.md:2In the instructionsOpen original file
---name: refactordescription: 'Surgical code refactoring to improve maintainability without changing behavior. Covers extracting functions, renaming variables, breaking down god functions, improving type safety, eliminating code smells, and applying design patterns. Less drastic than repo-rebuilder; use for gradual improvements.'license: MIT---
SKILL.md:9In the instructionsOpen original file
## OverviewImprove code structure and readability without changing external behavior. Refactoring is gradual evolution, not revolution. Use this for improving existing code, not rewriting from scratch.

The workflow calls for establishing tests, creating a feature branch, committing after each test-passing step, and making a final commit. Using the Skill may therefore change both the working tree and Git history rather than merely offering advice.

View source
SKILL.md:563In the instructionsOpen original file
```1. PREPARE   - Ensure tests exist (write them if missing)   - Commit current state   - Create feature branch2. IDENTIFY   - Find the code smell to address   - Understand what the code does   - Plan the refactoring3. REFACTOR (small steps)   - Make one small change   - Run tests   - Commit if tests pass   - Repeat
SKILL.md:580In the instructionsOpen original file
4. VERIFY   - All tests pass   - Manual testing if needed   - Performance unchanged or improved5. CLEAN UP   - Update comments   - Update documentation   - Final commit```

Email, payment, order, and user data appear in instructional BAD/GOOD code snippets. The visible content does not instruct the agent to actually send email, process payments, or disclose this data over a network.

View source
SKILL.md:104In the instructionsOpen original file
### 3. Large Class/Module```diff# BAD: God object that knows too much- class UserManager {-   createUser() { /* ... */ }-   updateUser() { /* ... */ }-   deleteUser() { /* ... */ }-   sendEmail() { /* ... */ }-   generateReport() { /* ... */ }-   handlePayment() { /* ... */ }-   validateAddress() { /* ... */ }-   // 50 more methods...- }# GOOD: Single responsibility per class+ class UserService {
Start here · InstructionsSKILL.md
refactor
Lines connect the instruction file to its sections, not an observed execution order. Select a section to read the source. 2 more sections are available in the original file.
Files and check records1 files

Coverage and gaps

Content covered in each file

These are the source ranges included in this check, not a guarantee that every issue has been resolved.

  • SKILL.mdFull text included

This report is for the version above. We read the available code and instructions without running the skill or checking extra packages it installs. This is not a promise of safety: a different version or setup may behave differently.

  • SKILL.mdInstructions
Lines read
646
File checksum (to compare versions)
397b162768be2eab93b64a0f88d69434d11441d45e089a61771e5b7b990507ee