agentic-dev 0.2.2 → 0.2.3

package/.claude/skills/sdd/SKILL.md

@@ -1,13 +1,184 @@
 ---
 name: sdd
-description: "Alias skill for repositories that use `sdd/` as the canonical delivery system."
-user_invocable: true
+description: "Use for any software development request in a repository that treats `sdd/` as the canonical delivery system. Trigger on requests like develop, implement, build, code, work on, modify, fix, patch, refactor, test, verify, deploy, monitor, or screen/UI-driven prompts such as 화면명세서, 화면설계서, 화면 설계, 화면, 화면 스펙, UI, 디자인, 디자인 가이드, screen spec, screen design, or design guide. The workflow is always SDD-first: inspect and update `sdd/01_planning`, create or update the task plan under `sdd/02_plan`, implement the change, record execution in `sdd/03_build`, capture validation in `sdd/04_verify`, and record deployment or monitoring in `sdd/05_operate` when rollout happens."
 ---
 
-## /sdd
+# SDD Development
 
-이 파일은 alias skill이다. canonical SDD workflow는 [`../sdd-dev/SKILL.md`](../sdd-dev/SKILL.md)를 따른다.
+## Overview
 
-Rules:
-- 실제 workflow와 section map은 `sdd-dev` 기준을 사용한다.
-- downstream repo가 `sdd` 이름으로 호출해도 동일한 current-state delivery 규칙으로 해석한다.
+Use this skill for implementation work in repositories that treat `sdd/` as the canonical delivery record.
+
+This skill enforces one workflow:
+1. inspect and fix relevant `sdd/01_planning` artifacts first,
+2. create or update the task plan under `sdd/02_plan/<section>/`,
+3. perform the code work,
+4. record the current implementation summary in `sdd/03_build`,
+5. record the current retained verification summary in `sdd/04_verify`,
+6. record deployment and monitoring outcomes in `sdd/05_operate` when rollout happens.
+
+When rollout is explicitly in scope, and the repository has separate DEV and PROD environments, this skill enforces a staged release rule: deploy to DEV first, complete the retained full-layer validation surface there, promote to PROD only after DEV passes, then rerun the same retained validation surface in PROD. If PROD validation fails, rollback is required unless the user explicitly redirects and that risk is recorded.
+For persistence-affecting work, this skill also enforces schema-parity verification. Always compare migration or model intent against the real DEV and PROD schema state for the affected database objects instead of assuming deployed reality matches the code.
+
+Read [references/section-map.md](references/section-map.md) when you need the exact destination inside `sdd/`.
+For screen-spec-driven UI work, reusable static assets from the spec must be extracted through the repo's canonical asset builder before being used in code.
+For screen-spec-driven layout work, inspect the repo's canonical design guide builder first when one exists.
+For local screen exactness, treat the repo's Playwright exactness runner and suite registry as the canonical automation gate when they exist.
+For verification work, treat regression scope selection as a required retained artifact and carry it through `sdd/02_plan`, `sdd/03_build`, and `sdd/04_verify`.
+Do not infer rollout scope from the existence of `sdd/05_operate` alone; require rollout only when the user asks for deployment or the repo's current policy/plan makes rollout part of completion.
+When a repo or team treats DEV deployment from `main` as the completion bar, temporary branches or worktrees are only working space. Before calling the task deployed, land the final retained change on `main` and push `origin/main`.
+
+## When To Use
+
+Use this skill when:
+- the repository has `sdd/01_planning`, `02_plan`, `03_build`, `04_verify`, `05_operate`,
+- the user gives a development instruction such as `개발해`, `작업해`, `구현해`, `수정해`, `고쳐`, `리팩토링해`, `테스트해`, `배포해`,
+- the user asks for screen/UI work with prompts such as `화면명세서`, `화면설계서`, `화면 설계`, `화면`, `화면 스펙`, `UI`, `디자인`, `디자인 가이드`, `screen spec`, `screen design`, or `design guide`,
+- the user wants work to be traceable through those folders,
+- the task includes both implementation and documentation/verification updates,
+- the task may end in deployment or operational follow-up.
+
+Do not use this skill for:
+- casual questions with no repo changes,
+- one-off local debugging where no durable SDD record is needed,
+- repositories that do not use `sdd/` as their primary document system.
+
+## Workflow
+
+### 1. Inspect Planning First
+
+- Identify the impacted planning area before editing code.
+- Open only the relevant artifacts in `sdd/01_planning`:
+  - feature
+  - screen
+  - architecture
+  - data
+  - api
+  - iac
+  - integration
+  - nonfunctional
+  - security
+  - test
+- If the implementation has already drifted from planning, update the planning artifact first or at least record the drift before coding.
+
+### 2. Create Or Update The Plan
+
+- Create or reuse a durable plan file under `sdd/02_plan/<section>/`.
+- Prefer the repo's planning scaffold if available.
+- The plan must include:
+  - scope
+  - assumptions
+  - acceptance criteria
+  - execution checklist
+  - current notes
+  - validation
+- For any task that may end in deployment, acceptance criteria must explicitly include the DEV gate, the matching PROD gate, the retained full-layer test surface, and the rollback trigger/path.
+- For any task that touches persistence, models, repositories, migrations, SQL, ORM mappings, or runtime failures that may involve schema drift, acceptance criteria must explicitly include DEV/PROD schema verification.
+- Keep exactly one checklist item in progress.
+
+### 3. Implement Against The Plan
+
+- Make code changes only after the impacted planning artifact and plan are aligned enough to proceed.
+- Update the plan current notes after meaningful edits or decisions.
+- When document generators or capture pipelines are involved, keep those tools under `sdd/99_toolchain`.
+- For local screen exactness, treat Playwright as the canonical automation gate unless the repo documents a stronger exact gate for that surface.
+  - In repos created from this template, prefer `python3 sdd/99_toolchain/01_automation/run_playwright_exactness.py --suite <suite-id>` over ad-hoc `npx playwright test ...`.
+  - Keep the suite registry in `sdd/99_toolchain/01_automation/playwright_exactness_manifest.py`.
+  - Browser Use, manual screenshots, or semantic extraction can supplement diagnosis, but they do not replace the retained Playwright exactness gate when a suite exists.
+  - If the needed suite does not exist yet, add or extend it in the same task and register it before calling the work complete.
+- When the task depends on icons, logos, illustrations, or other static assets visible in a screen spec, use the repo's canonical Asset Spec Builder first.
+  - In repos created from this template, this is typically `sdd/99_toolchain/01_automation/spec_asset_builder.py` or a wrapper/manifest around it.
+  - Reusable asset planning records belong under `sdd/01_planning/02_screen/assets/`.
+  - Build the runtime asset from the approved PDF/image source instead of hand-tracing or screenshot-cropping it.
+  - Use exact verification such as `--verify-exact` when the asset is expected to match the source crop exactly.
+  - Record the source, manifest, generated asset path, and any exception in `sdd/03_build` and `sdd/04_verify`.
+  - Only fall back to manual recreation when the builder cannot express the asset, and explicitly document that exception in the plan/build/verify trail.
+- When the task depends on spacing, layout density, typography, color rhythm, or component hierarchy derived from a screen spec, inspect the repo's canonical design guide builder first.
+  - In repos created from this template, inspect `sdd/99_toolchain/01_automation/README.md` and use the actual builder, wrapper, or manifest that exists in the repo.
+  - Use the generated guide as the working baseline before manual spacing or palette tweaks.
+  - If the repo does not provide a design guide builder yet, document the manual interpretation source in plan/build/verify.
+- Define the regression surface before calling implementation complete.
+  - Start from `sdd/02_plan/10_test/regression_verification.md`.
+  - Identify the direct target plus any upstream, downstream, and shared surfaces affected by the change.
+  - If the change touches shared routing, shell/auth, shared state, common components, contracts, generated assets, or builder output, widen the regression scope instead of validating only the edited module.
+  - Record the selected regression scope and any justified exclusions in plan/build/verify.
+- When rollout is in scope, define one retained full-layer validation surface and reuse it in DEV and PROD.
+  - Include the relevant app/runtime entrypoints, API/contracts, persistence/schema, jobs or workflow side effects, shared integrations, and health/monitoring checks affected by the change.
+  - Do not promote to PROD with a narrower verification surface than the DEV gate unless the user explicitly approves that exception and it is recorded.
+
+### 4. Record Build Summary
+
+- Record what you implemented in `sdd/03_build`.
+- Use:
+  - `03_build/01_feature` for feature implementation summaries
+  - `03_build/02_screen` for screen implementation summaries
+  - `03_build/03_architecture`, `06_iac`, `10_test` for current-state cross-cutting summaries
+- Keep entries factual and current-state only: implemented scope, modules, assets, contracts, and current user-visible behavior.
+
+### 5. Record Verification
+
+- Record retained verification status in `sdd/04_verify`.
+- Use:
+  - `04_verify/01_feature` for feature verification summaries
+  - `04_verify/02_screen` for screen verification summaries
+  - `04_verify/03_architecture`, `06_iac`, `10_test` for current retained checks and residual risk
+- Never claim completion without command-level validation evidence.
+- For staged DEV -> PROD rollout, verification must use the same retained full-layer validation surface in both environments.
+  - Run the full-layer validation in DEV after deployment and treat it as a hard gate before PROD promotion.
+  - After PROD deployment, rerun the same retained validation surface in PROD.
+  - If PROD validation fails, execute rollback or the approved recovery procedure immediately and record the failure and recovery outcome.
+- For persistence-affecting work, verification must include real schema evidence from both DEV and PROD when those environments exist.
+  - Check migration state and actual runtime schema separately.
+  - Validate the tables, columns, indexes, constraints, triggers, defaults, and any legacy compatibility objects touched by the change.
+  - Record the commands or queries used, the environments checked, and the drift or parity result.
+- Regression verification is mandatory.
+  - Verification must cover the direct surface and the retained upstream/downstream/shared surfaces selected from the regression baseline.
+  - If no automation exists for a needed regression slice yet, run the best available manual or command checks and record that gap as current residual risk.
+  - When a Playwright suite exists for the surface, record the canonical runner command, suite id, screenshot/json artifact paths, and any live-vs-local split explicitly.
+
+### 6. Record Operate Outcomes
+
+- If deployment or runtime follow-up happens, update `sdd/05_operate`.
+- Use:
+  - `05_operate/01_runbooks` for durable operating procedure changes
+  - `05_operate/02_delivery_status` for the current live state and monitoring baseline
+- Record:
+  - what was deployed
+  - which live baseline is current
+  - how it is monitored
+  - any current residual risk
+- For staged DEV -> PROD rollout, record the DEV gate, PROD gate, and any rollback outcome explicitly.
+- When the DEV deployment baseline is tied to `main`, do not treat a side-branch push as sufficient. Merge, cherry-pick, or otherwise replay the final change onto `main`, push `origin/main`, then record the deployment evidence against that `main` baseline.
+
+## Guardrails
+
+- Do not create or repopulate a parallel `docs/` tree when `sdd/` exists.
+- Do not skip planning review just because the code change looks small.
+- Do not leave build, verify, or operate evidence only in chat text when it should live in `sdd/`.
+- When PROD rollout is in scope, do not promote to PROD before the retained full-layer DEV validation surface has passed.
+- When PROD rollout is in scope, do not use a weaker PROD validation surface than the one that gated DEV unless the user explicitly approves and that risk is recorded.
+- When PROD rollout is in scope, do not stop at "PROD deployment succeeded"; post-deploy PROD validation is mandatory.
+- When PROD rollout is in scope, do not leave a failed PROD deployment unreconciled; rollback or the approved recovery procedure must be executed and recorded.
+- Do not assume local tests, migration heads, or current model code prove deployed schema parity.
+- Do not skip DEV/PROD schema inspection for persistence-affecting work when schema drift could influence behavior.
+- Do not manually redraw screen-spec static assets when a canonical Asset Spec Builder exists for the repo; extract them first and use the generated asset.
+- Do not skip a relevant screen automation builder just because the requested UI change looks like a small manual tweak.
+- Do not stop verification at the edited file, route, or screen when the change can affect shared or adjacent behavior.
+- Do not omit regression scope selection from the retained SDD trail.
+- Do not update `05_operate` for tasks that never reached deployment; explicitly note that rollout did not happen instead.
+- Do not call a DEV rollout complete from a temporary branch when the repo or team baseline expects the deployed change to be on `origin/main`.
+
+## Output Standard
+
+By the end of an implementation task, the expected trail is:
+- planning artifact reviewed or corrected,
+- plan file updated,
+- build summary written,
+- verification summary written, including selected regression scope and residual risk,
+- operate status updated if rollout occurred.
+
+When PROD rollout is in scope, the retained completion state also requires:
+- DEV deployment happened first and the retained full-layer DEV validation surface passed,
+- the same retained full-layer validation surface was executed again in PROD,
+- DEV/PROD schema state was checked and recorded when schema could influence behavior,
+- any PROD validation failure produced rollback or recovery evidence in verify/operate.

package/.claude/skills/sdd/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "SDD Development"
+  short_description: "Use SDD-first flow with schema parity, regression scope, and staged rollout gates"
+  default_prompt: "Use $sdd to handle this development task through sdd planning, build, verify, and operate, including regression scope selection, schema parity checks for persistence-affecting work, and staged DEV-first validation when multiple environments exist."

package/.claude/skills/sdd/references/section-map.md

@@ -0,0 +1,67 @@
+# SDD Section Map
+
+## Planning
+
+- `sdd/01_planning/01_feature`
+  - domain or service feature specifications
+- `sdd/01_planning/02_screen`
+  - service-level screen specifications and PDFs
+- `sdd/01_planning/03_architecture`
+  - bounded context, runtime, and structural design
+- `sdd/01_planning/04_data`
+  - data model and relationship definitions
+- `sdd/01_planning/05_api`
+  - transport contracts and API definitions
+- `sdd/01_planning/06_iac`
+  - infrastructure planning and deployment design
+- `sdd/01_planning/07_integration`
+  - integration contracts and external dependency planning
+- `sdd/01_planning/08_nonfunctional`
+  - performance, reliability, scalability, and operational constraints
+- `sdd/01_planning/09_security`
+  - security posture, threat model, and control planning
+- `sdd/01_planning/10_test`
+  - test strategy and planned cases
+
+## Plan
+
+- `sdd/02_plan/<section>`
+  - executable plan files and migration backlogs
+
+## Build
+
+- `sdd/03_build/01_feature`
+  - feature implementation summaries
+- `sdd/03_build/02_screen`
+  - screen implementation summaries
+- `sdd/03_build/03_architecture`
+  - structural and governance implementation summaries
+- `sdd/03_build/06_iac`
+  - current delivery/runtime implementation summaries
+- `sdd/03_build/10_test`
+  - current harness and validation implementation summaries
+
+## Verify
+
+- `sdd/04_verify/01_feature`
+  - feature verification summaries
+- `sdd/04_verify/02_screen`
+  - screen verification summaries
+- `sdd/04_verify/03_architecture`
+  - governance and structure verification summaries
+- `sdd/04_verify/06_iac`
+  - delivery/runtime verification summaries
+- `sdd/04_verify/10_test`
+  - current harness outputs and retained validation references
+
+## Operate
+
+- `sdd/05_operate/01_runbooks`
+  - durable operating procedures
+- `sdd/05_operate/02_delivery_status`
+  - current live state, monitoring baseline, and residual risk
+
+## Tooling
+
+- `sdd/99_toolchain`
+  - generators, capture tooling, manifests, and other SDD automation

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "agentic-dev",
-  "version": "0.2.2",
+  "version": "0.2.3",
   "description": "Scaffold an agentic template repo with the selected frontend surface and shared toolchain assets.",
   "type": "module",
   "packageManager": "pnpm@10.32.0",

package/.claude/skills/commit/SKILL.md

@@ -1,37 +0,0 @@
----
-name: commit
-description: "Write conventional commits with type, scope, and subject"
-user_invocable: true
----
-
-## /commit
-
-Conventional Commit 형식으로 커밋 메시지를 만든다.
-
-### Use when
-
-- 변경을 저장해야 할 때
-- PR 전 커밋 메시지를 정리할 때
-- 타입/스코프/subject를 일관되게 맞춰야 할 때
-
-### Canonical asset
-
-- `.codex/skills/commit/SKILL.md`
-
-### Rules
-
-- 형식: `type(scope): subject`
-- scope는 필수
-- subject는 현재형 명령문
-- subject 끝에 마침표 금지
-- vague message 금지
-
-### Common types
-
-- `feat`
-- `fix`
-- `refactor`
-- `test`
-- `docs`
-- `ci`
-- `chore`

package/.claude/skills/dev-browser/SKILL.md

@@ -1,30 +0,0 @@
----
-name: dev-browser
-description: "Browser automation with persistent page state"
-user_invocable: true
----
-
-## /dev-browser
-
-브라우저 자동화와 반복 웹 검증을 수행한다.
-
-### Use when
-
-- 페이지 이동, 클릭, 입력, 스크린샷이 필요할 때
-- 웹앱 검증을 자동화할 때
-- 반복 브라우저 작업을 스크립트로 굳힐 때
-
-### Canonical asset
-
-- `.codex/skills/dev-browser/SKILL.md`
-
-### Modes
-
-- standalone Chromium
-- extension relay via user browser
-
-### Rules
-
-- 작은 스크립트 단위로 진행
-- 상태를 확인한 뒤 다음 스크립트로 넘어감
-- 재사용이 필요한 경우에만 `tmp/` 파일로 승격

package/.claude/skills/otro/SKILL.md

@@ -1,43 +0,0 @@
----
-name: otro
-description: "OTRO loop orchestrator for repository-wide multi-step work"
-user_invocable: true
----
-
-## /otro
-
-Repository-wide 작업을 OTRO 루프로 실행한다.
-
-### Use when
-
-- 기능/리팩터/정합 작업이 단일 edit로 끝나지 않을 때
-- 전역 분석 -> TODO graph -> loop dispatch -> reconcile 이 필요할 때
-- 병렬 worker와 residual-based replan이 필요할 때
-
-### Canonical runtime
-
-- Skill assets: `.codex/skills/otro/`
-- Run root: `.codex/skills/otro/runs/<run-name>/`
-
-### Core contract
-
-- Canonical terms: `loop`, `step`, `loop_done`, `run_done`, `repository_done`
-- Task IDs are canonicalized per step as `T{step}{ordinal}`
-- Default planner/worker timeout is `600s`
-- Timeout means force-stop, record timeout, then split into at least two narrower next-step tasks
-- Replanning happens only at the loop boundary
-- If the repository uses `sdd/` or another canonical documentation tree, OTRO must use that system instead of creating parallel docs.
-
-### Process
-
-1. Initialize a run with `.codex/skills/otro/scripts/init_run.sh`.
-2. Write the repository-wide objective in `goal.md`.
-3. Generate the first global plan with `.codex/skills/otro/scripts/plan_loop.py`.
-4. Execute with `.codex/skills/otro/scripts/run_loop.py <run-dir> --until-done`.
-5. Inspect `plans/current-plan.json`, `results/loop-*.json`, and `state.json`.
-6. Continue until `repository_done` is satisfied.
-
-### Read first
-
-- `.codex/skills/otro/references/runtime.md`
-- `.codex/skills/otro/references/contracts.md`

package/.claude/skills/planning-with-files/SKILL.md

@@ -1,37 +0,0 @@
----
-name: planning-with-files
-description: "Keep multi-step work auditable through a live markdown plan file"
-user_invocable: true
----
-
-## /planning-with-files
-
-작업을 plan file로 시작하고, 실행 내내 갱신하고, 검증 로그로 닫는다.
-
-### Use when
-
-- 작업이 여러 단계로 길어질 때
-- edit/test/deploy 흔적을 남겨야 할 때
-- TODO를 durable하게 유지해야 할 때
-
-### Canonical assets
-
-- Codex skill: `.codex/skills/planning-with-files/`
-- Template: `.codex/skills/planning-with-files/assets/plan-template.md`
-- Scaffolder: `.codex/skills/planning-with-files/scripts/new_plan.sh`
-
-### Process
-
-1. `scripts/new_plan.sh "<title>" [repo_root] [section]`로 plan을 만든다.
-2. 저장소가 `sdd/02_plan/<section>/` 규칙을 쓰면 그 위치를 canonical로 사용한다.
-3. `templates` 같은 저장소에서는 `docs/plans/`를 만들지 않고 `sdd/02_plan/<section>/` 아래 생성된 파일에 scope, assumptions, acceptance criteria를 적는다.
-4. 5-10개의 concrete checklist로 쪼갠다.
-5. 항상 하나의 active item만 둔다.
-6. edit/test/deploy 뒤에는 evidence log를 짧게 남긴다.
-7. 마지막에 validation status와 residual risk를 적고 닫는다.
-
-### Guardrails
-
-- stale checklist를 남기지 않는다
-- evidence 없는 완료 표시는 금지
-- dead item을 쌓지 말고 현재 plan을 갱신한다

package/.claude/skills/prd/SKILL.md

@@ -1,27 +0,0 @@
----
-name: prd
-description: "Generate a structured JSON PRD for executable delivery work"
-user_invocable: true
----
-
-## /prd
-
-실행 가능한 JSON PRD를 생성한다.
-
-### Use when
-
-- 기능 요구사항을 정형화해야 할 때
-- stories, routes, quality gates를 한 파일로 고정해야 할 때
-- 구현 전에 scope를 잠가야 할 때
-
-### Canonical asset
-
-- `.codex/skills/prd/SKILL.md`
-
-### Rules
-
-- 구현하지 말고 PRD만 생성
-- quality gates는 반드시 묻고 포함
-- story는 single iteration 크기로 쪼갬
-- 새 프로젝트면 setup story를 먼저 둠
-- output은 JSON 정본 하나만 저장

package/.claude/skills/ralph-loop/SKILL.md

@@ -1,42 +0,0 @@
----
-name: ralph-loop
-description: "Run a bounded implement-test-fix loop with explicit stop conditions"
-user_invocable: true
----
-
-## /ralph-loop
-
-짧은 reproduce -> edit -> validate -> decide 루프를 돌린다.
-
-### Use when
-
-- 버그 수정이 반복 검증을 필요로 할 때
-- flaky 여부나 fail-same / fail-new 분류가 중요할 때
-- stop condition이 명확한 bounded loop가 필요할 때
-
-### Canonical assets
-
-- Codex skill: `.codex/skills/ralph-loop/`
-- Script: `.codex/skills/ralph-loop/scripts/loop_until_success.sh`
-- Reference: `.codex/skills/ralph-loop/references/failure-triage.md`
-
-### Loop contract
-
-1. failing reproduction 또는 target validation command를 고정한다.
-2. iteration마다 한 가지 change만 넣는다.
-3. 즉시 validation을 돌린다.
-4. 결과를 `pass`, `fail-same`, `fail-new`, `flaky`, `no-signal`로 분류한다.
-5. 다음 action을 정한 뒤에만 다시 edit한다.
-
-### Stop conditions
-
-- validation passes
-- max iterations reached
-- same failure repeats 3 times without new signal
-- missing dependency or external decision blocks progress
-
-### Command example
-
-```bash
-.codex/skills/ralph-loop/scripts/loop_until_success.sh --cmd "pytest -q tests/foo_test.py" --max 6
-```

package/.claude/skills/sdd-dev/SKILL.md

@@ -1,71 +0,0 @@
----
-name: sdd-dev
-description: "Use the SDD-first workflow for any development task in repos that use sdd/"
-user_invocable: true
----
-
-## /sdd-dev
-
-개발 작업을 항상 `sdd/` 산출물 기준으로 진행한다. 화면명세서, 화면설계서, 화면 스펙, 디자인, 디자인 가이드 같은 화면 개발 프롬프트도 이 스킬의 트리거로 본다.
-배포가 실제 범위이고 개발계 배포 completion bar가 `main` 기준인 저장소에서는 임시 브랜치나 worktree를 써도 최종 반영은 반드시 `origin/main`까지 올라가야 완료로 본다.
-배포가 실제 범위이고 개발계와 운영계가 분리된 저장소에서는 배포 순서를 `DEV 배포 -> DEV 전 레이어 검증 통과 -> PROD 배포 -> PROD 동일 레이어 검증`으로 고정한다. 운영 검증이 실패하면 롤백 또는 명시된 복구 절차가 필수다.
-스키마가 동작에 영향을 줄 수 있는 작업은 코드나 migration head만 보지 않고 DEV/PROD 실제 스키마 상태를 확인해야 한다.
-
-### Use when
-
-- 사용자가 `개발해`, `작업해`, `구현해`, `수정해`, `고쳐`, `리팩토링해`, `테스트해`, `배포해`처럼 개발을 지시할 때
-- 사용자가 `화면명세서`, `화면설계서`, `화면 설계`, `화면`, `화면 스펙`, `UI`, `디자인`, `디자인 가이드`처럼 화면 개발/정렬을 지시할 때
-- 저장소가 `sdd/01_planning`, `02_plan`, `03_build`, `04_verify`, `05_operate` 구조를 쓸 때
-- 코드 수정과 함께 계획, 검증, 운영 흔적도 남겨야 할 때
-
-### Canonical assets
-
-- Codex skill: `.codex/skills/sdd/`
-- Section map: `.codex/skills/sdd/references/section-map.md`
-
-### Workflow
-
-1. 먼저 `sdd/01_planning`의 관련 산출물을 확인하고 구현과 어긋난 부분을 바로잡는다.
-2. `sdd/02_plan/<section>/`에 작업 계획을 만들거나 기존 계획을 갱신한다.
-   - 배포가 범위에 있으면 acceptance criteria에 `DEV 게이트`, `동일한 PROD 게이트`, `전 레이어 테스트 범위`, `롤백 조건/절차`를 명시한다.
-   - persistence, migration, repository, ORM mapping, SQL, 운영 장애 대응이 걸린 작업이면 acceptance criteria에 `DEV/PROD 스키마 검증`을 넣는다.
-3. 코드 작업을 수행하고, 의미 있는 결정은 계획 로그에 남긴다.
-   - 화면명세서에 있는 아이콘, 로고, 일러스트, 기타 정적 자산이 필요하면 먼저 저장소의 canonical `스펙에셋빌더`로 추출한다.
-   - 템플릿 기준 canonical 경로는 `sdd/99_toolchain/01_automation/spec_asset_builder.py` 또는 그 wrapper/manifest다.
-   - reusable asset planning 기록은 `sdd/01_planning/02_screen/assets/` 아래에 둔다.
-   - source crop과 동일해야 하는 자산은 가능하면 `--verify-exact`까지 수행한다.
-   - builder로 표현 가능한 자산을 수동 redraw나 screenshot crop으로 대체하지 않는다. 예외가 필요하면 plan/build/verify에 이유를 남긴다.
-   - 화면 여백, 레이아웃 밀도, 타이포, 색상 리듬, 컴포넌트 hierarchy가 명세 기반이면 저장소의 canonical 디자인 가이드 빌더가 있는지 먼저 확인하고, 있으면 그 산출물을 기준으로 구현한다.
-   - 템플릿 기준으로는 `sdd/99_toolchain/01_automation/README.md`와 실제 존재하는 builder/wrapper/manifest를 canonical source로 본다.
-   - local screen exactness는 Playwright를 canonical automation gate로 본다.
-   - 템플릿 기준 canonical runner는 `python3 sdd/99_toolchain/01_automation/run_playwright_exactness.py --suite <suite-id>`이고, suite registry는 `sdd/99_toolchain/01_automation/playwright_exactness_manifest.py`다.
-   - direct `npx playwright test ...` 호출은 디버깅 예외로만 쓰고, retained verification command는 toolchain wrapper 기준으로 남긴다.
-   - Playwright suite가 이미 있으면 Browser Use/manual screenshot/semantic extraction은 보조 진단일 뿐 canonical gate를 대체하지 않는다.
-   - 배포가 범위에 있으면 DEV와 PROD에 같은 `전 레이어 검증 surface`를 재사용하도록 미리 정의한다. 앱/라우트, API, persistence/schema, 배치/워크플로, 연동, 헬스/모니터링을 포함한다.
-4. 구현/실행 기록은 `sdd/03_build`에 남긴다.
-5. 테스트와 검증 근거는 `sdd/04_verify`에 남긴다.
-   - DEV 배포가 있으면 DEV에서 먼저 전 레이어 검증을 수행하고, 통과 전에는 PROD로 올리지 않는다.
-   - PROD 배포 후에는 DEV와 같은 검증 surface를 PROD에서 다시 실행한다.
-   - persistence 영향 가능성이 있으면 DEV/PROD 모두에서 실제 스키마, index, constraint, trigger, default, legacy column drift를 확인한다.
-   - PROD 검증 실패 시 즉시 롤백 또는 승인된 복구 절차를 실행하고 결과를 남긴다.
-   - Playwright suite가 있는 surface는 suite id, canonical runner command, screenshot/json artifact path를 verify에 함께 남긴다.
-6. 실제 배포나 운영 후속이 있으면 `sdd/05_operate`에 남긴다.
-   - 개발계 배포 baseline이 `main`이면 완료 전에 `main`에 merge, cherry-pick, 또는 동등한 방식으로 반영한 뒤 `origin/main`을 push한다.
-   - side branch에만 올라간 상태로는 개발계 배포 완료로 보지 않는다.
-   - DEV 게이트 통과 근거, PROD 게이트 통과 근거, 롤백이 있었다면 그 트리거와 결과를 함께 기록한다.
-
-### Guardrails
-
-- `sdd/`가 있는 저장소에서 별도 `docs/` 트리를 만들지 않는다.
-- planning review 없이 바로 코드부터 수정하지 않는다.
-- 검증 결과를 채팅에만 남기지 말고 `sdd/04_verify`에도 기록한다.
-- PROD 배포가 범위일 때 DEV 전 레이어 검증이 통과하기 전에는 PROD 배포를 진행하지 않는다.
-- PROD 배포가 범위일 때 DEV보다 약한 범위로 PROD 검증을 축소하지 않는다. 예외는 사용자 승인과 문서화가 필요하다.
-- PROD 배포가 범위일 때 PROD는 "배포 성공"만으로 끝내지 않는다. 배포 후 동일 레이어 검증이 필수다.
-- PROD 배포가 범위일 때 실패한 PROD 배포를 미해결 상태로 두지 않는다. 롤백 또는 승인된 복구 절차를 실행하고 기록한다.
-- local 테스트 통과, model 코드, migration head만으로 DEV/PROD 스키마가 같다고 가정하지 않는다.
-- schema drift 가능성이 있는 작업에서 DEV/PROD 실제 스키마 확인을 생략하지 않는다.
-- canonical `스펙에셋빌더`가 있는 저장소에서는 화면명세 정적 자산을 수동 재작성하지 않는다.
-- 화면 관련 자동화 builder가 있으면 작은 UI 수정처럼 보여도 먼저 확인한다.
-- 배포가 없었으면 `05_operate`에 허위 기록을 남기지 않는다.
-- 개발계 배포 baseline이 `main`인 저장소에서 side branch push만으로 배포 완료라고 판단하지 않는다.

package/.claude/skills/sdd-development/SKILL.md

@@ -1,13 +0,0 @@
----
-name: sdd-development
-description: "Alias skill for the canonical SDD-first development workflow."
-user_invocable: true
----
-
-## /sdd-development
-
-이 파일은 alias skill이다. canonical SDD workflow는 [`../sdd-dev/SKILL.md`](../sdd-dev/SKILL.md)를 따른다.
-
-Rules:
-- planning, build, verify, operate 기록은 `sdd-dev` 규칙과 동일하다.
-- downstream repo는 `sdd-development` 이름을 그대로 복제할 수 있다.

package/.codex/skills/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "OTRO"
-  short_description: "Overlap-tolerant residual orchestration"
-  default_prompt: "Use $OTRO to analyze the repository globally, dispatch bounded Codex workers, reconcile residual overlap, and replan until repository-level gates are satisfied."