tidy-project-structure
关于
This skill organizes messy projects by moving files into standard directories, updating stale READMEs, and cleaning up configuration drift without altering core logic. It's ideal when projects have scattered files, outdated documentation, or inconsistent naming conventions. Developers should use it to quickly restore conventional structure and remove deprecated items.
快速安装
Claude Code
推荐npx skills add pjt222/agent-almanac -a claude-code/plugin add https://github.com/pjt222/agent-almanacgit clone https://github.com/pjt222/agent-almanac.git ~/.claude/skills/tidy-project-structure在 Claude Code 中复制并粘贴此命令以安装该技能
技能文档
tidy-project-structure
When Use
Use this skill when project organization has drifted from conventions:
- Files scattered across directories without clear organization
- READMEs 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 |
|---|---|---|---|
project_path | string | Yes | Absolute path to project root |
conventions | string | No | Path to style guide (e.g., docs/conventions.md) |
archive_mode | enum | No | move (default) or delete for deprecated files |
readme_update | boolean | No | Update stale READMEs (default: true) |
Steps
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
Got: List of files/directories violating conventions saved to structure_audit.txt
If fail: No conventions documented? Use language-standard defaults
Step 2: Move Misplaced Files
Relocate files to their conventional directories.
Common moves:
- Test files outside
tests/→ move totests/ - Documentation outside
docs/→ move todocs/ - Build artifacts in
src/→ delete (should be gitignored) - Config files in root → move to
config/or.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)
Got: All files in conventional locations; git history preserved via git mv
If fail: 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)
Got: List of stale READMEs in readme_freshness.txt with specific issues
If fail: markdown-link-check unavailable? Manual 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.
**Got:** All READMEs updated; examples verified to run
**If fail:** 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
Got: Config drift documented in config_review.txt; secrets flagged for escalation
If fail: 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
Got: Deprecated files archived; ARCHIVE_LOG.md updated
If fail: Uncertain whether file deprecated? Leave in place, document in report
Step 7: Verify Naming Conventions
Check for inconsistent file naming across project.
Common conventions:
- kebab-case:
my-file.js(common in JS/web projects) - snake_case:
my_file.py(Python standard) - PascalCase:
MyComponent.tsx(React components) - camelCase:
myUtility.js(JavaScript functions)
# 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)
Got: All files follow naming conventions or exceptions documented
If fail: 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]
Got: Report saved to TIDYING_REPORT.md
If fail: (N/A — generate report regardless)
Checks 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
git mv, notmv) - Tests still pass after moves
Pitfalls
-
Break Relative Imports: Moving files breaks relative import paths. Update all references or use absolute imports.
-
Lose Git History: Use
mvinstead ofgit mvloses file history. Always use git commands for moves. -
Over-Organizing: Creating too many nested directories makes navigation harder. Keep flat until complexity needs structure.
-
Delete Instead of Archive: Direct deletion loses ability to recover. Always archive first unless certain.
-
Ignore Language Conventions: Imposing personal preferences over language standards. Follow established conventions.
-
Not Update Documentation: Moving files without updating README paths leaves docs broken.
See Also
- 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
GitHub 仓库
相关推荐技能
qmd
开发这是一个本地搜索和索引的CLI工具,支持BM25、向量搜索和重排序功能。开发者可以用它快速索引本地文件(如Markdown文档)并进行混合搜索,特别适合代码库或文档的本地检索。它还提供MCP模式,能轻松集成到Claude开发环境中使用。
subagent-driven-development
开发该Skill用于在当前会话中执行包含独立任务的实施计划,它会为每个任务分派一个全新的子代理并在任务间进行代码审查。这种"全新子代理+任务间审查"的模式既能保障代码质量,又能实现快速迭代。适合需要在当前会话中连续执行独立任务,并希望在每个任务后都有质量把关的开发场景。
mcporter
开发mcporter Skill 让开发者能在Claude中直接管理和调用MCP服务器。它支持列出可用服务器、调用工具、处理OAuth认证以及管理服务器守护进程。开发者可以通过命令行式交互快速执行`mcporter list`查看服务器,或使用`mcporter call`直接调用工具,简化了MCP工作流程。
adk-deployment-specialist
开发这是一个用于部署和编排Google Vertex AI ADK智能体的Claude Skill,专为构建生产级多智能体系统而设计。它支持通过A2A协议进行智能体通信,提供代码执行沙箱和记忆库功能,并能处理智能体发现与任务提交。当开发者需要部署ADK智能体或编排多智能体协作时,可使用此Skill来简化Vertex AI Agent Engine的部署流程。
