oh-my-customcode 0.44.5 → 0.45.0

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 토픽)
 ```
 
 ## 오케스트레이션

package/templates/guides/git-worktree-workflow/README.md

@@ -0,0 +1,134 @@
+# Git Worktree Workflow
+
+## Overview
+
+Git worktrees allow you to check out multiple branches simultaneously in separate directories, each with its own working tree. This eliminates the need to stash changes or commit incomplete work when switching between branches.
+
+**Key benefits:**
+- Work on `develop` and `team-plugin` simultaneously without context switching
+- Keep long-running feature branches open alongside hotfix branches
+- Run tests on one branch while coding on another
+
+## Recommended Directory Structure
+
+```
+~/workspace/projects/
+├── oh-my-customcode/                    # Main worktree (develop)
+├── oh-my-customcode-team-plugin/        # team-plugin branch
+└── oh-my-customcode-release/            # release/* branches
+```
+
+Convention: `{repo-name}-{branch-suffix}` as sibling directories to the main worktree.
+
+## Basic Commands
+
+### Create a worktree
+
+```bash
+# From the main repository directory
+cd ~/workspace/projects/oh-my-customcode
+
+# Attach to an existing remote branch
+git worktree add ../oh-my-customcode-team-plugin team-plugin
+
+# Create a new branch and worktree together
+git worktree add ../oh-my-customcode-release release/v0.43.0
+```
+
+### List worktrees
+
+```bash
+git worktree list
+```
+
+Output:
+```
+/Users/you/workspace/projects/oh-my-customcode                 abc1234 [develop]
+/Users/you/workspace/projects/oh-my-customcode-team-plugin     def5678 [team-plugin]
+/Users/you/workspace/projects/oh-my-customcode-release         ghi9012 [release/v0.43.0]
+```
+
+### Remove a worktree
+
+```bash
+# Remove after branch is merged
+git worktree remove ../oh-my-customcode-release
+
+# Clean up stale worktree references
+git worktree prune
+```
+
+### Move a worktree
+
+```bash
+git worktree move ../oh-my-customcode-release ../oh-my-customcode-hotfix
+```
+
+## Claude Code Integration
+
+### Built-in Worktree Tools
+
+Claude Code provides `EnterWorktree` and `ExitWorktree` tools for session-scoped worktree management:
+
+```
+EnterWorktree(name: "feature-x")
+# Creates .claude/worktrees/feature-x with a new branch based on HEAD
+# Session working directory switches to the worktree
+
+ExitWorktree()
+# Returns to the main repository
+# Prompts to keep or remove the worktree
+```
+
+### Agent Isolation Mode
+
+Agents can use `isolation: worktree` in their frontmatter to run in an isolated git worktree:
+
+```yaml
+---
+name: my-agent
+isolation: worktree
+---
+```
+
+This gives the agent a separate working copy, enabling safe code changes with rollback capability. The worktree is automatically created and cleaned up by the agent lifecycle.
+
+### Superpowers Skill
+
+The `superpowers` plugin includes a `using-git-worktrees` skill with additional patterns for worktree-based workflows. Reference it for advanced use cases like parallel CI testing and multi-branch refactoring.
+
+## Caveats
+
+### Same branch restriction
+
+A branch cannot be checked out in multiple worktrees simultaneously. Attempting this will fail:
+
+```bash
+# ERROR: 'develop' is already checked out at '~/workspace/projects/oh-my-customcode'
+git worktree add ../oh-my-customcode-dev2 develop
+```
+
+### Independent dependencies
+
+Each worktree has its own `node_modules`. Run package installation separately:
+
+```bash
+cd ../oh-my-customcode-team-plugin
+bun install
+```
+
+### Gitignored files
+
+Files under `.claude/` are gitignored in this project. When adding new `.claude/` files, use `git add -f`:
+
+```bash
+git add -f .claude/agents/new-agent.md
+```
+
+### Shared git objects
+
+All worktrees share the same `.git` object store. Operations like `git gc` and `git fetch` affect all worktrees.
+
+### Worktree-local files
+
+Files listed in `.gitignore` (like `node_modules/`, `.env`) are independent per worktree. Configuration files that are not tracked must be set up separately in each worktree.