Agent-almanac tidy-project-structure
git clone https://github.com/pjt222/agent-almanac
T=$(mktemp -d) && git clone --depth=1 https://github.com/pjt222/agent-almanac "$T" && mkdir -p ~/.claude/skills && cp -r "$T/i18n/wenyan/skills/tidy-project-structure" ~/.claude/skills/pjt222-agent-almanac-tidy-project-structure-e1d4d1 && rm -rf "$T"
i18n/wenyan/skills/tidy-project-structure/SKILL.mdtidy-project-structure
When to Use
Use this skill when project organization has drifted from conventions:
- Files scattered across directories without clear organization
- READMEs are outdated or contain broken examples
- Configuration files have multiplied (dev, staging, prod drift)
- Deprecated files remain in project root
- Naming conventions inconsistent across directories
Do NOT use for code refactoring or dependency restructuring. This skill focuses on file organization and documentation hygiene.
Inputs
| Parameter | Type | Required | Description |
|---|---|---|---|
| string | Yes | Absolute path to project root |
| string | No | Path to style guide (e.g., ) |
| enum | No | (default) or for deprecated files |
| boolean | No | Update stale READMEs (default: true) |
Procedure
Step 1: Audit Directory Layout
Compare current structure against project conventions or language best practices.
Common conventions by language:
JavaScript/TypeScript:
src/ # Source code tests/ # Test files dist/ # Build output (gitignored) docs/ # Documentation .github/ # CI/CD workflows
Python:
package_name/ # Package code tests/ # Test suite docs/ # Sphinx docs scripts/ # Utility scripts
R:
R/ # R source tests/testthat/ # Test suite man/ # Documentation (generated) vignettes/ # Long-form guides inst/ # Installed files data/ # Package data
Rust:
src/ # Source code tests/ # Integration tests benches/ # Benchmarks examples/ # Usage examples
Expected: List of files/directories violating conventions saved to
structure_audit.txt
On failure: If no conventions documented, use language-standard defaults
Step 2: Move Misplaced Files
Relocate files to their conventional directories.
Common moves:
- Test files outside
→ move totests/tests/ - Documentation outside
→ move todocs/docs/ - Build artifacts in
→ delete (should be gitignored)src/ - Config files in root → move to
orconfig/.config/
For each move:
# Check if file is referenced anywhere grep -r "filename" . # If no references or only relative path references: mkdir -p target_directory/ git mv source/file target_directory/file # Update any imports/requires # (language-specific — see repair-broken-references skill)
Expected: All files in conventional locations; git history preserved via
git mv
On failure: If moving breaks imports, update import paths or escalate
Step 3: Check README Freshness
Identify stale information in all README files.
Staleness indicators:
- Last modified >6 months ago
- References to old version numbers
- Broken links or code examples
- Missing sections (Installation, Usage, Contributing)
- No license badge or broken badge links
# Find all READMEs find . -name "README.md" -o -name "readme.md" # For each README: # - Check last modified date git log -1 --format="%ci" README.md # - Check for broken links markdown-link-check README.md # - Verify example code still runs (sample first example)
Expected: List of stale READMEs in
readme_freshness.txt with specific issues
On failure: If markdown-link-check unavailable, manually review external links
Step 4: Update Stale READMEs
Fix broken links, update examples, add missing sections.
Standard fixes:
- Replace broken badge URLs
- Update version numbers in installation instructions
- Fix broken example code (run to verify)
- Add missing sections (use template from project conventions)
- Update copyright year
README template structure:
# Project Name Brief description (1-2 sentences). ## Installation ```bash # Language-specific install command
Usage
# Basic example
Documentation
Link to full docs.
Contributing
Link to CONTRIBUTING.md or inline guidelines.
License
LICENSE badge and link.
**Expected:** All READMEs updated; examples verified to run **On failure:** If example code cannot be verified, mark with warning comment ### Step 5: Review Config Files Identify configuration drift and consolidate duplicate settings. **Common config issues**: 1. Multiple `.env` files (`.env`, `.env.local`, `.env.dev`, `.env.prod`) 2. Duplicate settings across config files 3. Hardcoded secrets (should use environment variables) 4. Outdated API endpoints or feature flags ```bash # Find all config files find . -name "*.config.*" -o -name ".env*" -o -name "*.yml" -o -name "*.yaml" # For each config: # - Check for duplicate keys # - Grep for hardcoded secrets (API keys, tokens, passwords) grep -E "(api[_-]?key|token|password|secret)" config_file # - Compare dev vs prod settings diff .env.dev .env.prod
Expected: Config drift documented in
config_review.txt; secrets flagged for escalation
On failure: If diff shows major divergence, escalate to devops-engineer
Step 6: Archive Deprecated Files
Move or delete files no longer needed.
Candidates for archiving:
- Commented-out config files (e.g.,
)nginx.conf.old - Legacy scripts not run in >1 year
- Backup files (e.g.,
,file.bak
)file~ - Build artifacts accidentally committed
Archive process:
# Create archive directory (if archive_mode=move) mkdir -p archive/YYYY-MM-DD/ # For each deprecated file: # 1. Verify not referenced anywhere grep -r "filename" . # 2. Check git history for last modification git log -1 --format="%ci" filename # 3. If not modified in >1 year and no references: if [ "$archive_mode" = "move" ]; then git mv filename archive/YYYY-MM-DD/ else git rm filename fi # 4. Document in ARCHIVE_LOG.md echo "- filename (reason, last modified: DATE)" >> ARCHIVE_LOG.md
Expected: Deprecated files archived;
ARCHIVE_LOG.md updated
On failure: If uncertain whether file is deprecated, leave in place and document in report
Step 7: Verify Naming Conventions
Check for inconsistent file naming across project.
Common conventions:
- kebab-case:
(common in JS/web projects)my-file.js - snake_case:
(Python standard)my_file.py - PascalCase:
(React components)MyComponent.tsx - camelCase:
(JavaScript functions)myUtility.js
# Find files violating conventions # Example: Python project expecting snake_case find . -name "*.py" | grep -v "__pycache__" | grep -E "[A-Z-]" # For each violation, either: # 1. Rename to match conventions # 2. Document exception (e.g., Django settings.py convention)
Expected: All files follow naming conventions or exceptions documented
On failure: If renaming breaks imports, update references or escalate
Step 8: Generate Tidying Report
Document all structural changes.
# Project Structure Tidying Report **Date**: YYYY-MM-DD **Project**: <project_name> ## Directory Changes - Moved X files to conventional directories - Created Y new directories - Archived Z deprecated files ## README Updates - Updated W stale READMEs - Fixed X broken links - Verified Y code examples ## Config Cleanup - Consolidated X duplicate settings - Flagged Y hardcoded secrets for removal - Documented Z config drift issues ## Files Archived See ARCHIVE_LOG.md for full list (Z files). ## Naming Convention Fixes - Renamed X files to match conventions - Documented Y exceptions ## Escalations - [Config drift requiring devops review] - [Hardcoded secrets requiring security audit]
Expected: Report saved to
TIDYING_REPORT.md
On failure: (N/A — generate report regardless)
Validation Checklist
After tidying:
- All files in conventional directories
- No broken links in any README
- README examples verified to run
- Config files reviewed for secrets
- Deprecated files archived with documentation
- Naming conventions consistent
- Git history preserved (used
, notgit mv
)mv - Tests still pass after moves
Common Pitfalls
-
Breaking Relative Imports: Moving files breaks relative import paths. Update all references or use absolute imports.
-
Losing Git History: Using
instead ofmv
loses file history. Always use git commands for moves.git mv -
Over-Organizing: Creating too many nested directories makes navigation harder. Keep it flat until complexity requires structure.
-
Deleting Instead of Archiving: Direct deletion loses ability to recover. Always archive first unless certain.
-
Ignoring Language Conventions: Imposing personal preferences over language standards. Follow established conventions.
-
Not Updating Documentation: Moving files without updating README paths leaves docs broken.
Related Skills
- clean-codebase — Remove dead code, fix lint warnings
- repair-broken-references — Fix links and imports after moves
- escalate-issues — Route complex config issues to specialists
- devops/config-management — Advanced config consolidation
- compliance/documentation-audit — Comprehensive doc review