메뉴
Map an unfamiliar repo or subsystem fast: entry points, data flow, key abstractions, and where to make a change. Use when: onboarding to a codebase, understanding unfamiliar code, getting oriented in a new repo or subsystem, figuring out how something works.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Scaffold a web repo with pnpm, Astro, and astro-bulma — plus Drizzle when the site needs a database — including package.json scripts for build/lint/test/fmt (and db:migrate when db-backed). Use when: setting up a new Astro project, scaffolding a web repo, initializing the standard web stack. Building block for create-website.
Add a GitHub Actions CI workflow running build, lint, test, and fmt checks with pnpm. Use when: adding CI, setting up GitHub Actions checks, adding a build/lint/test workflow. Building block for create-website.
Create a new website end-to-end: Astro repo with pnpm/astro-bulma; GitHub Pages for static sites, or Turso + Fly.io when the site needs a database; GitHub Actions for CI and deploy. Use when: creating a new website, spinning up a new web project, new site, scaffolding a static or full-stack Astro project.
Create a new app on Fly.io for the current project without deploying it, generating fly.toml and a Dockerfile. Use when: creating a Fly.io app, setting up Fly hosting, fly launch. Building block for create-website.
Add a GitHub Actions workflow that builds a static site and deploys it to GitHub Pages, with an optional custom domain. Use when: deploying a static site, GitHub Pages hosting, static site with a custom domain. Building block for create-website.
Add a GitHub Actions workflow that deploys to Fly.io on merge to main, with db migrations run as a Fly release_command. Use when: adding a deploy workflow, deploying on merge, setting up continuous deployment to Fly.io. Building block for create-website.
| name | explain-codebase |
| description | Map an unfamiliar repo or subsystem fast: entry points, data flow, key abstractions, and where to make a change. Use when: onboarding to a codebase, understanding unfamiliar code, getting oriented in a new repo or subsystem, figuring out how something works. |
| argument-hint | A repo path, directory, or subsystem name (optional; defaults to the current directory) |
Produce a fast, accurate orientation to an unfamiliar repo or subsystem — enough to know how it works and where to change it.
Use the provided path, directory, or subsystem name. If none is given, default to the current directory. If the repo is large, ask which subsystem to focus on rather than mapping everything.
Explore breadth-first:
package.json, pyproject.toml, go.mod, Makefile, etc.)main, server bootstrap, CLI commands, route registration, exported public APIFor the target area, follow one representative path end to end — request → handler → service → data, or input → transform → output. Note where state lives (DB, cache, in-memory) and the boundaries it crosses.
Name the 3–6 core concepts the codebase is built around (the domain types, base classes, or modules everything routes through) and how they relate.
Produce a tight, scannable summary:
## <Target> — orientation
**What it does:** 1–2 sentences.
**Architecture:** the major pieces and how they connect.
**Primary flow:** the traced path, step by step.
**Key files (most-to-least important):**
- `path/to/file.ts:42` — what it owns
- ...
**Where to change X:** for the user's likely task, where the edit goes.
**Gotchas:** non-obvious coupling, surprising patterns, or landmines.
Every file reference must be a clickable path:line. Keep it a map, not a transcript — the goal is orientation, not exhaustive coverage.