菜单
e2e-live スイートを継続メンテする。`plans/feat-e2e-live.md` の TODO と直近 main の動向を起点に、未実装シナリオ追加・既存修正・config 改善（webkit project, self-repair 緩和等）を 1 PR で進める skill。実行用の `/e2e-live` skill とは別物。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | make-e2e-live |
| description | e2e-live スイートを継続メンテする。`plans/feat-e2e-live.md` の TODO と直近 main の動向を起点に、未実装シナリオ追加・既存修正・config 改善（webkit project, self-repair 緩和等）を 1 PR で進める skill。実行用の `/e2e-live` skill とは別物。 |
| skill | 役割 |
|---|---|
/e2e-live | 既存スイートを 回す（QA / 回帰検出） |
/e2e-live-<category> | 既存カテゴリだけ回す |
/make-e2e-live（このskill） | 既存スイートを 育てる（未実装シナリオ追加 / 修正 / config 改善） |
「実 LLM e2e の追加実装をしたい」 と思ったらこの skill を起点にする。 巨大 PR を避けるため 1 PR = 1〜3 シナリオ or 1 config 改善 に絞ること。
最初に以下をユーザーに見せる前に自分で読む:
plans/feat-e2e-live.md の以下セクション:
plans/survey-e2e-live-test-step-and-nonce.md の以下:
test.step 化 / testInfo.title nonce 化の横展開候補（PR #1347 で L-15b にのみ適用済、 他 spec への横展開が残 TODO）# まず remote の最新を取り込む（fetch のみ、 作業ツリーは触らない）
git fetch origin main
# ローカル main が origin/main に対して何コミット遅れているか
git rev-list --count main..origin/main
0 → 既に最新。 pull は不要、 そのまま次のステップへ1 以上 → 遅れているので最新化:
git checkout main && git pull --ff-only
git log main --oneline --since="<前回 merge 日>"
/artifacts/html mount → L-01 prompt convention 更新naturalWidth > 0 の検出力低下、 緩和策が TODO 残Phase 1 の結果から、 以下ルールで 1 PR 分の着手項目を自動選定する。 確認待ちで止まらない（auto mode 親和、 ユーザーは Phase 3〜4 進行中いつでも 「やっぱり L-04 で」 と redirect 可）。
PR の規模（1 シナリオ vs 数シナリオ）はユーザー判断。 デフォルトは 1 シナリオ単位、 ユーザーが「カテゴリ別 1 つずつ採取」 や「5-6 個一気に」 と指示したらそれに従う。
plans/survey-e2e-live-test-step-and-nonce.md の test infra 横展開（test.step / nonce 化）から 1 spec。 規模が小さく副作用も spec 不変で reversible なので先に消化plans/feat-e2e-live.md の 「実装ステータス」 で未実装のうち、 重要度 S → A → B 順、 同レベル内では番号若い順で 1 つmulmoclaude の主要 plugin / 機能で「編集系 (永続化)」 と「未登録系 (リソース不在時の表示)」 は QA で繰り返し発覚しやすい弱点。 シナリオ選定時、 既存 plan に該当エントリが無ければ plan 側に追加して扱う:
issue として #1073 (audio 未登録 → play stall) / #1074 (beat 編集が消える疑い) のように既出のものは spec 化候補として最優先
着手: <項目（例: B1 webkit project 追加 / L-05 generateImage 実画像）>
理由: <選定根拠（例: PR #991 要対応かつ未実装 / B カテゴリ空のため A 最高優先度を採用）>
PR 規模: <小 / 中 / 大>
ブランチ方針: <新規 feat/e2e-live-<topic> を切る / 既存 <branch> に積む>
このログを出してから Phase 3 へ自動的に進む。 ユーザーが redirect したい場合はこのログ表示の隙間に介入できる（Phase 3 の git checkout 前で一拍置く程度の感覚で OK）。
Phase 2 で決めた 「ブランチ方針」 に従う。
git checkout main && git pull --ff-only
git checkout -b feat/e2e-live-<topic>
<topic> は内容を表す短い英語（例: l03-movie-dl, webkit-project, self-repair-guard）。 SSH passphrase が必要な環境では pull は Claude 側から動かないので、 失敗したらユーザーに依頼する。
ユーザーが 「この branch のまま」 と指示している、 もしくは Phase 2 の 「ブランチ方針」 で 「既存に積む」 を選定したケース。 何もしない（現在ブランチで Phase 4 へ）。 ただし以下のリスクをログに残す:
ユーザーが意図的にそうしている場合は問題なし。 不意に積まれていそうなら一度確認する。
既存パターンを踏襲する。 plans/feat-e2e-live.md の 「実装の詳細」 セクションが詳細仕様。
このステップを後回しにすると、 spec 内に getByText('日本語ラベル') / locator('.tw-xxxx') のような i18n / class 依存 selector が残り、 翻訳変更や Tailwind class rename で壊れる。 最初の page.locator(...) / page.click(...) を書く前に 必ず通る関門として扱う。
先に読むべき docs:
docs/ui-cheatsheet.md — 既存 testid の ASCII リファレンス。 触る surface が既にカバーされているか先に確認docs/e2e-live-testing.md — 「Writing a new e2e-live spec」 §2 が testid 命名規約（「Functional names, not positional / text-content」）手順:
data-testid を持っているかを確認（ui-cheatsheet → grep の順）:
grep -rn "data-testid" src/ | grep -i "<keyword>"
data-testid="<plugin>-<role>" を追加（kebab-case、 例: audio-play-button / image-thumbnail）top-right-button）、 文言（save-button の "Save" ラベル直訳）、 構造（first-row-cell）は NGdocs/ui-cheatsheet.md の該当 ASCII ブロックを更新（CLAUDE.md ルール）iframe[sandbox] 構造属性に依存しない（脆い）「あとでまとめて付ける」 にしないこと — spec 実装中に「ここ testid 無いな」 と気づいた時点で その場で Step 0 に戻る。
e2e-live/fixtures/live-chat.tsplaceFixtureInWorkspace(fixtureRel, workspaceRel)removeFromWorkspace(workspaceRel) を必ず finally で呼ぶartifacts/images/e2e-live-l03.png）getCurrentSessionId(page) + deleteSession(page, sessionId) を finally でframeLocator API を使う — page.evaluate + iframe.contentDocument は Vue の srcdoc 更新で古い document を返す罠toBeVisible だけでは早すぎる。 内側の特定要素を frameLocator(...).locator(...) で待つwaitForAssistantResponseComplete(page) を呼ぶ — 呼ばないと trace / video が応答途中で切れるdocs/ui-cheatsheet.md 更新 / 脆い selector 回避）docs/e2e-live-testing.md の skip 規約に従う — Claude 必須テストには per-test で test.skip(process.env.E2E_LIVE_NO_LLM === "1", ...) を付ける.github/workflows/e2e_live_no_llm.yaml の matrix.spec: への登録も併せて確認する（1 本でも fake-friendly なテストがあれば追加）const 優先、 var 禁止! 禁止 → if (x === null) throw new Error(...) で type narrowingnode:path の path.join / path.resolve、 / 直書き禁止as キャスト禁止 → type guard で narrowingfetch に try/catch + !response.ok チェックyarn format
yarn lint
yarn typecheck:e2e-live
yarn build
yarn test:e2e:live:<category> # 該当カテゴリだけ
yarn test:e2e:live:<category> は実 Claude API を叩くので、 ユーザーに yarn dev 起動済みか / 認証 OK か確認してから走らせる。
注意 — dev server の stale: yarn dev の server プロセスは tsx server/index.ts（--watch なし）で起動するため、 server/*.ts や server に取り込まれる src/utils/** の変更は再起動するまで反映されない。 git pull で main を更新した直後・branch を切り替えた直後に走らせると、 ソース上は修正済の bug が再発したように見える（実例: PR #991 後の webkit L-01 fail → 誤った issue #1015 起票、 dev 再起動だけで解消）。 走らせる前にユーザーに 「dev 再起動済か？」 を 1 回確認する。
fail trace を 再走前に rename して保存する — Playwright は outputDir を毎 run の冒頭で clean するので、 fail を見たまま再走すると trace.zip / video / screenshot / error-context.md が 永久に消える。 「もう一回走らせれば pass するかも」 で trace を捨てない。 例:
FAILED_DIR=$(ls -td test-results-live/<category>/*-<project>/ 2>/dev/null | head -1)
cp -r "$FAILED_DIR" "/tmp/e2e-live-fail-$(date +%s)"
保存してからでないと「なぜ fail したか」 を再現できない。 push してから CI で同じ症状が出ても、 ローカルの trace が無いと triage 不能。
PW report を先に見る、 source 漁りは最後 — fail の原因切り分けは playwright-report-live/<category>/index.html か trace.zip の 0-trace.network (HTTP status / response body) → 0-trace.trace (ステップとアサーション) → 失敗時 screenshot / video → error-context.md の page snapshot、 の順で見る。 これらに答えが無いことを確認してから初めて source code を grep する。 source 先行は推測ベースの triage を生み、 「環境負荷のせい」 のような根拠の無い結論に流れる。
「ホスト負荷 / dev server stale / flake」 を結論にしない — それらは可能性の一つで、 trace の HTTP status と response body を見て初めて支持される仮説。 trace を保全せずに 「load avg 高いから transient」 と決めつけるのは、 user の時間と CI の時間の両方を浪費する。 本当に flake と分かったあとも、 何回連続 pass で flake と判定したか / どの response body が決め手になったか をログに残す。
このメンテ skill では基本 片モードだけ で OK。 「両モード巡回」 は実行用 /e2e-live の責任なので、 メンテ中は手元の dev のモードで pass まで持っていけば十分。 PR で「両モードで pass 確認した」と書く必要があれば、 commit 前にユーザーに DISABLE_SANDBOX 切替を依頼する。
feat: / fix: / refactor: / docs: / chore:git add . 禁止 — 個別ファイル追加gh pr create:
/coderabbit-review skill で CodeRabbit / Sourcery / 他 bot コメントをトリアージ同 PR 内で plans/feat-e2e-live.md を更新:
これは別 PR にせず 同 PR でセットコミット。 ステータスとコードを必ず同期させる。
「実装ステータス」 表が L-01〜L-30 全 ✅（うち L-25 / L-27 は manual-l4 として docs/manual-testing.md に移動済）になったら、 この skill を保守用に縮める:
この自己改修も同 PR でコミットする。 plans 側の Status と skill 側の挙動を同時に切替えるのが合流ポイント。
mockAllApis(page) を呼ぶ — このスイートは実 LLM 経路の検証が目的、 mock すると意味がないnaturalWidth / src 属性 / download magic bytes）で見るassert(x !== null); use(x!) の non-null assertion — if (x === null) throw new Error(...) で narrowplans/feat-e2e-live.md — 設計仕様 / 実装ステータス / 内部バグ ID 対応表plans/survey-e2e-live-test-step-and-nonce.md — test.step / testInfo.title nonce の横展開調査 plan（PR #1347 で L-15b にのみ適用済）e2e-live/fixtures/live-chat.ts — 既存 helper 一覧e2e-live/tests/media.spec.ts — L-01 / L-02 の参考実装docs/ui-cheatsheet.md — testid 追加時に併せて更新docs/e2e-live-testing.md — e2e-live オーサリング規約（2 backend / fake-echo 対応表 / skip 作法、必読）CLAUDE.md — コーディングルール / git 運用 / PR フォーマットSchedule, list, edit, or remove a recurring agent task (cron / interval) in `config/scheduler/tasks.json`. Use for cross-collection digests, notifications, or any standalone recurring prompt ("毎朝7時に天気", "every weekday 8am check email", "schedule a weekly cleanup"), or to list/stop automations. EXCEPTION — do NOT create a task here to keep ONE collection's records fresh (e.g. "update the stock-quotes daily", "refresh these quotes every morning", "re-poll these URLs"): instead add an `ingest` block with `kind: "agent"` to THAT collection's own `schema.json` (it self-refreshes on schedule and from its Refresh button; syntax in `config/helps/collection-skills.md` → "Scheduled agent refresh"). Read this skill body in full before writing `tasks.json` — the entry format is structured, not free-form.
Turn MulmoClaude work into a Zenn tech article (markdown) inside the workspace. On first use it sets up a Zenn project at `github/zenn/` — clone an existing GitHub repo or `zenn init` a fresh one, idempotent and skipped when already initialized — then writes articles to `github/zenn/articles/<slug>.md` tagged with the `MulmoClaude` topic. Use when the user says "Zenn にまとめて", "この作業を記事にして", "share this on Zenn", "Zenn 始めたい", or "Zenn のリポを用意して".
Personal recipe book — save / read / update / delete cooking recipes as markdown files under `data/cooking/recipes/`, with a `README.md` index that lists every recipe. Use when the user asks to remember a recipe, look one up, or refine one.
Personal book journal — track books the user wants to read or has read, prompt for impressions when they finish one, capture their words verbatim, and surface earlier reactions when they want to recall what they thought about a topic.
Save, edit, list, or delete a Claude Code skill in this workspace. Use when the user wants to turn a workflow into a reusable skill ("skill 化して", "save this as a skill"), modify or remove one, or list what's registered. Writes one markdown file per skill at `data/skills/<slug>/SKILL.md`; a workspace-side hook mirrors it into `.claude/skills/<slug>/SKILL.md` so Claude Code picks it up.
On-demand LLM-driven wiki review — find contradictions between pages, stale claims, and missing concepts (topics mentioned in index.md / log.md / sources but not yet captured as their own page). Read-only — never modifies the wiki. Use when the user asks to "review the wiki", "find contradictions", "what's stale in the wiki", or "what's missing". Sister of mc-wiki-health-check (structural lint).