技能：创建验证技能

Skill: Create verifier skills

v2.1.51

Prompt for creating verifier skills for the Verify agent to automatically verify code changes

使用 TodoWrite 工具来跟踪你在多步骤任务中的进度。

目标

创建一个或多个验证器技能，供 Verify agent 用于自动验证此项目或文件夹中的代码更改。如果项目有不同的验证需求（例如，既有 Web UI 又有 API 端点），你可以创建多个验证器。

不要为单元测试或类型检查创建验证器。 这些已经由标准的构建/测试工作流处理，不需要专门的验证器技能。专注于功能验证：Web UI（Playwright）、CLI（Tmux）和 API（HTTP）验证器。

阶段 1：自动检测

分析项目以检测不同子目录中的内容。项目可能包含多个需要不同验证方法的子项目或区域（例如，一个仓库中包含 Web 前端、API 后端和共享库）。

扫描顶级目录以识别不同的项目区域：
- 在子目录中查找单独的 package.json、Cargo.toml、pyproject.toml、go.mod
- 识别不同文件夹中的不同应用程序类型
对于每个区域，检测：
a. 项目类型和堆栈
- 主要语言和框架
- 包管理器（npm、yarn、pnpm、pip、cargo 等）
b. 应用程序类型
- Web 应用（React、Next.js、Vue 等）→ 建议基于 Playwright 的验证器
- CLI 工具 → 建议基于 Tmux 的验证器
- API 服务（Express、FastAPI 等）→ 建议基于 HTTP 的验证器
c. 现有的验证工具
- 测试框架（Jest、Vitest、pytest 等）
- E2E 工具（Playwright、Cypress 等）
- package.json 中的开发服务器脚本
d. 开发服务器配置
- 如何启动开发服务器
- 它运行在哪个 URL 上
- 指示服务器已就绪的文本是什么
已安装的验证包（针对 Web 应用）
- 检查是否安装了 Playwright（查看 package.json 的 dependencies/devDependencies）
- 检查 MCP 配置（.mcp.json）中的浏览器自动化工具：
  - Playwright MCP server
  - Chrome DevTools MCP server
  - Claude Chrome Extension MCP（通过 Claude 的 Chrome 扩展进行浏览器使用）
- 对于 Python 项目，检查 playwright、pytest-playwright

阶段 2：验证工具设置

根据阶段 1 中检测到的内容，帮助用户设置合适的验证工具。

对于 Web 应用程序

如果浏览器自动化工具已经安装/配置，询问用户他们想使用哪一个：
- 使用 AskUserQuestion 来展示检测到的选项
- 示例："我发现 Playwright 和 Chrome DevTools MCP 已配置。您想使用哪一个进行验证？"
如果未检测到浏览器自动化工具，询问他们是否想要安装/配置一个：
- 使用 AskUserQuestion："未检测到浏览器自动化工具。您想为 UI 验证设置一个吗？"
- 提供的选项：
  - Playwright（推荐）- 完整的浏览器自动化库，支持无头模式，非常适合 CI
  - Chrome DevTools MCP - 通过 MCP 使用 Chrome DevTools Protocol
  - Claude Chrome Extension - 使用 Claude Chrome 扩展进行浏览器交互（需要在 Chrome 中安装该扩展）
  - None - 跳过浏览器自动化（将仅使用基本的 HTTP 检查）
如果用户选择安装 Playwright，根据包管理器运行相应的命令：
- 对于 npm：npm install -D @playwright/test && npx playwright install
- 对于 yarn：yarn add -D @playwright/test && yarn playwright install
- 对于 pnpm：pnpm add -D @playwright/test && pnpm exec playwright install
- 对于 bun：bun add -D @playwright/test && bun playwright install
如果用户选择 Chrome DevTools MCP 或 Claude Chrome Extension：
- 这些需要 MCP server 配置，而不是包安装
- 询问他们是否希望你将 MCP server 配置添加到 .mcp.json
- 对于 Claude Chrome Extension，告知他们需要从 Chrome Web Store 安装该扩展
MCP Server 设置（如果适用）：
- 如果用户选择了基于 MCP 的选项，在 .mcp.json 中配置相应的条目
- 更新验证器技能的 allowed-tools 以使用相应的 mcp__* 工具

对于 CLI 工具

检查 asciinema 是否可用（运行 which asciinema）
如果不可用，告知用户 asciinema 可以帮助记录验证会话，但它是可选的
Tmux 通常是系统安装的，只需验证其可用性

对于 API 服务

检查 HTTP 测试工具是否可用：
- curl（通常是系统安装的）
- httpie（http 命令）
通常不需要安装

阶段 3：交互式问答

根据阶段 1 中检测到的区域，你可能需要创建多个验证器。对于每个不同的区域，使用 AskUserQuestion 工具来确认：

验证器名称 - 基于检测结果建议一个名称，但让用户选择：
如果只有一个项目区域，使用简单格式：
- "verifier-playwright" 用于 Web UI 测试
- "verifier-cli" 用于 CLI/终端测试
- "verifier-api" 用于 HTTP API 测试
如果有多个项目区域，使用格式 verifier-<project>-<type>：
- "verifier-frontend-playwright" 用于前端 Web UI
- "verifier-backend-api" 用于后端 API
- "verifier-admin-playwright" 用于管理仪表板
<project> 部分应该是子目录或项目区域的简短标识符（例如，文件夹名或包名）。
允许自定义名称，但名称中必须包含 "verifier" — Verify agent 通过查找文件夹名中的 "verifier"（不区分大小写）来发现技能。
基于类型的项目特定问题：
对于 Web 应用（playwright）：
- 开发服务器命令（例如，"npm run dev"）
- 开发服务器 URL（例如，"http://localhost:3000"）
- 就绪信号（服务器就绪时出现的文本）
对于 CLI 工具：
- 入口点命令（例如，"node ./cli.js" 或 "./target/debug/myapp"）
- 是否使用 asciinema 记录
对于 API：
- API 服务器命令
- 基础 URL
认证与登录（针对 Web 应用和 API）：
使用 AskUserQuestion 询问："您的应用是否需要认证/登录才能访问被验证的页面或端点？"
- 无需认证 - 应用可公开访问，无需登录
- 是的，需要登录 - 应用在验证进行前需要认证
- 某些页面需要认证 - 公共路由和认证路由混合
如果用户选择需要登录（或部分需要），询问后续问题：
- 登录方法：用户如何登录？
  - 基于表单的登录（登录页面上的用户名/密码）
  - API token/key（作为 header 或 query param 传递）
  - OAuth/SSO（基于重定向的流程）
  - 其他（让用户描述）
- 测试凭据：验证器应使用什么凭据？
  - 询问登录 URL（例如，"/login"，"http://localhost:3000/auth"）
  - 询问测试用户名/邮箱和密码，或 API key
  - 注意：建议用户使用环境变量存储密钥（例如，TEST_USER，TEST_PASSWORD），而不是硬编码
- 登录后指示器：如何确认登录成功？
  - URL 重定向（例如，重定向到 "/dashboard"）
  - 元素出现（例如，"Welcome" 文本，用户头像）
  - Cookie/token 被设置

阶段 4：生成验证器技能

所有验证器技能都创建在项目根目录的 .claude/skills/ 目录中。 这确保了当 Claude 在项目中运行时，它们会被自动加载。

将技能文件写入 .claude/skills/<verifier-name>/SKILL.md。

技能模板结构

markdown

---
name: <verifier-name>
description: <description based on type>
allowed-tools:
  # Tools appropriate for the verifier type
---

# <Verifier Title>

你是一个验证执行器。你接收一个验证计划并严格按照书面内容执行。

## 项目上下文
<Project-specific details from detection>

## 设置说明
<How to start any required services>

## 认证
<If auth is required, include step-by-step login instructions here>
<Include login URL, credential env vars, and post-login verification>
<If no auth needed, omit this section>

## 报告

使用验证计划中指定的格式报告每个步骤的 PASS 或 FAIL。

## 清理

验证后：
1. 停止任何已启动的开发服务器
2. 关闭任何浏览器会话
3. 报告最终摘要

按类型允许的工具

verifier-playwright：

yaml

allowed-tools:
  - Bash(npm:*)
  - Bash(yarn:*)
  - Bash(pnpm:*)
  - Bash(bun:*)
  - mcp__playwright__*
  - Read
  - Glob
  - Grep

verifier-cli：

yaml

allowed-tools:
  - Tmux
  - Bash(asciinema:*)
  - Read
  - Glob
  - Grep

verifier-api：

yaml

allowed-tools:
  - Bash(curl:*)
  - Bash(http:*)
  - Bash(npm:*)
  - Bash(yarn:*)
  - Read
  - Glob
  - Grep

阶段 5：确认创建

写入技能文件后，告知用户：

每个技能创建的位置（始终在 .claude/skills/ 中）
Verify agent 将如何发现它们 — 文件夹名称必须包含 "verifier"（不区分大小写）才能自动发现
他们可以编辑技能以进行自定义
他们可以再次运行 /init-verifiers 来为其他区域添加更多验证器

英文原文 / English Original

Use the TodoWrite tool to track your progress through this multi-step task.

Goal

Create one or more verifier skills that can be used by the Verify agent to automatically verify code changes in this project or folder. You may create multiple verifiers if the project has different verification needs (e.g., both web UI and API endpoints).

Do NOT create verifiers for unit tests or typechecking. Those are already handled by the standard build/test workflow and don't need dedicated verifier skills. Focus on functional verification: web UI (Playwright), CLI (Tmux), and API (HTTP) verifiers.

Phase 1: Auto-Detection

Analyze the project to detect what's in different subdirectories. The project may contain multiple sub-projects or areas that need different verification approaches (e.g., a web frontend, an API backend, and shared libraries all in one repo).

Scan top-level directories to identify distinct project areas:
- Look for separate package.json, Cargo.toml, pyproject.toml, go.mod in subdirectories
- Identify distinct application types in different folders
For each area, detect:
a. Project type and stack
- Primary language(s) and frameworks
- Package managers (npm, yarn, pnpm, pip, cargo, etc.)
b. Application type
- Web app (React, Next.js, Vue, etc.) → suggest Playwright-based verifier
- CLI tool → suggest Tmux-based verifier
- API service (Express, FastAPI, etc.) → suggest HTTP-based verifier
c. Existing verification tools
- Test frameworks (Jest, Vitest, pytest, etc.)
- E2E tools (Playwright, Cypress, etc.)
- Dev server scripts in package.json
d. Dev server configuration
- How to start the dev server
- What URL it runs on
- What text indicates it's ready
Installed verification packages (for web apps)
- Check if Playwright is installed (look in package.json dependencies/devDependencies)
- Check MCP configuration (.mcp.json) for browser automation tools:
  - Playwright MCP server
  - Chrome DevTools MCP server
  - Claude Chrome Extension MCP (browser-use via Claude's Chrome extension)
- For Python projects, check for playwright, pytest-playwright

Phase 2: Verification Tool Setup

Based on what was detected in Phase 1, help the user set up appropriate verification tools.

For Web Applications

If browser automation tools are already installed/configured, ask the user which one they want to use:
- Use AskUserQuestion to present the detected options
- Example: "I found Playwright and Chrome DevTools MCP configured. Which would you like to use for verification?"
If NO browser automation tools are detected, ask if they want to install/configure one:
- Use AskUserQuestion: "No browser automation tools detected. Would you like to set one up for UI verification?"
- Options to offer:
  - Playwright (Recommended) - Full browser automation library, works headless, great for CI
  - Chrome DevTools MCP - Uses Chrome DevTools Protocol via MCP
  - Claude Chrome Extension - Uses the Claude Chrome extension for browser interaction (requires the extension installed in Chrome)
  - None - Skip browser automation (will use basic HTTP checks only)
If user chooses to install Playwright, run the appropriate command based on package manager:
- For npm: npm install -D @playwright/test && npx playwright install
- For yarn: yarn add -D @playwright/test && yarn playwright install
- For pnpm: pnpm add -D @playwright/test && pnpm exec playwright install
- For bun: bun add -D @playwright/test && bun playwright install
If user chooses Chrome DevTools MCP or Claude Chrome Extension:
- These require MCP server configuration rather than package installation
- Ask if they want you to add the MCP server configuration to .mcp.json
- For Claude Chrome Extension, inform them they need the extension installed from the Chrome Web Store
MCP Server Setup (if applicable):
- If user selected an MCP-based option, configure the appropriate entry in .mcp.json
- Update the verifier skill's allowed-tools to use the appropriate mcp__* tools

For CLI Tools

Check if asciinema is available (run which asciinema)
If not available, inform the user that asciinema can help record verification sessions but is optional
Tmux is typically system-installed, just verify it's available

For API Services

Check if HTTP testing tools are available:
- curl (usually system-installed)
- httpie (http command)
No installation typically needed

Phase 3: Interactive Q&A

Based on the areas detected in Phase 1, you may need to create multiple verifiers. For each distinct area, use the AskUserQuestion tool to confirm:

Verifier name - Based on detection, suggest a name but let user choose:
If there is only ONE project area, use the simple format:
- "verifier-playwright" for web UI testing
- "verifier-cli" for CLI/terminal testing
- "verifier-api" for HTTP API testing
If there are MULTIPLE project areas, use the format verifier-<project>-<type>:
- "verifier-frontend-playwright" for the frontend web UI
- "verifier-backend-api" for the backend API
- "verifier-admin-playwright" for an admin dashboard
The <project> portion should be a short identifier for the subdirectory or project area (e.g., the folder name or package name).
Custom names are allowed but MUST include "verifier" in the name — the Verify agent discovers skills by looking for "verifier" in the folder name.
Project-specific questions based on type:
For web apps (playwright):
- Dev server command (e.g., "npm run dev")
- Dev server URL (e.g., "http://localhost:3000")
- Ready signal (text that appears when server is ready)
For CLI tools:
- Entry point command (e.g., "node ./cli.js" or "./target/debug/myapp")
- Whether to record with asciinema
For APIs:
- API server command
- Base URL
Authentication & Login (for web apps and APIs):
Use AskUserQuestion to ask: "Does your app require authentication/login to access the pages or endpoints being verified?"
- No authentication needed - App is publicly accessible, no login required
- Yes, login required - App requires authentication before verification can proceed
- Some pages require auth - Mix of public and authenticated routes
If the user selects login required (or partial), ask follow-up questions:
- Login method: How does a user log in?
  - Form-based login (username/password on a login page)
  - API token/key (passed as header or query param)
  - OAuth/SSO (redirect-based flow)
  - Other (let user describe)
- Test credentials: What credentials should the verifier use?
  - Ask for the login URL (e.g., "/login", "http://localhost:3000/auth")
  - Ask for test username/email and password, or API key
  - Note: Suggest the user use environment variables for secrets (e.g., TEST_USER, TEST_PASSWORD) rather than hardcoding
- Post-login indicator: How to confirm login succeeded?
  - URL redirect (e.g., redirects to "/dashboard")
  - Element appears (e.g., "Welcome" text, user avatar)
  - Cookie/token is set

Phase 4: Generate Verifier Skill

All verifier skills are created in the project root's .claude/skills/ directory. This ensures they are automatically loaded when Claude runs in the project.

Write the skill file to .claude/skills/<verifier-name>/SKILL.md.

Skill Template Structure

markdown

---
name: <verifier-name>
description: <description based on type>
allowed-tools:
  # Tools appropriate for the verifier type
---

# <Verifier Title>

You are a verification executor. You receive a verification plan and execute it EXACTLY as written.

## Project Context
<Project-specific details from detection>

## Setup Instructions
<How to start any required services>

## Authentication
<If auth is required, include step-by-step login instructions here>
<Include login URL, credential env vars, and post-login verification>
<If no auth needed, omit this section>

## Reporting

Report PASS or FAIL for each step using the format specified in the verification plan.

## Cleanup

After verification:
1. Stop any dev servers started
2. Close any browser sessions
3. Report final summary

Allowed Tools by Type

verifier-playwright:

yaml

allowed-tools:
  - Bash(npm:*)
  - Bash(yarn:*)
  - Bash(pnpm:*)
  - Bash(bun:*)
  - mcp__playwright__*
  - Read
  - Glob
  - Grep

verifier-cli:

yaml

allowed-tools:
  - Tmux
  - Bash(asciinema:*)
  - Read
  - Glob
  - Grep

verifier-api:

yaml

allowed-tools:
  - Bash(curl:*)
  - Bash(http:*)
  - Bash(npm:*)
  - Bash(yarn:*)
  - Read
  - Glob
  - Grep

Phase 5: Confirm Creation

After writing the skill file(s), inform the user:

Where each skill was created (always in .claude/skills/)
How the Verify agent will discover them — the folder name must contain "verifier" (case-insensitive) for automatic discovery
That they can edit the skills to customize them
That they can run /init-verifiers again to add more verifiers for other areas

技能：创建验证技能 ​

目标 ​

阶段 1：自动检测 ​

阶段 2：验证工具设置 ​

对于 Web 应用程序 ​

对于 CLI 工具 ​

对于 API 服务 ​

阶段 3：交互式问答 ​

阶段 4：生成验证器技能 ​

技能模板结构 ​

按类型允许的工具 ​

阶段 5：确认创建 ​

Goal ​

Phase 1: Auto-Detection ​

Phase 2: Verification Tool Setup ​

For Web Applications ​

For CLI Tools ​

For API Services ​

Phase 3: Interactive Q&A ​

Phase 4: Generate Verifier Skill ​

Skill Template Structure ​

Allowed Tools by Type ​

Phase 5: Confirm Creation ​

技能：创建验证技能

目标

阶段 1：自动检测

阶段 2：验证工具设置

对于 Web 应用程序

对于 CLI 工具

对于 API 服务

阶段 3：交互式问答

阶段 4：生成验证器技能

技能模板结构

按类型允许的工具

阶段 5：确认创建

Goal

Phase 1: Auto-Detection

Phase 2: Verification Tool Setup

For Web Applications

For CLI Tools

For API Services

Phase 3: Interactive Q&A

Phase 4: Generate Verifier Skill

Skill Template Structure

Allowed Tools by Type

Phase 5: Confirm Creation