ai-ops-cli 0.2.4 → 1.0.1

package/data/skills/task-skills/spec-product-03-brief-to-product-spec/references/template.md

@@ -0,0 +1,41 @@
+# 10_product-spec.md Template
+
+```md
+# 10 Product Spec
+
+## 핵심 사용자 플로우
+1. 플로우 1
+2. 플로우 2
+
+## 기능
+- 기능 1
+- 기능 2
+
+## 엔티티
+- 엔티티명
+  - 목적
+  - 핵심 필드
+
+## 비즈니스 규칙
+- 규칙 1
+- 규칙 2
+
+## 엣지 케이스
+- empty state
+- loading state
+- error state
+
+## 성공 기준
+- 기준 1
+- 기준 2
+
+## 기술 제약 반영 메모
+- 어떤 제약이 제품 구조에 영향을 주는지
+
+## 보안 고려사항
+- auth / 권한 / 민감정보 / 업로드 / 외부 호출 / tenant 경계 관련 메모
+- 없으면 `특이사항 없음`
+
+## 미해결 결정사항
+- 결정사항 1
+```

package/data/skills/task-skills/spec-product-04-product-spec-to-ui-spec/SKILL.md

@@ -0,0 +1,93 @@
+---
+name: spec-product-04-product-spec-to-ui-spec
+description: Generate initial Korean 20_ui-spec.md, optional English 21_stitch-prompt.md, and initial visual guidance from approved product specs, screenshots, or Stitch/reference drafts for first product implementation only.
+disable-model-invocation: true
+---
+
+# spec-product-04-product-spec-to-ui-spec
+
+Use this skill when `./docs/specs/baseline/10_product-spec.md` is approved and the product needs initial UI direction before first implementation.
+
+Default outputs:
+
+- `./docs/specs/baseline/20_ui-spec.md`
+- optional `./docs/specs/baseline/21_stitch-prompt.md`
+- optional `./docs/specs/baseline/22_stitch-assets/DESIGN.md`
+- optional `./docs/specs/baseline/24_design-tokens.md`
+
+Do not use this skill as the default path for MVP-afterward UI changes. Ongoing UI work belongs in `.codex/plans/*.md` with screenshots, reference apps, and detailed requested adjustments.
+
+## Language Rules
+
+- `20_ui-spec.md`, `DESIGN.md`, and `24_design-tokens.md` must be written in Korean.
+- `21_stitch-prompt.md`, when created, must be written in English.
+- Keep code-facing names, API field names, library/service names, protocol names, file paths, and standard technical terms in their natural English form when clearer.
+- Do not force awkward phonetic transliterations.
+
+## Required Inputs
+
+1. `./docs/specs/baseline/05_technical-context.md`
+2. `./docs/specs/baseline/10_product-spec.md`
+3. optional user-provided screenshots, reference apps, mood notes, or visual constraints
+4. optional Stitch output under `./docs/specs/baseline/22_stitch-assets/`
+
+## Objective
+
+Define initial UI structure and states clearly enough for first implementation, while treating visual references as concept/draft input rather than product truth.
+
+The skill should:
+
+- enumerate screens from approved user flows
+- define screen purpose, primary actions, states, and navigation boundaries
+- preserve target platform constraints
+- normalize initial visual direction against approved product scope
+- reject or defer visual ideas that imply unapproved product behavior
+- create a Stitch prompt only when external visual generation will reduce ambiguity
+
+## Workflow
+
+1. Read approved product and technical context.
+2. Identify UI surfaces that are required for the first build.
+3. Draft `20_ui-spec.md` around screens, states, interactions, and design constraints.
+4. If the user wants Stitch concepting, write `21_stitch-prompt.md` in English.
+5. If screenshots or Stitch output already establish reusable visual rules, write or update baseline `DESIGN.md` and optional tokens.
+6. Record security-relevant UI surfaces under `보안 고려사항`.
+
+## Visual Reference Rules
+
+- Stitch, screenshots, and reference apps are inspiration and structure references, not product truth.
+- Approved product spec and technical context outrank visual references.
+- If a reference introduces unsupported features, labels, business rules, biometric/medical claims, social mechanics, monetization, or platform assumptions, reject or mark them out of scope.
+- For Flutter or native apps, translate visual ideas into native primitives and theme/tokens. Do not treat HTML/CSS as the shipping stack.
+- Keep initial guidance practical enough for `spec-product-05` to create implementation packets.
+
+## Security Lens
+
+Keep this pass UI-focused and short.
+
+- Check whether the UI introduces auth-sensitive actions, destructive actions, file upload/download, rendered user content, or admin-only surfaces.
+- Record the result under `보안 고려사항`.
+- If any trigger appears or the trust boundary is unclear, recommend `spec-security-01-triage` in `mode=spec`.
+
+Use these references while drafting:
+
+- [references/ui-spec-template.md](references/ui-spec-template.md)
+- [references/stitch-prompt-template.md](references/stitch-prompt-template.md)
+
+## Required UI Spec Sections
+
+- `화면 목록`
+- `화면 목적`
+- `상태 정의`
+- `주요 인터랙션`
+- `디자인 제약`
+- `초기 시각 참고 / 구현 번역 규칙`
+- `보안 고려사항`
+
+## Mermaid Rule
+
+Include Mermaid only when navigation or state coverage is dense.
+
+- Use flowchart for screen-to-screen navigation.
+- Use stateDiagram for per-screen states when more than 4 states or transitions matter.
+- Skip Mermaid if prose is enough.

package/data/skills/task-skills/spec-product-04-product-spec-to-ui-spec/agents/openai.yaml

@@ -0,0 +1,6 @@
+interface:
+  display_name: "spec-product-04-product-spec-to-ui-spec"
+  short_description: "Create initial UI spec, optional Stitch prompt, and first-build visual guidance."
+  default_prompt: "Use $spec-product-04-product-spec-to-ui-spec to create an initial Korean 20_ui-spec.md, optional English 21_stitch-prompt.md, and practical first-build visual guidance from approved product specs and reference inputs."
+policy:
+  allow_implicit_invocation: false

package/data/skills/task-skills/spec-product-04-product-spec-to-ui-spec/references/stitch-prompt-template.md

@@ -0,0 +1,41 @@
+# 21_stitch-prompt.md Template
+
+```md
+# Stitch Prompt
+
+## Product Context
+- Summarize the product in 3-5 lines.
+
+## Technical Context
+- Mention the intended platform and implementation constraints relevant to UI generation.
+- Say the generated result is an initial visual reference, not product truth or the shipped technology stack.
+
+## Core User Flows
+1. Flow 1
+2. Flow 2
+
+## Screens To Generate
+- Screen 1
+- Screen 2
+
+## Required States
+- empty
+- loading
+- error
+- success
+
+## Key Interactions
+- Interaction 1
+- Interaction 2
+
+## Design Direction
+- Visual tone
+- Layout constraints
+- Platform assumptions
+- Current design-system constraints, if any
+
+## Scope Guardrails
+- Do not invent unapproved features, pricing, social mechanics, medical claims, or backend behavior.
+- Do not imply that HTML/CSS is the implementation stack.
+- Treat output as concept art/reference for first implementation.
+```

package/data/skills/task-skills/spec-product-04-product-spec-to-ui-spec/references/ui-spec-template.md

@@ -0,0 +1,39 @@
+# 20_ui-spec.md Template
+
+```md
+# 20 UI Spec
+
+## 화면 목록
+- 화면명
+
+## 화면 목적
+- 화면별 목적과 주요 사용자 행동
+
+## 상태 정의
+- empty
+- loading
+- error
+- success
+
+## 주요 인터랙션
+- 인터랙션 1
+- 인터랙션 2
+
+## 디자인 제약
+- 접근성
+- 반응형
+- 시각 톤
+- 플랫폼 제약
+
+## 초기 시각 참고 / 구현 번역 규칙
+- 참고 screenshot, reference app, Stitch 결과는 initial concept reference다.
+- 승인된 product spec과 technical context가 더 우선한다.
+- 구현 대상은 승인된 target platform이며, Flutter 프로젝트라면 Flutter widget tree와 theme/token으로 번역한다.
+- HTML/CSS를 그대로 이식하지 않는다.
+- 레이아웃 계층, CTA 우선순위, 정보 그룹, 상태 표현, 주요 인터랙션 중 제품에 승인된 부분만 유지한다.
+- 범위 밖 아이디어는 `범위 제외` 또는 후속 plan 후보로 분리한다.
+
+## 보안 고려사항
+- auth-sensitive action, destructive action, upload/download, rendered content 관련 메모
+- 없으면 `특이사항 없음`
+```

package/data/skills/task-skills/spec-product-05-spec-to-work-packets/SKILL.md

@@ -0,0 +1,157 @@
+---
+name: spec-product-05-spec-to-work-packets
+description: Convert approved baseline product specs into initial-build Korean work packets under docs/specs/initial-build, with explicit scope, tests, dependencies, and repo-reality bootstrap/foundation packets when needed.
+disable-model-invocation: true
+---
+
+# spec-product-05-spec-to-work-packets
+
+Use this skill only when the next artifact is the first implementation packet set for a product baseline.
+
+## Output Location
+
+- Write into the current workspace.
+- Create or continue one initial-build batch such as `./docs/specs/initial-build/2026-03-21_initial-build/`.
+- If no active initial-build batch exists yet, create `./docs/specs/initial-build/YYYY-MM-DD_initial-build/`.
+- Default output path: `./docs/specs/initial-build/<initial-build-topic>/30_work-packets/*.md`
+- Optional summary artifact: `./docs/specs/initial-build/<initial-build-topic>/30_work-packets/00_packet-map.md`
+
+Do not use this skill as the default path for MVP 이후 changes. Ongoing changes belong in `.codex/plans/*.md`.
+
+## Required Inputs
+
+Read all relevant available inputs before writing packets:
+
+1. `./docs/specs/baseline/05_technical-context.md`
+2. `./docs/specs/baseline/10_product-spec.md`
+3. `./docs/specs/baseline/20_ui-spec.md` when the product includes approved UI surfaces
+4. optional initial visual references under `./docs/specs/baseline/22_stitch-assets/`
+5. optional `./docs/specs/baseline/22_stitch-assets/DESIGN.md`
+6. optional `./docs/specs/baseline/24_design-tokens.md`
+7. current repository manifests, config files, and top-level app/package directories relevant to the approved stack
+
+Use what exists. Explicitly note missing but relevant inputs.
+
+If the product has no user-facing UI by design, proceed from `05_technical-context.md` and `10_product-spec.md` without inventing UI docs or visual inputs.
+
+If the product has UI but no visual references exist, proceed from `20_ui-spec.md`; visual references are helpful but never a blocker.
+
+## Language Rules
+
+- Write every work packet in Korean.
+- Keep code identifiers, API field names, library/service names, protocol names, file paths, and standard technical terms in their natural English form when clearer.
+- Do not force awkward phonetic transliterations.
+
+## Objective
+
+Produce initial-build packets that are independently understandable, independently implementable, and small enough for human review and safe AI execution.
+
+For initial-build work, packet generation must stay grounded in the current repository reality, not an imagined clean scaffold.
+
+The packet set should be `parallel-ready`:
+
+- packets are small enough to hand to one worker at a time
+- dependencies are explicit enough that plan mode can order or parallelize them
+- hidden coupling is minimized before execution begins
+
+## Required Sections
+
+Every packet must include:
+
+- `목표`
+- `범위`
+- `입력물`
+- `산출물`
+- `대상 파일 / 모듈`
+- `승인 기준`
+- `보안 검토`
+- `테스트`
+- `의존성`
+- `범위 제외`
+
+For UI-touching packets:
+
+- `입력물` should include `20_ui-spec.md` and any relevant visual guidance that exists
+- `승인 기준` must state which UI structure, hierarchy, states, and interactions must survive in the approved target platform
+- any intentional deviation from initial visual references must be named explicitly
+
+## Security Overlay
+
+Every packet must include `보안 검토`.
+
+- `보안 검토` must state `판정: 필요 | 불필요 | 확인 필요`.
+- It must briefly list trigger surfaces and say whether implementation-stage security review is required.
+- If the packet touches auth, permission, sensitive data, tenant boundaries, external fetch, uploads, raw queries, rendered content, or destructive actions, do not mark it `불필요` unless the packet is clearly documentation-only.
+- If risk is unclear, use `확인 필요` and recommend `spec-security-01-triage` in `mode=spec`.
+
+## Dependency Rules
+
+Every packet must make dependency state explicit.
+
+- If there is no dependency, write `없음`.
+- If another packet must finish first, name the packet ID explicitly.
+- If the packet is blocked by a contract, schema, design decision, or external approval, name that dependency explicitly.
+- If the packet is likely parallel-safe with other packets, note that inside `의존성`.
+- Never leave dependencies implied or blank.
+
+Use a compact structure such as:
+
+- `선행 패킷: 없음`
+- `선행 패킷: 001_api-shell`
+- `외부 결정 / 선행 계약: Supabase auth schema 확정`
+- `병렬 가능 후보: 003_home-shell, 004_session-card`
+
+## Repository Reality Check
+
+Before drafting packets, inspect the current repository for concrete evidence of the approved stack.
+
+- Check stack signals such as `package.json`, lockfiles, workspace manifests, `next.config.*`, `components.json`, `tailwind.config.*`, `pubspec.yaml`, `lib/`, `android/`, `ios/`, `nest-cli.json`, `src/main.ts`, `prisma/schema.prisma`, GraphQL schema/config files, and existing app/package directories.
+- Use product surfaces declared in `05_technical-context.md` to decide which signals matter.
+- Classify each approved surface as `present`, `partial`, or `absent`.
+- If any approved surface is `partial` or `absent`, create explicit bootstrap/foundation packets before feature packets for that surface.
+
+## Bootstrap / Foundation Rules
+
+Bootstrap work is first-class packet work.
+
+- Prefer clear packet names such as `000_repo-bootstrap`, `001_web-foundation`, `002_backend-foundation`, or `003_db-foundation`.
+- Cover the minimum setup required to make later feature packets realistic:
+  - package manager / workspace initialization when missing
+  - framework scaffold or base module wiring
+  - required approved dependencies installation
+  - baseline config files and directory structure
+  - environment/example config wiring needed for local execution
+  - smoke-level verification such as install success, boot success, or schema generation success
+- Downstream feature packets must list relevant foundation packet IDs in `선행 패킷`.
+- Do not scatter the same installation or scaffold work across multiple feature packets.
+
+Use these references while drafting:
+
+- [references/work-packet-template.md](references/work-packet-template.md)
+- [references/stitch-html-review.md](references/stitch-html-review.md) only when initial Stitch HTML exists and materially helps UI packet boundaries
+
+## Glossary Rule
+
+- Check `./docs/specs/baseline/01_glossary.md` only if packet wording could drift from established entity, state, or UI terminology.
+- Do not run `spec-shared-glossary-sync` by default after packet generation. Run it only if packeting surfaced meaningful new terms or clear terminology collisions.
+
+## Mermaid Rule
+
+Include Mermaid only when dependency structure is hard to scan in prose.
+
+- If packet count is 4 or more, or dependency order across backend/mobile/domain seams is hard to scan, prefer adding `00_packet-map.md`.
+- Use graph TD for packet dependency DAGs.
+- Skip Mermaid if packets are already linear and obvious.
+
+If `00_packet-map.md` is created, packet files' `## 의존성` sections remain the canonical dependency source.
+
+## Quality Bar
+
+The packet set is not ready if:
+
+- it assumes a framework scaffold that is absent from the repo
+- dependencies are implied rather than explicit
+- bootstrap work is hidden inside feature packets
+- security trigger surfaces are not marked
+- UI packets ignore approved UI spec or current visual guidance
+- packets are too broad for one worker to implement safely

package/data/skills/task-skills/spec-product-05-spec-to-work-packets/agents/openai.yaml

@@ -0,0 +1,6 @@
+interface:
+  display_name: "spec-product-05-spec-to-work-packets"
+  short_description: "Split baseline specs into initial-build packets with repo-reality foundation work."
+  default_prompt: "Use $spec-product-05-spec-to-work-packets to convert the approved baseline spec set into initial-build Korean work packets under docs/specs/initial-build, checking the current repository against the approved stack and creating explicit foundation packets when required surfaces are missing."
+policy:
+  allow_implicit_invocation: false

package/data/skills/task-skills/spec-product-05-spec-to-work-packets/references/stitch-html-review.md

@@ -0,0 +1,25 @@
+# Stitch HTML Review Checklist
+
+Use this checklist before writing initial-build UI packets from Stitch output.
+
+## Extract
+
+- top-level screens represented by each HTML file
+- repeated layout regions such as header, shell, side panel, footer
+- major interactive blocks such as forms, tables, tabs, charts, filters
+- visible state variants such as disabled, active, empty, loading-like placeholders, error copy
+
+## Do Not Assume
+
+- generated class names are production-ready structure
+- every visual grouping should become a component
+- missing states mean those states do not exist
+- HTML output means the shipped product should be implemented as web markup
+
+## Use For Packeting
+
+- identify natural UI seams
+- identify likely component boundaries
+- identify stateful regions needing separate implementation work
+- cross-check whether the generated visuals introduce behavior not present in the approved spec
+- identify which approved layout hierarchy, CTA priority, copy grouping, and state presentation should survive target-platform translation

package/data/skills/task-skills/spec-product-05-spec-to-work-packets/references/work-packet-template.md

@@ -0,0 +1,67 @@
+# Work Packet Template
+
+```md
+# 001 패킷 제목
+
+## 목표
+
+- 이번 패킷이 끝나면 무엇이 가능해져야 하는가
+- foundation 패킷이면 이후 기능 패킷이 실제 repo 위에서 시작 가능해야 한다.
+
+## 범위
+
+- 포함되는 변경 범위
+- 설치, scaffold, config, env wiring만 다루는 foundation 패킷인지 여부를 명확히 적는다.
+
+## 입력물
+
+- `./docs/specs/baseline/05_technical-context.md`
+- `./docs/specs/baseline/10_product-spec.md`
+- 필요 시 `./docs/specs/baseline/20_ui-spec.md`
+- 필요 시 `./docs/specs/baseline/22_stitch-assets/...`
+- 필요 시 `./docs/specs/baseline/22_stitch-assets/DESIGN.md`
+- 필요 시 `./docs/specs/baseline/24_design-tokens.md`
+- 현재 repo의 관련 manifest / config / app 디렉터리 상태 (`package.json`, `pubspec.yaml`, `next.config.*`, `nest-cli.json`, `prisma/schema.prisma` 등)
+
+## 산출물
+
+- 기대 결과물
+- foundation 패킷이면 생성되거나 정리될 scaffold, config, dependency install 결과를 적는다.
+
+## 대상 파일 / 모듈
+
+- 수정 또는 생성 대상
+- 필요 시 `package.json`, lockfile, `pubspec.yaml`, `next.config.*`, `tailwind.config.*`, `components.json`, `nest-cli.json`, `src/main.ts`, `prisma/schema.prisma`, `apps/*`, `packages/*`, `lib/*` 같은 기반 파일을 명시한다.
+
+## 승인 기준
+
+- 기준 1
+- 기준 2
+- foundation 패킷이면 이후 패킷이 가정하는 framework scaffold와 dependency wiring이 repo에 실제로 존재해야 한다.
+- foundation 패킷이면 최소 한 가지 smoke 검증 기준을 넣는다. 예: install 성공, dev boot 성공, schema generation 성공.
+- UI 패킷이면 `20_ui-spec.md`와 initial visual guidance에서 승인된 화면 구조, CTA 우선순위, 상태 표현, 주요 인터랙션을 target platform에 맞게 보존해야 한다.
+- 헤드리스 / 백엔드 패킷이면 화면 문서를 새로 만들지 않고 계약, 데이터 흐름, 운영 동작 기준으로 검증 가능해야 한다.
+
+## 보안 검토
+
+- 판정: 필요 / 불필요 / 확인 필요
+- 트리거: auth / 권한 / 민감정보 / 업로드 / 외부 호출 / raw query / 렌더링 / tenant 경계 / 삭제 동작 중 해당 사항
+- 구현 후 리뷰 조건: 필요 없으면 `없음`
+
+## 테스트
+
+- 테스트 1
+- 테스트 2
+- foundation 패킷이면 smoke test, install verification, scaffold verification, generated file presence 중 최소 하나를 넣는다.
+
+## 의존성
+
+- 선행 패킷: 없음 / `000_repo-bootstrap` / `001_xxx`
+- 외부 결정 / 선행 계약: 없으면 `없음`
+- 병렬 가능 후보: 없으면 `없음`
+
+## 범위 제외
+
+- 이번 패킷에서 다루지 않을 것
+- foundation 패킷이면 실제 기능 구현, 세부 UI 완성, 비즈니스 로직은 범위 제외로 분리한다.
+```

package/data/skills/task-skills/spec-shared-glossary-sync/SKILL.md

@@ -0,0 +1,102 @@
+---
+name: spec-shared-glossary-sync
+description: Create or update a Korean 01_glossary.md inside the current project's docs/specs/baseline directory by standardizing domain terms, entities, states, UI labels, and English code-facing names across baseline docs and active .codex/plans.
+disable-model-invocation: true
+---
+
+# spec-shared-glossary-sync
+
+Use this skill when the project needs a shared glossary or when existing docs/specs/plans have begun to drift in terminology.
+
+Typical high-value run points are:
+
+- after `brief`
+- after `product spec`
+- after `ui spec`
+- during `spec-baseline-sync` if implemented terminology changed
+- whenever naming drift is noticed
+
+Usually skip automatic reruns after small plans unless new shared terminology was introduced.
+
+## Output Location
+
+- Write into the current workspace.
+- Default output path: `./docs/specs/baseline/01_glossary.md`
+
+## Language Rules
+
+- Write the glossary in Korean.
+- Keep code-facing English identifiers, API field names, library/service names, protocol names, file paths, and standard technical terms in their natural English form when clearer.
+- Do not invent awkward Koreanized spellings for standard English technical terms.
+- If a term needs explanation, keep the standard term and add a short Korean definition.
+
+## Objective
+
+Maintain one canonical vocabulary so briefs, specs, UI docs, plans, packets, and baseline sync entries use the same terms for the same concepts.
+
+The default output style is:
+
+- tables first for fast scanning
+- detailed subsections only for genuinely complex concepts
+- diagrams only when relationships or state vocabularies are hard to understand in prose
+
+## Create Or Update Rules
+
+- If `./docs/specs/baseline/01_glossary.md` does not exist, create it from currently approved specs and relevant active plans.
+- If it exists, update it instead of replacing it blindly.
+- Preserve stable canonical terms unless there is a strong reason to change them.
+- If a newly found term conflicts with an existing definition, keep the current canonical term and record the conflict in `정의 충돌 / 검토 필요`.
+- Normalize synonyms toward one preferred term.
+- Prefer Korean for user-facing/domain wording, but keep standard English when clearer, more stable, or already established in the project.
+
+## Recommended Inputs
+
+Read relevant files that exist:
+
+- `./docs/specs/baseline/00_brief.md`
+- `./docs/specs/baseline/05_technical-context.md`
+- `./docs/specs/baseline/10_product-spec.md`
+- `./docs/specs/baseline/20_ui-spec.md`
+- active `./.codex/plans/*.md` when terminology from a current change needs to become canonical
+- `./docs/specs/initial-build/<topic>/30_work-packets/*.md` when reviewing initial build terminology
+- existing `./docs/specs/baseline/01_glossary.md`
+
+Use only files that are present and relevant.
+
+## Workflow
+
+1. Identify repeated nouns, states, and labels across available docs.
+2. Separate true domain concepts from incidental wording.
+3. Choose one canonical project term per concept.
+4. Attach English code-facing counterpart when needed.
+5. Capture harmless synonyms only when useful.
+6. List discouraged or banned wording when ambiguity is likely.
+7. Write most glossary content as tables.
+8. Move only hard cases into detailed sections.
+9. Update the glossary without deleting still-valid prior decisions.
+
+Use these references while drafting:
+
+- [references/template.md](references/template.md)
+- [references/checklist.md](references/checklist.md)
+
+## Required Sections
+
+- `핵심 용어`
+- `엔티티 용어`
+- `상태 용어`
+- `UI 용어`
+- `금지하거나 피할 표현`
+- `복잡한 개념 상세 설명`
+- `정의 충돌 / 검토 필요`
+
+## Quality Bar
+
+The glossary is not ready if:
+
+- simple vocabulary that should be in tables is expanded into unnecessary prose
+- the same concept still appears under multiple primary names
+- terms are listed without definitions
+- code-facing English names and canonical project terms conflict without explanation
+- banned or confusing wording is omitted despite clear ambiguity
+- existing approved terminology is overwritten without explanation

package/data/skills/task-skills/spec-shared-glossary-sync/agents/openai.yaml

@@ -0,0 +1,6 @@
+interface:
+  display_name: "spec-shared-glossary-sync"
+  short_description: "Standardize Korean spec terms into a shared baseline glossary."
+  default_prompt: "Use $spec-shared-glossary-sync to create or update a Korean 01_glossary.md that standardizes terms across baseline docs and active .codex/plans."
+policy:
+  allow_implicit_invocation: false

package/data/skills/task-skills/spec-shared-glossary-sync/references/checklist.md

@@ -0,0 +1,36 @@
+# Glossary Sync Checklist
+
+Use this checklist before finalizing `01_glossary.md`.
+
+## Look For
+
+- one concept described with multiple Korean names
+- one Korean term mapped to multiple English code names
+- UI copy that conflicts with domain terms
+- product docs and change docs using different names for the same thing
+- states that appear in packets but were never defined centrally
+
+## Prefer
+
+- a table-first structure for most vocabulary
+- one canonical project term per concept
+- prefer Korean for user-facing/domain nouns, but keep standard English when that is clearer or already the stable norm
+- one code-facing English name per canonical concept when possible
+- short definitions that explain scope, not implementation
+- explicit “do not use” wording for risky ambiguities
+- detailed prose only for genuinely complex concepts
+
+## 대표 예시
+
+- 플랜 / 루틴 / 프로그램
+- 운동 세션 / 운동 기록 / workout
+- 세트 템플릿 / 세트 기록
+- 저장 / 완료 / 확정
+- 초안 / 진행 중 / 임시 저장
+
+## Update Rule
+
+- merge new terms into the existing glossary
+- do not delete stable terms unless they are clearly wrong
+- when uncertain, add the conflict to `정의 충돌 / 검토 필요`
+- keep simple terms in tables; avoid turning the whole glossary into long prose