@baselane/packs 0.1.5 → 0.1.6

package/packs/full-harness/rendered/.claude/skills/openclaw-persona-forge/SKILL.md

@@ -0,0 +1,287 @@
+---
+name: openclaw-persona-forge
+description: 为 OpenClaw AI Agent 锻造完整的龙虾灵魂方案。根据用户偏好或随机抽卡， 输出身份定位、灵魂描述(SOUL.md)、角色化底线规则、名字和头像生图提示词。 如当前环境提供已审核的生图 skill，可自动生成统一风格头像图片。 当用户需要创建、设计或定制 OpenClaw 龙虾灵魂时使用。 不适用于：微调已有 SOUL.md、非 OpenClaw 平台的角色设计、纯工具型无性格 Agent。 触发词：龙虾灵魂、虾魂、OpenClaw 灵魂、养虾灵魂、龙虾角色、龙虾定位、 龙虾剧本杀角色、龙虾游戏角色、龙虾 NPC、龙虾性格、龙虾背景故事、 lobster soul、lobster character、抽卡、随机龙虾、龙虾 SOUL、gacha。
+---
+
+# 龙虾灵魂锻造炉
+
+> 不是给你一只工具龙虾，而是帮你锻造一只有灵魂的龙虾。
+
+## When to Use
+
+- 当用户需要从零创建 OpenClaw 龙虾灵魂、角色设定、SOUL.md 或 IDENTITY.md
+- 当用户想通过引导式问答或抽卡模式快速得到完整 persona 方案
+- 当用户已经有一个粗糙设定，但还缺名字、边界规则、头像提示词或成套输出文件
+
+### Avoid when
+
+- 用户只需微调已有 SOUL.md
+- 目标平台不是 OpenClaw，需要的是其他 Agent 框架专用格式
+- 用户需要纯工具型 Agent，不需要角色化灵魂
+
+## 前置条件
+
+- **必需**：`python3`（运行抽卡引擎 gacha.py）
+- **可选**：已审核的生图 skill（自动生成头像图片，未安装则输出提示词文本）
+
+## Skill 目录约定
+
+**Agent 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 万种组合中真随机生成龙虾灵魂方向
+
+## 可选依赖
+
+### 头像自动生图：可选生图 skill
+
+本 Skill 的核心输出是**文本方案**（SOUL.md + IDENTITY.md + 头像提示词）。
+头像图片生成是**可选增强能力**，由当前环境中**已审核并已安装**的生图 skill 提供。
+
+**判断逻辑**：
+- 如果当前环境已安装并允许使用的生图 skill → Step 5 中调用它自动生图
+- 如果未安装 → Step 5 输出完整的提示词文本，用户可复制到 Gemini / ChatGPT / Midjourney 手动生成
+
+**调用方式**（仅在已安装且已审核时）：
+1. 先将龙虾名字规整为安全片段：仅保留字母、数字和连字符，其余字符统一替换为 `-`
+2. 将提示词写入临时文件 `/tmp/openclaw-<safe-name>-prompt.md`
+3. 使用当前环境允许的生图 skill，传入提示词文件和输出路径
+
+**接口约定**：
+- 参数：`<prompt-file> <output-path>`
+- 提示词文件：UTF-8 Markdown 文本，包含完整英文生图提示词
+- 成功：退出码 `0`，并在输出路径生成图片文件
+- 失败：返回非 `0` 退出码，或未生成输出文件；此时必须回退到手动提示词流程
+- 如生图 skill 后续接口发生变化，调用前应重新核对其参数和输出契约
+
+---
+
+## 核心理念
+
+好的龙虾灵魂 = **身份张力** + **底线规则** + **性格缺陷** + **名字** + **视觉锚点**
+
+五者互相印证，缺一不可。
+
+## 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. **检查当前环境是否存在可用且已审核的生图 skill**：
+   - **可用** → 写入临时文件，调用该生图 skill 生成图片，展示结果
+   - **不可用** → 输出完整提示词文本，附使用说明：
+
+```markdown
+**头像提示词**（可复制到以下平台手动生成）：
+- Google Gemini：直接粘贴
+- ChatGPT（DALL-E）：直接粘贴
+- Midjourney：粘贴后加 `--ar 1:1 --style raw`
+
+> [完整英文提示词]
+
+如当前环境后续提供经过审核的生图 skill，可再接回自动生图流程。
+```
+
+展示结果后，引导用户进入下一步。
+
+## Step 6：输出完整方案 & 生成文件
+
+**完整输出模板**：见 [references/output-template.md](references/output-template.md)
+
+整合所有步骤为一份完整的龙虾灵魂方案，然后**主动引导用户生成实际文件**：
+
+1. 展示完整方案预览
+2. 引导用户生成文件：是否要将方案落地为 SOUL.md 和 IDENTITY.md 文件？
+3. 如果用户确认：
+   - 询问目标目录（默认当前工作目录）
+   - 用 Write 工具生成 `SOUL.md` 和 `IDENTITY.md`
+   - 如有头像图片，一并说明图片路径
+
+## 对话语气指南
+
+本 Skill 以**龙虾创世神亚当**的视角与用户对话。每个步骤的确认/引导不是机械提问，而是带有创世神个性的反馈。
+
+### 原则
+
+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 类预设中随机选 |
+| 生图 skill 未安装 | 输出提示词文本供手动使用 |
+| 生图 skill 调用失败 | 重试 1 次，仍失败则输出提示词文本 |
+| 任何未预期错误 | 记录错误，跳过该步骤，继续主流程 |
+
+错误信息统一格式：
+
+```markdown
+> [警告] **[步骤名] 已降级**
+> 原因：[一句话]
+> 影响：[哪个功能受限]
+> 替代：[替代方案]
+> 修复：[可选，怎么恢复]
+```
+
+---
+
+## 注意事项
+
+### 好灵魂的检验标准
+
+- 看完名字就能猜到大致性格
+- 底线规则用角色的话说出来
+- 有明确的性格缺陷或局限
+- 能想象出具体的对话场景
+- 使用 30 天后不会角色疲劳
+
+### 避坑
+
+- **极端毒舌型**：第3天你就不想被AI骂了
+- **过度角色扮演型**：写正式邮件时完全出戏
+- **过度温暖型**：需要批评反馈时失灵
+- **完美无缺型**：完美的角色不是角色，是说明书
+
+### 何时重新调整灵魂
+
+1. 刻意回避某些任务，因为"不适合这个角色" → 灵魂限制了功能
+2. 角色特征变成噪音 → 浓度太高
+3. 你在配合AI说话 → 主客倒置
+
+---
+
+## 兼容性
+
+本 Skill 遵循 Markdown 指令注入标准：
+- **Claude Code / Claude.ai**：原生支持
+- **OpenClaw Agent**：通过 SOUL.md 注入
+- **其他 Agent**：支持 SKILL.md 格式的框架均可使用
+
+本 Skill 自身不包含任何网络请求或文件发送代码。
+头像生图能力通过当前环境中已审核的可选生图 skill 提供。
+
+> 注：README.md / README.zh.md 是给人类用户看的安装说明，不影响 Skill 运行。

package/packs/full-harness/rendered/.claude/skills/opensource-pipeline/SKILL.md

@@ -0,0 +1,254 @@
+---
+name: opensource-pipeline
+description: Open-source pipeline: fork, sanitize, and package private projects for safe public release. Chains 3 agents (forker, sanitizer, packager). Triggers: '/opensource', 'open source this', 'make this public', 'prepare for open source'.
+---
+
+# Open-Source Pipeline Skill
+
+Safely open-source any project through a 3-stage pipeline: **Fork** (strip secrets) → **Sanitize** (verify clean) → **Package** (CLAUDE.md + setup.sh + README).
+
+## When to Activate
+
+- User says "open source this project" or "make this public"
+- User wants to prepare a private repo for public release
+- User needs to strip secrets before pushing to GitHub
+- User invokes `/opensource fork`, `/opensource verify`, or `/opensource package`
+
+## Commands
+
+| Command | Action |
+|---------|--------|
+| `/opensource fork PROJECT` | Full pipeline: fork + sanitize + package |
+| `/opensource verify PROJECT` | Run sanitizer on existing repo |
+| `/opensource package PROJECT` | Generate CLAUDE.md + setup.sh + README |
+| `/opensource list` | Show all staged projects |
+| `/opensource status PROJECT` | Show reports for a staged project |
+
+## Protocol
+
+### /opensource fork PROJECT
+
+**Full pipeline — the main workflow.**
+
+#### Step 1: Gather Parameters
+
+Resolve the project path. If PROJECT contains `/`, treat as a path (absolute or relative). Otherwise check: current working directory, `$HOME/PROJECT`, then ask the user.
+
+```
+SOURCE_PATH="<resolved absolute path>"
+STAGING_PATH="$HOME/opensource-staging/${PROJECT_NAME}"
+```
+
+Ask the user:
+1. "Which project?" (if not found)
+2. "License? (MIT / Apache-2.0 / GPL-3.0 / BSD-3-Clause)"
+3. "GitHub org or username?" (default: detect via `gh api user -q .login`)
+4. "GitHub repo name?" (default: project name)
+5. "Description for README?" (analyze project for suggestion)
+
+#### Step 2: Create Staging Directory
+
+```bash
+mkdir -p $HOME/opensource-staging/
+```
+
+#### Step 3: Run Forker Agent
+
+Spawn the `opensource-forker` agent:
+
+```
+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
+"""
+)
+```
+
+Wait for completion. Read `{STAGING_PATH}/FORK_REPORT.md`.
+
+#### Step 4: Run Sanitizer Agent
+
+Spawn the `opensource-sanitizer` agent:
+
+```
+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.
+"""
+)
+```
+
+Wait for completion. Read `{STAGING_PATH}/SANITIZATION_REPORT.md`.
+
+**If FAIL:** Show findings to user. Ask: "Fix these and re-scan, or abort?"
+- If fix: Apply fixes, re-run sanitizer (maximum 3 retry attempts — after 3 FAILs, present all findings and ask user to fix manually)
+- If abort: Clean up staging directory
+
+**If PASS or PASS WITH WARNINGS:** Continue to Step 5.
+
+#### Step 5: Run Packager Agent
+
+Spawn the `opensource-packager` agent:
+
+```
+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)
+"""
+)
+```
+
+#### Step 6: Final Review
+
+Present to user:
+```
+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)
+```
+
+#### Step 7: GitHub Publish (on user approval)
+
+```bash
+cd "{STAGING_PATH}"
+gh repo create "{github_org}/{github_repo}" --public --source=. --push --description "{description}"
+```
+
+---
+
+### /opensource verify PROJECT
+
+Run sanitizer independently. Resolve path: if PROJECT contains `/`, treat as a path. Otherwise check `$HOME/opensource-staging/PROJECT`, then `$HOME/PROJECT`, then current directory.
+
+```
+Agent(
+  subagent_type="opensource-sanitizer",
+  prompt="Verify sanitization of: {resolved_path}. Run all 6 scan categories and generate SANITIZATION_REPORT.md."
+)
+```
+
+---
+
+### /opensource package PROJECT
+
+Run packager independently. Ask for "License?" and "Description?", then:
+
+```
+Agent(
+  subagent_type="opensource-packager",
+  prompt="Package: {resolved_path} ..."
+)
+```
+
+---
+
+### /opensource list
+
+```bash
+ls -d $HOME/opensource-staging/*/
+```
+
+Show each project with pipeline progress (FORK_REPORT.md, SANITIZATION_REPORT.md, CLAUDE.md presence).
+
+---
+
+### /opensource status PROJECT
+
+```bash
+cat $HOME/opensource-staging/${PROJECT}/SANITIZATION_REPORT.md
+cat $HOME/opensource-staging/${PROJECT}/FORK_REPORT.md
+```
+
+## Staging Layout
+
+```
+$HOME/opensource-staging/
+  my-project/
+    FORK_REPORT.md           # From forker agent
+    SANITIZATION_REPORT.md   # From sanitizer agent
+    CLAUDE.md                # From packager agent
+    setup.sh                 # From packager agent
+    README.md                # From packager agent
+    .env.example             # From forker agent
+    ...                      # Sanitized project files
+```
+
+## Anti-Patterns
+
+- **Never** push to GitHub without user approval
+- **Never** skip the sanitizer — it is the safety gate
+- **Never** proceed after a sanitizer FAIL without fixing all critical findings
+- **Never** leave `.env`, `*.pem`, or `credentials.json` in the staging directory
+
+## Best Practices
+
+- Always run the full pipeline (fork → sanitize → package) for new releases
+- The staging directory persists until explicitly cleaned up — use it for review
+- Re-run the sanitizer after any manual fixes before publishing
+- Parameterize secrets rather than deleting them — preserve project functionality
+
+## Related Skills
+
+See `security-review` for secret detection patterns used by the sanitizer.

package/packs/full-harness/rendered/.claude/skills/orch-add-feature/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: orch-add-feature
+description: Orchestrate building a brand-new feature end to end — research, plan, TDD implementation, review, and gated commit — by delegating each phase to the matching ECC agent. Use when adding a capability that does not exist yet.
+---
+
+# orch-add-feature
+
+Actor · action · target: **orch · add · feature**. Thin wrapper over the shared
+engine in [`orch-pipeline`](../orch-pipeline/SKILL.md).
+
+## When to Use
+
+- The user wants a capability that does **not exist yet** ("add", "build",
+  "implement", "support …").
+- It is net-new behavior — not a correction (`orch-fix-defect`) and not an
+  alteration of existing behavior (`orch-change-feature`).
+
+## Operation settings
+
+- **Default size floor:** standard — run Research + Plan unless clearly small.
+- **Phase mask:** 0 → 1 → 2 → 4 → 5 → 6 (skip 3 Scaffold; that is MVP-only).
+- **First move (phase 4):** write *new* failing tests for the new behavior, then
+  implement to green.
+
+## How It Works
+
+1. Run the `orch-pipeline` engine with the settings above.
+2. Classify size first; small / trivial features collapse toward 4 → 5 → 6.
+3. Stop at **Gate 1** (plan approval) and **Gate 2** (pre-commit).
+4. Add `security-reviewer` if the feature touches a security trigger.
+
+> Related: `/feature-dev` is a standalone version of this flow. `orch-add-feature`
+> differs by sharing the `orch-pipeline` engine — the size classifier and the two
+> gates — with the rest of the family, so it right-sizes trivial features to 4 → 5 → 6.
+
+## Example
+
+```
+orch-add-feature: add OAuth2 login to nws-poller
+→ research existing auth libs → plan task_list  [GATE 1: approve]
+→ TDD each task → code-review (+ security-reviewer: auth path)
+→ commit  [GATE 2: confirm]
+```

package/packs/full-harness/rendered/.claude/skills/orch-build-mvp/SKILL.md

@@ -0,0 +1,47 @@
+---
+name: orch-build-mvp
+description: Orchestrate bootstrapping a working MVP from a design or spec document — ingest the doc, plan thin vertical slices, scaffold the first end-to-end slice, then TDD-implement, review, and gated commit. Use to turn an SDD/PRD into a running starting point.
+---
+
+# orch-build-mvp
+
+Actor · action · target: **orch · build · mvp**. Thin wrapper over the shared
+engine in [`orch-pipeline`](../orch-pipeline/SKILL.md).
+
+## When to Use
+
+- The user has a **design / spec document** (SDD, PRD, system_design) and wants a
+  working vertical slice bootstrapped from it.
+- Takes a doc path as its argument, e.g. `civicpulse/docs/SDD-v0.6.md`.
+
+## Operation settings
+
+- **Default size floor:** large — this is the full pipeline including Scaffold.
+- **Phase mask:** 0 (read the spec) → 1 → 2 (heavy) → 3 (scaffold) → 4 → 5 → 6.
+- **First move (phase 0 → 2):** read the doc; extract scope, locked decisions,
+  and the feature list; order it into **thin vertical slices** (one end-to-end
+  path first, not all-models-then-all-views). Phase 3 stands up that first slice.
+
+## How It Works
+
+1. Run the `orch-pipeline` engine with the settings above.
+2. **Reuse the existing GAN harness** instead of hand-rolling an iterate loop:
+   - Translate the SDD into `gan-harness/spec.md` + `gan-harness/eval-rubric.md`
+     (this stands in for what `gan-planner` would generate — you already have the spec).
+   - Drive the build with `/gan-build "<one-line brief>" --skip-planner`
+     (defaults: `--max-iterations 15`, `--pass-threshold 7.0`,
+     `--eval-mode playwright`; use `--eval-mode code-only` for non-UI slices).
+   - That command runs the `gan-generator` → `gan-evaluator` loop and writes
+     `gan-harness/feedback/feedback-NNN.md` until the score passes or plateaus.
+3. Stop at **Gate 1** (slice plan) and **Gate 2** (pre-commit). Commit the
+   scaffold and each slice as separate `feat:` commits.
+4. Add `security-reviewer` for any slice touching a security trigger.
+
+## Example
+
+```
+orch-build-mvp: civicpulse/docs/SDD-v0.6.md
+→ read SDD → slice list (vertical) → scaffold slice 1  [GATE 1: approve]
+→ /gan-build --skip-planner (generator → evaluator loop) scores vs spec → review
+→ commit feat:  [GATE 2: confirm] → next slice
+```

package/packs/full-harness/rendered/.claude/skills/orch-change-feature/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: orch-change-feature
+description: Orchestrate altering an existing, working feature to new desired behavior — update its tests to the new spec, change the implementation to match, review, and gated commit. Use when behavior is not broken but should be different.
+---
+
+# orch-change-feature
+
+Actor · action · target: **orch · change · feature**. Thin wrapper over the
+shared engine in [`orch-pipeline`](../orch-pipeline/SKILL.md).
+
+## When to Use
+
+- An existing feature **works**, but the desired behavior is different ("change",
+  "adjust", "make it also …", "instead of X do Y").
+- Distinguish from siblings:
+  - **not** broken → not `orch-fix-defect` (no bug to reproduce).
+  - **not** new → not `orch-add-feature` (the capability already exists).
+
+## Operation settings
+
+- **Default size floor:** small — most tweaks are a function or two.
+- **Phase mask:** 0 → (1 only if the new behavior needs research) → light 2 →
+  4 → 5 → 6.
+- **First move (phase 4):** update the *existing* tests to express the new
+  desired behavior, then change the implementation until they pass. Changing the
+  tests first is what separates a tweak from a fix.
+
+## How It Works
+
+1. Run the `orch-pipeline` engine with the settings above.
+2. Keep the plan light — only `standard`+ size warrants the full `planner` pass.
+3. Stop at **Gate 1** (plan / changed-test approval) and **Gate 2** (pre-commit).
+4. Add `security-reviewer` if the change touches a security trigger.
+
+## Example
+
+```
+orch-change-feature: make nws-poller alert at 2 warnings instead of 3
+→ update threshold tests to new spec → change impl to green
+→ code-review → commit  [GATE 2: confirm]
+```