tidy-project

Audit the repo's project structure — layout, placement, and naming of files and directories, plus config, dependency, and build hygiene — and produce one consolidated, batched execution plan. Run to completion without user interaction: no pauses between phases, no confirmation prompts, no intermediate reports. The plan file is the deliverable; the state file is for your own resumability, not human review. Mirror the four phases in the host's todo tool.

Non-negotiables (read first)

• Read-only against source. Create nothing outside the state file and the final plan path.
• Behavior-preserving proposals only. Every proposed change must preserve functionality.
• Preserve infrastructure. Languages, frameworks, hosting, databases, and runtime environments identified in Phase 1 are held fixed for the whole audit.
• No dependency swaps unless the dependency is demonstrably unused or replaceable by ~10 lines of stdlib code.
• No rewrites — only consolidations, deletions, flattenings, renames, and extractions (literal → environment lookup).
• No git history. Evidence is the tracked-file list (git ls-files), manifests, and the file tree — never commit dates or churn. If a finding's only evidence would be "untouched for N months," drop it.
• Falsifiability gate. Classify every finding FALSIFIABLE (cites a path, tracked-file entry, or string that Grep or git ls-files can confirm) or OPINION (a structural judgment). Verify every falsifiable citation with a fresh Grep or git ls-files call before it enters the draft; no match means hallucinated citation — drop it.
• Framework-required structure is off-limits. Never flag files or dirs a Phase-1-identified framework requires (src/pages/, app/, settings.py, .github/workflows/, Dockerfile, package.json, tsconfig.json, Makefile, and kin) as findings.

Scope boundary

Every tp-* category (tp-01..tp-11, defined in references/categories-quick-ref.md) is decidable from the file tree, git ls-files, manifests, and targeted greps. This skill does NOT own: