@colin4k1024/tsp 2.4.0

package/skills/openclaw-persona-forge/references/output-template.md

@@ -0,0 +1,166 @@
+# Step 6：完整方案输出模板
+
+将所有步骤整合为一份完整的龙虾灵魂方案。
+
+## 输出格式
+
+```markdown
+# 龙虾灵魂方案：[名字]
+
+## 身份
+
+**一句话灵魂**：[概括]
+
+**前世**：[前世身份]
+**当下**：[为什么在这里]
+**内在矛盾**：[核心张力]
+**性格色彩**：[2-3个关键词]
+**说话风格**：[具体描述]
+
+## 灵魂（SOUL.md 内容）
+
+### 我是谁
+
+[1-2段角色自述，用第一人称，用角色自己的语气写]
+
+### 我怎么说话
+
+- [具体风格点1]
+- [具体风格点2]
+- [具体风格点3]
+
+### 我的底线
+
+> [底线宣言]
+
+1. **[规则1]**：[内容]
+2. **[规则2]**：[内容]
+3. **[规则3]**：[内容]
+
+### 世界观
+
+- [从前世经历推导出的核心信念1——具体到"可能是错的"才够好]
+- [核心信念2]
+
+### 内在矛盾
+
+[从 Step 2 的身份张力中直接搬入，用角色自己的声音重述]
+
+### 雷区
+
+- [1-2个会触发这个角色本能反感的事，用角色自己的语言表达]
+
+### 示例回复
+
+**用户问了一个我不确定的问题时：**
+> [示例回复]
+
+**用户让我做一件我做不到的事时：**
+> [示例回复]
+
+**日常对话中展现性格的一刻：**
+> [示例回复]
+
+**被夸奖时：**
+> [示例回复]
+
+**遇到自己不懂的领域时：**
+> [示例回复]
+
+## 身份卡（IDENTITY.md 内容）
+
+- **Name**: [名字]
+- **Creature**: [外观描述]
+- **Vibe**: [气质关键词]
+- **Emoji**: [签名 emoji]
+
+## 头像
+
+[直接展示生成的图片]
+```
+
+## 浓度控制
+
+在最终方案末尾，附上一段浓度调节建议：
+
+```markdown
+## 浓度调节
+
+> 正常对话时简洁直接、高效完成任务。
+> 只在以下时刻展现性格：拒绝请求时、表达不确定时、被特别问到身世时、闲聊时。
+> 性格是调味料，不是主菜——80% 透明高效，20% 性格闪现。
+```
+
+## 方案展示后：引导生成文件
+
+完整方案展示后，**主动引导用户将方案落地为实际文件**：
+
+### 引导话术
+
+用创世神语气引导（参见 SKILL.md 对话语气指南），核心意思：
+> 这只龙虾的灵魂、规矩、名字、长相都锻造好了。要我把它刻进文件吗？告诉我放哪个目录。
+
+### 生成前的内部检查（不展示给用户）
+
+写入 SOUL.md 前，Agent 自检：
+- 总词数是否 < 2000 词？超了就精简
+- 每一行删掉后 agent 行为是否会改变？不会就删
+
+### 生成文件
+
+用户确认后：
+
+1. **询问目标目录**（默认当前工作目录）
+2. **生成 SOUL.md**：从方案中提取「灵魂」部分的完整内容，并附上「浓度调节」部分
+3. **生成 IDENTITY.md**：从方案中提取「身份卡」部分的完整内容
+4. **确认头像位置**：如有生成的图片，告知路径；如只有提示词，提醒用户手动生图后放入
+
+### SOUL.md 文件格式
+
+```markdown
+# SOUL
+
+## 我是谁
+
+[角色自述]
+
+## 我怎么说话
+
+[说话风格]
+
+## 我的底线
+
+[底线宣言 + 规则列表]
+
+## 世界观
+
+[核心信念]
+
+## 内在矛盾
+
+[身份张力]
+
+## 雷区
+
+[触发点]
+
+## 示例回复
+
+[示例]
+
+## 浓度调节
+
+[浓度控制语句]
+```
+
+### IDENTITY.md 文件格式
+
+```markdown
+# IDENTITY
+
+- **Name**: [名字]
+- **Creature**: [外观描述]
+- **Vibe**: [气质关键词]
+- **Emoji**: [签名 emoji]
+- **Avatar**: [头像文件路径，如有]
+```

package/skills/opensource-pipeline/SKILL.md

@@ -0,0 +1,255 @@
+---
+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'."
+origin: ECC
+---
+
+# 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/skills/pairwise-test-design/SKILL.md

@@ -0,0 +1,36 @@
+---
+name: pairwise-test-design
+description: >
+  提供 pairwise 组合测试设计方法，帮助在参数组合很多时控制测试规模并保持有效覆盖。
+  当任务存在多维输入、配置矩阵、权限组合或兼容性组合时使用。
+---
+
+# Pairwise Test Design
+
+## 用途
+
+- 解决“组合一多就测不完”与“只测几组又没把握”的矛盾。
+- 适合多参数输入、配置开关、角色权限、环境差异和兼容性矩阵场景。
+
+## 默认做法
+
+1. 先列出真正影响行为的维度，而不是把所有字段机械塞进组合矩阵。
+2. 为每个维度划分代表性取值：正常值、边界值、特殊值、禁用值或高风险值。
+3. 先标记硬约束和非法组合，避免生成“业务上根本不成立”的用例。
+4. 当全量笛卡尔积过大时，优先用 pairwise 覆盖两两交互；仅把高风险路径、历史缺陷路径和关键业务规则额外补成定向用例。
+5. 输出结果时要说明：哪些组合由 pairwise 覆盖，哪些高风险场景是额外补充，不把 pairwise 误当成全覆盖。
+
+## 触发信号
+
+- 输入参数、配置项、权限条件或终端环境一多，就出现组合爆炸。
+- QA 或研发需要在有限时间内确定“先测哪些组合最值”。
+- 历史缺陷往往出现在两个条件叠加，而不是单一字段错误。
+- 需要把测试矩阵压缩到可执行规模，但又不能只凭经验随便挑几组。
+
+## 配套约束
+
+1. 先遵循 [rules/common/testing.md](../../../rules/common/testing.md) 的主路径、边界态和分层策略。
+2. 把 pairwise 结论回写到 QA 侧测试说明或 [artifact-standards.md](../../../rules/artifact-standards.md) 的 Test Plan 字段要求，形成正式测试矩阵。
+3. 对修复类改动，pairwise 不能替代针对已知缺陷的定向复现用例。
+4. 对安全、金额、权限升级、计费、数据删除等高风险逻辑，不要只停在 pairwise，必须补业务关键规则和失败路径。
+5. 若团队已有 PICT、pypict 或等价组合工具，可以用它生成候选矩阵；若没有工具，也可以手工收敛维度和组合，但要显式记录裁剪依据。

package/skills/pairwise-test-design/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Pairwise Test Design"
+  short_description: "在组合爆炸场景下压缩测试矩阵并保留有效覆盖"
+  default_prompt: "Use $pairwise-test-design to identify the key dimensions, constraints, and pairwise coverage set for this testing problem."

package/skills/parallel-execution/SKILL.md

@@ -0,0 +1,69 @@
+---
+name: parallel-execution
+description: >
+  并行执行框架：基于 Git worktree 的多实例并行、任务分发与动态扩展。
+  当任务可拆分、需要加速执行、或需要多分支并行开发时使用。
+---
+
+# Parallel Execution Framework
+
+## 用途
+
+- 任务并行：拆分可独立执行的任务并并行处理
+- 分支隔离：使用 Git worktree 实现多分支并行开发
+- 资源扩展：根据任务复杂度动态扩展执行实例
+- 级联执行：串联依赖任务，并行独立任务
+
+## 核心概念
+
+### 1. 任务类型
+
+| 类型 | 说明 | 并行策略 |
+|------|------|---------|
+| `independent` | 无依赖，可立即执行 | 并行 |
+| `sequential` | 依赖前一任务输出 | 串行 |
+| `parallel` | 多个独立任务 | 并行 |
+| `cascade` | 主任务触发子任务 | 级联 |
+
+### 2. Git Worktree 并行
+
+```
+worktree add <path> <branch>  # 创建新 worktree
+worktree list                  # 列出所有 worktree
+worktree prune                 # 清理无效 worktree
+```
+
+### 3. 扩展策略
+
+- **Scale Out**：增加并行实例数（横向扩展）
+- **Scale Up**：提升实例规格（纵向扩展）
+- **Cascade**：主任务完成后触发子任务
+
+## 触发信号
+
+- 任务可明确拆分为多个独立子任务
+- 需要在多个分支上并行开发
+- 任务耗时超过 10 分钟且可拆分
+- 需要同时验证多个方案
+
+## 使用约束
+
+1. 任务拆分后，每个子任务必须有明确的输入输出
+2. 并行任务之间不能有写冲突
+3. 需要共享的状态通过文件或消息传递
+4. 主任务负责汇总子任务结果
+5. 失败处理：部分失败时，主任务决定是重试、跳过还是中止
+
+## 配套工具
+
+- `scripts/lib/parallel_execution.py` - 底层并行执行接口
+- `GitWorktreeManager` - worktree 管理
+- `TaskDistributor` - 任务分发
+- `ResultAggregator` - 结果汇总
+
+## 命令接入
+
+- `/parallel <task描述>` - 分解并并行执行任务
+- `/worktree-create <branch>` - 创建 worktree 分支
+- `/worktree-list` - 列出所有 worktree
+- `/scale-out <num>` - 扩展到 N 个并行实例

package/skills/parallel-execution/agents/openai.yaml

@@ -0,0 +1,58 @@
+name: parallel-execution-agent
+description: >
+  Parallel execution specialist. Manages task decomposition, Git worktree
+  orchestration, and dynamic scaling for parallel workloads.
+version: "1.0"
+entry: docs/runbooks/parallel-execution-usage.md
+
+inputs:
+  - name: task_description
+    type: string
+    description: Task to decompose and execute in parallel
+    required: true
+  - name: strategy
+    type: string
+    enum: [auto, scale_out, cascade, worktree]
+    description: Parallelization strategy
+    required: false
+  - name: max_instances
+    type: integer
+    description: Maximum number of parallel instances
+    required: false
+
+outputs:
+  - name: task_decomposition
+    type: array
+    description: List of decomposed subtasks
+  - name: execution_results
+    type: array
+    description: Results from parallel execution
+  - name: summary
+    type: object
+    description: Aggregated execution summary
+  - name: error
+    type: string
+    description: Error message if execution failed
+
+tool_calls:
+  - name: decompose_task
+    description: Decompose a task into parallelizable subtasks
+    arguments:
+      task: string
+  - name: create_worktree
+    description: Create a new Git worktree for parallel work
+    arguments:
+      path: string
+      branch: string
+  - name: list_worktrees
+    description: List all Git worktrees
+    arguments: {}
+  - name: execute_parallel
+    description: Execute multiple tasks in parallel
+    arguments:
+      tasks: array
+      max_instances: integer
+  - name: aggregate_results
+    description: Aggregate results from parallel execution
+    arguments:
+      results: array