How do I install the Tidying skill?

Run npx skillmds@latest add tomevault-io/tidying in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Tidying safe to use?

This skill has not completed SkillMD's automated safety review yet. Independent scanners report: SkillSpector: PASS, Skill Scanner: PASS. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Tidying?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Tidying free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Tidying?

tomevault-io (@tomevault-io) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Tidying by tomevault-io — Agent Skill

Name: Tidying
Author: tomevault-io

Tidying

Guide structural code improvements using Kent Beck's Tidy First methodology. Use when seeing messy code, before making behavioral changes, after completing features, or discussing when to clean up code. Use when this capability is needed.

tomevault-io Updated Sep 17, 2026

File contents

INSTRUCTIONS

Apply Kent Beck's "Tidy First?" philosophy: small, safe structural changes that improve code without changing behavior. Tidying is separate from feature work and gets its own commits.

Behavior Contract: See behavior-contract.md for complete definition of "behavior" (inputs, validation, outputs, side effects, errors) and structural vs behavioral change examples
Context Boundaries: See context-boundaries.md for what's safe to tidy in frontend/backend/CLI/library contexts (behavior boundary differs by context!)

Core Principle

"Tidying is a special kind of refactoring... tidying is small, and you never need to tidy."

Tidyings are:

Small: Minutes, not hours
Safe: Structure only, no behavior change
Optional: You choose when (or if) to tidy
Separate: Own commits, distinct from behavioral changes

The Three Timings

Timing	Trigger	Flow
Tidy First	Code is hard to change	`/tidy:first` → `refactor:` commit → behavioral change → `feat:/fix:` commit
Tidy After	Feature revealed better structure	behavioral change → `feat:/fix:` commit → `/tidy:after` → `refactor:` commit
Tidy Later	Tidying too big or off-focus	Note opportunity → backlog/TODO → continue current work

Decision Framework

1. Does this code need to change for my current task?
   No  → Tidy Later (or never)
   Yes ↓
2. Would tidying make my change easier/safer?
   No  → Make behavioral change, consider Tidy After
   Yes ↓
3. Is the tidying small (< 15 minutes)?
   No  → Tidy Later, make behavioral change anyway
   Yes → Tidy First, then make behavioral change

When NOT to DRY

"Duplication is far cheaper than the wrong abstraction." — Sandi Metz

Keep code inline when:

Pattern is simple and self-explanatory (vec![], None, error returns)
Abstraction adds indirection without clarity
Repetitions might evolve differently
grep/search is easier with inline code

Reference

Based on: Tidy First? by Kent Beck (2023)

Converted and distributed by TomeVault — claim your Tome and manage your conversions.

---name: tidyingdescription: Guide structural code improvements using Kent Beck's Tidy First methodology. Use when seeing messy code, before making behavioral changes, after completing features, or discussing when to clean up code. Use when this capability is needed.---# INSTRUCTIONSApply Kent Beck's "Tidy First?" philosophy: small, safe structural changes that improve code without changing behavior. Tidying is separate from feature work and gets its own commits.- **Behavior Contract**: See `behavior-contract.md` for complete definition of "behavior" (inputs, validation, outputs, side effects, errors) and structural vs behavioral change examples- **Context Boundaries**: See `context-boundaries.md` for what's safe to tidy in frontend/backend/CLI/library contexts (behavior boundary differs by context!)## Core Principle> "Tidying is a special kind of refactoring... tidying is small, and you never need to tidy."Tidyings are:- **Small**: Minutes, not hours- **Safe**: Structure only, no behavior change- **Optional**: You choose when (or if) to tidy- **Separate**: Own commits, distinct from behavioral changes## The Three Timings| Timing | Trigger | Flow ||--------|---------|------|| **Tidy First** | Code is hard to change | `/tidy:first` → `refactor:` commit → behavioral change → `feat:/fix:` commit || **Tidy After** | Feature revealed better structure | behavioral change → `feat:/fix:` commit → `/tidy:after` → `refactor:` commit || **Tidy Later** | Tidying too big or off-focus | Note opportunity → backlog/TODO → continue current work |## Decision Framework```1. Does this code need to change for my current task? No → Tidy Later (or never) Yes ↓2. Would tidying make my change easier/safer? No → Make behavioral change, consider Tidy After Yes ↓3. Is the tidying small (< 15 minutes)? No → Tidy Later, make behavioral change anyway Yes → Tidy First, then make behavioral change```## When NOT to DRY> "Duplication is far cheaper than the wrong abstraction." — Sandi MetzKeep code inline when:- Pattern is simple and self-explanatory (`vec![]`, `None`, error returns)- Abstraction adds indirection without clarity- Repetitions might evolve differently- grep/search is easier with inline code## ReferenceBased on: *Tidy First?* by Kent Beck (2023)---> Converted and distributed by [TomeVault](https://tomevault.io/claim/atusy) — claim your Tome and manage your conversions.

Frequently asked questions