用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt;运行前请先检查来源。
npx skills add https://github.com/tomevault-io/skills-registry --skill qa命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地?可下载 SkillsMP 当前能够提供的文件。
| Use when this capability is needed.
> Use when this capability is needed.
Review architecture and API design for the vfs-s3 project. Use when the user mentions @architect, asks to review an issue's design, discuss module boundaries, API shape, or architectural decisions for vfs-s3. Also trigger when the user wants to create an ADR (Architecture Decision Record) or evaluate a technical approach for the project. Intended for dispatch from Codex automation or Claude routines; GitHub trigger phrase: @vfs-s3-bot please prepare design doc Use when this capability is needed.
基于 SOC 职业分类
正在显示 SKILL.md
| name | qa |
| description | >- Use when this capability is needed. |
Run automated and interactive regression tests for a San feature by name.
<feature> — Feature name, e.g. agent, cli-startup, loop, session, hook.--interactive — Also run interactive tmux tests (default: automated only).--pane — For interactive tests, split a pane in the current tmux window instead of creating a separate session. Lets the user watch the test live.Look for the feature in this order:
docs/reference/<feature>.md — reference docs, may have Automated Tests and Interactive Tests (tmux) sectionsdocs/packages/2-feature/<feature>.md — feature package docs, has a ## Tests sectionRead the file. Extract:
go test commands and known test cases (from reference docs).If the feature matches an integration test directory name (tests/integration/<feature>/), add go test ./tests/integration/<feature>/... as a default test command even if the doc doesn't list one.
If the feature cannot be found in any doc path, list all available features (integration test dirs + doc stems from both locations) and ask the user to pick one.
Always build first so tests run against the latest code:
make build
If the build fails, stop and report the error — no point running tests against stale code.
Execute every go test command extracted from the feature doc's Automated Tests section, plus the default integration test command if applicable. Capture stdout/stderr and exit codes. Each command is a separate test group.
Record results as:
--interactive or --pane)Skip this phase unless the user explicitly opts in.
--pane)Split a pane in the current tmux window for the test:
# Detect current session and window
TMUX_TARGET=$(tmux display-message -p '#{session_name}:#{window_index}')
# Split horizontally, 50% width
tmux split-window -h -t "$TMUX_TARGET" -l '50%'
Run all interactive test steps in that pane via tmux send-keys. Use tmux capture-pane -p to read the pane output after each step and verify the Expected comments from the doc.
--interactive without --pane)Create a dedicated tmux session:
tmux new-session -d -s qa_<feature> -x 220 -y 60
Run the interactive test steps there. Kill the session when done.
For each test step:
tmux send-keys.sleep duration (or a reasonable default).tmux capture-pane -t <target> -p.After all steps, clean up (kill session/pane, remove temp files) as specified in the doc's cleanup section.
Print a summary table:
## QA Report: Feature — <Name>
### Automated Tests
| Test Group | Result |
|--------------------------|--------|
| go test ./internal/x/... | PASS |
| go test ./tests/int/... | FAIL |
### Interactive Tests
| Step | Result | Notes |
|------------------------------|--------|--------------------------|
| Test 1: Basic TUI startup | PASS | TUI with input box shown |
| Test 2: Print mode | FAIL | No output after 15s |
### Summary
Automated: 2/3 passed
Interactive: 3/4 passed
Overall: PARTIAL PASS
Use PASS, FAIL, or SKIP for each item. Include failure details inline so the user can act on them immediately.
./bin/san (built by make build), not the installed san.Ctrl+C (C-c) to exit san, not q (which gets interpreted as user input).Source: genai-io/gen-code — distributed by TomeVault.