oh-my-customcode 0.44.6 → 0.45.1

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "oh-my-customcode",
   "workspaces": ["packages/*"],
-  "version": "0.44.6",
+  "version": "0.45.1",
   "description": "Batteries-included agent harness for Claude Code",
   "type": "module",
   "bin": {
@@ -43,6 +43,7 @@
   },
   "dependencies": {
     "@clack/prompts": "^1.1.0",
+    "@inquirer/prompts": "^8.3.2",
     "commander": "^14.0.2",
     "i18next": "^25.8.0",
     "yaml": "^2.8.2"

package/templates/.claude/skills/ambiguity-gate/SKILL.md

@@ -0,0 +1,94 @@
+---
+name: ambiguity-gate
+description: Pre-routing ambiguity analysis — scores request clarity and asks clarifying questions when needed (inspired by ouroboros)
+scope: core
+user-invocable: true
+argument-hint: "[request to analyze for ambiguity]"
+---
+
+# Ambiguity Gate
+
+## Purpose
+
+Analyze a user request for ambiguity before routing to implementation. Inspired by the [ouroboros](https://github.com/Q00/ouroboros) Socratic interviewer pattern, this skill measures request clarity on a 0.0–1.0 scale and asks targeted clarifying questions when needed.
+
+## Ambiguity Scoring
+
+| Score Range | Verdict | Action |
+|-------------|---------|--------|
+| ≤ 0.2 | Clear | Proceed with implementation |
+| 0.2–0.5 | Moderate | Suggest clarifications but allow proceeding |
+| > 0.5 | High | Require clarification before proceeding |
+
+## Scoring Factors
+
+| Factor | Weight | Description |
+|--------|--------|-------------|
+| Scope clarity | 30% | Is the scope of work well-defined? |
+| Technical specificity | 25% | Are technical requirements clear? |
+| Acceptance criteria | 20% | Can we determine when the task is done? |
+| Constraint clarity | 15% | Are constraints and limitations specified? |
+| Context sufficiency | 10% | Is there enough context to proceed? |
+
+**Composite score** = weighted sum of individual factor scores (each 0.0–1.0, inverted: 0.0 = clear, 1.0 = ambiguous).
+
+## Output Format
+
+```
+[Ambiguity Analysis]
+├── Score: {0.0-1.0}
+├── Verdict: {Clear | Moderate | High}
+├── Breakdown:
+│   ├── Scope: {score} — {reason}
+│   ├── Technical: {score} — {reason}
+│   ├── Acceptance: {score} — {reason}
+│   ├── Constraints: {score} — {reason}
+│   └── Context: {score} — {reason}
+└── Suggestions: {clarifying questions if score > 0.2}
+```
+
+## Workflow
+
+1. Receive the request to analyze (from `$ARGUMENTS` or conversation context)
+2. Score each factor independently
+3. Compute weighted composite score
+4. Determine verdict based on threshold
+5. If score > 0.2: generate targeted clarifying questions (max 3, prioritized by highest-weight ambiguous factors)
+6. If score > 0.5: do NOT proceed to implementation; present analysis and wait for clarification
+7. If score ≤ 0.2: output analysis and proceed
+
+## Clarifying Question Guidelines
+
+- Ask **one question per ambiguous factor** (max 3 total)
+- Order by factor weight (scope → technical → acceptance criteria)
+- Make questions specific and answerable
+- Avoid yes/no questions; prefer open-ended with examples
+
+**Example questions:**
+- Scope: "Should this change affect all environments or only development?"
+- Technical: "What language/framework should this be implemented in?"
+- Acceptance: "What would a passing test look like for this feature?"
+- Constraints: "Are there performance or memory constraints to consider?"
+- Context: "Is this a new feature or modifying existing behavior?"
+
+## Integration
+
+This skill can be:
+- **Invoked manually**: `/ambiguity-gate [request]` — analyze a specific request
+- **Integrated into routing skills**: Insert as a pre-check step before agent delegation when request complexity warrants it
+
+Routing skill integration example:
+```
+1. Run ambiguity-gate on user request
+2. If score > 0.5: surface questions, wait for response, re-run gate
+3. If score ≤ 0.5: proceed with normal routing
+```
+
+## When NOT to Use
+
+Skip this skill for:
+- Simple, one-line questions ("What does X do?")
+- One-line fixes with clear scope ("Fix the typo in line 42")
+- Well-defined bug reports with reproduction steps and expected behavior
+- Requests with explicit acceptance criteria already stated
+- Follow-up requests that clarify a previous ambiguous request

package/templates/.claude/skills/omcustom-feedback/SKILL.md

@@ -0,0 +1,137 @@
+---
+name: omcustom-feedback
+description: Submit feedback about oh-my-customcode as a GitHub issue
+scope: harness
+user-invocable: true
+disable-model-invocation: true
+argument-hint: "[description or leave empty for interactive]"
+---
+
+# Feedback Submitter
+
+Submit feedback about oh-my-customcode (bugs, features, improvements, questions) directly as a GitHub issue from the CLI session.
+
+## Purpose
+
+Lowers the barrier for submitting feedback by allowing users to create GitHub issues without leaving their terminal session. All feedback is filed to the `baekenough/oh-my-customcode` repository.
+
+## Usage
+
+```
+# Inline feedback
+/omcustom:feedback HUD display is missing during parallel agent spawn
+
+# Interactive (no arguments)
+/omcustom:feedback
+```
+
+## Workflow
+
+### Phase 1: Input Parsing
+
+If arguments are provided:
+1. Analyze the content to auto-detect category (`bug`, `feature`, `improvement`, `question`)
+2. Use the content as the issue title (truncate to 80 chars if needed)
+3. Use the full content as the description body
+
+If no arguments:
+1. Ask the user for category using AskUserQuestion: `[bug / feature / improvement / question]`
+2. Ask for title and optional detailed description (combine into a single prompt when possible)
+
+### Phase 2: Preflight Check
+
+```bash
+# Verify gh CLI is installed
+command -v gh >/dev/null 2>&1 || { echo "Error: gh CLI not installed. Install from https://cli.github.com/"; exit 1; }
+
+# Verify authentication
+gh auth status 2>&1 | grep -q "Logged in" || { echo "Error: Not authenticated. Run 'gh auth login' first."; exit 1; }
+```
+
+### Phase 3: Environment Collection
+
+Collect environment info via Bash:
+
+```bash
+# omcustom version
+OMCUSTOM_VERSION=$(node -e "console.log(require('./package.json').version)" 2>/dev/null || echo "unknown")
+
+# Claude Code version
+CLAUDE_VERSION=$(claude --version 2>/dev/null || echo "unknown")
+
+# OS
+OS_INFO=$(uname -s 2>/dev/null || echo "unknown")
+
+# Project name
+PROJECT_NAME=$(basename "$(pwd)")
+```
+
+### Phase 4: Confirmation and Create
+
+1. Show the user a preview of the issue to be created:
+   ```
+   [Preview]
+   ├── Title: {title}
+   ├── Category: {category}
+   ├── Labels: feedback, {category-label}
+   └── Repo: baekenough/oh-my-customcode
+   ```
+2. Ask for confirmation before creating
+
+3. Ensure labels exist (defensive):
+   ```bash
+   gh label create feedback --description "User feedback via /omcustom:feedback" --color 0E8A16 --repo baekenough/oh-my-customcode 2>/dev/null || true
+   ```
+
+4. Create the issue using `--body-file` for safe markdown handling:
+   ```bash
+   # Write body to temp file to avoid shell escaping issues
+   cat > /tmp/omcustom-feedback-body.md << 'FEEDBACK_EOF'
+   ## Feedback
+
+   **Category**: {category}
+   **Source**: omcustom CLI v{version}
+
+   ### Description
+   {user description}
+
+   ### Environment
+   - omcustom version: {omcustom_version}
+   - Claude Code version: {claude_version}
+   - OS: {os_info}
+   - Project: {project_name}
+
+   ---
+   *Submitted via `/omcustom:feedback`*
+   FEEDBACK_EOF
+
+   # Create issue
+   gh issue create \
+     --repo baekenough/oh-my-customcode \
+     --title "{title}" \
+     --label "feedback,{category_label}" \
+     --body-file /tmp/omcustom-feedback-body.md
+
+   # Clean up
+   rm -f /tmp/omcustom-feedback-body.md
+   ```
+
+5. If label creation fails AND issue creation fails due to labels, retry without labels as fallback
+
+6. Return the issue URL to the user
+
+### Category-to-Label Mapping
+
+| Category | GitHub Label |
+|----------|-------------|
+| bug | bug |
+| feature | enhancement |
+| improvement | enhancement |
+| question | question |
+
+## Notes
+
+- Target repo is hardcoded to `baekenough/oh-my-customcode` — feedback is always about omcustom itself
+- Requires `gh` CLI with authentication
+- Uses `--body-file` instead of `--body` to safely handle markdown with special characters
+- `disable-model-invocation: true` ensures this skill only runs when explicitly invoked by the user

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

@@ -0,0 +1,24 @@
+---
+name: sdd
+description: Alias for sdd-dev — Spec-Driven Development workflow
+scope: core
+version: 1.0.0
+user-invocable: true
+argument-hint: "[task description or leave empty for guided workflow]"
+---
+
+# SDD Skill (Alias)
+
+This is an alias for the `sdd-dev` skill.
+
+**Redirects to**: `.claude/skills/sdd-dev/SKILL.md`
+
+See [sdd-dev](../sdd-dev/SKILL.md) for full documentation.
+
+## Usage
+
+```
+/sdd [task description]
+```
+
+Equivalent to `/sdd-dev [task description]`.

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

@@ -0,0 +1,257 @@
+---
+name: sdd-dev
+description: Spec-Driven Development workflow — enforces sdd/ folder hierarchy with planning-first gates, current-state artifacts, and completion verification
+scope: core
+version: 1.0.0
+user-invocable: true
+argument-hint: "[task description or leave empty for guided workflow]"
+---
+
+# SDD (Spec-Driven Development) Skill
+
+Spec-Driven Development workflow that enforces the `sdd/` folder hierarchy. All development work proceeds through planning-first gates and produces current-state artifacts as completion evidence.
+
+## Trigger Keywords
+
+Invoke this skill when user requests:
+- 개발해, 작업해, 구현해, 수정해, 고쳐, 리팩토링해, 테스트해, 배포해
+- 화면명세서, 화면설계서, UI, 디자인, screen spec, screen design
+- develop, implement, fix, refactor, build, deploy
+
+## sdd/ Folder Hierarchy
+
+```
+sdd/
+├── 01_planning/     # Requirements, constraints, stakeholder input
+├── 02_plan/         # Execution plan, acceptance criteria, approach
+├── 03_build/        # Current build state, implementation notes
+├── 04_verify/       # Verification evidence, test results, residual risks
+├── 05_operate/      # Deployment notes, runbooks (conditional)
+└── 99_toolchain/    # Tool configs, scripts, environment setup
+```
+
+**Key Principle**: These folders are **current-state artifacts**, not history archives. Each file reflects the current state of the work — update in place rather than appending new versions.
+
+## Workflow
+
+### Step 0: Activation Check
+
+Verify `sdd/` folder exists in the project root:
+
+```bash
+ls sdd/ 2>/dev/null || echo "sdd/ folder not found"
+```
+
+If `sdd/` does not exist:
+1. Inform the user that SDD workflow requires a `sdd/` folder
+2. Offer to create the folder structure: `mkdir -p sdd/{01_planning,02_plan,03_build,04_verify,05_operate,99_toolchain}`
+3. Ask user to confirm before proceeding
+
+If `sdd/` exists, continue to Step 1.
+
+### Step 1: Planning Review (Gate)
+
+**MUST complete before any coding begins.**
+
+Read all relevant planning documents:
+
+```
+[SDD] Reading planning documents...
+├── sdd/01_planning/ — requirements, constraints
+└── sdd/99_toolchain/ — tool configs, environment
+```
+
+Actions:
+1. Read `sdd/01_planning/` contents (all .md files)
+2. Read `sdd/99_toolchain/` if present
+3. Identify: What is the task? What constraints exist? What is in scope?
+4. If planning docs are empty or missing, prompt user to fill them before proceeding
+
+**Gate**: If planning docs are absent or insufficient, pause and ask user to provide requirements. Do NOT proceed to plan phase without understanding the context.
+
+### Step 2: Plan Phase
+
+Create or update `sdd/02_plan/` with the execution plan.
+
+Artifact to produce: `sdd/02_plan/current.md`
+
+```markdown
+# Execution Plan
+
+## Task
+{task description}
+
+## Approach
+{implementation strategy}
+
+## Acceptance Criteria
+- [ ] {criterion 1}
+- [ ] {criterion 2}
+- [ ] {criterion N}
+
+## Out of Scope
+- {what will NOT be done}
+
+## Dependencies
+- {prerequisite or dependency}
+```
+
+**Display**:
+```
+[SDD Plan] Created sdd/02_plan/current.md
+├── Approach: {one-line summary}
+├── Criteria: {N} acceptance criteria defined
+└── Gate: Plan ready — proceeding to build
+```
+
+### Step 3: Build Phase
+
+Implement the changes. Update `sdd/03_build/` with current build state.
+
+Artifact to produce or update: `sdd/03_build/current.md`
+
+```markdown
+# Build State
+
+## Status
+{In Progress | Complete}
+
+## Implemented
+- {file or component}: {what was done}
+
+## Decisions Made
+- {decision}: {rationale}
+
+## Known Issues
+- {issue}: {planned resolution}
+```
+
+During implementation:
+- Follow the plan from Step 2
+- Update `sdd/03_build/current.md` as work progresses
+- Keep the artifact current (not a log — overwrite stale entries)
+
+**Display**:
+```
+[SDD Build] Implementing changes...
+[SDD Build] Updated sdd/03_build/current.md
+└── Status: {In Progress | Complete}
+```
+
+### Step 4: Verify Phase
+
+Run verification and update `sdd/04_verify/` with evidence.
+
+Artifact to produce or update: `sdd/04_verify/current.md`
+
+```markdown
+# Verification Evidence
+
+## Acceptance Criteria Results
+- [x] {criterion 1}: {evidence}
+- [x] {criterion 2}: {evidence}
+- [ ] {criterion N}: {reason if not passing}
+
+## Tests Run
+- {test command or suite}: {result}
+
+## Residual Risks
+- {risk}: {severity} — {mitigation plan}
+
+## Verdict
+{Pass | Fail | Conditional Pass}
+```
+
+Actions:
+1. Check each acceptance criterion from `sdd/02_plan/current.md`
+2. Run applicable tests or verification commands
+3. Document evidence (do NOT just say "tests pass" — include actual output or reference)
+4. List residual risks honestly
+
+**Gate**: If verdict is Fail, return to Step 3 (Build). Do NOT declare done with a Fail verdict.
+
+**Display**:
+```
+[SDD Verify] Running verification...
+[SDD Verify] Updated sdd/04_verify/current.md
+├── Criteria: {N}/{total} passing
+├── Residual risks: {count}
+└── Verdict: {Pass | Fail | Conditional Pass}
+```
+
+### Step 5: Operate Phase (Conditional)
+
+Only execute if deployment is in scope for this task.
+
+Artifact to produce or update: `sdd/05_operate/current.md`
+
+```markdown
+# Operate State
+
+## Deployment
+- Environment: {target}
+- Method: {how deployed}
+- Timestamp: {when}
+
+## Runbook
+{steps to operate, restart, rollback}
+
+## Monitoring
+{what to watch, alerts, logs}
+```
+
+Skip this step if:
+- Task is code-only (no deployment)
+- User did not request deployment
+- Deployment is handled by CI/CD automatically
+
+### Step 6: Completion Gate
+
+Before declaring `[Done]`, verify:
+
+```
+[SDD Done?] Checking completion gates...
+├── sdd/02_plan/current.md — exists? {Y/N}
+├── sdd/03_build/current.md — exists and current? {Y/N}
+├── sdd/04_verify/current.md — exists and verdict Pass? {Y/N}
+└── sdd/05_operate/current.md — exists (if deploy in scope)? {Y/N}
+```
+
+If any gate fails, complete the missing artifact before declaring done.
+
+Final display:
+```
+[SDD Done] Task complete
+├── Plan: sdd/02_plan/current.md
+├── Build: sdd/03_build/current.md
+├── Verify: sdd/04_verify/current.md (Verdict: Pass)
+└── Artifacts are current-state — ready for next iteration
+```
+
+## Artifact Maintenance Rules
+
+1. **Overwrite, don't append**: Update files in place. These are current-state docs, not logs.
+2. **One file per folder**: `current.md` is the canonical artifact. Supplementary files are allowed but the main doc is always `current.md`.
+3. **Checkboxes reflect reality**: Do NOT pre-check criteria. Update checkboxes as work is verified.
+4. **Residual risks are honest**: List known risks even after passing. Hiding risks defeats the purpose.
+
+## Integration with Other Skills
+
+| Skill | When to Use Together |
+|-------|---------------------|
+| `/deep-plan` | Before `/sdd-dev` when requirements are ambiguous — use deep-plan to research, then sdd-dev to execute |
+| `/structured-dev-cycle` | Alternative workflow without sdd/ folder — use sdd-dev when project uses sdd/ hierarchy |
+| `/dev-review` | After Step 4 — use dev-review for additional code quality check |
+| `/adversarial-review` | After Step 4 — use adversarial-review for security-sensitive changes |
+
+## Example Usage
+
+```
+/sdd-dev add user authentication to the API
+/sdd-dev implement pagination for the product list screen
+/sdd-dev 화면명세서 기반으로 대시보드 UI 구현
+/sdd-dev refactor the payment module
+/sdd-dev  # (no argument — guided workflow)
+```
+
+When no argument is provided, ask: "어떤 작업을 진행할까요? sdd/01_planning/ 의 요구사항을 기반으로 계획을 수립합니다."

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

@@ -0,0 +1,24 @@
+---
+name: sdd-development
+description: Alias for sdd-dev — Spec-Driven Development workflow
+scope: core
+version: 1.0.0
+user-invocable: true
+argument-hint: "[task description or leave empty for guided workflow]"
+---
+
+# SDD Development Skill (Alias)
+
+This is an alias for the `sdd-dev` skill.
+
+**Redirects to**: `.claude/skills/sdd-dev/SKILL.md`
+
+See [sdd-dev](../sdd-dev/SKILL.md) for full documentation.
+
+## Usage
+
+```
+/sdd-development [task description]
+```
+
+Equivalent to `/sdd-dev [task description]`.

package/templates/CLAUDE.md

@@ -103,6 +103,7 @@ oh-my-customcode로 구동됩니다.
 | `/omcustom:fix-refs` | 깨진 참조 수정 |
 | `/omcustom:takeover` | 기존 에이전트/스킬에서 canonical spec 추출 |
 | `/adversarial-review` | 공격자 관점 보안 코드 리뷰 |
+| `/ambiguity-gate` | 요청 모호성 분석 및 명확화 질문 (ouroboros 패턴) |
 | `/dev-review` | 코드 베스트 프랙티스 리뷰 |
 | `/dev-refactor` | 코드 리팩토링 |
 | `/memory-save` | 세션 컨텍스트를 claude-mem에 저장 |
@@ -112,6 +113,7 @@ oh-my-customcode로 구동됩니다.
 | `/omcustom:npm-version` | 시맨틱 버전 관리 |
 | `/omcustom:npm-audit` | 의존성 감사 |
 | `/omcustom:release-notes` | 릴리즈 노트 생성 (git 히스토리 기반) |
+| `/omcustom:feedback` | 사용자 피드백을 GitHub Issue로 등록 |
 | `/codex-exec` | Codex CLI 프롬프트 실행 |
 | `/optimize-analyze` | 번들 및 성능 분석 |
 | `/optimize-bundle` | 번들 크기 최적화 |
@@ -131,11 +133,11 @@ project/
 +-- CLAUDE.md                    # 진입점
 +-- .claude/
 |   +-- agents/                  # 서브에이전트 정의 (44 파일)
-|   +-- skills/                  # 스킬 (76 디렉토리)
+|   +-- skills/                  # 스킬 (78 디렉토리)
 |   +-- rules/                   # 전역 규칙 (R000-R021)
 |   +-- hooks/                   # 훅 스크립트 (보안, 검증, HUD)
 |   +-- contexts/                # 컨텍스트 파일 (ecomode)
-+-- guides/                      # 레퍼런스 문서 (26 토픽)
++-- guides/                      # 레퍼런스 문서 (27 토픽)
 ```
 
 ## 오케스트레이션