ai-ops-cli 0.2.4 → 1.0.1

package/data/skills/task-skills/doc-impact-reviewer/SKILL.md

@@ -0,0 +1,101 @@
+---
+name: doc-impact-reviewer
+description: 변경 완료 또는 커밋 직전 diff를 보고 갱신해야 할 운영 문서 후보를 판정하고, 사용자 승인 후 승인된 문서만 수정한다.
+disable-model-invocation: true
+---
+
+# doc-impact-reviewer
+
+이 skill은 사용자가 명시적으로 호출했을 때만 사용한다. 자동 git hook, 자동 staging, 자동 commit을 만들거나 실행하지 않는다.
+
+## 목적
+
+구현 변경이 프로젝트 운영 문서에 미치는 영향을 짧고 근거 있게 판정한다.
+
+결과는 다음 세 단계로 나눈다.
+
+- `required`: 변경을 반영하지 않으면 운영 문서가 실제 동작과 어긋난다.
+- `recommended`: 지금 반영하면 재진입, 리뷰, 운영 판단 비용이 줄어든다.
+- `not needed`: 문서 영향이 없거나 기존 문서가 이미 충분하다.
+
+## 입력 확인
+
+먼저 diff 확인을 한다.
+
+1. `git status --short`
+2. `git diff --stat`
+3. `git diff`
+4. `git diff --name-only`
+5. `git diff --cached --stat`
+6. `git diff --cached`
+7. `git diff --cached --name-only`
+8. `git ls-files --others --exclude-standard`
+
+staged 변경과 untracked 파일도 구현 영향에 포함한다.
+
+프로젝트 운영 레이어가 있으면 존재하는 파일만 읽는다.
+
+- `AGENTS.md`
+- `docs/docs-status.md`
+- `.ai-ops/manifest.json`
+- `.ai-ops/context-layer.json`
+- `docs/agent/rules/doc-update-rules.md`
+- `docs/agent/checks/impact-checklist.md`
+- `docs/agent/checks/review-checklist.md`
+
+필요하면 변경 파일과 가까운 README, runbook, spec, API 문서도 읽되, 전체 문서를 기계적으로 훑지 않는다.
+
+## 분류 기준
+
+변경 파일과 diff를 다음 관점으로 분류한다.
+
+- CLI/API surface: command, option, endpoint, request/response, public SDK contract
+- manifest/schema: `.ai-ops/*`, registry, JSON schema, migration, generated index
+- pack/specs: `docs/specs/`, optional pack, baseline/spec lifecycle
+- skill/subagent catalog: skill source, subagent prompt, tool metadata, registry
+- business/domain rule: 권한, 정책, 상태 전이, 요금, onboarding, domain validation
+- verification/runtime docs: 배포, smoke, dry-run, OAuth/local setup, troubleshooting
+- user-facing workflow: 설치, 사용 예시, operator flow, manual QA
+
+## 보고 형식
+
+문서 편집 전에는 문서 후보 제안을 먼저 보고하고 사용자 컨펌 전 편집 금지를 지킨다.
+
+보고에는 다음을 포함한다.
+
+- `required / recommended / not needed`별 갱신 후보 문서
+- 각 후보의 근거가 되는 변경 파일 또는 diff 요약
+- 갱신하지 않을 때의 리스크
+- 읽었지만 영향 없음으로 판단한 문서
+- 추가 확인이 필요한 질문이 있으면 최대 3개
+
+보고는 짧게 작성한다. 문서 본문을 길게 재작성하지 말고, 승인 전에는 편집하지 않는다.
+
+## 편집 규칙
+
+사용자가 승인한 문서만 수정한다.
+
+- 승인 범위 밖의 문서는 수정하지 않는다.
+- 직접 commit하지 않는다.
+- 직접 staging하지 않는다.
+- 자동 hook, 자동 commit, 자동 staging 설정을 추가하지 않는다.
+- 이미 있는 사용자 변경을 되돌리지 않는다.
+- 변경 이유가 문서에 남아야 하는 경우에는 짧은 근거 문장만 추가한다.
+
+## 보호 규칙
+
+- Reserved 승격 금지: `Reserved` 문서는 명시 승인 없이 현재 사실 문서처럼 승격하거나 근거로 인용하지 않는다.
+- create-only 문서 보호: 프로젝트 운영자가 채워야 하는 create-only 문서는 자동 덮어쓰지 않는다.
+- adapter 보호: `GEMINI.md`, `CLAUDE.md`에는 canonical 운영 규칙을 복제하지 않는다. 필요한 경우 `AGENTS.md` 또는 해당 canonical 문서 갱신을 제안한다.
+- stale 문서 보호: 구현 diff보다 오래된 문서는 사실로 단정하지 말고 후보 근거로만 다룬다.
+
+## 완료 응답
+
+승인 후 문서를 수정했다면 마지막에 다음을 요약한다.
+
+- 수정한 문서
+- 수정하지 않은 후보와 이유
+- 남은 리스크 또는 후속 확인
+- 실행한 검증 또는 생략한 검증
+
+직접 커밋 금지와 직접 staging 금지를 마지막까지 유지한다.

package/data/skills/task-skills/doc-impact-reviewer/agents/openai.yaml

@@ -0,0 +1,6 @@
+interface:
+  display_name: 'doc-impact-reviewer'
+  short_description: '변경 완료 또는 커밋 직전 운영 문서 영향도를 검토합니다.'
+  default_prompt: '$doc-impact-reviewer를 사용해 현재 git status와 diff를 확인하고, 갱신이 필요한 운영 문서를 required/recommended/not-needed로 분류한 뒤, 리스크를 보고하고 사용자 승인 전에는 문서를 수정하지 마세요.'
+policy:
+  allow_implicit_invocation: false

package/data/skills/task-skills/spec-baseline-sync/SKILL.md

@@ -0,0 +1,134 @@
+---
+name: spec-baseline-sync
+description: Update the current project's docs/specs/baseline documents from an implemented and verified .codex/plans change, then archive the completed plan and append a compact .codex/CHANGE_LOG.md entry.
+disable-model-invocation: true
+---
+
+# spec-baseline-sync
+
+Use this skill after a post-MVP change has been implemented and verified, and the team wants `./docs/specs/baseline/` to match the current product again.
+
+## Output Location
+
+- Update only affected files under `./docs/specs/baseline/`.
+- Move the completed plan from `./.codex/plans/<plan>.md` to `./.codex/plans/archived/YYYY-MM/<plan>.md`.
+- Append a compact entry to `./.codex/CHANGE_LOG.md`.
+
+If the change does not affect baseline truth, still archive the completed plan and write a changelog entry that says no baseline document update was required.
+
+## Language Rules
+
+- Write updated baseline docs in Korean unless the target file has a fixed English rule.
+- Write changelog entries in Korean.
+- 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
+
+Read the relevant available inputs before updating baseline:
+
+1. active plan under `./.codex/plans/*.md`
+2. implemented code changes, PR diff, commit diff, or implementation notes
+3. verification results and known skipped tests
+4. optional issue or PR link
+5. existing `./docs/specs/baseline/01_glossary.md`
+6. existing `./docs/specs/baseline/05_technical-context.md`
+7. existing `./docs/specs/baseline/10_product-spec.md`
+8. existing `./docs/specs/baseline/20_ui-spec.md`
+9. existing `./docs/specs/baseline/22_stitch-assets/DESIGN.md`
+10. existing `./docs/specs/baseline/24_design-tokens.md`
+
+Use only the files that exist and are relevant. Do not require every optional document mechanically.
+
+## Objective
+
+Turn a completed implementation into updated baseline truth without:
+
+- rewriting unaffected baseline documents
+- promoting planned but unimplemented ideas
+- hiding implementation-vs-plan mismatches
+- leaving completed plans mixed with active plans
+- losing the short reason why the change happened
+
+## Source-Of-Truth Rule
+
+Baseline sync is implementation-confirming work.
+
+- Treat implemented and verified product behavior as the primary source of truth.
+- Treat `.codex/plans/*.md` as the intended-change and decision record.
+- Treat existing baseline docs as the canonical starting point to update carefully.
+- If implementation and plan disagree, update baseline to match implementation and record the mismatch in the changelog entry.
+- Do not promote reverted, deferred, or unimplemented plan ideas into baseline.
+
+## Workflow
+
+1. Identify the plan being closed and the implementation evidence.
+2. Compare shipped behavior against current baseline docs.
+3. Decide which baseline docs are affected among `01,05,10,20,22,24`.
+4. Update only affected baseline docs while preserving still-valid prior decisions.
+5. Append one changelog entry summarizing what changed, why, evidence, baseline impact, and follow-up.
+6. Move the plan into `.codex/plans/archived/YYYY-MM/`.
+7. In the final response, summarize updated baseline files, archive path, changelog entry, and tests reviewed.
+
+Use [references/template.md](references/template.md) for the changelog entry shape.
+
+## Baseline Update Rules
+
+- `./docs/specs/baseline/01_glossary.md`: update only when the implementation introduced or normalized meaningful shared terms.
+- `./docs/specs/baseline/05_technical-context.md`: update only when architecture, stack, boundaries, integrations, or deployment assumptions changed materially.
+- `./docs/specs/baseline/10_product-spec.md`: update for implemented user-flow, feature, entity, rule, edge-case, or success-criteria changes.
+- `./docs/specs/baseline/20_ui-spec.md`: update for implemented screens, states, interactions, or UI constraints.
+- `./docs/specs/baseline/22_stitch-assets/DESIGN.md` and `./docs/specs/baseline/24_design-tokens.md`: update only when the implementation established reusable visual rules.
+- `./docs/specs/baseline/00_brief.md` is normally out of scope. Touch it only if the product premise itself changed and the user explicitly asks.
+
+Do not rewrite an entire baseline doc when a targeted update is enough.
+
+## Plan Archive Rules
+
+- Archive only completed or explicitly closed plans.
+- Preserve the original filename.
+- Use the archive month from the completion date, not the plan creation date, unless the user explicitly asks otherwise.
+- Create `.codex/plans/archived/YYYY-MM/` if missing.
+- Do not archive unrelated active plans.
+
+## Changelog Rules
+
+Append to `.codex/CHANGE_LOG.md`. Create the file if missing.
+
+Each entry should include:
+
+- date
+- plan path before archive
+- archived path
+- issue/PR link when available
+- what changed
+- why it changed
+- baseline docs updated, or `none`
+- verification summary
+- follow-up or `없음`
+
+Keep the entry compact. The changelog is an audit trail, not a second plan.
+
+## UI Reference Rule
+
+Post-MVP UI changes usually come from screenshots, reference apps, and detailed adjustment requests in `.codex/plans`. Interpret those references through the current design system and implemented result.
+
+Do not create new Stitch artifacts during baseline sync. If initial-build visual reference files already exist, update canonical visual guidance only when the implemented product established reusable design rules.
+
+## Security Lens
+
+Keep this pass short and implementation-confirming.
+
+- Check whether baseline docs now need updated wording for auth, permission, tenant boundaries, admin-only surfaces, sensitive data, uploads, external callbacks, rendered content, raw queries, or destructive actions.
+- Record any security-relevant change in the changelog entry.
+- If implementation introduced or clarified a risky seam, recommend `spec-security-01-triage` or implementation-stage review as appropriate.
+
+## Quality Bar
+
+The sync is not ready if:
+
+- baseline was updated from intent alone without checking implementation
+- unaffected baseline docs were rewritten broadly
+- unimplemented or deferred plan ideas were promoted
+- the changelog omits what changed and why
+- a completed plan remains in active `.codex/plans/`

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

@@ -0,0 +1,6 @@
+interface:
+  display_name: "spec-baseline-sync"
+  short_description: "Sync implemented changes into baseline docs, archive the plan, and update the changelog."
+  default_prompt: "Use $spec-baseline-sync to update affected docs/specs/baseline documents from an implemented .codex/plans change, archive the completed plan, and append a compact .codex/CHANGE_LOG.md entry."
+policy:
+  allow_implicit_invocation: false

package/data/skills/task-skills/spec-baseline-sync/references/template.md

@@ -0,0 +1,14 @@
+# CHANGE_LOG Entry Template
+
+```md
+## YYYY-MM-DD - 변경 제목
+
+- Plan: `.codex/plans/<plan>.md`
+- Archived: `.codex/plans/archived/YYYY-MM/<plan>.md`
+- Issue / PR: 링크 또는 `없음`
+- 변경 내용: 무엇이 바뀌었는지 한두 줄
+- 변경 이유: 왜 바뀌었는지 한두 줄
+- Baseline: 갱신한 문서 목록 또는 `none`
+- 검증: 실행한 테스트 / 확인한 결과 / 생략한 검증
+- 후속 조치: 남은 작업 또는 `없음`
+```

package/data/skills/task-skills/spec-product-01-idea-to-brief/SKILL.md

@@ -0,0 +1,78 @@
+---
+name: spec-product-01-idea-to-brief
+description: Turn a rough new product idea into a Korean 00_brief.md inside the current project's docs/specs/baseline directory, fixing problem, user, value, goals, non-goals, MVP scope, and risks before downstream planning begins.
+disable-model-invocation: true
+---
+
+# spec-product-01-idea-to-brief
+
+Use this skill when the input is still rough and the next artifact should be `./docs/specs/baseline/00_brief.md` for a new product or major new module.
+
+## Output Location
+
+- Write into the current workspace, not the skill folder.
+- Default output path: `./docs/specs/baseline/00_brief.md`
+
+## Language Rules
+
+- Write the document in Korean.
+- Keep product names, code-facing names, API field names, library/service names, file paths, and widely used technical terms in their natural English form when that is clearer and more standard.
+- Do not force awkward phonetic transliterations such as `소스 오브 트루스`, `타겟 플랫폼`, or `워크 패킷`.
+- If an English technical term needs explanation, keep the English term and add a short Korean gloss on first mention, for example `source of truth(가장 신뢰하는 기준)`.
+
+## Glossary Rule
+
+- Check `./docs/specs/baseline/01_glossary.md` only if it exists and the brief introduces product terms, user-facing labels, or domain nouns that may collide with existing terminology.
+- After writing the target document, `spec-shared-glossary-sync` is recommended because briefs often introduce new canonical terms.
+
+## Objective
+
+Freeze direction and scope early enough that later stages do not expand the product by accident.
+
+## Security Lens
+
+Run a short security pass without turning the brief into a security review.
+
+- Check whether the idea touches auth, permissions, tenant boundaries, or admin-only behavior.
+- Check whether it introduces sensitive data, billing, deletion, uploads, or external callbacks.
+- Record the result under `보안 고려사항`.
+- If any trigger is present or the risk is unclear, recommend `spec-security-01-triage` in `mode=spec`.
+
+## Workflow
+
+1. Compress the idea into one clear problem statement.
+2. Identify the target user as specifically as possible.
+3. State the value proposition in one short paragraph.
+4. Reduce goals to the smallest set that defines MVP success.
+5. Write non-goals aggressively to protect scope.
+6. Capture assumptions and risks that could invalidate the brief.
+
+Use [references/template.md](references/template.md) when drafting the file.
+
+## Required Sections
+
+- `문제`
+- `대상 사용자`
+- `가치 제안`
+- `목표`
+- `비목표`
+- `MVP 범위`
+- `리스크 / 가정`
+- `보안 고려사항`
+- `승인 체크포인트`
+
+## Mermaid Rule
+
+Include a Mermaid diagram only when it materially improves comprehension.
+
+- Use a simple flowchart when the brief has 3 or more distinct user flows or actor handoffs.
+- Skip Mermaid if the brief is already obvious from short prose.
+
+## Quality Bar
+
+The brief is not ready if:
+
+- the target user is broad enough to imply multiple products
+- goals imply several systems at once
+- non-goals are weak or missing
+- the MVP scope still contains epic-sized areas without limits

package/data/skills/task-skills/spec-product-01-idea-to-brief/agents/openai.yaml

@@ -0,0 +1,6 @@
+interface:
+  display_name: "spec-product-01-idea-to-brief"
+  short_description: "Turn a product idea into a Korean baseline brief."
+  default_prompt: "Use $spec-product-01-idea-to-brief to turn this product idea into a Korean 00_brief.md under docs/specs/baseline."
+policy:
+  allow_implicit_invocation: false

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

@@ -0,0 +1,36 @@
+# 00_brief.md Template
+
+```md
+# 00 Brief
+
+## 문제
+- 해결하려는 문제를 한 문장으로 정리
+
+## 대상 사용자
+- 가장 중요한 사용자 한 유형
+
+## 가치 제안
+- 왜 이 제품이 의미 있는지
+
+## 목표
+- 목표 1
+- 목표 2
+
+## 비목표
+- 이번 v1에서 하지 않을 것
+
+## MVP 범위
+- 반드시 포함할 최소 범위
+
+## 리스크 / 가정
+- 가정 1
+- 리스크 1
+
+## 보안 고려사항
+- 없으면 `특이사항 없음`
+- 있으면 auth/권한, 민감정보, 업로드, 외부 호출, tenant 경계 같은 트리거와 후속 검토 필요 여부를 짧게 적기
+
+## 승인 체크포인트
+- 방향이 맞는가?
+- 범위가 충분히 작은가?
+```

package/data/skills/task-skills/spec-product-02-brief-to-technical-context/SKILL.md

@@ -0,0 +1,91 @@
+---
+name: spec-product-02-brief-to-technical-context
+description: Convert an approved Korean 00_brief.md into a Korean 05_technical-context.md inside the current project's docs/specs/baseline directory, selecting preferred stacks first and requiring explicit justification for any extra technology outside those defaults.
+disable-model-invocation: true
+---
+
+# spec-product-02-brief-to-technical-context
+
+Use this skill after `./docs/specs/baseline/00_brief.md` is approved and before writing the product spec.
+
+## Output Location
+
+- Write into the current workspace.
+- Default output path: `./docs/specs/baseline/05_technical-context.md`
+
+## Language Rules
+
+- Write the document in Korean.
+- Keep code-facing names, API field names, library/service names, protocol names, file paths, and widely used technical terms in their natural English form when that is clearer and more standard.
+- Do not force awkward phonetic transliterations such as `소스 오브 트루스`, `타겟 플랫폼`, or `워크 패킷`.
+- If an English technical term needs explanation, keep the English term and add a short Korean gloss on first mention, for example `source of truth(가장 신뢰하는 기준)`.
+
+## Glossary Rule
+
+- Check `./docs/specs/baseline/01_glossary.md` only if it exists and the document introduces stack names, architectural terms, or labels that should align with existing terminology.
+- After writing the target document, run `spec-shared-glossary-sync` only if new technical terms, product-facing labels, or collisions were introduced.
+
+## Default Stack Preferences
+
+- Web service:
+  - TypeScript
+  - Next.js
+  - shadcn/ui
+  - Tailwind CSS
+  - date-fns
+  - Supabase
+- App service:
+  - Flutter
+- Backend server:
+  - NestJS
+  - Prisma
+  - Supabase
+  - GraphQL
+- Simple serverless service:
+  - Hono
+  - RESTful API
+
+## Decision Rules
+
+- First, decide within the preferred stack range.
+- Only recommend technology outside the preferred range when the need is concrete.
+- Read the current repository shape when it already exists and record whether each chosen stack surface is already present, partially present, or absent.
+- If the repository is empty or missing the chosen surface, record that downstream packet generation must include explicit bootstrap work rather than assuming scaffolded files already exist.
+- Any extra technology must include:
+  - why the preferred stack is insufficient
+  - what benefit the new technology adds
+  - what complexity or operating cost increases
+  - whether explicit human approval is needed before adopting it
+
+## Security Lens
+
+Keep the security pass short and infrastructure-focused.
+
+- Check whether the chosen stack introduces auth, secret, storage, external callback, upload, or tenant-isolation constraints.
+- Record the result under `보안 고려사항`.
+- If the architecture or deployment assumptions create unclear trust boundaries, recommend `spec-security-01-triage` in `mode=spec`.
+
+Use [references/template.md](references/template.md) when drafting the file.
+
+## Required Sections
+
+- `제품 형태`
+- `기본 선택 스택`
+- `선택 근거`
+- `운영 / 배포 가정`
+- `보안 고려사항`
+- `프로젝트 제약`
+- `현재 저장소 상태 / 스택 갭`
+- `추가 기술 제안 규칙`
+- `미해결 기술 결정사항`
+
+## Mermaid Rule
+
+Include Mermaid only when the stack split or deployment shape is non-trivial.
+
+- Use a simple graph when web, app, backend, workers, or third-party services interact.
+- Skip Mermaid for a single-surface product with an obvious stack.
+
+## Objective
+
+Lock implementation constraints early enough that downstream specs, UI work, packets, and plans all assume the same stack boundaries, while making stack gaps against the current repository explicit enough that bootstrap packets can be generated later without guesswork.

package/data/skills/task-skills/spec-product-02-brief-to-technical-context/agents/openai.yaml

@@ -0,0 +1,6 @@
+interface:
+  display_name: "spec-product-02-brief-to-technical-context"
+  short_description: "Convert an approved brief into a constrained technical context."
+  default_prompt: "Use $spec-product-02-brief-to-technical-context to expand the approved brief into a Korean 05_technical-context.md with justified stack choices."
+policy:
+  allow_implicit_invocation: false

package/data/skills/task-skills/spec-product-02-brief-to-technical-context/references/template.md

@@ -0,0 +1,58 @@
+# 05_technical-context.md Template
+
+```md
+# 05 Technical Context
+
+## 제품 형태
+- web / app / backend / mixed
+
+## 기본 선택 스택
+- web:
+  - TypeScript
+  - Next.js
+  - shadcn/ui
+  - Tailwind CSS
+  - date-fns
+  - Supabase
+- app:
+  - Flutter
+- backend:
+  - NestJS
+  - Prisma
+  - Supabase
+  - GraphQL
+- simple serverless:
+  - Hono
+  - RESTful API
+
+## 선택 근거
+- 왜 이 조합이 현재 제품 범위에 맞는가
+
+## 운영 / 배포 가정
+- 인증
+- 데이터 저장
+- 배포 환경
+- 서버 필요 여부
+
+## 보안 고려사항
+- auth / secret / storage / upload / 외부 callback / tenant 경계 같은 제약
+- 없으면 `특이사항 없음`
+
+## 프로젝트 제약
+- 기존 코드베이스
+- 팀 숙련도
+- 일정 / 운영 부담
+
+## 현재 저장소 상태 / 스택 갭
+- web / app / backend surface별 현재 repo 상태: `present` / `partial` / `absent`
+- 이미 재사용할 수 있는 manifest, config, app/package 디렉터리
+- 부족한 scaffold, dependency install, env/config wiring
+- downstream work packet에서 선행 bootstrap 패킷이 필요한 영역
+
+## 추가 기술 제안 규칙
+- 기본 선호 스택으로 해결 가능한지 먼저 검토
+- 선호 밖 기술은 이유, 이점, 비용, 승인 필요 여부를 함께 기록
+
+## 미해결 기술 결정사항
+- 결정사항 1
+```

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

@@ -0,0 +1,85 @@
+---
+name: spec-product-03-brief-to-product-spec
+description: Expand an approved Korean 00_brief.md and 05_technical-context.md into a Korean 10_product-spec.md in the current project's docs/specs/baseline directory with concrete user flows, features, entities, business rules, edge cases, and success criteria while preserving approved scope and stack constraints.
+disable-model-invocation: true
+---
+
+# spec-product-03-brief-to-product-spec
+
+Use this skill after `./docs/specs/baseline/00_brief.md` and `./docs/specs/baseline/05_technical-context.md` are approved and the next artifact should be `./docs/specs/baseline/10_product-spec.md`.
+
+## Output Location
+
+- Write into the current workspace.
+- Default output path: `./docs/specs/baseline/10_product-spec.md`
+
+## Language Rules
+
+- Write the document in Korean.
+- Keep code-facing names, API field names, library/service names, protocol names, file paths, and widely used technical terms in their natural English form when that is clearer and more standard.
+- Do not force awkward phonetic transliterations such as `소스 오브 트루스`, `타겟 플랫폼`, or `워크 패킷`.
+- If an English technical term needs explanation, keep the English term and add a short Korean gloss on first mention, for example `source of truth(가장 신뢰하는 기준)`.
+
+## Required Inputs
+
+1. `./docs/specs/baseline/00_brief.md`
+2. `./docs/specs/baseline/05_technical-context.md`
+
+## Objective
+
+Convert direction into a tighter operational product spec without reopening already approved scope or ignoring the fixed technical context.
+
+## Workflow
+
+1. Turn goals into 1-3 core user flows.
+2. Derive the minimum feature set needed for those flows.
+3. Define only the entities needed for v1 decisions.
+4. Make business rules explicit, especially permissions and state transitions.
+5. Add edge cases that affect validation, UI states, or data integrity.
+6. Reflect technical constraints only where they meaningfully change the product shape.
+7. Rewrite success criteria so they can be checked later.
+
+## Security Lens
+
+Keep this pass lightweight and product-facing.
+
+- Check whether user flows or business rules introduce auth, permission, ownership, tenant, or destructive-action concerns.
+- Check whether features handle sensitive data, uploads, external callbacks, or rendered rich content.
+- Record the result under `보안 고려사항`.
+- If any of those triggers exist or the boundary is unclear, recommend `spec-security-01-triage` in `mode=spec`.
+
+Use [references/template.md](references/template.md) when drafting the file.
+
+## Glossary Rule
+
+- Check `./docs/specs/baseline/01_glossary.md` if it exists and the product spec introduces or chooses domain terms, entity names, state names, or user-facing labels.
+- After writing the target document, `spec-shared-glossary-sync` is recommended because product specs often add or refine canonical vocabulary.
+
+## Required Sections
+
+- `핵심 사용자 플로우`
+- `기능`
+- `엔티티`
+- `비즈니스 규칙`
+- `엣지 케이스`
+- `성공 기준`
+- `기술 제약 반영 메모`
+- `보안 고려사항`
+- `미해결 결정사항`
+
+## Mermaid Rule
+
+Add Mermaid when the product behavior is easier to understand visually.
+
+- Use flowchart for multi-step user flows.
+- Use stateDiagram for non-trivial state transitions.
+- Skip Mermaid if there is only one short flow and no meaningful state logic.
+
+## Quality Bar
+
+The product spec is not ready if:
+
+- features do not map cleanly to user flows
+- entities exist without behavioral rules
+- success criteria cannot be validated later
+- technical context is contradicted or ignored

package/data/skills/task-skills/spec-product-03-brief-to-product-spec/agents/openai.yaml

@@ -0,0 +1,6 @@
+interface:
+  display_name: "spec-product-03-brief-to-product-spec"
+  short_description: "Expand an approved brief into a concrete Korean product spec."
+  default_prompt: "Use $spec-product-03-brief-to-product-spec to turn the approved brief and technical context into a detailed Korean 10_product-spec.md."
+policy:
+  allow_implicit_invocation: false