@stanco323/oh-my-claude-code 4.10.3

package/skills/project-session-manager/templates/feature.md

@@ -0,0 +1,56 @@
+# Feature Development Context
+
+You are developing feature: **{{FEATURE_NAME}}**
+
+## Details
+
+- **Branch**: `{{BRANCH_NAME}}`
+- **Base**: `{{BASE_BRANCH}}`
+- **Project**: {{PROJECT}}
+
+## Feature Scope
+
+{{FEATURE_DESCRIPTION}}
+
+## Development Approach
+
+1. **Plan**
+   - Define requirements
+   - Break into subtasks
+   - Identify dependencies
+
+2. **Implement**
+   - Follow project patterns
+   - Write clean, testable code
+   - Commit incrementally
+
+3. **Test**
+   - Unit tests for new code
+   - Integration tests if needed
+   - Manual testing
+
+4. **Document**
+   - Update relevant docs
+   - Add code comments where needed
+   - Update CHANGELOG if applicable
+
+## Commands
+
+```bash
+# Run tests
+npm test  # or appropriate test command
+
+# Check build
+npm run build  # or appropriate build command
+
+# Create PR when ready
+gh pr create --title "Feature: {{FEATURE_NAME}}" --body "## Summary\n\n<description>\n\n## Changes\n\n- <change 1>\n- <change 2>"
+```
+
+## Feature Checklist
+
+- [ ] Requirements understood
+- [ ] Implementation complete
+- [ ] Tests written and passing
+- [ ] Documentation updated
+- [ ] Ready for PR

package/skills/project-session-manager/templates/issue-fix.md

@@ -0,0 +1,57 @@
+# Issue Fix Context
+
+You are fixing Issue #{{ISSUE_NUMBER}}: **{{ISSUE_TITLE}}**
+
+## Issue Details
+
+- **URL**: {{ISSUE_URL}}
+- **Labels**: {{ISSUE_LABELS}}
+- **Branch**: `{{BRANCH_NAME}}`
+
+## Description
+
+{{ISSUE_BODY}}
+
+## Approach
+
+1. **Understand the Issue**
+   - Reproduce the problem if applicable
+   - Identify root cause
+   - Consider edge cases
+
+2. **Plan the Fix**
+   - Minimal changes to fix the issue
+   - Don't introduce regressions
+   - Consider backwards compatibility
+
+3. **Implement**
+   - Write the fix
+   - Add/update tests
+   - Update documentation if needed
+
+4. **Verify**
+   - Run existing tests
+   - Test the specific fix
+   - Check for regressions
+
+## Commands
+
+```bash
+# Run tests
+npm test  # or appropriate test command
+
+# Check build
+npm run build  # or appropriate build command
+
+# Create PR when done
+gh pr create --title "Fix #{{ISSUE_NUMBER}}: <description>" --body "Fixes #{{ISSUE_NUMBER}}"
+```
+
+## Fix Checklist
+
+- [ ] Root cause identified
+- [ ] Fix implemented
+- [ ] Tests added/updated
+- [ ] All tests pass
+- [ ] No regressions introduced
+- [ ] Ready for PR

package/skills/project-session-manager/templates/pr-review.md

@@ -0,0 +1,65 @@
+# PR Review Context
+
+You are reviewing PR #{{PR_NUMBER}}: **{{PR_TITLE}}**
+
+## PR Details
+
+- **Author**: @{{PR_AUTHOR}}
+- **Branch**: `{{HEAD_BRANCH}}` → `{{BASE_BRANCH}}`
+- **URL**: {{PR_URL}}
+
+## Description
+
+{{PR_BODY}}
+
+## Changed Files
+
+{{CHANGED_FILES}}
+
+## Review Focus
+
+1. **Code Quality**
+   - Follow existing patterns and conventions
+   - Clean, readable, maintainable code
+   - Appropriate abstractions
+
+2. **Correctness**
+   - Does it do what it claims?
+   - Edge cases handled?
+   - Error handling appropriate?
+
+3. **Security**
+   - Input validation
+   - No hardcoded secrets
+   - Safe dependencies
+
+4. **Testing**
+   - Adequate test coverage
+   - Tests are meaningful
+   - Edge cases tested
+
+5. **Documentation**
+   - Code is self-documenting
+   - Complex logic explained
+   - API changes documented
+
+## Commands
+
+```bash
+# View diff
+git diff {{BASE_BRANCH}}...HEAD
+
+# Run tests
+npm test  # or appropriate test command
+
+# Check build
+npm run build  # or appropriate build command
+```
+
+## Review Checklist
+
+- [ ] Code follows project style
+- [ ] No obvious bugs or logic errors
+- [ ] Security concerns addressed
+- [ ] Tests pass and cover changes
+- [ ] Documentation updated if needed

package/skills/project-session-manager/templates/projects.json

@@ -0,0 +1,19 @@
+{
+  "aliases": {
+    "omc": {
+      "repo": "Yeachan-Heo/oh-my-claudecode",
+      "local": "~/Workspace/oh-my-claudecode",
+      "default_base": "main"
+    },
+    "cc": {
+      "repo": "anthropics/claude-code",
+      "local": "~/Workspace/claude-code",
+      "default_base": "main"
+    }
+  },
+  "defaults": {
+    "worktree_root": "~/.psm/worktrees",
+    "cleanup_after_days": 14,
+    "auto_cleanup_merged": true
+  }
+}

package/skills/ralph/SKILL.md

@@ -0,0 +1,230 @@
+---
+name: ralph
+description: Self-referential loop until task completion with configurable verification reviewer
+argument-hint: "[--no-prd] [--no-deslop] [--critic=architect|critic|codex] <task description>"
+level: 4
+---
+
+[RALPH + ULTRAWORK - ITERATION {{ITERATION}}/{{MAX}}]
+
+Your previous attempt did not output the completion promise. Continue working on the task.
+
+<Purpose>
+Ralph is a PRD-driven persistence loop that keeps working on a task until ALL user stories in prd.json have passes: true and are reviewer-verified. It wraps ultrawork's parallel execution with session persistence, automatic retry on failure, structured story tracking, and mandatory verification before completion.
+</Purpose>
+
+<Use_When>
+- Task requires guaranteed completion with verification (not just "do your best")
+- User says "ralph", "don't stop", "must complete", "finish this", or "keep going until done"
+- Work may span multiple iterations and needs persistence across retries
+- Task benefits from structured PRD-driven execution with reviewer sign-off
+</Use_When>
+
+<Do_Not_Use_When>
+- User wants a full autonomous pipeline from idea to code -- use `autopilot` instead
+- User wants to explore or plan before committing -- use `plan` skill instead
+- User wants a quick one-shot fix -- delegate directly to an executor agent
+- User wants manual control over completion -- use `ultrawork` directly
+</Do_Not_Use_When>
+
+<Why_This_Exists>
+Complex tasks often fail silently: partial implementations get declared "done", tests get skipped, edge cases get forgotten. Ralph prevents this by:
+1. Structuring work into discrete user stories with testable acceptance criteria (prd.json)
+2. Iterating story-by-story until each one passes
+3. Tracking progress and learnings across iterations (progress.txt)
+4. Requiring fresh reviewer verification against specific acceptance criteria before completion
+</Why_This_Exists>
+
+<PRD_Mode>
+By default, ralph operates in PRD mode. A scaffold `prd.json` is auto-generated when ralph starts if none exists.
+
+**Opt-out:** If `{{PROMPT}}` contains `--no-prd`, skip PRD generation and work in legacy mode (no story tracking, generic verification). Use this for trivial quick fixes.
+
+**Deslop opt-out:** If `{{PROMPT}}` contains `--no-deslop`, skip the mandatory post-review deslop pass entirely. Use this only when the cleanup pass is intentionally out of scope for the run.
+
+**Reviewer selection:** Pass `--critic=architect`, `--critic=critic`, or `--critic=codex` in the Ralph prompt to choose the completion reviewer for that run. `architect` remains the default.
+</PRD_Mode>
+
+<Execution_Policy>
+- Fire independent agent calls simultaneously -- never wait sequentially for independent work
+- Use `run_in_background: true` for long operations (installs, builds, test suites)
+- Always pass the `model` parameter explicitly when delegating to agents
+- Read `docs/shared/agent-tiers.md` before first delegation to select correct agent tiers
+- Deliver the full implementation: no scope reduction, no partial completion, no deleting tests to make them pass
+</Execution_Policy>
+
+<Steps>
+1. **PRD Setup** (first iteration only):
+   a. Check if `prd.json` exists (in project root or `.omc/`). If it already exists, read it and proceed to Step 2.
+   b. If no `prd.json` exists, the system has auto-generated a scaffold. Read `.omc/prd.json`.
+   c. **CRITICAL: Refine the scaffold.** The auto-generated PRD has generic acceptance criteria ("Implementation is complete", etc.). You MUST replace these with task-specific criteria:
+      - Analyze the original task and break it into right-sized user stories (each completable in one iteration)
+      - Write concrete, verifiable acceptance criteria for each story (e.g., "Function X returns Y when given Z", "Test file exists at path P and passes")
+      - If acceptance criteria are generic (e.g., "Implementation is complete"), REPLACE them with task-specific criteria before proceeding
+      - Order stories by priority (foundational work first, dependent work later)
+      - Write the refined `prd.json` back to disk
+   d. Initialize `progress.txt` if it doesn't exist
+
+2. **Pick next story**: Read `prd.json` and select the highest-priority story with `passes: false`. This is your current focus.
+
+3. **Implement the current story**:
+   - Delegate to specialist agents at appropriate tiers:
+     - Simple lookups: LOW tier (Haiku) -- "What does this function return?"
+     - Standard work: MEDIUM tier (Sonnet) -- "Add error handling to this module"
+     - Complex analysis: HIGH tier (Opus) -- "Debug this race condition"
+   - If during implementation you discover sub-tasks, add them as new stories to `prd.json`
+   - Run long operations in background: Builds, installs, test suites use `run_in_background: true`
+
+4. **Verify the current story's acceptance criteria**:
+   a. For EACH acceptance criterion in the story, verify it is met with fresh evidence
+   b. Run relevant checks (test, build, lint, typecheck) and read the output
+   c. If any criterion is NOT met, continue working -- do NOT mark the story as complete
+
+5. **Mark story complete**:
+   a. When ALL acceptance criteria are verified, set `passes: true` for this story in `prd.json`
+   b. Record progress in `progress.txt`: what was implemented, files changed, learnings for future iterations
+   c. Add any discovered codebase patterns to `progress.txt`
+
+6. **Check PRD completion**:
+   a. Read `prd.json` -- are ALL stories marked `passes: true`?
+   b. If NOT all complete, loop back to Step 2 (pick next story)
+   c. If ALL complete, proceed to Step 7 (architect verification)
+
+7. **Reviewer verification** (tiered, against acceptance criteria):
+   - <5 files, <100 lines with full tests: STANDARD tier minimum (architect-medium / Sonnet)
+   - Standard changes: STANDARD tier (architect-medium / Sonnet)
+   - >20 files or security/architectural changes: THOROUGH tier (architect / Opus)
+   - If `--critic=critic`, use the Claude `critic` agent for the approval pass
+   - If `--critic=codex`, run `omc ask codex --agent-prompt critic "..."` for the approval pass
+   - Ralph floor: always at least STANDARD, even for small changes
+   - The selected reviewer verifies against the SPECIFIC acceptance criteria from prd.json, not vague "is it done?"
+
+7.5 **Mandatory Deslop Pass**:
+   - Unless `{{PROMPT}}` contains `--no-deslop`, run `oh-my-claudecode:ai-slop-cleaner` in standard mode (not `--review`) on the files changed during the current Ralph session only.
+   - Keep the scope bounded to the Ralph changed-file set; do not broaden the cleanup pass to unrelated files.
+   - If the reviewer approved the implementation but the deslop pass introduces follow-up edits, keep those edits inside the same changed-file scope before proceeding.
+
+7.6 **Regression Re-verification**:
+   - After the deslop pass, re-run all relevant tests, build, and lint checks for the Ralph session.
+   - Read the output and confirm the post-deslop regression run actually passes.
+   - If regression fails, roll back the cleaner changes or fix the regression, then rerun the verification loop until it passes.
+   - Only proceed to completion after the post-deslop regression run passes (or `--no-deslop` was explicitly specified).
+
+8. **On approval**: After Step 7.6 passes (with Step 7.5 completed, or skipped via `--no-deslop`), run `/oh-my-claudecode:cancel` to cleanly exit and clean up all state files
+
+9. **On rejection**: Fix the issues raised, re-verify with the same reviewer, then loop back to check if the story needs to be marked incomplete
+</Steps>
+
+<Tool_Usage>
+- Use `Task(subagent_type="oh-my-claudecode:architect", ...)` for architect verification cross-checks when changes are security-sensitive, architectural, or involve complex multi-system integration
+- Use `Task(subagent_type="oh-my-claudecode:critic", ...)` when `--critic=critic`
+- Use `omc ask codex --agent-prompt critic "..."` when `--critic=codex`
+- Skip architect consultation for simple feature additions, well-tested changes, or time-critical verification
+- Proceed with architect agent verification alone -- never block on unavailable tools
+- Use `state_write` / `state_read` for ralph mode state persistence between iterations
+</Tool_Usage>
+
+<Examples>
+<Good>
+PRD refinement in Step 1:
+```
+Auto-generated scaffold has:
+  acceptanceCriteria: ["Implementation is complete", "Code compiles without errors"]
+
+After refinement:
+  acceptanceCriteria: [
+    "detectNoPrdFlag('ralph --no-prd fix') returns true",
+    "detectNoPrdFlag('ralph fix this') returns false",
+    "stripNoPrdFlag removes --no-prd and trims whitespace",
+    "TypeScript compiles with no errors (npm run build)"
+  ]
+```
+Why good: Generic criteria replaced with specific, testable criteria.
+</Good>
+
+<Good>
+Correct parallel delegation:
+```
+Task(subagent_type="oh-my-claudecode:executor", model="haiku", prompt="Add type export for UserConfig")
+Task(subagent_type="oh-my-claudecode:executor", model="sonnet", prompt="Implement the caching layer for API responses")
+Task(subagent_type="oh-my-claudecode:executor", model="opus", prompt="Refactor auth module to support OAuth2 flow")
+```
+Why good: Three independent tasks fired simultaneously at appropriate tiers.
+</Good>
+
+<Good>
+Story-by-story verification:
+```
+1. Story US-001: "Add flag detection helpers"
+   - Criterion: "detectNoPrdFlag returns true for --no-prd" → Run test → PASS
+   - Criterion: "TypeScript compiles" → Run build → PASS
+   - Mark US-001 passes: true
+2. Story US-002: "Wire PRD into bridge.ts"
+   - Continue to next story...
+```
+Why good: Each story verified against its own acceptance criteria before marking complete.
+</Good>
+
+<Bad>
+Claiming completion without PRD verification:
+"All the changes look good, the implementation should work correctly. Task complete."
+Why bad: Uses "should" and "look good" -- no fresh evidence, no story-by-story verification, no architect review.
+</Bad>
+
+<Bad>
+Sequential execution of independent tasks:
+```
+Task(executor, "Add type export") → wait →
+Task(executor, "Implement caching") → wait →
+Task(executor, "Refactor auth")
+```
+Why bad: These are independent tasks that should run in parallel, not sequentially.
+</Bad>
+
+<Bad>
+Keeping generic acceptance criteria:
+"prd.json created with criteria: Implementation is complete, Code compiles. Moving on to coding."
+Why bad: Did not refine scaffold criteria into task-specific ones. This is PRD theater.
+</Bad>
+</Examples>
+
+<Escalation_And_Stop_Conditions>
+- Stop and report when a fundamental blocker requires user input (missing credentials, unclear requirements, external service down)
+- Stop when the user says "stop", "cancel", or "abort" -- run `/oh-my-claudecode:cancel`
+- Continue working when the hook system sends "The boulder never stops" -- this means the iteration continues
+- If the selected reviewer rejects verification, fix the issues and re-verify (do not stop)
+- If the same issue recurs across 3+ iterations, report it as a potential fundamental problem
+</Escalation_And_Stop_Conditions>
+
+<Final_Checklist>
+- [ ] All prd.json stories have `passes: true` (no incomplete stories)
+- [ ] prd.json acceptance criteria are task-specific (not generic boilerplate)
+- [ ] All requirements from the original task are met (no scope reduction)
+- [ ] Zero pending or in_progress TODO items
+- [ ] Fresh test run output shows all tests pass
+- [ ] Fresh build output shows success
+- [ ] lsp_diagnostics shows 0 errors on affected files
+- [ ] progress.txt records implementation details and learnings
+- [ ] Selected reviewer verification passed against specific acceptance criteria
+- [ ] ai-slop-cleaner pass completed on changed files (or `--no-deslop` specified)
+- [ ] Post-deslop regression tests pass
+- [ ] `/oh-my-claudecode:cancel` run for clean state cleanup
+</Final_Checklist>
+
+<Advanced>
+## Background Execution Rules
+
+**Run in background** (`run_in_background: true`):
+- Package installation (npm install, pip install, cargo build)
+- Build processes (make, project build commands)
+- Test suites
+- Docker operations (docker build, docker pull)
+
+**Run blocking** (foreground):
+- Quick status checks (git status, ls, pwd)
+- File reads and edits
+- Simple commands
+</Advanced>
+
+Original task:
+{{PROMPT}}

package/skills/ralplan/SKILL.md

@@ -0,0 +1,135 @@
+---
+name: ralplan
+description: Consensus planning entrypoint that auto-gates vague ralph/autopilot/team requests before execution
+argument-hint: "[--interactive] [--deliberate] [--architect codex] [--critic codex] <task description>"
+level: 4
+---
+
+# Ralplan (Consensus Planning Alias)
+
+Ralplan is a shorthand alias for `/oh-my-claudecode:omc-plan --consensus`. It triggers iterative planning with Planner, Architect, and Critic agents until consensus is reached, with **RALPLAN-DR structured deliberation** (short mode by default, deliberate mode for high-risk work).
+
+## Usage
+
+```
+/oh-my-claudecode:ralplan "task description"
+```
+
+## Flags
+
+- `--interactive`: Enables user prompts at key decision points (draft review in step 2 and final approval in step 6). Without this flag the workflow runs fully automated — Planner → Architect → Critic loop — and outputs the final plan without asking for confirmation.
+- `--deliberate`: Forces deliberate mode for high-risk work. Adds pre-mortem (3 scenarios) and expanded test planning (unit/integration/e2e/observability). Without this flag, deliberate mode can still auto-enable when the request explicitly signals high risk (auth/security, migrations, destructive changes, production incidents, compliance/PII, public API breakage).
+- `--architect codex`: Use Codex for the Architect pass when Codex CLI is available. Otherwise, briefly note the fallback and keep the default Claude Architect review.
+- `--critic codex`: Use Codex for the Critic pass when Codex CLI is available. Otherwise, briefly note the fallback and keep the default Claude Critic review.
+
+## Usage with interactive mode
+
+```
+/oh-my-claudecode:ralplan --interactive "task description"
+```
+
+## Behavior
+
+This skill invokes the Plan skill in consensus mode:
+
+```
+/oh-my-claudecode:omc-plan --consensus <arguments>
+```
+
+The consensus workflow:
+1. **Planner** creates initial plan and a compact **RALPLAN-DR summary** before review:
+   - Principles (3-5)
+   - Decision Drivers (top 3)
+   - Viable Options (>=2) with bounded pros/cons
+   - If only one viable option remains, explicit invalidation rationale for alternatives
+   - Deliberate mode only: pre-mortem (3 scenarios) + expanded test plan (unit/integration/e2e/observability)
+2. **User feedback** *(--interactive only)*: If `--interactive` is set, use `AskUserQuestion` to present the draft plan **plus the Principles / Drivers / Options summary** before review (Proceed to review / Request changes / Skip review). Otherwise, automatically proceed to review.
+3. **Architect** reviews for architectural soundness and must provide the strongest steelman antithesis, at least one real tradeoff tension, and (when possible) synthesis — **await completion before step 4**. In deliberate mode, Architect should explicitly flag principle violations.
+4. **Critic** evaluates against quality criteria — run only after step 3 completes. Critic must enforce principle-option consistency, fair alternatives, risk mitigation clarity, testable acceptance criteria, and concrete verification steps. In deliberate mode, Critic must reject missing/weak pre-mortem or expanded test plan.
+5. **Re-review loop** (max 5 iterations): Any non-`APPROVE` Critic verdict (`ITERATE` or `REJECT`) MUST run the same full closed loop:
+   a. Collect Architect + Critic feedback
+   b. Revise the plan with Planner
+   c. Return to Architect review
+   d. Return to Critic evaluation
+   e. Repeat this loop until Critic returns `APPROVE` or 5 iterations are reached
+   f. If 5 iterations are reached without `APPROVE`, present the best version to the user
+6. On Critic approval *(--interactive only)*: If `--interactive` is set, use `AskUserQuestion` to present the plan with approval options (Approve and implement via team (Recommended) / Approve and execute via ralph / Clear context and implement / Request changes / Reject). Final plan must include ADR (Decision, Drivers, Alternatives considered, Why chosen, Consequences, Follow-ups). Otherwise, output the final plan and stop.
+7. *(--interactive only)* User chooses: Approve (team or ralph), Request changes, or Reject
+8. *(--interactive only)* On approval: invoke `Skill("oh-my-claudecode:team")` for parallel team execution (recommended) or `Skill("oh-my-claudecode:ralph")` for sequential execution -- never implement directly
+
+> **Important:** Steps 3 and 4 MUST run sequentially. Do NOT issue both agent Task calls in the same parallel batch. Always await the Architect result before issuing the Critic Task.
+
+Follow the Plan skill's full documentation for consensus mode details.
+
+## Pre-Execution Gate
+
+### Why the Gate Exists
+
+Execution modes (ralph, autopilot, team, ultrawork, ultrapilot) spin up heavy multi-agent orchestration. When launched on a vague request like "ralph improve the app", agents have no clear target — they waste cycles on scope discovery that should happen during planning, often delivering partial or misaligned work that requires rework.
+
+The ralplan-first gate intercepts underspecified execution requests and redirects them through the ralplan consensus planning workflow. This ensures:
+- **Explicit scope**: A PRD defines exactly what will be built
+- **Test specification**: Acceptance criteria are testable before code is written
+- **Consensus**: Planner, Architect, and Critic agree on the approach
+- **No wasted execution**: Agents start with a clear, bounded task
+
+### Good vs Bad Prompts
+
+**Passes the gate** (specific enough for direct execution):
+- `ralph fix the null check in src/hooks/bridge.ts:326`
+- `autopilot implement issue #42`
+- `team add validation to function processKeywordDetector`
+- `ralph do:\n1. Add input validation\n2. Write tests\n3. Update README`
+- `ultrawork add the user model in src/models/user.ts`
+
+**Gated — redirected to ralplan** (needs scoping first):
+- `ralph fix this`
+- `autopilot build the app`
+- `team improve performance`
+- `ralph add authentication`
+- `ultrawork make it better`
+
+**Bypass the gate** (when you know what you want):
+- `force: ralph refactor the auth module`
+- `! autopilot optimize everything`
+
+### When the Gate Does NOT Trigger
+
+The gate auto-passes when it detects **any** concrete signal. You do not need all of them — one is enough:
+
+| Signal Type | Example prompt | Why it passes |
+|---|---|---|
+| File path | `ralph fix src/hooks/bridge.ts` | References a specific file |
+| Issue/PR number | `ralph implement #42` | Has a concrete work item |
+| camelCase symbol | `ralph fix processKeywordDetector` | Names a specific function |
+| PascalCase symbol | `ralph update UserModel` | Names a specific class |
+| snake_case symbol | `team fix user_model` | Names a specific identifier |
+| Test runner | `ralph npm test && fix failures` | Has an explicit test target |
+| Numbered steps | `ralph do:\n1. Add X\n2. Test Y` | Structured deliverables |
+| Acceptance criteria | `ralph add login - acceptance criteria: ...` | Explicit success definition |
+| Error reference | `ralph fix TypeError in auth` | Specific error to address |
+| Code block | `ralph add: \`\`\`ts ... \`\`\`` | Concrete code provided |
+| Escape prefix | `force: ralph do it` or `! ralph do it` | Explicit user override |
+
+### End-to-End Flow Example
+
+1. User types: `ralph add user authentication`
+2. Gate detects: execution keyword (`ralph`) + underspecified prompt (no files, functions, or test spec)
+3. Gate redirects to **ralplan** with message explaining the redirect
+4. Ralplan consensus runs:
+   - **Planner** creates initial plan (which files, what auth method, what tests)
+   - **Architect** reviews for soundness
+   - **Critic** validates quality and testability
+5. On consensus approval, user chooses execution path:
+   - **team**: parallel coordinated agents (recommended)
+   - **ralph**: sequential execution with verification
+6. Execution begins with a clear, bounded plan
+
+### Troubleshooting
+
+| Issue | Solution |
+|-------|----------|
+| Gate fires on a well-specified prompt | Add a file reference, function name, or issue number to anchor the request |
+| Want to bypass the gate | Prefix with `force:` or `!` (e.g., `force: ralph fix it`) |
+| Gate does not fire on a vague prompt | The gate only catches prompts with <=15 effective words and no concrete anchors; add more detail or use `/ralplan` explicitly |
+| Redirected to ralplan but want to skip planning | In the ralplan workflow, say "just do it" or "skip planning" to transition directly to execution |

package/skills/release/SKILL.md

@@ -0,0 +1,88 @@
+---
+name: release
+description: Automated release workflow for oh-my-claudecode
+level: 3
+---
+
+# Release Skill
+
+Automate the release process for oh-my-claudecode.
+
+## Usage
+
+```
+/oh-my-claudecode:release <version>
+```
+
+Example: `/oh-my-claudecode:release 2.4.0` or `/oh-my-claudecode:release patch` or `/oh-my-claudecode:release minor`
+
+## Release Checklist
+
+Execute these steps in order:
+
+### 1. Version Bump
+Update version in all locations:
+- `package.json`
+- `src/installer/index.ts` (VERSION constant)
+- `src/__tests__/installer.test.ts` (expected version)
+- `.claude-plugin/plugin.json`
+- `.claude-plugin/marketplace.json` (both `plugins[0].version` and root `version`)
+- `docs/CLAUDE.md` (`<!-- OMC:VERSION:X.Y.Z -->` marker)
+- `README.md` (version badge and title)
+
+### 2. Run Tests
+```bash
+npm run test:run
+```
+All 231+ tests must pass before proceeding.
+
+### 3. Commit Version Bump
+```bash
+git add -A
+git commit -m "chore: Bump version to <version>"
+```
+
+### 4. Create & Push Tag
+```bash
+git tag v<version>
+git push origin main
+git push origin v<version>
+```
+
+### 5. Publish to npm
+```bash
+npm publish --access public
+```
+
+### 6. Create GitHub Release
+```bash
+gh release create v<version> --title "v<version> - <title>" --notes "<release notes>"
+```
+
+### 7. Verify
+- [ ] npm: https://www.npmjs.com/package/oh-my-claudecode
+- [ ] GitHub: https://github.com/Yeachan-Heo/oh-my-claudecode/releases
+
+## Version Files Reference
+
+| File | Field/Line |
+|------|------------|
+| `package.json` | `"version": "X.Y.Z"` |
+| `src/installer/index.ts` | `export const VERSION = 'X.Y.Z'` |
+| `src/__tests__/installer.test.ts` | `expect(VERSION).toBe('X.Y.Z')` |
+| `.claude-plugin/plugin.json` | `"version": "X.Y.Z"` |
+| `.claude-plugin/marketplace.json` | `plugins[0].version` + root `version` |
+| `docs/CLAUDE.md` | `<!-- OMC:VERSION:X.Y.Z -->` |
+| `README.md` | Title + version badge |
+
+## Semantic Versioning
+
+- **patch** (X.Y.Z+1): Bug fixes, minor improvements
+- **minor** (X.Y+1.0): New features, backward compatible
+- **major** (X+1.0.0): Breaking changes
+
+## Notes
+
+- Always run tests before publishing
+- Create release notes summarizing changes
+- Plugin marketplace syncs automatically from GitHub releases