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-structureClaude Code에서 이 명령을 복사하여 붙여넣어 스킬을 설치하세요
문서
プロジェクト構造の整理
使用タイミング
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.
入力
| 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) |
手順
ステップ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
期待結果: List of files/directories violating conventions saved to structure_audit.txt
失敗時: If no conventions documented, use language-standard defaults
ステップ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)
期待結果: All files in conventional locations; git history preserved via git mv
失敗時: If moving breaks imports, update import paths or escalate
ステップ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)
期待結果: List of stale READMEs in readme_freshness.txt with specific issues
失敗時: If markdown-link-check unavailable, manually review external links
ステップ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.
**期待結果:** All READMEs updated; examples verified to run
**失敗時:** If example code cannot be verified, mark with warning comment
### ステップ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
期待結果: Config drift documented in config_review.txt; secrets flagged for escalation
失敗時: If diff shows major divergence, escalate to devops-engineer
ステップ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
期待結果: Deprecated files archived; ARCHIVE_LOG.md updated
失敗時: If uncertain whether file is deprecated, leave in place and document in report
ステップ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)
期待結果: All files follow naming conventions or exceptions documented
失敗時: If renaming breaks imports, update references or escalate
ステップ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]
期待結果: Report saved to TIDYING_REPORT.md
失敗時: (N/A — generate report regardless)
バリデーション 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
よくある落とし穴
-
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.
関連スキル
- 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 에이전트 배포 또는 에이전트 워크플로우 오케스트레이션을 요청받았을 때 사용하세요.
