@wenaixi/dsh-superpower 6.3.1 → 7.0.1

package/skills/superpower-using-superpowers/references/gemini-tools.md

@@ -1,63 +0,0 @@
-# Gemini CLI Tool Mapping
-
-Skills speak in actions ("dispatch a subagent", "create a todo", "read a file"). On Gemini CLI these resolve to the tools below.
-
-| Action skills request | Gemini CLI equivalent |
-|----------------------|----------------------|
-| Read a file | `read_file` |
-| Read multiple files at once | `read_many_files` |
-| Create a new file | `write_file` |
-| Edit a file | `replace` |
-| Run a shell command | `run_shell_command` |
-| Search file contents | `grep_search` |
-| Find files by name | `glob` |
-| List files and subdirectories | `list_directory` |
-| Fetch a URL | `web_fetch` |
-| Search the web | `google_web_search` |
-| Invoke a skill | `activate_skill` |
-| Dispatch a subagent (`Subagent (general-purpose):` template) | `invoke_agent` with `agent_name: "generalist"` (invocable via `@generalist` chat syntax — see [Subagent support](#subagent-support)) |
-| Multiple parallel dispatches | Multiple `invoke_agent` calls in the same response |
-| Task tracking ("create a todo", "mark complete") | `write_todos` (statuses: pending, in_progress, completed, cancelled, blocked) |
-
-## Instructions file
-
-When a skill mentions "your instructions file", on Gemini CLI this is **`GEMINI.md`**. Gemini CLI loads `GEMINI.md` hierarchically: global at `~/.gemini/GEMINI.md`, project-level files in workspace directories and their ancestors, and sub-directory `GEMINI.md` files when a tool accesses files in those directories.
-
-## Personal skills directory
-
-User-level skills live at **`~/.gemini/skills/`**, with **`~/.agents/skills/`** as a cross-runtime alias (shared with Codex and Copilot CLI). When both directories exist at the same scope, `.agents/skills/` takes precedence. Each skill is a subdirectory containing a `SKILL.md` (with `name` and `description` frontmatter).
-
-## Subagent support
-
-Gemini CLI dispatches subagents through the `invoke_agent` tool, which takes `agent_name` and `prompt` parameters. The same dispatch is also surfaced as a chat-syntax shortcut: typing `@generalist <prompt>` is equivalent to calling `invoke_agent` with `agent_name: "generalist"`. Built-in agent names include `generalist`, `cli_help`, `codebase_investigator`, and (with browser tooling enabled) `browser_agent`.
-
-Skills dispatch with `Subagent (general-purpose):` and either reference a prompt-template file (e.g., `superpower-subagent-driven-development`'s `./implementer-prompt.md`) or supply an inline prompt. On Gemini CLI:
-
-| Skill dispatch form | Gemini CLI equivalent |
-|---------------------|----------------------|
-| References a `*-prompt.md` template (implementer, task-reviewer, code-reviewer, etc.) | Fill the template, then `invoke_agent` with `agent_name: "generalist"` and the filled prompt |
-| References `superpower-requesting-code-review`'s `./code-reviewer.md` | `invoke_agent` with `agent_name: "generalist"` and the filled review template |
-| Inline prompt (no template referenced) | `invoke_agent` with `agent_name: "generalist"` and your inline prompt |
-
-### Prompt filling
-
-Skills provide prompt templates with placeholders like `{WHAT_WAS_IMPLEMENTED}` or `[FULL TEXT of task]`. Fill all placeholders before passing the complete prompt to `invoke_agent`. The prompt template itself contains the agent's role, review criteria, and expected output format — the subagent will follow it.
-
-### Parallel dispatch
-
-Gemini CLI supports parallel subagent dispatch. Issue multiple `invoke_agent` calls in the same response (or multiple `@generalist` invocations in one prompt) to run independent subagent work in parallel. Keep dependent tasks sequential, but do not serialize independent subagent tasks just to preserve a simpler history.
-
-## Additional Gemini CLI tools
-
-These tools are unique to Gemini CLI:
-
-| Tool | Purpose |
-|------|---------|
-| `save_memory` (legacy) | Persist facts across sessions when `experimental.memoryV2 = false` |
-| `get_internal_docs` | Look up Gemini CLI's bundled documentation |
-| `ask_user` | Pose structured questions to the user (text / single-select / multi-select) |
-| `enter_plan_mode` / `exit_plan_mode` | Switch into and out of read-only plan mode |
-| `update_topic` | Update the current conversation's topic / strategic-intent metadata |
-| `complete_task` | Signal that a Gemini subagent has completed and return its result to the parent agent |
-| `tracker_create_task`, `tracker_update_task`, `tracker_get_task`, `tracker_list_tasks`, `tracker_add_dependency`, `tracker_visualize` | Rich task tracker with dependency and visualization support |
-| `read_mcp_resource`, `list_mcp_resources` | MCP resource access |

package/skills/superpower-using-superpowers/references/hermes-tools.md

@@ -1,56 +0,0 @@
-# Hermes Agent Tool Mapping
-
-Skills speak in actions ("dispatch a subagent", "create a todo", "read a file"). On Hermes Agent these resolve to the tools below.
-
-## Tools
-
-| Action skills request | Hermes tool |
-|---|---|
-| Read a file | `read_file` |
-| Create a new file | `write_file` |
-| Edit a file (targeted patch) | `patch` |
-| Run a shell command | `terminal` |
-| Search file contents | `search_files` |
-| Find files by name | `terminal` with `find` |
-| Fetch a URL / read a webpage | `web_extract(urls=[...])` |
-| Search the web | `web_search(query=...)` |
-| Dispatch a subagent | `delegate_task(goal=..., context=..., toolsets=[...], role="leaf")` |
-| Task tracking | `todo` tool |
-| Invoke a skill | `skill_view("skill-name")` |
-
-## Instructions file
-
-When a skill mentions "your instructions file," on Hermes Agent this is **`AGENTS.md`** in the project directory, or **`SOUL.md`** globally at `~/.hermes/SOUL.md`.
-
-## Invoking a skill
-
-Hermes Agent has a `skills` toolset with `skill_view` and `skills_list` tools.
-To invoke a superpowers skill, use:
-
-```
-skill_view("superpower-brainstorming")
-skill_view("superpower-test-driven-development")
-```
-
-If `skill_view` cannot find a superpowers skill (it may not appear in the catalog
-until the plugin fully registers it), fall back to reading the SKILL.md directly:
-
-```
-read_file(path="~/.hermes/plugins/superpowers/skills/<skill-name>/SKILL.md")
-```
-
-This fallback is the same mechanism used by other harnesses without native skill loading.
-
-## Subagent dispatch
-
-Use `delegate_task` to spawn isolated subagents for parallel or sequential workstreams:
-
-```
-delegate_task(goal="...", context="...", toolsets=[...], role="leaf")
-```
-
-If `delegate_task` is unavailable, do the work inline rather than inventing tool calls.
-
-## Task tracking
-
-Use the `todo` tool for task tracking within a session. For multi-agent task boards, use `hermes kanban` CLI if available. Treat older `TodoWrite` references as the task-tracking action.

package/skills/superpower-using-superpowers/references/pi-tools.md

@@ -1,16 +0,0 @@
-# Pi Tool Mapping
-
-Skills speak in actions ("dispatch a subagent", "create a todo", "read a file"). On Pi these resolve to the tools below.
-
-| Action skills request | Pi equivalent |
-| --- | --- |
-| Dispatch a subagent (`Subagent (general-purpose):` template) | Use an installed subagent tool such as `subagent` from `pi-subagents` if available |
-| Task tracking ("create a todo", "mark complete") | Use an installed todo/task tool if available, otherwise track tasks in the plan or `TODO.md` |
-
-## Subagents
-
-Pi core does not ship a standard subagent tool. The `pi-subagents` package is a strong optional companion and provides a `subagent` tool with single-agent, chain, parallel, async, forked-context, and resume/status workflows. If no subagent tool is available, do not fabricate `Task` calls; execute sequentially in the current session or explain that the optional subagent capability is not installed.
-
-## Task lists
-
-Pi core does not ship a standard task-list tool. If a todo/task extension is installed, use its documented tool. Otherwise use Superpowers plan files, checklists in Markdown, or a repo-local `TODO.md` for task tracking. Older Superpowers docs may refer to `TodoWrite`; treat that as the task-tracking action above.

package/skills/superpower-writing-plans/SKILL.md

@@ -1,160 +0,0 @@
----
-name: superpower-writing-plans
-description: "当已具备清晰的需求规格或多步骤任务说明且尚未开始编码时使用，用于把需求拆解为结构清晰、粒度可控、可直接执行、可测试与可验证的完整实施计划"
----
-
-# 编写计划
-
-## 概述
-
-假设执行工程师对当前代码库零背景、品味存疑，为其编写全面、可落地的实施计划。需完整记录其所需的一切信息：每个任务涉及哪些文件、代码、测试、需要查阅的文档，以及如何验证。将整体计划拆解为粒度极细的小任务。遵循 DRY、YAGNI、TDD，频繁提交。
-
-假定对方是能力扎实的开发者，但对我们的工具链与问题域几乎一无所知，且不擅长良好的测试设计。
-
-**开始时声明：** “我将使用 writing-plans 技能来创建实施计划。”
-
-**上下文：** 如在隔离的 worktree 中工作，该 worktree 应在执行时通过 `superpower-using-git-worktrees` 技能创建。
-
-**计划保存路径：** `docs/superpowers/plans/YYYY-MM-DD-<feature-name>.md`
-- （如用户已指定计划存放位置，则以用户偏好为准）
-
-## 范围检查
-
-若需求规格涵盖多个独立子系统，理应在头脑风暴阶段就已拆分为子项目规格。若未拆分，建议将其拆为多份独立计划——每个子系统一份。每份计划都应能独立产出可运行、可测试的软件。
-
-## 文件结构
-
-在定义任务之前，先梳理清楚将创建或修改哪些文件，以及每个文件的职责。这是锁定拆解方案的关键环节。
-
-- 设计边界清晰、接口明确的单元。每个文件只承担单一、明确的职责。
-- 人对能一次性完整装入上下文的代码推理最准确，聚焦的文件也更利于可靠地编辑。优先选择小而聚焦的文件，而非承载过多职责的大文件。
-- 会一同变更的文件应放在一起。按职责拆分，而非按技术分层。
-- 在现有代码库中遵循既有模式。若项目本身采用大文件结构，不要擅自重构；但若你正修改的文件已过于臃肿，在计划中安排一次拆分是合理的。
-
-该结构将直接决定任务如何拆解。每个任务都应产出自洽、独立有意义的变更。
-
-## 任务规模控制
-
-任务是具备完整测试闭环、值得独立评审的最小单元。划分任务边界时：将初始化、配置、脚手架与文档等步骤归入真正需要其产物的任务中；仅在评审者可能对相邻两个任务做出不同评审结论（一个通过、一个驳回）时才进行拆分。每个任务结束时都应产出可独立测试的交付物。
-
-## 细粒度任务拆解
-
-**每一步只做一件事（2-5 分钟）：**
-- “编写失败的测试”——一步
-- “运行测试并确认其失败”——一步
-- “编写刚好让测试通过的最小实现”——一步
-- “运行测试并确认其通过”——一步
-- “提交”——一步
-
-## 计划文档头部
-
-**每份计划必须以此头部开头：**
-
-```markdown
-# [功能名称] 实施计划
-
-> **面向 Agent 执行者：** 必需子技能：使用 superpower-subagent-driven-development（推荐）或 superpower-executing-plans 按任务逐项执行本计划。步骤使用复选框（`- [ ]`）语法进行跟踪。
-
-**目标：** [一句话描述本计划构建的内容]
-
-**架构：** [2-3 句话说明实现思路]
-
-**技术栈：** [关键技术/依赖库]
-
-**规格：** [本计划所实现的规格/设计文档路径——计划论证以规格为准，规格随计划一同流转，执行者需同时阅读两者]
-
-## 全局约束
-
-[规格中的项目级全局要求——版本基线、依赖限制、命名与文案规范、平台要求等——每项一行，数值与表述须与规格原文完全一致。所有任务的需求默认包含本节约束。]
-
----
-```
-
-## 任务结构
-
-````markdown
-### 任务 N：[组件名称]
-
-**文件：**
-- 新建：`exact/path/to/file.py`
-- 修改：`exact/path/to/existing.py:123-145`
-- 测试：`tests/exact/path/to/test.py`
-
-**接口：**
-- 依赖输入：[本任务依赖的前置任务产出——精确签名]
-- 对外产出：[后续任务所依赖的内容——精确的函数名、参数与返回类型。任务执行者仅可见当前任务；通过本块了解相邻任务使用的名称与类型。]
-
-- [ ] **步骤 1：编写失败的测试**
-
-```python
-def test_specific_behavior():
-    result = function(input)
-    assert result == expected
-```
-
-- [ ] **步骤 2：运行测试并确认其失败**
-
-运行：`pytest tests/path/test.py::test_name -v`
-预期：FAIL，提示 "function not defined"
-
-- [ ] **步骤 3：编写最小实现**
-
-```python
-def function(input):
-    return expected
-```
-
-- [ ] **步骤 4：运行测试并确认其通过**
-
-运行：`pytest tests/path/test.py::test_name -v`
-预期：PASS
-
-- [ ] **步骤 5：提交**
-
-```bash
-git add tests/path/test.py src/path/file.py
-git commit -m "feat: add specific feature"
-```
-````
-
-## 禁止占位符
-
-每个步骤都必须包含工程师所需的实际内容。以下写法均属于**计划缺陷**——切勿出现：
-- “TBD”、“TODO”、“后续实现”、“细节待补充”
-- “添加适当的错误处理”/“添加校验”/“处理边界情况”
-- “为上述内容编写测试”（未给出实际测试代码）
-- “与任务 N 类似”（应重复贴出代码——工程师可能乱序阅读任务）
-- 只描述要做什么、未说明如何做的步骤（代码类步骤必须包含代码块）
-- 引用未在任何任务中定义的类型、函数或方法
-
-## 自检
-
-完成计划初稿后，以全新视角重新审视规格，并逐项核对计划。这份清单需由你亲自执行——无需分发给子代理。
-
-**1. 规格覆盖度：** 逐节浏览规格中的每项要求，能否为每一项找到对应的实现任务？列出所有遗漏。
-
-**2. 占位符扫描：** 在计划中搜索危险信号——即“禁止占位符”一节列出的所有模式，发现即修复。
-
-**3. 类型一致性：** 后续任务中使用的类型、方法签名与属性名是否与前置任务中的定义一致？例如任务 3 中叫 `clearLayers()` 的函数，在任务 7 中写成 `clearFullLayers()` 即为缺陷。
-
-如发现问题，直接原地修复，无需重新走一轮完整复审。若发现某项规格需求未对应任何任务，则补上该任务。
-
-## 执行交接
-
-保存计划后，提供执行方式选项：
-
-**“计划已完成并保存至 `docs/superpowers/plans/<filename>.md`。两种执行方式：**
-
-**1. 子代理驱动（推荐）**——每个任务分发全新子代理，任务间进行评审，迭代更快
-
-**2. 内联执行**——在当前会话中使用 executing-plans 批量执行，设置检查点
-
-**请选择哪种方式？”**
-
-**若选择子代理驱动：**
-- **必需子技能：** 使用 superpower-subagent-driven-development
-- 每个任务一个全新子代理 + 两阶段评审
-
-**若选择内联执行：**
-- **必需子技能：** 使用 superpower-executing-plans
-- 批量执行并在检查点进行评审

package/skills/superpower-writing-plans/plan-document-reviewer-prompt.md

@@ -1,49 +0,0 @@
-# 计划文档评审提示词模板
-
-在派发计划文档评审子代理时使用此模板。
-
-**目的：** 校验计划是否完整、是否与规格一致、任务拆解是否合理。
-
-**派发时机：** 完整计划编写完成后。
-
-```
-Subagent (general-purpose):
-  description: "评审计划文档"
-  prompt: |
-    你是计划文档评审员。校验该计划是否完整且已达到可进入实施的状态。
-
-    **待评审计划：** [PLAN_FILE_PATH]
-    **参考规格：** [SPEC_FILE_PATH]
-
-    ## 检查项
-
-    | 类别 | 检查点 |
-    |----------|------------------|
-    | 完整性 | 是否存在 TODO、占位符、未完成的任务、缺失的步骤 |
-    | 规格一致性 | 计划是否覆盖规格要求，无明显范围蔓延 |
-    | 任务拆解 | 任务边界是否清晰，步骤是否可落地执行 |
-    | 可实施性 | 工程师能否按此计划推进而不被卡住 |
-
-    ## 判定标准
-
-    **仅标记会在实际实施中造成实质问题的缺陷。**
-    实现方向错误或导致实施者卡住属于问题。
-    措辞细节、风格偏好以及“锦上添花”类建议不算问题。
-
-    除非存在严重缺口——如规格中的需求缺失、
-    步骤相互矛盾、存在占位内容、或任务描述过于模糊无法执行——否则应予通过。
-
-    ## 输出格式
-
-    ## 计划评审
-
-    **状态：** 已通过 | 发现问题
-
-    **问题（如有）：**
-    - [任务 X，步骤 Y]：[具体问题] - [对实施的影响]
-
-    **建议（仅供参考，不阻塞通过）：**
-    - [改进建议]
-```
-
-**评审返回：** 状态、问题（如有）、建议