agentleFS
sequant-iosequant-io/sequant/.claude/skills/clean/SKILL.md

clean

Skill1 starsChanged 3 months agoMITView on GitHub

Repository Cleanup Command

  • Deletes or force-pushes
  • Commits and pushes

18 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use expressive, friendly and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • bergsideSkill

    expressive

    Vibrant, personality-driven design with bold colors, playful graphics, and dynamic layouts that balance creativity with structure.

    Also in 4 projects that use this

  • bergsideSkill

    friendly

    Approachable, intuitive design with rounded elements, ample whitespace, and soft pastel color palettes.

    Also in 4 projects that use this

  • +10 more from bergside

The file

We split this skill into the rules it gives an agent

11 rules. 0 are common, 9 are distinctive, and 2 are very specific to this project.

  • 0

    Common

    Most of the 16 edited versions we read keep these.

  • 9

    Distinctive

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Before making ANY changes:

    line 38
  2. Distinctive:

    Verify we're on main branch with clean working tree

    line 39
  3. Very specific:

    Run npm run build to ensure current state builds

    line 40
  4. Distinctive:

    Create a safety checkpoint (stash any uncommitted work)

    line 41
  5. Distinctive:

    If build fails or we're not on main with clean tree, STOP and report.

    line 105
  6. Distinctive:

    Create archive directories if needed

    line 118
  7. Very specific:

    Update docs/archive/README.md with current date

    line 124
  8. Distinctive:

    If either fails, ROLLBACK all changes immediately.

    line 136
  9. Distinctive:

    If anything goes wrong:

    line 161
  10. Distinctive:

    Run monthly or when repo feels cluttered

    line 189
  11. Distinctive:

    Always verifies build before and after

    line 192

“Common” is measured: kept by at least 6 in 10 of the 16 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md
<!-- sequant:local-override -->

Local overrides (read this first). Before following any instruction below, check whether .claude/.local/skills/clean/overrides.md exists. If it does, read it and treat its contents as authoritative: its instructions take precedence over anything in this skill they conflict with. This is the supported way to tailor /clean without forking it — overrides.md lives under .claude/.local/, which sequant update and sync never overwrite.

Repository Cleanup Command

Comprehensive, safe repository cleanup that archives stale files, removes artifacts, and commits changes.

Safety First

Before making ANY changes:

  1. Verify we're on main branch with clean working tree
  2. Run npm run build to ensure current state builds
  3. Create a safety checkpoint (stash any uncommitted work)

Cleanup Categories

Category 1: Safe to Auto-Archive (No Review Needed)

These files are always safe to archive - they're historical artifacts:

Root directory patterns:

  • *.backup files (e.g., CLAUDE.md.backup)
  • CODE_REVIEW_PR_*.md - Old PR reviews
  • *_AUDIT.md files older than 30 days
  • One-off shell scripts with dates in names

docs/ patterns:

  • ISSUE_*_PHASE_*.md - Issue implementation specs (work is done)
  • *_IMPLEMENTATION.md older than 30 days
  • content-audit-*.md - Point-in-time audits
  • City-specific audit files (e.g., NYC_*_AUDIT.md, LA_*_REPORT.md)

Category 2: Review Before Archiving

These need a quick check - might still be referenced:

  • Files in migrations/ (check if applied to database)
  • context/ directory contents
  • Any APPLY_*.md or apply-*.sh files

Category 3: Always Keep

Never archive these:

  • CLAUDE.md - Active project instructions
  • README.md - Project readme
  • docs/WORKFLOW_COMMANDS.md - Active workflow docs
  • docs/patterns/* - Active pattern catalog
  • docs/CONTENT_STANDARDS.md - Active standards
  • Any file modified in the last 7 days

Archive Structure

scripts/archive/
├── one-off-migrations/    # Shell scripts for one-time tasks
├── adhoc-migrations/      # SQL files applied manually (not via migrations tool)
└── deprecated/            # Old/replaced scripts

docs/archive/
├── audits/                # Completed audits and reviews
├── issue-specs/           # GitHub issue implementation specs
├── implementation-reports/ # Feature implementation summaries
└── context/               # Old project context files

Execution Steps

Step 1: Pre-flight Checks

# Verify branch and status
git branch --show-current  # Must be 'main'
git status --porcelain     # Should be empty or only untracked

# Verify build works
npm run build

If build fails or we're not on main with clean tree, STOP and report.

Step 2: Identify Cleanup Candidates

Scan for files matching Category 1 and 2 patterns. Create a manifest of what will be archived.

Report to user:

  • Files to auto-archive (Category 1)
  • Files needing review (Category 2)
  • Total space to be reclaimed

Step 3: Execute Cleanup

  1. Create archive directories if needed
  2. Move Category 1 files to appropriate archive locations
  3. Move Category 2 files (after user confirmation via manifest)
  4. Remove artifacts:
    • .DS_Store files (except in node_modules)
    • Empty directories (except .git, node_modules, .next)
  5. Update docs/archive/README.md with current date

Step 4: Verification

# Verify build still works
npm run build

# Verify no breaking imports
npm run lint

If either fails, ROLLBACK all changes immediately.

Step 5: Commit and Push

# Stage all changes
git add -A

# Create descriptive commit
git commit -m "chore: repository cleanup $(date +%Y-%m-%d)

Archived:
- [X] old issue specs
- [X] completed audits
- [X] one-off migration scripts
- [X] stale documentation

Build verified: passing"

# Push to origin
git push origin main

Rollback Procedure

If anything goes wrong:

git checkout -- .
git clean -fd

Output Format

Report final summary:

Repository Cleanup Complete

Archived:
- X files from root directory
- X files from docs/
- X migration scripts

Removed:
- X .DS_Store files
- X empty directories

Commit: [hash] pushed to origin/main

Next cleanup recommended: [date + 30 days]

Usage Notes

  • Run monthly or when repo feels cluttered
  • Safe to run multiple times (idempotent)
  • Will not touch files modified in last 7 days
  • Always verifies build before and after

BEGIN EXECUTION

Execute the cleanup following the steps above. Be thorough but safe - when in doubt, skip a file rather than risk breaking something.


Output Verification

Before responding, verify your output includes ALL of these:

  • Pre-flight Results - Branch check, build verification passed
  • Cleanup Manifest - List of files to be archived/removed
  • Archive Summary - Count of files archived by category
  • Build Verification - Post-cleanup build/lint passed
  • Commit Details - Commit hash and push confirmation
  • Next Cleanup Date - Recommended date for next cleanup

DO NOT respond until all items are verified.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.