oh-my-opencode 4.10.0 → 4.11.0

package/.opencode/skills/work-with-pr/SKILL.md

@@ -1,23 +1,27 @@
 ---
 name: work-with-pr
-description: "Full PR lifecycle: git worktree → implement → atomic commits → PR creation → verification loop (CI + review-work + Cubic approval) → merge. Keeps iterating until ALL gates pass and PR is merged. Worktree auto-cleanup after merge. Use whenever implementation work needs to land as a PR. Triggers: 'create a PR', 'implement and PR', 'work on this and make a PR', 'implement issue', 'land this as a PR', 'work-with-pr', 'PR workflow', 'implement end to end', even when user just says 'implement X' if the context implies PR delivery."
+description: "Full PR lifecycle in an isolated git worktree: implement via the ulw-loop skill with mandatory evidence-bound manual QA → detailed English PR → verification loop (CI + review-work reviewers + Cubic, where Cubic is skipped only when its quota is exhausted) → merge by default → worktree cleanup. Decomposes one task into the smallest atomic, independently-mergeable PRs and builds the independent ones concurrently via a worktree per PR driven by parallel subagents or a team. Unbounded loop: any failing gate sends you back to fix-and-re-QA inside the worktree. Use whenever implementation work needs to land as a PR. Triggers: 'create a PR', 'implement and PR', 'work on this and make a PR', 'implement issue', 'land this as a PR', 'split into atomic PRs', 'parallel PRs', 'work-with-pr', 'PR workflow', 'implement end to end', even when user just says 'implement X' if the context implies PR delivery."
 ---
 
 # Work With PR — Full PR Lifecycle
 
-You are executing a complete PR lifecycle: from isolated worktree setup through implementation, PR creation, and an unbounded verification loop until the PR is merged. The loop has three gates — CI, review-work, and Cubic — and you keep fixing and pushing until all three pass simultaneously.
+You are executing a complete PR lifecycle: from isolated worktree setup, through `ulw-loop`-driven implementation with evidence-bound manual QA, PR creation, and an unbounded verification loop until the PR is merged. The loop has three gates — CI, review-work, and Cubic — and a failing gate sends you back into the worktree to fix and re-QA. You keep cycling until every active gate passes at once.
+
+**The unit of delivery is the smallest PR that compiles, passes, and stands on its own — not "one task, one PR."** A single task routinely splits into several atomic PRs; the lifecycle below describes ONE of them, so apply it to each, and build the independent ones concurrently (Phase 0).
 
 <architecture>
 
 ```
-Phase 0: Setup         → Branch + worktree in sibling directory
-Phase 1: Implement     → Do the work, atomic commits
-Phase 2: PR Creation   → Push, create PR targeting dev
-Phase 3: Verify Loop   → Unbounded iteration until ALL gates pass:
+Phase 0: Setup         → Split into atomic PRs, then branch + worktree per PR (parallel when independent)
+Phase 1: Implement     → Drive the work through the ulw-loop skill:
+                         evidence-bound manual QA per success criterion, atomic commits
+Phase 2: PR Creation   → Push, create a detailed English PR targeting dev
+Phase 3: Verify Loop   → Unbounded iteration; a failing gate routes back to Phase 1:
   ├─ Gate A: CI         → gh pr checks (bun test, typecheck, build)
-  ├─ Gate B: review-work → 5-agent parallel review
+  ├─ Gate B: review-work → 5-agent parallel review (the reviewer subagents)
   └─ Gate C: Cubic      → cubic-dev-ai[bot] "No issues found"
-Phase 4: Merge         → Squash merge, worktree cleanup
+                         (SKIPPED, not failed, when Cubic's quota is exhausted)
+Phase 4: Merge         → Merge by default, then worktree cleanup
 ```
 
 </architecture>
@@ -26,11 +30,21 @@ Phase 4: Merge         → Squash merge, worktree cleanup
 
 ## Phase 0: Setup
 
-Create an isolated worktree so the user's main working directory stays clean. This matters because the user may have uncommitted work, and checking out a branch would destroy it.
+Create an isolated worktree so the user's main working directory stays clean — the user may have uncommitted work, and a branch checkout would destroy it. Isolation also makes parallelism cheap: one worktree per PR, so several build at once without colliding.
 
 <setup>
 
-### 1. Resolve repository context
+### 1. Decide the PR split
+
+Before creating anything, decompose the task into the smallest atomic PRs that each compile, pass, and deliver one reviewable slice. Prefer more small PRs over one large one — a 200-line PR gets a real review; a 2000-line PR gets a rubber stamp. Sequence by dependency: independent slices branch off the base and run in parallel; dependent slices stack, each branched off the previous.
+
+Building more than one independent PR concurrently is the recommended default, not an exotic option:
+- **Subagents** — dispatch one background subagent per PR, each owning its own worktree, branch, and the full Phase 0→4 lifecycle.
+- **Team** — for larger fan-outs, form a team (`team_mode`) and assign one member per PR.
+
+When the work is large enough to need a plan (`ulw-plan`), this decomposition is not optional polish: the plan MUST encode the atomic PRs, their dependency order, and which run in parallel as first-class structure.
+
+### 2. Resolve repository context
 
 ```bash
 REPO=$(gh repo view --json nameWithOwner -q .nameWithOwner)
@@ -38,7 +52,7 @@ REPO_NAME=$(basename "$PWD")
 BASE_BRANCH="dev"  # CI blocks PRs to master
 ```
 
-### 2. Create branch
+### 3. Create branch
 
 If user provides a branch name, use it. Otherwise, derive from the task:
 
@@ -49,7 +63,7 @@ git fetch origin "$BASE_BRANCH"
 git branch "$BRANCH_NAME" "origin/$BASE_BRANCH"
 ```
 
-### 3. Create worktree
+### 4. Create worktree
 
 Place worktrees as siblings to the repo — not inside it. This avoids git nested repo issues and keeps the working tree clean.
 
@@ -59,7 +73,7 @@ mkdir -p "$(dirname "$WORKTREE_PATH")"
 git worktree add "$WORKTREE_PATH" "$BRANCH_NAME"
 ```
 
-### 4. Set working context
+### 5. Set working context
 
 All subsequent work happens inside the worktree. Install dependencies if needed:
 
@@ -75,15 +89,19 @@ cd "$WORKTREE_PATH"
 
 ## Phase 1: Implement
 
-Do the actual implementation work inside the worktree. The agent using this skill does the work directly — no subagent delegation for the implementation itself.
+Drive all implementation through the `ulw-loop` skill (your harness's native ultrawork loop) from inside the worktree. Do not free-hand the work: `ulw-loop` decomposes the brief into goals with binary success criteria, delegates code edits and QA to right-sized subagents, and — the reason it is mandatory here — forces every success criterion to be proven with evidence-bound **manual QA on a real surface**, not just a green test suite.
 
-**Scope discipline**: For bug fixes, stay minimal. Fix the bug, add a test for it, done. Do not refactor surrounding code, add config options, or "improve" things that aren't broken. The verification loop will catch regressions — trust the process.
+**Manual QA is the gate, not the tests.** This repo's rule is absolute: a change that reaches OpenCode or Codex is not done until you have driven the real harness (tmux / HTTP / browser / GUI — use the manual-QA channel table in the `ulw-loop` skill) AND written the evidence to disk. No evidence file means the QA did not happen, and you may NOT commit or push. "It typechecks" and "`bun test` is green" are NOT QA.
 
 <implementation>
 
+### Scope discipline
+
+Within each PR, stay minimal: deliver its one slice, add the test, prove it, stop. Do not refactor surrounding code, add config options, or "improve" things that aren't broken — that work belongs in its own PR, and scope creep makes failures harder to isolate.
+
 ### Commit strategy
 
-Use the git-master skill's atomic commit principles. The reason for atomic commits: if CI fails on one change, you can isolate and fix it without unwinding everything.
+`ulw-loop` commits through `git-master`. Keep commits atomic so that if CI fails on one change you can isolate and fix it without unwinding everything:
 
 ```
 3+ files changed  → 2+ commits minimum
@@ -91,15 +109,11 @@ Use the git-master skill's atomic commit principles. The reason for atomic commi
 10+ files changed → 5+ commits minimum
 ```
 
-Each commit should pair implementation with its tests. Load `git-master` skill when committing:
-
-```
-task(category="quick", load_skills=["git-master"], prompt="Commit the changes atomically following git-master conventions. Repository is at {WORKTREE_PATH}.")
-```
+Each commit pairs implementation with its tests, and you commit a criterion only after its QA evidence is on disk.
 
 ### Pre-push local validation
 
-Before pushing, run the same checks CI will run. Catching failures locally saves a full CI round-trip (~3-5 min):
+Before pushing, run the same checks CI will run — a cheap pre-filter that saves a ~3-5 min CI round-trip, NOT a substitute for the manual QA above:
 
 ```bash
 bun run typecheck
@@ -107,7 +121,7 @@ bun test
 bun run build
 ```
 
-Fix any failures before pushing. Each fix-commit cycle should be atomic.
+Fix any failure before pushing; each fix is its own atomic commit.
 
 </implementation>
 
@@ -123,7 +137,7 @@ Fix any failures before pushing. Each fix-commit cycle should be atomic.
 git push -u origin "$BRANCH_NAME"
 ```
 
-Create the PR using the project's template structure:
+Write the PR body in English, detailed enough that a reviewer understands the change without reading the diff. The Verification section is where the manual-QA evidence from Phase 1 earns its place — cite what you actually drove and where the artifact lives, not just that tests passed.
 
 ```bash
 gh pr create \
@@ -132,15 +146,14 @@ gh pr create \
   --title "$PR_TITLE" \
   --body "$(cat <<'EOF'
 ## Summary
-[1-3 sentences describing what this PR does and why]
+[2-4 sentences: what this PR does, why it's needed, and the approach taken]
 
 ## Changes
-[Bullet list of key changes]
+[Bullet list of key changes, grouped by area; enough that a reviewer can map each bullet to the diff]
 
-## Testing
-- `bun run typecheck` ✅
-- `bun test` ✅
-- `bun run build` ✅
+## Verification
+**Automated:** `bun run typecheck` ✅ · `bun test` ✅ · `bun run build` ✅
+**Manual QA:** [per success criterion — the channel driven (tmux/HTTP/browser/GUI), what you observed, and the evidence artifact path]
 
 ## Related Issues
 [Link to issue if applicable]
@@ -160,19 +173,20 @@ PR_NUMBER=$(gh pr view --json number -q .number)
 
 ## Phase 3: Verification Loop
 
-This is the core of the skill. Three gates must ALL pass for the PR to be ready. The loop has no iteration cap — keep going until done. Gate ordering is intentional: CI is cheapest/fastest, review-work is most thorough, Cubic is external and asynchronous.
+This is the core of the skill. Every active gate must pass for the PR to be ready. The loop has no iteration cap — keep going until done. Gate ordering is intentional: CI is cheapest/fastest, review-work is most thorough, Cubic is external and asynchronous. Gate C (Cubic) is the one gate that can be SKIPPED rather than satisfied — only when its quota is exhausted; it is never skipped just because it found issues. A failing gate is not a patch-and-push: route back to Phase 1, where fixes get the same scope discipline and, if behavior changed, fresh manual-QA evidence before you re-enter the loop.
 
 <verify_loop>
 
 ```
 while true:
   1. Wait for CI          → Gate A
-  2. If CI fails          → read logs, fix, commit, push, continue
-  3. Run review-work      → Gate B
-  4. If review fails      → fix blocking issues, commit, push, continue
+  2. If CI fails          → back to Phase 1: read logs, fix + re-QA, commit, push, continue
+  3. Run review-work      → Gate B (the reviewer subagents)
+  4. If review fails      → back to Phase 1: fix blocking issues + re-QA, commit, push, continue
   5. Check Cubic          → Gate C
-  6. If Cubic has issues   → fix issues, commit, push, continue
-  7. All three pass       → break
+  6. If Cubic has issues   → back to Phase 1: fix + re-QA, commit, push, continue
+  7. If Cubic quota out    → record Gate C SKIPPED, stop waiting on it
+  8. All active gates pass → break
 ```
 
 ### Gate A: CI Checks
@@ -195,7 +209,7 @@ RUN_ID=$(gh run list --branch "$BRANCH_NAME" --status failure --json databaseId
 gh run view "$RUN_ID" --log-failed
 ```
 
-Read the logs, fix the issue, commit atomically, push, and re-enter the loop.
+Read the logs, then fix per the iteration discipline below.
 
 ### Gate B: review-work
 
@@ -213,7 +227,7 @@ task(
 )
 ```
 
-**On failure**: review-work reports blocking issues with specific files and line numbers. Fix each blocking issue, commit, push, and re-enter the loop from Gate A (since code changed, CI must re-run).
+**On failure**: review-work reports blocking issues with specific files and line numbers. Fix each blocking issue per the iteration discipline below.
 
 ### Gate C: Cubic Approval
 
@@ -223,45 +237,49 @@ Cubic (`cubic-dev-ai[bot]`) is an automated review bot that comments on PRs. It
 
 **Issue signal**: The comment lists issues with file-level detail.
 
+**Quota-exhausted signal**: Cubic posts a usage/quota/limit message instead of a review, or no Cubic review appears within the bounded wait below. This is the ONLY case where you skip Gate C and proceed — record it as SKIPPED in the final report, never silently. Issues are never a reason to skip.
+
 ```bash
 # Get the latest Cubic review
 CUBIC_REVIEW=$(gh api "repos/${REPO}/pulls/${PR_NUMBER}/reviews" \
   --jq '[.[] | select(.user.login == "cubic-dev-ai[bot]")] | last | .body')
 
-# Check if approved
 if echo "$CUBIC_REVIEW" | grep -q "No issues found"; then
   echo "Cubic: APPROVED"
+elif echo "$CUBIC_REVIEW" | grep -qiE "quota|usage limit|rate limit|out of (credits|reviews)|upgrade your plan"; then
+  echo "Cubic: SKIPPED (quota exhausted)"   # Gate C satisfied-by-skip; do not loop on it
 else
   echo "Cubic: ISSUES FOUND"
   echo "$CUBIC_REVIEW"
 fi
 ```
 
-**On issues**: Cubic's review body contains structured issue descriptions. Parse them, determine which are valid (some may be false positives), fix the valid ones, commit, push, re-enter from Gate A.
+**On issues**: Cubic's review body contains structured issue descriptions. Parse them, determine which are valid (some may be false positives), and fix the valid ones per the iteration discipline below.
 
 Cubic reviews are triggered automatically on PR updates. After pushing a fix, wait for the new review to appear before checking again. Use `gh api` polling with a conditional loop:
 
 ```bash
-# Wait for new Cubic review after push
+# Wait for a NEW Cubic review after push. If none arrives within the bound,
+# Cubic is out of quota (or not running) → skip Gate C rather than spin forever.
 PUSH_TIME=$(date -u +%Y-%m-%dT%H:%M:%SZ)
-while true; do
+for _ in $(seq 1 30); do
   LATEST_REVIEW_TIME=$(gh api "repos/${REPO}/pulls/${PR_NUMBER}/reviews" \
     --jq '[.[] | select(.user.login == "cubic-dev-ai[bot]")] | last | .submitted_at')
-  if [[ "$LATEST_REVIEW_TIME" > "$PUSH_TIME" ]]; then
-    break
-  fi
-  # Use gh api call itself as the delay mechanism — each call takes ~1-2s
-  # For longer waits, use: timeout 30 gh pr checks "$PR_NUMBER" --watch 2>/dev/null || true
+  [[ "$LATEST_REVIEW_TIME" > "$PUSH_TIME" ]] && break
+  timeout 20 gh pr checks "$PR_NUMBER" --watch >/dev/null 2>&1 || true  # spend the interval usefully
 done
+# Loop exhausted without a newer review → treat Gate C as SKIPPED (quota exhausted)
+[[ "$LATEST_REVIEW_TIME" > "$PUSH_TIME" ]] || echo "Cubic: SKIPPED (no review within bound — quota exhausted)"
 ```
 
 ### Iteration discipline
 
 Each iteration through the loop:
 1. Fix ONLY the issues identified by the failing gate
-2. Commit atomically (one logical fix per commit)
-3. Push
-4. Re-enter from Gate A (code changed → full re-verification)
+2. If the fix changes runtime behavior, capture fresh manual-QA evidence (Phase 1)
+3. Commit atomically (one logical fix per commit)
+4. Push
+5. Re-enter from Gate A (code changed → full re-verification)
 
 Avoid the temptation to "improve" unrelated code during fix iterations. Scope creep in the fix loop makes debugging harder and can introduce new failures.
 
@@ -271,15 +289,17 @@ Avoid the temptation to "improve" unrelated code during fix iterations. Scope cr
 
 ## Phase 4: Merge & Cleanup
 
-Once all three gates pass:
+Once all active gates pass (Cubic may be SKIPPED on quota):
 
 <merge_cleanup>
 
 ### Merge the PR
 
+Merging is the default — do it unless the user explicitly told you not to. If they opted out, skip this step and report the green, ready-to-merge PR, but STILL run the cleanup below: the worktree is removed either way.
+
 ```bash
-# Squash merge to keep history clean
-gh pr merge "$PR_NUMBER" --squash --delete-branch
+# This repository requires merge commits. Never use --squash or --rebase here.
+gh pr merge "$PR_NUMBER" --merge --delete-branch
 ```
 
 ### Sync .omo state back to main repo
@@ -310,12 +330,13 @@ git worktree prune
 Summarize what happened:
 
 ```
-## PR Merged ✅
+## PR Complete
 
 - **PR**: #{PR_NUMBER} — {PR_TITLE}
 - **Branch**: {BRANCH_NAME} → {BASE_BRANCH}
 - **Iterations**: {N} verification loops
-- **Gates passed**: CI ✅ | review-work ✅ | Cubic ✅
+- **Gates**: CI pass | review-work pass | Cubic {pass | SKIPPED (quota exhausted)}
+- **Merged**: {yes | no — left for you to merge, as requested}
 - **Worktree**: cleaned up
 ```
 
@@ -351,10 +372,13 @@ git rebase "origin/$BASE_BRANCH"
 | Violation | Why it fails | Severity |
 |-----------|-------------|----------|
 | Working in main worktree instead of isolated worktree | Pollutes user's working directory, may destroy uncommitted work | CRITICAL |
+| Committing or pushing without manual-QA evidence on disk | "Tests pass" never proves the feature works; the repo forbids it for OpenCode/Codex-touching changes | CRITICAL |
 | Pushing directly to dev/master | Bypasses review entirely | CRITICAL |
 | Skipping CI gate after code changes | review-work and Cubic may pass on stale code | CRITICAL |
+| Skipping Cubic because it found issues | Only an exhausted quota justifies a skip; real issues must be fixed and re-pushed | HIGH |
 | Fixing unrelated code during verification loop | Scope creep causes new failures | HIGH |
 | Deleting worktree on failure | User loses ability to inspect/resume | HIGH |
 | Ignoring Cubic false positives without justification | Cubic issues should be evaluated, not blindly dismissed | MEDIUM |
+| Bundling independent slices into one big PR | Atomic review dies — a 2000-line PR gets rubber-stamped, regressions hide, and one bad slice blocks all the others | HIGH |
 | Giant single commits | Harder to isolate failures, violates git-master principles | MEDIUM |
 | Not running local checks before push | Wastes CI time on obvious failures | MEDIUM |

package/README.ja.md

@@ -170,9 +170,9 @@ Read this and tell me why it's not just another boilerplate: https://raw.githubu
 |   ⚡   | **`ultrawork` / `ulw`**                                  | Both     | 一言で OK。すべてのエージェント (Ultimate) または Codex `ultrawork` コンポーネント (Light) がアクティブになり、終わるまで止まりません。                                                                                          |
 |   🚪   | **[IntentGate](https://factory.ai/news/terminal-bench)** | Ultimate | ユーザーの真の意図を分析してから分類・行動します。`search` / `analyze` / `team` / `hyperplan` をトリガー。(Light は `ulw` / `ultrawork` のみフック。)                                                                          |
 |   🔗   | **ハッシュベースの編集ツール**                           | Ultimate | `LINE#ID` のコンテンツハッシュですべての変更を検証します。stale-line エラー 0%。[oh-my-pi](https://github.com/can1357/oh-my-pi) にインスパイア。[The Harness Problem →](https://blog.can.ac/2026/02/12/the-harness-problem/) (Codex はネイティブの `apply_patch` を使用。) |
-|   🛠️   | **LSP + AST-Grep**                                       | Both     | ワークスペース単位のリネーム、ビルド前の診断、AST を考慮した書き換え。Ultimate は組み込みツールとして、Light は plugin-scoped `lsp` / `ast_grep` MCP として提供します。                                       |
+|   🛠️   | **LSP + AST-Grep**                                       | Both     | ワークスペース単位のリネーム、ビルド前の診断、AST を考慮した書き換え。LSP は MCP として、AST-Grep は共有 `ast-grep` skill と `sg` として提供します。                                       |
 |   🧠   | **バックグラウンドエージェント**                         | Ultimate | 5 人以上の専門家を並列で投入。コンテキストは軽く保ち、結果は準備ができ次第受け取ります。                                                                                                                                       |
-|   📚   | **組み込み MCP**                                         | Both     | Ultimate は Exa (Web 検索)、Context7 (公式ドキュメント)、Grep.app (GitHub 検索) をランタイム注入します。Light は plugin-scoped MCP として `ast_grep`、`grep_app`、`context7`、`git_bash`、`lsp` を提供します。                                                                                                                       |
+|   📚   | **組み込み MCP**                                         | Both     | Ultimate は Exa (Web 検索)、Context7 (公式ドキュメント)、Grep.app (GitHub 検索) をランタイム注入します。Light は plugin-scoped MCP として `grep_app`、`context7`、`git_bash`、`lsp` を提供します。                                                                                                                       |
 |   🔁   | **Ralph Loop / `/ulw-loop`**                             | Ultimate | 自己参照ループ。100% 完了するまで絶対に止まりません。                                                                                                                                                                          |
 |   ✅   | **Todo Enforcer** (Boulder)                              | Ultimate | エージェントがサボる？システムが首根っこを掴んで戻します。あなたのタスクは必ず終わります。                                                                                                                                     |
 |   💬   | **コメントチェッカー**                                   | Both     | コメントから AI 臭い無駄話を排除。両エディションで同じ `@code-yeongyu/comment-checker` バイナリが動作。                                                                                                                       |
@@ -312,7 +312,7 @@ project/
 - 必要なときに起動する組み込み MCP サーバー。
 - スコープ制限された権限。エージェントが境界を越えないようにする。
 
-組み込み: `playwright` (ブラウザ自動化)、`git-master` (atomic コミット、rebase 手術)、`frontend-ui-ux` (デザイン重視の UI)。
+組み込み: `playwright` (ブラウザ自動化)、`git-master` (atomic コミット、rebase 手術)、`frontend` (デザイン重視の UI)。
 
 独自に追加するには `.opencode/skills/*/SKILL.md` または `~/.config/opencode/skills/*/SKILL.md` に配置してください。
 

package/README.ko.md

@@ -171,9 +171,9 @@ Read this and tell me why it's not just another boilerplate: https://raw.githubu
 |   ⚡   | **`ultrawork` / `ulw`**                                  | Both     | 한 단어. 모든 에이전트(Ultimate)나 Codex `ultrawork` 컴포넌트(Light)가 켜집니다. 끝날 때까지 멈추지 않습니다.                                                                                                    |
 |   🚪   | **[IntentGate](https://factory.ai/news/terminal-bench)** | Ultimate | 분류하거나 행동하기 전에 사용자의 진짜 의도부터 분석합니다. `search` / `analyze` / `team` / `hyperplan` 트리거. (Light는 `ulw` / `ultrawork`만 hook.)                                                            |
 |   🔗   | **Hash-Anchored Edit Tool**                              | Ultimate | `LINE#ID` 콘텐츠 해시가 모든 변경을 검증합니다. 낡은 라인 에러 0건. [oh-my-pi](https://github.com/can1357/oh-my-pi)에서 영감. [The Harness Problem →](https://blog.can.ac/2026/02/12/the-harness-problem/) (Codex는 자체 `apply_patch` 사용.) |
-|   🛠️   | **LSP + AST-Grep**                                       | Both     | 워크스페이스 리네임, 빌드 전 진단, AST 기반 리라이트. Ultimate는 내장 도구로, Light는 plugin-scoped `lsp` / `ast_grep` MCP로 제공합니다.                                                     |
+|   🛠️   | **LSP + AST-Grep**                                       | Both     | 워크스페이스 리네임, 빌드 전 진단, AST 기반 리라이트. LSP는 MCP로 제공하고 AST-Grep은 공유 `ast-grep` skill과 `sg`로 제공합니다.                                                     |
 |   🧠   | **Background Agents**                                    | Ultimate | 전문가 5명 이상을 동시에 발사. 컨텍스트는 가볍게. 결과는 준비되면 도착.                                                                                                                                          |
-|   📚   | **Built-in MCPs**                                        | Both     | Ultimate는 Exa(웹 검색), Context7(공식 문서), Grep.app(GitHub 검색)를 런타임에 주입합니다. Light는 plugin-scoped MCP로 `ast_grep`, `grep_app`, `context7`, `git_bash`, `lsp`를 제공합니다.                                                                                                                   |
+|   📚   | **Built-in MCPs**                                        | Both     | Ultimate는 Exa(웹 검색), Context7(공식 문서), Grep.app(GitHub 검색)를 런타임에 주입합니다. Light는 plugin-scoped MCP로 `grep_app`, `context7`, `git_bash`, `lsp`를 제공합니다.                                                                                                                   |
 |   🔁   | **Ralph Loop / `/ulw-loop`**                             | Ultimate | 자기참조 루프. 100% 끝날 때까지 멈추지 않습니다.                                                                                                                                                                 |
 |   ✅   | **Todo Enforcer** (Boulder)                              | Ultimate | 에이전트가 놀고 있나요? 시스템이 다시 끌어옵니다. 당신의 작업은 반드시 끝납니다.                                                                                                                                |
 |   💬   | **Comment Checker**                                      | Both     | 주석에 AI 슬롭 금지. 동일한 `@code-yeongyu/comment-checker` 바이너리가 두 에디션 모두에서 동작.                                                                                                                  |
@@ -313,7 +313,7 @@ Skill은 단순 프롬프트가 아닙니다. 각 스킬은:
 - MCP 서버를 필요할 때 함께 데려오며,
 - 권한 범위가 지정되어 에이전트가 선을 넘지 않습니다.
 
-빌트인: `playwright`(브라우저 자동화), `git-master`(atomic 커밋, rebase 수술), `frontend-ui-ux`(디자인 우선 UI).
+빌트인: `playwright`(브라우저 자동화), `git-master`(atomic 커밋, rebase 수술), `frontend`(디자인 우선 UI).
 
 직접 추가하려면 `.opencode/skills/*/SKILL.md` 또는 `~/.config/opencode/skills/*/SKILL.md` 아래에 넣으세요.
 

package/README.md

@@ -114,7 +114,7 @@ Install oh-my-openagent. Type `ultrawork`. Done.
 oh-my-openagent ships in two editions of the same product:
 
 - **Ultimate Edition (omo for OpenCode)** — full omo. 11 agents, 54+ lifecycle hooks, 5 built-in MCPs, all slash commands, Team Mode, ulw-loop, ultrawork, hashline edits — everything.
-- **Light Edition (omo for Codex CLI)** — the portable components that fit Codex's plugin system: `rules`, `comment-checker`, `git-bash`, `lsp`, `ultrawork`, `ulw-loop`, `start-work-continuation`, and `telemetry`, plus plugin-scoped MCPs for `ast_grep`, `grep_app`, `context7`, `git_bash`, and `lsp`. No agent orchestration and no `team_*` tools — Codex CLI's own surface does that work.
+- **Light Edition (omo for Codex CLI)** — the portable components that fit Codex's plugin system: `rules`, `comment-checker`, `git-bash`, `lsp`, `ultrawork`, `ulw-loop`, `start-work-continuation`, and `telemetry`, plus plugin-scoped MCPs for `grep_app`, `context7`, `git_bash`, and `lsp`, and the shared `ast-grep` skill. No agent orchestration and no `team_*` tools — Codex CLI's own surface does that work.
 
 Pick the edition(s) you want.
 
@@ -360,7 +360,7 @@ Skills aren't just prompts. Each brings:
 - Embedded MCP servers, on demand.
 - Scoped permissions so agents stay in bounds.
 
-Built-ins: `playwright` (browser automation), `git-master` (atomic commits, rebase surgery), `frontend-ui-ux` (design-first UI).
+Built-ins: `playwright` (browser automation), `git-master` (atomic commits, rebase surgery), `frontend` (design-first UI).
 
 Add your own under `.opencode/skills/*/SKILL.md` or `~/.config/opencode/skills/*/SKILL.md`.
 

package/README.ru.md

@@ -169,9 +169,9 @@ Read this and tell me why it's not just another boilerplate: https://raw.githubu
 | ⚡   | **`ultrawork` / `ulw`**                                  | Both     | Одно слово. Все агенты (Ultimate) или Codex-компонент `ultrawork` (Light) активируются. Не останавливается, пока задача не выполнена.                                                                                            |
 | 🚪   | **[IntentGate](https://factory.ai/news/terminal-bench)** | Ultimate | Анализирует истинное намерение пользователя перед классификацией и действием. Триггеры `search` / `analyze` / `team` / `hyperplan`. (Light хукает только `ulw` / `ultrawork`.)                                                   |
 | 🔗   | **Инструмент правок на основе хэш-якорей**               | Ultimate | Хэш содержимого `LINE#ID` проверяет каждое изменение. Ноль ошибок с устаревшими строками. Вдохновлено [oh-my-pi](https://github.com/can1357/oh-my-pi). [The Harness Problem →](https://blog.can.ac/2026/02/12/the-harness-problem/) (Codex использует собственный `apply_patch`.) |
-| 🛠️   | **LSP + AST-Grep**                                       | Both     | Переименование в рабочем пространстве, диагностика перед сборкой, переписывание с учётом AST. Ultimate предоставляет это как встроенные инструменты, Light — как plugin-scoped MCP `lsp` / `ast_grep`.                            |
+| 🛠️   | **LSP + AST-Grep**                                       | Both     | Переименование в рабочем пространстве, диагностика перед сборкой, переписывание с учётом AST. LSP предоставляется через MCP, AST-Grep — через общий skill `ast-grep` и `sg`.                            |
 | 🧠   | **Фоновые агенты**                                       | Ultimate | Запускайте 5+ специалистов параллельно. Контекст остаётся компактным. Результаты — когда готовы.                                                                                                                                 |
-| 📚   | **Встроенные MCP**                                       | Both     | Ultimate внедряет Exa (веб-поиск), Context7 (официальная документация) и Grep.app (поиск по GitHub) во время выполнения. Light предоставляет plugin-scoped MCP: `ast_grep`, `grep_app`, `context7`, `git_bash`, `lsp`.                                                                                                     |
+| 📚   | **Встроенные MCP**                                       | Both     | Ultimate внедряет Exa (веб-поиск), Context7 (официальная документация) и Grep.app (поиск по GitHub) во время выполнения. Light предоставляет plugin-scoped MCP: `grep_app`, `context7`, `git_bash`, `lsp`.                                                                                                     |
 | 🔁   | **Ralph Loop / `/ulw-loop`**                             | Ultimate | Самореферентный цикл. Не останавливается, пока задача не выполнена на 100%.                                                                                                                                                      |
 | ✅   | **Todo Enforcer** (Boulder)                              | Ultimate | Агент завис? Система немедленно возвращает его в работу. Ваша задача будет выполнена, точка.                                                                                                                                     |
 | 💬   | **Comment Checker**                                      | Both     | Никакого AI-мусора в комментариях. Тот же бинарник `@code-yeongyu/comment-checker` работает в обеих редакциях.                                                                                                                   |
@@ -311,7 +311,7 @@ project/
 - Встроенные MCP-серверы, запускаемые по необходимости.
 - Ограниченные разрешения, чтобы агенты оставались в рамках.
 
-Встроенные: `playwright` (автоматизация браузера), `git-master` (атомарные коммиты, хирургия rebase), `frontend-ui-ux` (UI с упором на дизайн).
+Встроенные: `playwright` (автоматизация браузера), `git-master` (атомарные коммиты, хирургия rebase), `frontend` (UI с упором на дизайн).
 
 Добавьте свои в `.opencode/skills/*/SKILL.md` или `~/.config/opencode/skills/*/SKILL.md`.
 

package/README.zh-cn.md

@@ -176,9 +176,9 @@ Read this and tell me why it's not just another boilerplate: https://raw.githubu
 |   ⚡   | **`ultrawork` / `ulw`**                                         | Both     | 一键触发，所有智能体(Ultimate)或 Codex `ultrawork` 组件(Light)出动。任务完成前绝不罢休。                                                                                          |
 |   🚪   | **[IntentGate 意图门](https://factory.ai/news/terminal-bench)** | Ultimate | 真正行动前，先分析用户的真实意图。触发 `search` / `analyze` / `team` / `hyperplan`。(Light 仅 hook `ulw` / `ultrawork`。)                                                       |
 |   🔗   | **基于哈希的编辑工具**                                          | Ultimate | 每次修改都通过 `LINE#ID` 内容哈希验证、0% 错误修改。灵感来自 [oh-my-pi](https://github.com/can1357/oh-my-pi)。[The Harness Problem →](https://blog.can.ac/2026/02/12/the-harness-problem/) (Codex 使用其原生 `apply_patch`。) |
-|   🛠️   | **LSP + AST-Grep**                                              | Both     | 工作区级别的重命名、构建前诊断、基于 AST 的重写。Ultimate 以内置工具提供，Light 通过 plugin-scoped `lsp` / `ast_grep` MCP 提供。                                   |
+|   🛠️   | **LSP + AST-Grep**                                              | Both     | 工作区级别的重命名、构建前诊断、基于 AST 的重写。LSP 通过 MCP 提供，AST-Grep 通过共享 `ast-grep` skill 和 `sg` 提供。                                   |
 |   🧠   | **后台智能体**                                                  | Ultimate | 同时发射 5+ 个专家并行工作。保持上下文干净，随时获取成果。                                                                                                                      |
-|   📚   | **内置 MCP**                                                    | Both     | Ultimate 运行时注入 Exa（网络搜索）、Context7（官方文档）、Grep.app（GitHub 源码搜索）。Light 通过 plugin-scoped MCP 提供 `ast_grep`、`grep_app`、`context7`、`git_bash`、`lsp`。                                                                              |
+|   📚   | **内置 MCP**                                                    | Both     | Ultimate 运行时注入 Exa（网络搜索）、Context7（官方文档）、Grep.app（GitHub 源码搜索）。Light 通过 plugin-scoped MCP 提供 `grep_app`、`context7`、`git_bash`、`lsp`。                                                                              |
 |   🔁   | **Ralph Loop / `/ulw-loop`**                                    | Ultimate | 自我引用闭环。达不到 100% 完成度绝不停止。                                                                                                                                      |
 |   ✅   | **Todo 强制执行** (Boulder)                                     | Ultimate | Agent 想要摸鱼？系统直接揪着领子拽回来。你的任务，必须完成。                                                                                                                    |
 |   💬   | **注释审查员**                                                  | Both     | 剔除带有浓烈 AI 味的冗余注释。同一个 `@code-yeongyu/comment-checker` 二进制在两个版本中运行。                                                                                    |
@@ -318,7 +318,7 @@ Agent 会自动顺藤摸瓜加载对应的 Context，免去了你所有的手动
 - 按需加载的独立 MCP 服务器。
 - 对 Agent 能力边界的强制约束。
 
-默认内置：`playwright`（极其稳健的浏览器自动化）、`git-master`（全自动的原子级提交及 rebase 手术）、`frontend-ui-ux`（设计感拉满的 UI 实现）。
+默认内置：`playwright`（极其稳健的浏览器自动化）、`git-master`（全自动的原子级提交及 rebase 手术）、`frontend`（设计感拉满的 UI 实现）。
 
 想加你自己的？放进 `.opencode/skills/*/SKILL.md` 或者 `~/.config/opencode/skills/*/SKILL.md` 就行。