tidy-project-structure
について
このスキルは、乱雑なプロジェクトを整理し、ファイルを標準ディレクトリに移動させ、古くなったREADMEを更新し、コアコードロジックを変更することなく設定のずれをクリーンアップします。ファイルが散らばっているプロジェクト、古くなったドキュメント、または一貫性のない命名規則がある場合に理想的です。開発者はこれを使用して、迅速に慣例的な構造を復元し、非推奨項目を削除できます。
クイックインストール
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
Cuándo Usar
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.
Entradas
| 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) |
Procedimiento
Paso 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
Esperado: List of files/directories violating conventions saved to structure_audit.txt
En caso de fallo: If no conventions documented, use language-standard defaults
Paso 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)
Esperado: All files in conventional locations; git history preserved via git mv
En caso de fallo: If moving breaks imports, update import paths or escalate
Paso 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)
Esperado: List of stale READMEs in readme_freshness.txt with specific issues
En caso de fallo: If markdown-link-check unavailable, manually review external links
Paso 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.
**Esperado:** All READMEs updated; examples verified to run
**En caso de fallo:** If example code cannot be verified, mark with warning comment
### Paso 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
Esperado: Config drift documented in config_review.txt; secrets flagged for escalation
En caso de fallo: If diff shows major divergence, escalate to devops-engineer
Paso 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
Esperado: Deprecated files archived; ARCHIVE_LOG.md updated
En caso de fallo: If uncertain whether file is deprecated, leave in place and document in report
Paso 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)
Esperado: All files follow naming conventions or exceptions documented
En caso de fallo: If renaming breaks imports, update references or escalate
Paso 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]
Esperado: Report saved to TIDYING_REPORT.md
En caso de fallo: (N/A — generate report regardless)
Validación
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
Errores Comunes
-
Breaking Relative Imports: Moving files breaks relative import paths. Update all references or use absolute imports.
-
Losing Git History: Using
mvinstead ofgit mvloses file history. Always use git commands for moves. -
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.
Habilidades Relacionadas
- 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
開発qmdは、BM25、ベクトル埋め込み、およびリランキングを組み合わせたハイブリッド検索を用いて、ローカルファイルのインデックス作成と検索を可能にするローカル検索・インデックス作成CLIツールです。コマンドラインでの使用と、Claudeとの統合のためのMCP(Model Context Protocol)モードの両方をサポートしています。このツールは埋め込みにOllamaを使用し、インデックスをローカルに保存するため、ターミナルから直接ドキュメントやコードベースを検索するのに最適です。
subagent-driven-development
開発このスキルは、各独立したタスクに対して新規のサブエージェントを起動し、タスク間でコードレビューを実施しながら実装計画を実行します。レビュープロセスを通じて品質基準を維持しつつ、迅速な反復を可能にします。同一セッション内で主に独立したタスクに取り組む際に本スキルをご利用いただくことで、組み込まれた品質チェックを伴う継続的な進捗を確保できます。
mcporter
開発mcporterスキルは、開発者がClaudeから直接Model Context Protocol(MCP)サーバーを管理および呼び出せるようにします。このスキルは、利用可能なサーバーの一覧表示、引数を指定したツールの呼び出し、認証およびデーモンのライフサイクル管理を行うコマンドを提供します。開発ワークフローにおいてMCPサーバーの機能を統合およびテストする際に、このスキルをご利用ください。
adk-deployment-specialist
開発このスキルは、A2Aプロトコルを使用してVertex AI ADKエージェントをデプロイおよびオーケストレーションし、AgentCardの発見、タスク送信、およびコード実行サンドボックスやメモリバンクなどのサポートツールを管理します。Python、Java、またはGoで、順次、並列、またはループのオーケストレーションパターンを用いたマルチエージェントシステムの構築を可能にします。Google Cloud上でADKエージェントのデプロイやエージェントワークフローのオーケストレーションを求められた際にご利用ください。
