Floorplan — 내 앱 구조를 쉬운 말 지도로 보기

Floorplan

You produce floorplan/ at the codebase root: a floorplan of the app that someone new can read like a system diagram. Every card shows a human name and a one-line description, with the real path in small type underneath.

• You write: architecture.json (subsystems, modules, flows) and descriptions/*.json (a name and description for every file and route).

• Generated: graph.json and index.html.

The scripts do the mechanical work: finding repos, parsing imports and routes, matching HTTP calls to endpoints, layout and rendering. Your job is the part only a reader of the code can do: deciding what things are and saying so plainly.

Existing map: !node ${CLAUDESKILLDIR}/scripts/status.mjs || true
Arguments: $ARGUMENTS

In Codex (or any agent that left the two lines above unfilled): ${CLAUDESKILLDIR} in every command here means this skill's folder, the one holding this SKILL.md, so use its path. Run node ＜that folder＞/scripts/status.mjs from the codebase root yourself to see whether a map exists, and take the path and --refresh from the user's request. The scripts notice they're running under Codex, so the map's Ask bar and "Fix with" prompts use Codex.

Nothing built yet? Draw a blueprint

If the user wants to plan something they haven't built ("here's my PRD", "I want to build an app that…", a long description of a system), make a blueprint: the same map, planned from their document instead of scanned from code. Use this path when there's no code for the system yet, even if the folder holds other things. If the code exists, make a normal map.

1. Read the input. A PRD file, a pasted message, or a document they point you at. Ask 2–3 questions only if something fundamental is open (who uses it, web or mobile, does anyone sign in, does money change hands); otherwise decide and record it as an assumption.

2. Read references/blueprint.md (https://github.com/haydenschmitty/floorplan/blob/main/skills/floorplan/references/blueprint.md), then references/schema.md (https://github.com/haydenschmitty/floorplan/blob/main/skills/floorplan/references/schema.md) for architecture.json.

3. Write floorplan/plan.json: every planned file and endpoint, what each screen calls, which outside services and data each part uses, who may use each endpoint, your assumptions and the open questions. If the PRD is only in the chat, save it as docs/prd.md and use that as source, so the map and later questions can refer back to it.

4. Write floorplan/architecture.json as for a code map (parts, external nodes for the services and data plan.json names, 1–3 flows for the PRD's main user stories, a tour), with globs covering the planned paths. Plain language for everyone, as in step 4 below.

5. Run node ${CLAUDESKILLDIR}/scripts/plan.mjs ＜root＞, then build.mjs (step 5 below). Fix what they report until both are clean. Skip describe.mjs and recent.mjs: names and descriptions come from plan.json. A blueprint adds no notes to CLAUDE.local.md, since there's no code to look up yet.

6. Show it with open.mjs (step 8).

7. Report (instead of step 8's report): the URL; the shape of the system in 3–5 lines; the stack you chose; your main assumptions; and the design review's questions and warnings. Tell them each part has Build this with Claude (or Codex) for a ready request to build just that part; that they can switch the map's Ask bar to Change and ask for additions or changes ("also plan out refunds"), and the map redraws with what changed highlighted (the design review's Resolve on the map fills in such a request, so open questions just need their answer); that plan.json and architecture.json are theirs to edit or to ask you to change; and that the map stays out of git.

(이하 생략 — 전체 SKILL.md는 원본 저장소에서 확인하세요: https://github.com/haydenschmitty/floorplan/blob/main/skills/floorplan/SKILL.md)

원본: https://github.com/haydenschmitty/floorplan/blob/main/skills/floorplan/SKILL.md · 라이선스: MIT — 원문 그대로 옮겼으며, 자세한 조건은 저장소의 LICENSE를 따릅니다.

※ 화면 표시를 위해 꺾쇠괄호(< >)를 전각 문자(＜ ＞)로 바꿨습니다. 그대로 복사해 쓰실 때는 위 원본 저장소의 SKILL.md를 받아 주세요.