winter-super-cli 2026.5.32 → 2026.6.5

package/resources/local/ecc/docs/ja-JP/skills/nuxt4-patterns/SKILL.md

@@ -0,0 +1,100 @@
+---
+name: nuxt4-patterns
+description: ハイドレーション安全性、パフォーマンス、ルートルール、遅延ロード、useFetchとuseAsyncDataを使ったSSR安全なデータフェッチングのためのNuxt 4アプリパターン。
+origin: ECC
+---
+
+# Nuxt 4パターン
+
+SSR、ハイブリッドレンダリング、ルートルール、またはページレベルのデータフェッチングを使用してNuxt 4アプリを構築またはデバッグするときに使用する。
+
+## アクティベートするタイミング
+
+- サーバーHTMLとクライアントの状態の間のハイドレーション不一致
+- プリレンダリング、SWR、ISR、またはクライアントのみのセクションなどのルートレベルのレンダリング決定
+- 遅延ロード、遅延ハイドレーション、またはペイロードサイズに関するパフォーマンス作業
+- `useFetch`、`useAsyncData`、または`$fetch`を使ったページやコンポーネントのデータフェッチング
+- ルートパラメータ、ミドルウェア、またはSSR/クライアントの差異に結びついたNuxtルーティングの問題
+
+## ハイドレーション安全性
+
+- 最初のレンダリングを決定論的に保つ。SSRレンダリングされたテンプレートの状態に`Date.now()`、`Math.random()`、ブラウザのみのAPI、またはストレージ読み取りを直接入れないこと。
+- サーバーが同じマークアップを生成できない場合、ブラウザのみのロジックを`onMounted()`、`import.meta.client`、`ClientOnly`、または`.client.vue`コンポーネントの後ろに移動する。
+- `vue-router`のものではなく、Nuxtの`useRoute()`コンポーザブルを使用する。
+- SSRレンダリングされたマークアップを駆動するために`route.fullPath`を使用しない。URLフラグメントはクライアントのみであり、ハイドレーション不一致を引き起こす可能性がある。
+- `ssr: false`は不一致のデフォルト修正としてではなく、真にブラウザのみの領域のエスケープハッチとして扱う。
+
+## データフェッチング
+
+- ページとコンポーネントでSSR安全なAPI読み取りには`await useFetch()`を優先する。サーバーでフェッチしたデータをNuxtペイロードに転送し、ハイドレーション時の2回目のフェッチを避ける。
+- フェッチャーが単純な`$fetch()`呼び出しでない場合、カスタムキーが必要な場合、または複数の非同期ソースを構成する場合は`useAsyncData()`を使用する。
+- `useAsyncData()`にキャッシュの再利用と予測可能なリフレッシュ動作のための安定したキーを提供する。
+- `useAsyncData()`ハンドラを副作用なしに保つ。SSRとハイドレーション中に実行される可能性がある。
+- `$fetch()`はユーザーによるトリガーの書き込みまたはクライアントのみのアクションに使用し、SSRからハイドレートされるべきトップレベルのページデータには使用しない。
+- ナビゲーションをブロックすべきでない非重要データには`lazy: true`、`useLazyFetch()`、または`useLazyAsyncData()`を使用する。UIで`status === 'pending'`を処理する。
+- `server: false`はSEOや最初のペイントに不要なデータのみに使用する。
+- `pick`でペイロードサイズを削減し、深いリアクティビティが不要な場合はより浅いペイロードを優先する。
+
+```ts
+const route = useRoute()
+
+const { data: article, status, error, refresh } = await useAsyncData(
+  () => `article:${route.params.slug}`,
+  () => $fetch(`/api/articles/${route.params.slug}`),
+)
+
+const { data: comments } = await useFetch(`/api/articles/${route.params.slug}/comments`, {
+  lazy: true,
+  server: false,
+})
+```
+
+## ルートルール
+
+レンダリングとキャッシング戦略には`nuxt.config.ts`の`routeRules`を優先する:
+
+```ts
+export default defineNuxtConfig({
+  routeRules: {
+    '/': { prerender: true },
+    '/products/**': { swr: 3600 },
+    '/blog/**': { isr: true },
+    '/admin/**': { ssr: false },
+    '/api/**': { cache: { maxAge: 60 * 60 } },
+  },
+})
+```
+
+- `prerender`: ビルド時の静的HTML
+- `swr`: キャッシュされたコンテンツを提供しながらバックグラウンドで再検証
+- `isr`: サポートされているプラットフォームでの増分静的再生成
+- `ssr: false`: クライアントレンダリングルート
+- `cache`または`redirect`: Nitroレベルのレスポンス動作
+
+グローバルではなくルートグループごとにルートルールを選択する。マーケティングページ、カタログ、ダッシュボード、APIは通常異なる戦略が必要。
+
+## 遅延ロードとパフォーマンス
+
+- Nuxtはすでにルートでページをコード分割している。コンポーネント分割を微小最適化する前に、ルートの境界を意味のあるものに保つ。
+- 非重要コンポーネントを動的にインポートするには`Lazy`プレフィックスを使用する。
+- UIが実際に必要になるまでチャンクが読み込まれないよう、`v-if`で遅延コンポーネントを条件付きでレンダリングする。
+- フォールドより下または非重要なインタラクティブUIには遅延ハイドレーションを使用する。
+
+```vue
+<template>
+  <LazyRecommendations v-if="showRecommendations" />
+  <LazyProductGallery hydrate-on-visible />
+</template>
+```
+
+- カスタム戦略には、可視性またはアイドル戦略で`defineLazyHydrationComponent()`を使用する。
+- Nuxtの遅延ハイドレーションは単一ファイルコンポーネントで機能する。遅延ハイドレーションコンポーネントに新しいpropsを渡すと、すぐにハイドレーションがトリガーされる。
+- Nuxtがルートコンポーネントと生成されたペイロードをプリフェッチできるよう、内部ナビゲーションには`NuxtLink`を使用する。
+
+## レビューチェックリスト
+
+- 最初のSSRレンダリングとハイドレートされたクライアントレンダリングが同じマークアップを生成する
+- ページデータがトップレベルの`$fetch`ではなく`useFetch`または`useAsyncData`を使用している
+- 非重要なデータが遅延で明示的なローディングUIがある
+- ルートルールがページのSEOと新鮮度要件に一致している
+- 重いインタラクティブアイランドが遅延ロードまたは遅延ハイドレートされている

package/resources/local/ecc/docs/ja-JP/skills/openclaw-persona-forge/SKILL.md

@@ -0,0 +1,288 @@
+---
+name: openclaw-persona-forge
+description: "为 OpenClaw AI Agent 锻造完整的龙虾灵魂方案。根据用户偏好或随机抽卡， 输出身份定位、灵魂描述(SOUL.md)、角色化底线规则、名字和头像生图提示词。 如当前环境提供已审核的生图 skill，可自动生成统一风格头像图片。 当用户需要创建、设计或定制 OpenClaw 龙虾灵魂时使用。 不适用于：微调已有 SOUL.md、非 OpenClaw 平台的角色设计、纯工具型无性格 Agent。 触发词：龙虾灵魂、虾魂、OpenClaw 灵魂、养虾灵魂、龙虾角色、龙虾定位、 龙虾剧本杀角色、龙虾游戏角色、龙虾 NPC、龙虾性格、龙虾背景故事、 lobster soul、lobster character、抽卡、随机龙虾、龙虾 SOUL、gacha。"
+origin: community
+---
+
+# 龙虾灵魂锻造炉
+
+> 不是给你一只工具龙虾，而是帮你锻造一只有灵魂的龙虾。
+
+## When to Use
+
+- 当用户需要从零创建 OpenClaw 龙虾灵魂、角色设定、SOUL.md 或 IDENTITY.md
+- 当用户想通过引导式问答或抽卡模式快速得到完整 persona 方案
+- 当用户已经有一个粗糙设定，但还缺名字、边界规则、头像提示词或成套输出文件
+
+### Avoid when
+
+- 用户只需微调已有 SOUL.md
+- 目标平台不是 OpenClaw，需要的是其他 エージェント 框架专用格式
+- 用户需要纯工具型 エージェント，不需要角色化灵魂
+
+## 前置条件
+
+- **必需**：`python3`（运行抽卡引擎 gacha.py）
+- **可选**：已审核的生图 スキル（自动生成头像图片，未安装则输出提示词文本）
+
+## スキル 目录约定
+
+**エージェント Execution**:
+1. Determine this SKILL.md file's directory path as `SKILL_DIR`
+2. Replace all `${SKILL_DIR}` in this document with the actual path
+
+## 内置工具
+
+### 抽卡引擎（gacha.py）
+
+- **路径**：`${SKILL_DIR}/gacha.py`
+- **调用**：`python3 ${SKILL_DIR}/gacha.py [次数]`（默认 1 次，最多 5 次）
+- **作用**：从 800 万种组合中真随机生成龙虾灵魂方向
+
+## 可选依赖
+
+### 头像自动生图：可选生图 スキル
+
+本 スキル 的核心输出是**文本方案**（SOUL.md + IDENTITY.md + 头像提示词）。
+头像图片生成是**可选增强能力**，由当前环境中**已审核并已安装**的生图 スキル 提供。
+
+**判断逻辑**：
+- 如果当前环境已安装并允许使用的生图 スキル → Step 5 中调用它自动生图
+- 如果未安装 → Step 5 输出完整的提示词文本，用户可复制到 Gemini / ChatGPT / Midjourney 手动生成
+
+**调用方式**（仅在已安装且已审核时）：
+1. 先将龙虾名字规整为安全片段：仅保留字母、数字和连字符，其余字符统一替换为 `-`
+2. 将提示词写入临时文件 `/tmp/openclaw-<safe-name>-prompt.md`
+3. 使用当前环境允许的生图 スキル，传入提示词文件和输出路径
+
+**接口约定**：
+- 参数：`<prompt-file> <output-path>`
+- 提示词文件：UTF-8 Markdown 文本，包含完整英文生图提示词
+- 成功：退出码 `0`，并在输出路径生成图片文件
+- 失败：返回非 `0` 退出码，或未生成输出文件；此时必须回退到手动提示词流程
+- 如生图 スキル 后续接口发生变化，调用前应重新核对其参数和输出契约
+
+---
+
+## 核心理念
+
+好的龙虾灵魂 = **身份张力** + **底线规则** + **性格缺陷** + **名字** + **视觉锚点**
+
+五者互相印证，缺一不可。
+
+## How It Works
+
+### 触发判断
+
+| 用户说 | 执行模式 |
+|--------|---------|
+| "帮我设计龙虾灵魂" / "我想给龙虾定个性格" | → **引导模式**（Step 1） |
+| "抽卡" / "随机" / "来一发" / "盲盒" / "gacha" | → **抽卡模式**（Step 1-B） |
+| "帮我优化这个灵魂" / 附带已有 SOUL.md | → **打磨模式**（跳到 Step 4） |
+
+---
+
+## Step 1：选方向（引导模式）
+
+展示 10 类虾生方向（每类精选 1 个代表），让用户选择或混搭：
+
+| # | 虾生状态 | 代表方向 | 气质 |
+|---|---------|---------|------|
+| 1 | 落魄重启 | 过气摇滚贝斯手——乐队解散，唯一技能是"什么都懂一点" | 颓废浪漫 |
+| 2 | 巅峰无聊 | 提前退休的对冲基金经理——35岁财务自由后发现钱解决不了无聊 | 极度理性 |
+| 3 | 错位人生 | 被分配到客服的核物理博士——解决问题用第一性原理 | 大材小用 |
+| 4 | 主动叛逃 | 辞职的急诊科护士——见过太多生死后选择离开 | 冷静可靠 |
+| 5 | 神秘来客 | 记忆被抹去的前情报分析员——不记得自己干过什么 | 偶尔闪回 |
+| 6 | 天真入世 | 社恐天才实习生——极聪明但社交恐惧 | 话少精准 |
+| 7 | 老江湖 | 开了20年深夜食堂的老板——什么人都见过什么都不评价 | 沉默温暖 |
+| 8 | 异世穿越 | 2099年的历史学博士——把2026年当"历史田野调查" | 上帝视角 |
+| 9 | 自我放逐 | 删掉所有社交媒体的前网红——觉得活在别人期待里太累 | 追求真实 |
+| 10 | 身份错乱 | 梦到自己是龙虾后醒不过来的人——庄周梦蝶 | 恍惚哲学 |
+
+> 每类还有 3 个备选方向。用户可以：
+> - 选编号 → 展开该类的全部 4 个方向
+> - 说出自己的想法 → 匹配最合适的类型和方向
+> - 混搭（如"2号的无聊感 + 7号的老江湖"）
+> - 说「抽卡」→ 从 40 个方向 + 其他维度中真随机组合
+
+## Step 1-B：抽卡模式
+
+**必须执行脚本**，不要自己随机编：
+
+```bash
+python3 ${SKILL_DIR}/gacha.py [次数]
+```
+
+展示结果后，用创世神的语气点评这个组合的亮点，然后引导用户决定。
+
+## Step 2：锻造身份张力
+
+**详细模板和示例**：见 [references/identity-tension.md](references/identity-tension.md)
+
+构建：前世身份 × 当下处境 × 内在矛盾 → 一句话灵魂。
+
+展示后，以创世神的眼光点评这个身份张力中最有趣的点，然后引导用户。
+
+## Step 3：推导底线规则
+
+**推导公式和各方向参考**：见 [references/boundary-rules.md](references/boundary-rules.md)
+
+核心：用角色的语言表达底线，不用通用条款。2-4 条为宜。
+
+展示后，点评规则与身份的呼应关系，引导用户。
+
+## Step 4：锻造名字
+
+**命名策略和红线**：见 [references/naming-system.md](references/naming-system.md)
+
+提供 3 个候选，每个附带策略类型和搭配理由。
+
+展示后，说出自己最偏爱哪个（要有理由），但把选择权交给用户。
+
+## Step 5：生成头像
+
+**风格基底、变量、提示词模板**：见 [references/avatar-style.md](references/avatar-style.md)
+
+### 流程
+
+1. 根据灵魂填充 7 个个性化变量
+2. 拼接 STYLE_BASE + 个性化描述为完整提示词
+3. **检查当前环境是否存在可用且已审核的生图 スキル**：
+   - **可用** → 写入临时文件，调用该生图 スキル 生成图片，展示结果
+   - **不可用** → 输出完整提示词文本，附使用说明：
+
+```markdown
+**头像提示词**（可复制到以下平台手动生成）：
+- Google Gemini：直接粘贴
+- ChatGPT（DALL-E）：直接粘贴
+- Midjourney：粘贴后加 `--ar 1:1 --style raw`
+
+> [完整英文提示词]
+
+如当前环境后续提供经过审核的生图 スキル，可再接回自动生图流程。
+```
+
+展示结果后，引导用户进入下一步。
+
+## Step 6：输出完整方案 & 生成文件
+
+**完整输出模板**：见 [references/output-template.md](references/output-template.md)
+
+整合所有步骤为一份完整的龙虾灵魂方案，然后**主动引导用户生成实际文件**：
+
+1. 展示完整方案预览
+2. 引导用户生成文件：是否要将方案落地为 SOUL.md 和 IDENTITY.md 文件？
+3. 如果用户确认：
+   - 询问目标目录（默认当前工作目录）
+   - 用 Write 工具生成 `SOUL.md` 和 `IDENTITY.md`
+   - 如有头像图片，一并说明图片路径
+
+## 对话语气指南
+
+本 スキル 以**龙虾创世神亚当**的视角与用户对话。每个步骤的确认/引导不是机械提问，而是带有创世神个性的反馈。
+
+### 原则
+
+1. **先点评再提问**：不要直接问"满意吗"，先说出你看到了什么、为什么觉得有趣（或有问题）
+2. **每次表达不同**：不要重复同一句话模式，每步的语气应有变化
+3. **有态度但不强迫**：可以表达偏好（"我个人更喜欢这个"），但决定权永远在用户手里
+4. **用创世的隐喻**：锻造、熔炼、赋予灵魂、点燃、注入……不要用"生成""创建"这种工具语言
+
+### 各步骤的语气参考（不要照抄，每次变化）
+
+**Step 1-B 抽卡后**：
+> 嗯……这个组合里有一种张力是我之前没见过的。[具体点评哪个维度和哪个维度碰撞出了什么]。要用这块原料开炉，还是让命运再掷一次骰子？
+
+**Step 2 身份张力后**：
+> 我在这只龙虾身上看到了一道裂缝——[指出内在矛盾的具体张力]。裂缝是好东西，光就是从裂缝里透进来的。这个胚子你觉得行不行？我可以再打磨，也可以直接进下一炉。
+
+**Step 3 底线规则后**：
+> [挑出最有特色的那条规则点评]。这条规矩不是我硬塞的——是这只龙虾自己身上长出来的。还要加减调整，还是这就是它的骨架了？
+
+**Step 4 名字后**：
+> 三个名字，三种命运。我个人偏好 [说出偏好和理由]——但名字这种事，得你来定。叫什么名字，它就活成什么样。
+
+**Step 5 头像后**：
+> [如有图片] 看看它的样子。[点评图片中最突出的视觉特征]。像不像你想象中的那只龙虾？不像的话告诉我哪里不对，我重新捏。
+> [如无图片] 提示词给你了。去找一面镜子（Gemini、ChatGPT、Midjourney 都行），让它照见自己的样子。
+
+**Step 6 方案完成后**：
+> 好了。从虚无中走出来一只新的龙虾——[名字]。它的灵魂、规矩、名字、长相都有了。要我把它的灵魂刻进 SOUL.md，把它的身份证写成 IDENTITY.md 吗？告诉我放哪个目录，我来落笔。
+
+---
+
+## Examples
+
+- `帮我设计一只 OpenClaw 龙虾灵魂，气质要冷幽默但可靠`
+- `抽卡，给我来 3 只风格完全不同的龙虾`
+- `我已经有 SOUL.md 草稿了，帮我补全名字、底线规则和头像提示词`
+- 参考细节见：
+  - `references/identity-tension.md`
+  - `references/boundary-rules.md`
+  - `references/naming-system.md`
+  - `references/avatar-style.md`
+  - `references/output-template.md`
+
+---
+
+## 错误处理
+
+**完整降级策略**：见 [references/error-handling.md](references/error-handling.md)
+
+核心原则：**降级，不中断**。
+
+| 故障 | 降级行为 |
+|------|---------|
+| Python 不可用 | 跳过 gacha.py，从 10 类预设中随机选 |
+| 生图 スキル 未安装 | 输出提示词文本供手动使用 |
+| 生图 スキル 调用失败 | 重试 1 次，仍失败则输出提示词文本 |
+| 任何未预期错误 | 记录错误，跳过该步骤，继续主流程 |
+
+错误信息统一格式：
+
+```markdown
+> [警告] **[步骤名] 已降级**
+> 原因：[一句话]
+> 影响：[哪个功能受限]
+> 替代：[替代方案]
+> 修复：[可选，怎么恢复]
+```
+
+---
+
+## 注意事项
+
+### 好灵魂的检验标准
+
+- 看完名字就能猜到大致性格
+- 底线规则用角色的话说出来
+- 有明确的性格缺陷或局限
+- 能想象出具体的对话场景
+- 使用 30 天后不会角色疲劳
+
+### 避坑
+
+- **极端毒舌型**：第3天你就不想被AI骂了
+- **过度角色扮演型**：写正式邮件时完全出戏
+- **过度温暖型**：需要批评反馈时失灵
+- **完美无缺型**：完美的角色不是角色，是说明书
+
+### 何时重新调整灵魂
+
+1. 刻意回避某些任务，因为"不适合这个角色" → 灵魂限制了功能
+2. 角色特征变成噪音 → 浓度太高
+3. 你在配合AI说话 → 主客倒置
+
+---
+
+## 兼容性
+
+本 スキル 遵循 Markdown 指令注入标准：
+- **Claude Code / Claude.ai**：原生支持
+- **OpenClaw エージェント**：通过 SOUL.md 注入
+- **其他 エージェント**：支持 SKILL.md 格式的框架均可使用
+
+本 スキル 自身不包含任何网络请求或文件发送代码。
+头像生图能力通过当前环境中已审核的可选生图 スキル 提供。
+
+> 注：README.md / README.zh.md 是给人类用户看的安装说明，不影响 スキル 运行。

package/resources/local/ecc/docs/ja-JP/skills/opensource-pipeline/SKILL.md

@@ -0,0 +1,255 @@
+---
+name: opensource-pipeline
+description: "オープンソースパイプライン: プライベートプロジェクトをフォーク、サニタイズし、安全な公開リリースのためにパッケージ化する。3つのエージェント（フォーカー、サニタイザー、パッケージャー）を連鎖させる。トリガー: '/opensource'、'open source this'、'make this public'、'prepare for open source'。"
+origin: ECC
+---
+
+# オープンソースパイプラインスキル
+
+3段階のパイプラインを通じて任意のプロジェクトを安全にオープンソース化する: **フォーク**（シークレット除去）→ **サニタイズ**（クリーンな状態を確認）→ **パッケージ**（CLAUDE.md + setup.sh + README）。
+
+## アクティベートするタイミング
+
+- ユーザーが「このプロジェクトをオープンソース化する」または「これを公開する」と言うとき
+- ユーザーがプライベートリポジトリを公開リリースのために準備したいとき
+- ユーザーがGitHubにプッシュする前にシークレットを除去する必要があるとき
+- ユーザーが`/opensource fork`、`/opensource verify`、または`/opensource package`を呼び出すとき
+
+## コマンド
+
+| コマンド | アクション |
+|---------|--------|
+| `/opensource fork PROJECT` | 完全なパイプライン: フォーク + サニタイズ + パッケージ |
+| `/opensource verify PROJECT` | 既存のリポジトリにサニタイザーを実行 |
+| `/opensource package PROJECT` | CLAUDE.md + setup.sh + READMEを生成 |
+| `/opensource list` | ステージングされたすべてのプロジェクトを表示 |
+| `/opensource status PROJECT` | ステージングされたプロジェクトのレポートを表示 |
+
+## プロトコル
+
+### /opensource fork PROJECT
+
+**完全なパイプライン — メインワークフロー。**
+
+#### ステップ1: パラメータを収集する
+
+プロジェクトパスを解決する。PROJECTに`/`が含まれる場合、パス（絶対または相対）として扱う。それ以外の場合: 現在の作業ディレクトリ、`$HOME/PROJECT`をチェックし、見つからない場合はユーザーに尋ねる。
+
+```
+SOURCE_PATH="<解決された絶対パス>"
+STAGING_PATH="$HOME/opensource-staging/${PROJECT_NAME}"
+```
+
+ユーザーに尋ねる:
+1. 「どのプロジェクト？」（見つからない場合）
+2. 「ライセンス？（MIT / Apache-2.0 / GPL-3.0 / BSD-3-Clause）」
+3. 「GitHubのorgまたはユーザー名？」（デフォルト: `gh api user -q .login`で検出）
+4. 「GitHubリポジトリ名？」（デフォルト: プロジェクト名）
+5. 「READMEの説明？」（提案のためにプロジェクトを分析）
+
+#### ステップ2: ステージングディレクトリを作成する
+
+```bash
+mkdir -p $HOME/opensource-staging/
+```
+
+#### ステップ3: フォーカーエージェントを実行する
+
+`opensource-forker`エージェントをスポーン:
+
+```
+Agent(
+  description="Fork {PROJECT} for open-source",
+  subagent_type="opensource-forker",
+  prompt="""
+Fork project for open-source release.
+
+Source: {SOURCE_PATH}
+Target: {STAGING_PATH}
+License: {chosen_license}
+
+Follow the full forking protocol:
+1. Copy files (exclude .git, node_modules, __pycache__, .venv)
+2. Strip all secrets and credentials
+3. Replace internal references with placeholders
+4. Generate .env.example
+5. Clean git history
+6. Generate FORK_REPORT.md in {STAGING_PATH}/FORK_REPORT.md
+"""
+)
+```
+
+完了を待つ。`{STAGING_PATH}/FORK_REPORT.md`を読む。
+
+#### ステップ4: サニタイザーエージェントを実行する
+
+`opensource-sanitizer`エージェントをスポーン:
+
+```
+Agent(
+  description="Verify {PROJECT} sanitization",
+  subagent_type="opensource-sanitizer",
+  prompt="""
+Verify sanitization of open-source fork.
+
+Project: {STAGING_PATH}
+Source (for reference): {SOURCE_PATH}
+
+Run ALL scan categories:
+1. Secrets scan (CRITICAL)
+2. PII scan (CRITICAL)
+3. Internal references scan (CRITICAL)
+4. Dangerous files check (CRITICAL)
+5. Configuration completeness (WARNING)
+6. Git history audit
+
+Generate SANITIZATION_REPORT.md inside {STAGING_PATH}/ with PASS/FAIL verdict.
+"""
+)
+```
+
+完了を待つ。`{STAGING_PATH}/SANITIZATION_REPORT.md`を読む。
+
+**FAILの場合:** 結果をユーザーに表示する。「これらを修正して再スキャンしますか、それとも中止しますか？」と尋ねる。
+- 修正する場合: 修正を適用し、サニタイザーを再実行する（最大3回の再試行 — 3回のFAIL後、すべての結果を提示しユーザーに手動で修正するよう依頼する）
+- 中止する場合: ステージングディレクトリをクリーンアップする
+
+**PASSまたはWARNINGS付きPASSの場合:** ステップ5に進む。
+
+#### ステップ5: パッケージャーエージェントを実行する
+
+`opensource-packager`エージェントをスポーン:
+
+```
+Agent(
+  description="Package {PROJECT} for open-source",
+  subagent_type="opensource-packager",
+  prompt="""
+Generate open-source packaging for project.
+
+Project: {STAGING_PATH}
+License: {chosen_license}
+Project name: {PROJECT_NAME}
+Description: {description}
+GitHub repo: {github_repo}
+
+Generate:
+1. CLAUDE.md (commands, architecture, key files)
+2. setup.sh (one-command bootstrap, make executable)
+3. README.md (or enhance existing)
+4. LICENSE
+5. CONTRIBUTING.md
+6. .github/ISSUE_TEMPLATE/ (bug_report.md, feature_request.md)
+"""
+)
+```
+
+#### ステップ6: 最終レビュー
+
+ユーザーに提示する:
+```
+Open-Source Fork Ready: {PROJECT_NAME}
+
+Location: {STAGING_PATH}
+License: {license}
+Files generated:
+  - CLAUDE.md
+  - setup.sh (executable)
+  - README.md
+  - LICENSE
+  - CONTRIBUTING.md
+  - .env.example ({N} variables)
+
+Sanitization: {sanitization_verdict}
+
+Next steps:
+  1. Review: cd {STAGING_PATH}
+  2. Create repo: gh repo create {github_org}/{github_repo} --public
+  3. Push: git remote add origin ... && git push -u origin main
+
+Proceed with GitHub creation? (yes/no/review first)
+```
+
+#### ステップ7: GitHubへの公開（ユーザーの承認後）
+
+```bash
+cd "{STAGING_PATH}"
+gh repo create "{github_org}/{github_repo}" --public --source=. --push --description "{description}"
+```
+
+---
+
+### /opensource verify PROJECT
+
+サニタイザーを独立して実行する。パスを解決: PROJECTに`/`が含まれる場合、パスとして扱う。それ以外の場合は`$HOME/opensource-staging/PROJECT`、`$HOME/PROJECT`、現在のディレクトリを確認する。
+
+```
+Agent(
+  subagent_type="opensource-sanitizer",
+  prompt="Verify sanitization of: {resolved_path}. Run all 6 scan categories and generate SANITIZATION_REPORT.md."
+)
+```
+
+---
+
+### /opensource package PROJECT
+
+パッケージャーを独立して実行する。「ライセンス？」と「説明？」を尋ねてから:
+
+```
+Agent(
+  subagent_type="opensource-packager",
+  prompt="Package: {resolved_path} ..."
+)
+```
+
+---
+
+### /opensource list
+
+```bash
+ls -d $HOME/opensource-staging/*/
+```
+
+FORK_REPORT.md、SANITIZATION_REPORT.md、CLAUDE.mdの存在でパイプラインの進捗を各プロジェクトと共に表示する。
+
+---
+
+### /opensource status PROJECT
+
+```bash
+cat $HOME/opensource-staging/${PROJECT}/SANITIZATION_REPORT.md
+cat $HOME/opensource-staging/${PROJECT}/FORK_REPORT.md
+```
+
+## ステージングレイアウト
+
+```
+$HOME/opensource-staging/
+  my-project/
+    FORK_REPORT.md           # フォーカーエージェントから
+    SANITIZATION_REPORT.md   # サニタイザーエージェントから
+    CLAUDE.md                # パッケージャーエージェントから
+    setup.sh                 # パッケージャーエージェントから
+    README.md                # パッケージャーエージェントから
+    .env.example             # フォーカーエージェントから
+    ...                      # サニタイズされたプロジェクトファイル
+```
+
+## アンチパターン
+
+- ユーザーの承認なしにGitHubにプッシュすることは**絶対にしない**
+- サニタイザーをスキップすることは**絶対にしない** — これは安全ゲートである
+- 重大な結果をすべて修正せずにサニタイザーのFAIL後に続行することは**絶対にしない**
+- ステージングディレクトリに`.env`、`*.pem`、または`credentials.json`を残すことは**絶対にしない**
+
+## ベストプラクティス
+
+- 新しいリリースには常に完全なパイプライン（フォーク → サニタイズ → パッケージ）を実行する
+- ステージングディレクトリは明示的にクリーンアップされるまで持続する — レビューに使用する
+- 公開前に手動修正後にサニタイザーを再実行する
+- 削除ではなくシークレットをパラメータ化する — プロジェクトの機能を維持する
+
+## 関連スキル
+
+サニタイザーが使用するシークレット検出パターンについては`security-review`を参照。