메뉴
Document a new architectural decision as an ADR in docs/adrs/. Use when a significant decision was just made or confirmed — one that chose an approach over real alternatives, has non-obvious consequences, or encodes a constraint a future contributor would want to understand.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
HTTP API reference for the /api/* endpoints — generate-image, verify-access-code, verify-key, report, and the admin bearer-session endpoints, plus the CORS, rate-limiting, and auth model. Use before adding, changing, or calling any /api endpoint.
Inventory and evaluate every third-party dependency — who publishes it, its license, stars, release cadence, maintenance health, abandonment risk, and whether to keep or replace it — written to docs/DEPENDENCIES.md. Use when asked to inventory or catalog dependencies, assess dependency health or provenance, review maintenance/abandonment risk, find dependencies worth replacing, or produce an SBOM-style dependency review. It analyzes dependencies but never upgrades them — to apply version updates use dependency-update-audit instead.
Audit package.json dependencies for updates (incl. majors), then upgrade them one at a time — read the migration guide, fix all usage, verify, and commit each on its own
Splotch tech stack, file-by-file source map of web/src/, route table, and the canonical UI element glossary. Use when navigating unfamiliar parts of the codebase, deciding where new code belongs, or needing the proper name of a UI element.
Capacitor native app guide — Android/iOS toolchain setup (macOS + Linux), build/sign/run commands, on-device testing, Chrome remote profiling, and the store release & kids-compliance checklists. Use before touching anything Android, iOS, or Capacitor related.
Capture and read an automated performance profile of the drawing app (web, Android, iOS). Use when measuring drawing/canvas performance, investigating jank or a slow interaction, verifying a perf change, or checking for regressions over time. Covers the `npm run perf:*` harness, how to read report.md/summary.json, and the bottleneck decision guide.
| name | create-adr |
| description | Document a new architectural decision as an ADR in docs/adrs/. Use when a significant decision was just made or confirmed — one that chose an approach over real alternatives, has non-obvious consequences, or encodes a constraint a future contributor would want to understand. |
Document a new architectural decision as an ADR in docs/adrs/.
An ADR is warranted when a decision:
Skip trivial implementation details, stylistic choices, and decisions that are self-evident from reading the code.
Decisions about the asset-generation pipeline (line art, coloring fills, the tools under
tools/asset-gen/) do NOT become numbered ADRs — they live as un-numbered decision records in
tools/asset-gen/docs/ (same Context/Decision/Consequences structure, a descriptive kebab-case
filename, no number). Everything below about numbering and the index applies only to app/infra
decisions in docs/adrs/.
Identify the decision. If the user named it, use that. Otherwise infer it from the current
conversation, recent git log (git log --oneline -20), or the code change being made.
Check for duplicates. Read docs/adrs/README.md and scan existing ADR titles. If the
decision is already covered, update the existing ADR instead of creating a new one.
Verify against current code. Before writing, confirm that the decision is actually reflected in the codebase — read the relevant file(s) and grep for the key patterns. Do not document a decision that has already been reversed.
Determine the next ADR number. Count existing files in docs/adrs/ (excluding README.md)
and use the next four-digit number (0015, 0016, etc.).
Write the ADR file at docs/adrs/NNNN-kebab-case-title.md using the template below.
Update the index. Add one row to the table in docs/adrs/README.md.
# ADR-NNNN: Title
**Status:** Active **Date:** YYYY-MM (approximate is fine)
## Context
What situation or constraint made this decision necessary? What alternatives were considered and why
were they inadequate? Name the alternatives explicitly — "we considered X and Y" is more useful than
a blank "we needed Z."
## Decision
What was decided, and exactly how is it implemented? Cite the key files/lines. If the decision has
gotchas or non-obvious invariants, call them out here (not in Consequences).
## Consequences
Use `\+` / `−` bullets — escape the plus (a bare `+` after the list marker parses as a nested list
and dprint restructures it, ADR-0057) and use U+2212 `−` for minus. Be honest about the downsides —
an ADR with only upsides is not credible and not useful.
After creating the ADR, print a one-paragraph summary of what was documented and why it merited an ADR rather than just a code comment.