メニュー
The Atelier Structure Law — canonical, industrial-standard file structures per stack (Next.js, FastAPI, monorepo, full platform), naming rules, and the intake questions that settle layout once. Load before scaffolding or moving files.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Atelier's native asset tools — image→webp compression, video→webp frame sequences, scrollytelling scaffolding, and AI video generation (Gemini Omni Flash / Veo 3.1) with a graceful no-credentials fallback. Load when handling images, video, storytelling sections, or media generation.
Turn any component site, asset library, or API into something agents can use — a registry entry, a skill, or a full MCP server. Load when the user says "add this site/library to Atelier" or wants to contribute a new integration.
The Atelier operating loop — understand → clarify → plan → execute → review → compare-vs-done-state. Governs when to stop, when to ask, which model tier runs each phase, and when to think deep or compact. Load for ANY nontrivial task.
The thinking protocol — load FIRST on every prompt, before any other skill. Makes any model (Opus, Sonnet, Haiku) reason like a principal engineer - decisive answers, root-cause debugging, security reflexes, outcome-first communication. This is step 0 of the loop.
The design-truth gateway — resolves which design files are authoritative right now (core law + self-learning overlays). Run at the START of any UI/design task, before reading the design law.
The Atelier Auth Law — production-hardened session architecture (rotating refresh tokens, families, grace window, silent refresh, sliding window) plus the anti-patterns that corrupt auth. Load before designing or touching ANY authentication code.
| name | structure-law |
| description | The Atelier Structure Law — canonical, industrial-standard file structures per stack (Next.js, FastAPI, monorepo, full platform), naming rules, and the intake questions that settle layout once. Load before scaffolding or moving files. |
Every stack has ONE canonical layout. Repos never invent their own. Structure
is settled at intake and recorded in projects — never re-litigated per task.
frontend/ or product name? (default: apps/<name>)app/ # routes; server components by default
components/ # one component per file; ui/ for primitives
hooks/ # use*.ts
lib/ # pure utils, api clients, auth
services/ # domain logic calling APIs
public/ # assets: images/ fonts/ icons/ (industry conventions)
styles/ # globals.css, tokens
apps/ # app/ marketing/ studio/ admin/ … (one Next.js app each)
packages/ # ui/ auth/ config/ types/ eslint-config/
turbo.json pnpm-workspace.yaml
app/
api/v1/endpoints/ # thin route handlers
services/ # business logic, LLM/external APIs
core/ # config, db, redis, security — no business logic
workers/ # celery tasks
models/ schemas/ # SQLAlchemy | Pydantic
database/schema.sql # single source of truth
apps/{frontend…, backend-api, worker, model-serving}
packages/ docs/ infra/{docker, cloudflared} scripts/ .github/workflows/
docker-compose.yml .env.example README.md
/api/v1/{feature}/{action}; keep endpoints thin,
logic in services.public/ mirrors industry conventions; docs live in docs/, never scattered.packages//lib/ on second use — DRY is structural..env.example; secrets never committed.