claudecode-omc 4.4.10 → 4.7.4

package/skills/quick-init-project/SKILL.md

@@ -0,0 +1,333 @@
+---
+name: quick-init-project
+description: Use when the user wants to "quick init project", "bootstrap a new project", "recommend fullstack vs frontend vs backend", "initialize monorepo", "generate project scaffold", "project setup recommendation", or asks "快速初始化项目", "初始化 monorepo", "生成项目脚手架方案"
+version: 1.0.0
+argument-hint: <product requirement or idea>
+---
+
+<Purpose>
+Quickly bootstrap a new project with intelligent mode selection (fullstack/frontend/backend/demo), data-dense tech stack recommendations based on 2026 ecosystem data, and executable initialization commands. Delivers a complete startup plan in 5-10 minutes with minimal input.
+</Purpose>
+
+<Use_When>
+- User wants to start a new project from scratch
+- User needs help deciding between fullstack, frontend-only, or backend-only architecture
+- User asks for monorepo setup or project scaffolding
+- User wants tech stack recommendations based on current ecosystem data
+- User says "quick init", "bootstrap project", "initialize monorepo", "快速初始化项目", "根据需求推荐全栈还是前端/后端"
+- User wants a project scaffold with best practices and modern tooling
+</Use_When>
+
+<Do_Not_Use_When>
+- User wants to modify an existing project structure
+- User has already decided on tech stack and just needs implementation help
+- User wants to explore multiple architectural options without commitment (use `plan` skill instead)
+- User wants to add features to an existing project (use `executor` agent)
+- User is asking about general architecture concepts without a specific project
+</Do_Not_Use_When>
+
+<Why_This_Exists>
+Starting a new project involves critical early decisions: architecture mode, tech stack, repository structure, and tooling. Making wrong choices early can compound into significant technical debt. This skill uses data-driven decision making (Stack Overflow surveys, npm download stats, State of JS/CSS 2024) to recommend proven, well-supported stacks and provides executable commands to get started immediately.
+</Why_This_Exists>
+
+## Research Baseline (as of 2026-02-26)
+
+Decision making is based on the following public signals:
+- Stack Overflow Developer Survey 2024: Node.js 40.8%, React 39.5%, Next.js 17.9%, NestJS 5.8%
+- State of JS 2024: 67% respondents write more TypeScript than JavaScript
+- State of CSS 2024: Tailwind CSS usage significantly leads CSS framework category
+- npm weekly downloads (2026-02-18 to 2026-02-24):
+  - `typescript`: 131,004,723
+  - `react`: 96,415,450
+  - `tailwindcss`: 60,494,373
+  - `next`: 36,026,759
+  - `@nestjs/core`: 7,290,173
+
+## Input Contract
+
+Extract at least the following inputs; use defaults when missing and note assumptions:
+- Product goal: target users and core scenarios
+- Delivery speed: `urgent (<1 week)` / `normal (2-4 weeks)` / `long (>4 weeks)`
+- Team shape: frontend-heavy / backend-heavy / fullstack
+- Runtime: web / api / both
+- Data complexity: low / medium / high
+
+Default assumptions: `normal + small team + web-first + medium complexity`
+
+## Mode Selection
+
+### Step 1: Hard Gates
+
+Check in order; if hit, select mode immediately:
+1. Only concept demo, idea validation, no production requirement -> `demo`
+2. Backend exists with stable API contract, only need UI -> `frontend-only`
+3. Frontend consumer exists, only need API/service -> `backend-only`
+4. Frontend and backend both needed with frequent interface changes -> proceed to scoring (usually `full-stack`)
+
+### Step 2: Weighted Scoring (0-100)
+
+Dimension scoring range `1-5`:
+- Requirement complexity (weight 25)
+- Delivery speed pressure (weight 20)
+- Team skill fitness (weight 20)
+- Deployment constraint strength (weight 15)
+- Data/state complexity (weight 20)
+
+Mode target profiles:
+- `full-stack`: [4, 3, 4, 3, 4]
+- `frontend-only`: [2, 4, 4, 3, 2]
+- `backend-only`: [3, 3, 4, 4, 4]
+- `demo`: [1, 5, 3, 1, 1]
+
+Calculation:
+- `fit = 5 - abs(actual - target)`
+- `modeScore = Σ(fit/5 * weight)`
+
+Decision rules:
+1. Top score < 60 -> fallback to `demo` + output information gaps
+2. Top1 - Top2 >= 8 -> select Top1 directly
+3. Gap < 8 -> compare `delivery speed`, `team skill fitness`, `change surface` in order
+
+## Tech Stack Policy (Data-Dense First)
+
+### Preferred Default Stack
+
+- Language: `TypeScript`
+- Frontend: `React + Next.js (App Router) + Tailwind CSS`
+- Backend: `NestJS (REST-first) + OpenAPI`
+- Package manager: `pnpm`
+- Repository: `Monorepo` (pnpm workspaces)
+- Task orchestration: `Turborepo` (default), upgrade to `Nx` when governance is required
+- Quality baseline: `ESLint + Prettier + Vitest + Playwright`
+
+### Escalation to Nx
+
+Upgrade from Turborepo to Nx when:
+- Project count >= 6 packages/apps
+- Need enforced module boundaries (lint-level boundaries)
+- Need mature affected execution and stronger governance
+
+### Downgrade Rules
+
+- Ultra-short PoC with only runnable pages -> can downgrade to single-repo single-app (non-monorepo)
+- Backend single service with no shared packages -> can skip monorepo for now
+
+## Architecture Templates
+
+### 1) full-stack
+
+```text
+repo/
+  apps/
+    web/           # Next.js
+    api/           # NestJS
+  packages/
+    ui/            # React shared components
+    config/        # eslint/tsconfig/prettier shared config
+    types/         # shared DTO/types
+    sdk/           # typed API client
+  turbo.json
+  pnpm-workspace.yaml
+  tsconfig.base.json
+```
+
+Layering rules:
+- `apps/*` can depend on `packages/*`
+- `packages/ui` cannot depend on `apps/*`
+- `packages/types` must stay framework-agnostic
+
+### 2) frontend-only
+
+```text
+repo/
+  apps/web/
+  packages/
+    ui/
+    config/
+    types/
+```
+
+Default: use `MSW` or mock server to decouple backend availability.
+
+### 3) backend-only
+
+```text
+repo/
+  apps/api/
+  packages/
+    config/
+    types/
+    contracts/     # OpenAPI schema + generated clients
+```
+
+Default: deliver `OpenAPI` first with health/readiness endpoints.
+
+### 4) demo
+
+```text
+repo/
+  apps/demo/
+  packages/config/
+```
+
+Scope limit: single main flow + minimal dependencies + quick demo capability.
+
+## Execution Workflow
+
+<Agent_Orchestration>
+Phase A (Requirement Parsing):
+- Use Agent(subagent_type="oh-my-claudecode:analyst", model="sonnet")
+- Extract: product goal, delivery speed, team shape, runtime, data complexity
+- Output summary: problem statement, assumptions, unknowns (max 1 screen)
+- Save to: `.omc/quick-init/requirements.md`
+
+Phase B (Mode Decision):
+- Use Agent(subagent_type="oh-my-claudecode:architect", model="opus")
+- Apply hard gates first, then weighted scoring if needed
+- Output: selected mode, scores, hard gate hit (if any), reasoning (max 3 bullets), risk note (1 line)
+- Save to: `.omc/quick-init/decision.md`
+
+Phase C (Bootstrap Plan):
+- Use Agent(subagent_type="oh-my-claudecode:planner", model="sonnet")
+- Generate: directory structure, init commands, milestones (Day 1/3/7), minimal verification commands
+- Save to: `.omc/quick-init/bootstrap-plan.md`
+
+Phase D (Command Generation):
+- Direct execution: generate executable commands based on selected mode
+- Save to: `.omc/quick-init/init-commands.sh`
+</Agent_Orchestration>
+
+### Default Command Templates
+
+Full-stack or multi-package:
+```bash
+pnpm dlx create-turbo@latest
+pnpm install
+pnpm -r lint
+pnpm -r test
+pnpm -r build
+```
+
+Frontend-only (non-monorepo):
+```bash
+pnpm create next-app@latest web --ts --tailwind --eslint --app
+cd web && pnpm test
+```
+
+Backend-only (non-monorepo):
+```bash
+pnpm add -g @nestjs/cli
+nest new api
+cd api && pnpm test
+```
+
+## Output Format
+
+Every execution must return:
+
+```text
+## Init Recommendation
+- Selected Mode: <full-stack|frontend-only|backend-only|demo>
+- Confidence: <HIGH|MEDIUM|LOW>
+
+## Decision Evidence
+- Hard Gate: <rule-id or none>
+- Scores: full-stack=<n>, frontend-only=<n>, backend-only=<n>, demo=<n>
+- Why: <3 bullets max>
+
+## Recommended Stack
+- Runtime: ...
+- Frameworks: ...
+- Repo Strategy: ...
+
+## Bootstrap Commands
+[exact commands here]
+
+## Folder Blueprint
+[tree here]
+
+## 7-Day Plan
+1. Day 1 ...
+2. Day 3 ...
+3. Day 7 ...
+
+## Risks & Mitigations
+- Risk: ...
+- Mitigation: ...
+```
+
+## Quality Gates
+
+Before claiming "ready to initialize", must satisfy:
+1. Mode selection has traceable basis (hard gate or complete scoring)
+2. Tech stack includes TypeScript, with explanation if not using default stack
+3. Commands are directly executable, no placeholders
+4. Directory structure matches selected mode
+5. At least one risk with mitigation provided
+
+<Tool_Usage>
+- Use `Agent` tool with appropriate subagent types for each phase
+- Use `Write` tool to save outputs to `.omc/quick-init/` directory
+- Use `Bash` tool to execute verification commands (lint/test/build) if user requests immediate setup
+- Use `state_write(mode="quick-init")` to track progress across phases
+- Use `notepad_write_working` to log key decisions for session context
+</Tool_Usage>
+
+<Examples>
+<Good>
+User: "快速初始化一个电商项目，需要前后端"
+Why good: Clear domain (e-commerce), explicit requirement (fullstack). Skill will analyze and recommend appropriate stack with monorepo structure.
+</Good>
+
+<Good>
+User: "bootstrap a SaaS dashboard with user auth and billing"
+Why good: Specific features mentioned, clear product type. Skill can make informed mode and stack decisions based on complexity.
+</Good>
+
+<Good>
+User: "quick init a REST API for inventory management"
+Why good: Clear backend-only scenario. Skill will detect this via hard gate and recommend NestJS + OpenAPI setup.
+</Good>
+
+<Bad>
+User: "add a new feature to my existing Next.js app"
+Why bad: This is about modifying existing code, not initializing a new project. Use executor agent instead.
+</Bad>
+
+<Bad>
+User: "what's the best way to structure a monorepo?"
+Why bad: This is a general architecture question without a specific project. Respond conversationally or use plan skill.
+</Bad>
+</Examples>
+
+<Execution_Policy>
+- Each phase must complete before the next begins
+- Analyst extracts requirements first, architect makes mode decision, planner generates bootstrap plan
+- If requirements are too vague and analyst cannot extract sufficient information, pause and ask user for clarification
+- If mode decision confidence is LOW, present options to user before proceeding
+- All outputs must be saved to `.omc/quick-init/` for traceability
+- Commands must be tested for syntax validity before presenting to user
+</Execution_Policy>
+
+<Escalation_And_Stop_Conditions>
+- Stop and ask for clarification when requirements are too vague (confidence < 50%)
+- Stop and present options when mode decision is ambiguous (top two scores within 5 points)
+- Stop when user says "stop", "cancel", or "wait"
+- If tech stack constraints conflict with best practices, explain tradeoffs and ask for confirmation
+</Escalation_And_Stop_Conditions>
+
+## Sources
+
+- Stack Overflow Developer Survey 2024 (Technology): https://survey.stackoverflow.co/2024/technology
+- State of JS 2024 (Usage): https://2024.stateofjs.com/en-US/usage/
+- State of CSS 2024 (Tools): https://2024.stateofcss.com/en-US/tools/
+- npm downloads API:
+  - https://api.npmjs.org/downloads/point/last-week/typescript
+  - https://api.npmjs.org/downloads/point/last-week/react
+  - https://api.npmjs.org/downloads/point/last-week/tailwindcss
+  - https://api.npmjs.org/downloads/point/last-week/next
+  - https://api.npmjs.org/downloads/point/last-week/@nestjs/core
+- Turborepo docs: https://turborepo.com/docs
+- pnpm workspaces: https://pnpm.io/workspaces
+- Nx monorepo docs: https://nx.dev/docs/features/maintain-typescript-monorepos
+- TypeScript project references: https://www.typescriptlang.org/docs/handbook/project-references

package/skills/ralph/SKILL.md

@@ -8,14 +8,14 @@ description: Self-referential loop until task completion with architect verifica
 Your previous attempt did not output the completion promise. Continue working on the task.
 
 <Purpose>
-Ralph is a persistence loop that keeps working on a task until it is fully complete and architect-verified. It wraps ultrawork's parallel execution with session persistence, automatic retry on failure, and mandatory verification before completion.
+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 architect-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 parallel execution with architect sign-off at the end
+- Task benefits from structured PRD-driven execution with architect sign-off
 </Use_When>
 
 <Do_Not_Use_When>
@@ -26,9 +26,19 @@ Ralph is a persistence loop that keeps working on a task until it is fully compl
 </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 looping until work is genuinely complete, requiring fresh verification evidence before allowing completion, and using tiered architect review to confirm quality.
+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 architect 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.
+</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)
@@ -38,25 +48,52 @@ Complex tasks often fail silently: partial implementations get declared "done",
 </Execution_Policy>
 
 <Steps>
-1. **Review progress**: Check TODO list and any prior iteration state
-2. **Continue from where you left off**: Pick up incomplete tasks
-3. **Delegate in parallel**: Route tasks 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"
-4. **Run long operations in background**: Builds, installs, test suites use `run_in_background: true`
-5. **Verify completion with fresh evidence**:
-   a. Identify what command proves the task is complete
-   b. Run verification (test, build, lint)
-   c. Read the output -- confirm it actually passed
-   d. Check: zero pending/in_progress TODO items
-6. **Architect verification** (tiered):
+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. **Architect 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)
    - Ralph floor: always at least STANDARD, even for small changes
-7. **On approval**: Run `/oh-my-claudecode:cancel` to cleanly exit and clean up all state files
-8. **On rejection**: Fix the issues raised, then re-verify at the same tier
+   - The architect verifies against the SPECIFIC acceptance criteria from prd.json, not vague "is it done?"
+
+8. **On approval**: Run `/oh-my-claudecode:cancel` to cleanly exit and clean up all state files
+
+9. **On rejection**: Fix the issues raised, re-verify at the same tier, then loop back to check if the story needs to be marked incomplete
 </Steps>
 
 <Tool_Usage>
@@ -67,43 +104,67 @@ Complex tasks often fail silently: partial implementations get declared "done",
 </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-low", model="haiku", prompt="Add type export for UserConfig")
+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-high", model="opus", prompt="Refactor auth module to support OAuth2 flow")
+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>
-Correct verification before completion:
+Story-by-story verification:
 ```
-1. Run: npm test           → Output: "42 passed, 0 failed"
-2. Run: npm run build      → Output: "Build succeeded"
-3. Run: lsp_diagnostics    → Output: 0 errors
-4. Spawn architect-medium  → Verdict: "APPROVED"
-5. Run /oh-my-claudecode:cancel
+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: Fresh evidence at each step, architect verification, then clean exit.
+Why good: Each story verified against its own acceptance criteria before marking complete.
 </Good>
 
 <Bad>
-Claiming completion without verification:
+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 test/build output, no architect verification.
+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-low, "Add type export") → wait →
+Task(executor, "Add type export") → wait →
 Task(executor, "Implement caching") → wait →
-Task(executor-high, "Refactor auth")
+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>
@@ -115,54 +176,19 @@ Why bad: These are independent tasks that should run in parallel, not sequential
 </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
-- [ ] Architect verification passed (STANDARD tier minimum)
+- [ ] progress.txt records implementation details and learnings
+- [ ] Architect verification passed (STANDARD tier minimum) against specific acceptance criteria
 - [ ] `/oh-my-claudecode:cancel` run for clean state cleanup
 </Final_Checklist>
 
 <Advanced>
-## PRD Mode (Optional)
-
-When the user provides the `--prd` flag, initialize a Product Requirements Document before starting the ralph loop.
-
-### Detecting PRD Mode
-Check if `{{PROMPT}}` contains `--prd` or `--PRD`.
-
-### PRD Workflow
-1. Create `.omc/prd.json` and `.omc/progress.txt`
-2. Parse the task (everything after `--prd` flag)
-3. Break down into user stories:
-
-```json
-{
-  "project": "[Project Name]",
-  "branchName": "ralph/[feature-name]",
-  "description": "[Feature description]",
-  "userStories": [
-    {
-      "id": "US-001",
-      "title": "[Short title]",
-      "description": "As a [user], I want to [action] so that [benefit].",
-      "acceptanceCriteria": ["Criterion 1", "Typecheck passes"],
-      "priority": 1,
-      "passes": false
-    }
-  ]
-}
-```
-
-4. Create `progress.txt` with timestamp and empty patterns section
-5. Guidelines: right-sized stories (one session each), verifiable criteria, independent stories, priority order (foundational work first)
-6. Proceed to normal ralph loop using user stories as the task list
-
-### Example
-User input: `--prd build a todo app with React and TypeScript`
-Workflow: Detect flag, extract task, create `.omc/prd.json`, create `.omc/progress.txt`, begin ralph loop.
-
 ## Background Execution Rules
 
 **Run in background** (`run_in_background: true`):

package/skills/ralplan/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: ralplan
-description: Alias for /plan --consensus
+description: Alias for /omc-plan --consensus
 ---
 
 # Ralplan (Consensus Planning Alias)
 
-Ralplan is a shorthand alias for `/oh-my-claudecode: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).
+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
 
@@ -29,7 +29,7 @@ Ralplan is a shorthand alias for `/oh-my-claudecode:plan --consensus`. It trigge
 This skill invokes the Plan skill in consensus mode:
 
 ```
-/oh-my-claudecode:plan --consensus <arguments>
+/oh-my-claudecode:omc-plan --consensus <arguments>
 ```
 
 The consensus workflow:
@@ -49,9 +49,9 @@ The consensus workflow:
    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 execute via ralph / Approve and implement via team / 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 (ralph or team), Request changes, or Reject
-8. *(--interactive only)* On approval: invoke `Skill("oh-my-claudecode:ralph")` for sequential execution or `Skill("oh-my-claudecode:team")` for parallel team execution -- never implement directly
+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.
 
@@ -117,8 +117,8 @@ The gate auto-passes when it detects **any** concrete signal. You do not need al
    - **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
-   - **team**: parallel coordinated agents
 6. Execution begins with a clear, bounded plan
 
 ### Troubleshooting

package/skills/security-review/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: security-review
+name: omc-security-review
 description: Run a comprehensive security review on code
 ---
 
@@ -258,7 +258,7 @@ The security-reviewer agent verifies:
 ```
 /pipeline security "review authentication module"
 ```
-Uses: explore → security-reviewer → executor → security-reviewer-low (re-verify)
+Uses: explore → security-reviewer → executor → security-reviewer (re-verify)
 
 **With Swarm:**
 ```