菜单
Review recent decisions from the current conversation and git history, verify existing ADRs still reflect reality, and add or amend ADRs as needed. Use at the end of a session that touched architecture, testing, infrastructure, or build tooling, or when asked to refresh or reconcile the ADRs.
用 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 | update-adrs |
| description | Review recent decisions from the current conversation and git history, verify existing ADRs still reflect reality, and add or amend ADRs as needed. Use at the end of a session that touched architecture, testing, infrastructure, or build tooling, or when asked to refresh or reconcile the ADRs. |
Review recent decisions from the current conversation and git history, verify that all existing ADRs still reflect reality, and add or amend ADRs as needed.
Look for decisions made since the ADRs were last updated. Use these sources in order:
git log --oneline -30 and look for commits whose message implies a
decision: feat:, fix:, refactor:, chore: entries that changed an approach rather than
just adding code.Do NOT go through the full git history — only look at recent context (this session + the last ~30 commits). Decisions from further back are already covered by the existing ADRs or are too stale to recover reliably.
Read docs/adrs/README.md to get the full list, then for each ADR:
**Status:** Active to
**Status:** Superseded by ADR-NNNN or **Status:** Deprecated, and add a short note at the
top explaining what replaced it.Spot-check at minimum: any ADR that references a specific version number, file path, or external tool (Capacitor, Node, JDK, Maestro) — these age fastest.
For each decision found in Step 1 that is not already covered by an existing ADR:
/create-adr for criteria)./create-adr.docs/adrs/README.md.If a decision amends an existing ADR (same topic, updated approach), update the existing file rather than creating a new one — unless the approach changed so substantially that the old reasoning should be preserved as a historical record, in which case deprecate the old one and write a new one.
Print three short lists:
If nothing changed, say so explicitly rather than producing empty lists.