EasyPlatform scan-project-structure
[Documentation] Scan project and populate/sync docs/project-reference/project-structure-reference.md with service architecture, ports, directory tree, tech stack, and module registry.
git clone https://github.com/duc01226/EasyPlatform
T=$(mktemp -d) && git clone --depth=1 https://github.com/duc01226/EasyPlatform "$T" && mkdir -p ~/.claude/skills && cp -r "$T/.claude/skills/scan-project-structure" ~/.claude/skills/duc01226-easyplatform-scan-project-structure && rm -rf "$T"
.claude/skills/scan-project-structure/SKILL.md<!-- SYNC:critical-thinking-mindset -->[IMPORTANT] Use
to break ALL work into small tasks BEFORE starting — including tasks for each file read. This prevents context loss from long files. For simple tasks, AI MUST ATTENTION ask user whether to skip.TaskCreate
<!-- /SYNC:critical-thinking-mindset --> <!-- SYNC:ai-mistake-prevention -->Critical Thinking Mindset — Apply critical thinking, sequential thinking. Every claim needs traced proof, confidence >80% to act. Anti-hallucination: Never present guess as fact — cite sources for every claim, admit uncertainty freely, self-check output for errors, cross-reference independently, stay skeptical of own confidence — certainty without evidence root of all hallucination.
<!-- /SYNC:ai-mistake-prevention -->AI Mistake Prevention — Failure modes to avoid on every task:
- Check downstream references before deleting. Deleting components causes documentation and code staleness cascades. Map all referencing files before removal.
- Verify AI-generated content against actual code. AI hallucinates APIs, class names, and method signatures. Always grep to confirm existence before documenting or referencing.
- Trace full dependency chain after edits. Changing a definition misses downstream variables and consumers derived from it. Always trace the full chain.
- Trace ALL code paths when verifying correctness. Confirming code exists is not confirming it executes. Always trace early exits, error branches, and conditional skips — not just happy path.
- When debugging, ask "whose responsibility?" before fixing. Trace whether bug is in caller (wrong data) or callee (wrong handling). Fix at responsible layer — never patch symptom site.
- Assume existing values are intentional — ask WHY before changing. Before changing any constant, limit, flag, or pattern: read comments, check git blame, examine surrounding code.
- Verify ALL affected outputs, not just the first. Changes touching multiple stacks require verifying EVERY output. One green check is not all green checks.
- Holistic-first debugging — resist nearest-attention trap. When investigating any failure, list EVERY precondition first (config, env vars, DB names, endpoints, DI registrations, data preconditions), then verify each against evidence before forming any code-layer hypothesis.
- Surgical changes — apply the diff test. Bug fix: every changed line must trace directly to the bug. Don't restyle or improve adjacent code. Enhancement task: implement improvements AND announce them explicitly.
- Surface ambiguity before coding — don't pick silently. If request has multiple interpretations, present each with effort estimate and ask. Never assume all-records, file-based, or more complex path.
Prerequisites: MUST ATTENTION READ before executing:
<!-- SYNC:scan-and-update-reference-doc --><!-- /SYNC:scan-and-update-reference-doc --> <!-- SYNC:output-quality-principles -->Scan & Update Reference Doc — Surgical updates only, never full rewrite.
- Read existing doc first — understand current structure and manual annotations
- Detect mode: Placeholder (only headings, no content) → Init mode. Has content → Sync mode.
- Scan codebase for current state (grep/glob for patterns, counts, file paths)
- Diff findings vs doc content — identify stale sections only
- Update ONLY sections where code diverged from doc. Preserve manual annotations.
- Update metadata (date, counts, version) in frontmatter or header
- NEVER rewrite entire doc. NEVER remove sections without evidence they're obsolete.
<!-- /SYNC:output-quality-principles -->Output Quality — Token efficiency without sacrificing quality.
- No inventories/counts — AI can
. Counts go stale instantlygrep | wc -l- No directory trees — AI can
/glob. Use 1-line path conventionsls- No TOCs — AI reads linearly. TOC wastes tokens
- No examples that repeat what rules say — one example only if non-obvious
- Lead with answer, not reasoning. Skip filler words and preamble
- Sacrifice grammar for concision in reports
- Unresolved questions at end, if any
Quick Summary
Goal: Scan the project codebase and populate
docs/project-reference/project-structure-reference.md with accurate service architecture, API ports, directory tree, tech stack, and module codes.
Workflow:
- Read — Load current target doc, detect init vs sync mode
- Scan — Discover services, apps, ports, tech stack via parallel sub-agents
- Report — Write findings to external report file
- Generate — Build/update the reference doc from report
- Verify — Spot-check paths and ports
Key Rules:
- Generic — discover everything dynamically, never hardcode project-specific values
- Use
for hints if available, fall back to filesystem scanningdocs/project-config.json - All examples must reference real files found in this project
Be skeptical. Apply critical thinking, sequential thinking. Every claim needs traced proof, confidence percentages (Idea should be more than 80%).
Scan Project Structure
Phase 0: Read & Assess
- Read
docs/project-reference/project-structure-reference.md - Detect mode: init (placeholder only) or sync (has real content)
- If sync: note which sections exist and their line counts
Phase 1: Plan Scan Strategy
Check if
docs/project-config.json exists for module lists and service maps. Plan these scan areas:
- Backend services — Find
,.csproj
,Dockerfile
,Program.cs
for portslaunchSettings.json - Frontend apps — Find
,angular.json
,nx.json
,package.json
,vite.confignext.config - Infrastructure — Find
,docker-compose.yml
, K8s manifests, CI/CD configDockerfile - Tech stack — Parse
dependencies,package.json
PackageReferences, build tool configs.csproj
Phase 2: Execute Scan (Parallel Sub-Agents)
Launch 3 Explore agents in parallel:
Agent 1: Backend Services
- Glob for
and**/*.csproj
to find services**/Dockerfile - Grep
orlaunchSettings.json
for port numbersappsettings*.json - Grep for
or[ApiController]
to find API servicesMapControllers - List service directories with their ports
Agent 2: Frontend Apps
- Glob for
,**/angular.json
,**/nx.json
(not in node_modules)**/package.json - Find app entry points (
,main.ts
,index.tsx
)App.vue - Extract dev server ports from configs (
commands, proxy configs)serve - Identify framework versions from package.json
Agent 3: Infrastructure & Tech Stack
- Find
— extract service definitions and port mappingsdocker-compose*.yml - Find CI/CD configs (
,.github/workflows/*.yml
,azure-pipelines.yml
)Jenkinsfile - Parse primary package managers (
,package.json
) for key dependencies*.csproj - Identify databases, message brokers, caching from connection strings or Docker services
Write all findings to:
plans/reports/scan-project-structure-{YYMMDD}-{HHMM}-report.md
Phase 3: Analyze & Generate
Read the report file. Build these sections:
Target Sections
| Section | Content |
|---|---|
| Service Architecture | Table: Service Name, Type (API/Worker/App), Port, Dockerfile path |
| Infrastructure Ports | Table: Service (DB/MQ/Cache), Port, Credentials (if in docker-compose) |
| API Service Ports | Table: API service name, Port, Dockerfile path |
| Project Directory Tree | Top 2-3 levels of directory structure |
| Tech Stack | Table: Category (Backend/Frontend/Infra), Technology, Version |
| Module Codes | Table: Module code abbreviation, Full name, Service path |
Content Rules
- Use tables for structured data (not prose)
- Include actual port numbers found in configs
- Directory tree: show only meaningful structure (skip node_modules, bin, obj)
- Tech stack: include version numbers from package.json/csproj
Phase 4: Write & Verify
- Write updated doc with
at top<!-- Last scanned: YYYY-MM-DD --> - Verify: spot-check 3 service paths exist on filesystem
- Verify: port numbers match actual config files
- Report: sections updated vs unchanged
Closing Reminders
- IMPORTANT MUST ATTENTION break work into small todo tasks using
BEFORE startingTaskCreate - IMPORTANT MUST ATTENTION search codebase for 3+ similar patterns before creating new code
- IMPORTANT MUST ATTENTION cite
evidence for every claim (confidence >80% to act)file:line - IMPORTANT MUST ATTENTION add a final review todo task to verify work quality MANDATORY IMPORTANT MUST ATTENTION READ the following before starting: <!-- SYNC:scan-and-update-reference-doc:reminder -->
- IMPORTANT MUST ATTENTION read existing doc first, scan codebase, diff, surgical update only. Never rewrite entire doc. <!-- /SYNC:scan-and-update-reference-doc:reminder --> <!-- SYNC:output-quality-principles:reminder -->
- IMPORTANT MUST ATTENTION follow output quality rules: no counts/trees/TOCs, rules > descriptions, 1 example per pattern, primacy-recency anchoring. <!-- /SYNC:output-quality-principles:reminder --> <!-- SYNC:critical-thinking-mindset:reminder -->
- MUST ATTENTION apply critical thinking — every claim needs traced proof, confidence >80% to act. Anti-hallucination: never present guess as fact. <!-- /SYNC:critical-thinking-mindset:reminder --> <!-- SYNC:ai-mistake-prevention:reminder -->
- MUST ATTENTION apply AI mistake prevention — holistic-first debugging, fix at responsible layer, surface ambiguity before coding, re-read files after compaction. <!-- /SYNC:ai-mistake-prevention:reminder -->