一键导入
vs-perf
Use when optimizing latency, throughput, memory, startup, bundle size, or any performance target that needs evaluator-backed proof.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Use when optimizing latency, throughput, memory, startup, bundle size, or any performance target that needs evaluator-backed proof.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Analyze Codex, Claude Code, or Cursor threads, transcripts, and transcriptions. Use for thread analysis, transcript review, conversation audits, agent-performance diagnosis, comparing sessions, finding loops or corrections, and extracting decisions, outcomes, evidence, and actionable improvements.
Internal reference for vs shared conventions: artifact paths, project ID resolution, storage preference, and skill taxonomy.
Use when asked to scan a named external repo for ideas worth porting. Produces a cited, ranked steals report.
Use when asked to QA, test this site or app, find bugs, or test and fix a user-facing interface. Runs harness-aware browser or computer-use QA, fixes issues, and re-verifies.
Use when the user wants to create/open a pull request, submit changes for review, send changes to dev, or otherwise ship local Git changes. Also use for explicit commit and push or push to main/master or the current branch requests. Requires affirmative publish intent; do not use for review/readiness-only requests. Creates and verifies a GitHub PR by default; honors explicit direct pushes and babysits only when requested.
Use when asked to watch a PR, fix CI, address review comments, or keep a branch merge-ready in a loop.
| name | vs-perf |
| description | Use when optimizing latency, throughput, memory, startup, bundle size, or any performance target that needs evaluator-backed proof. |
Performance work needs a scoreboard before code changes. This building block turns a performance goal into an evaluator-backed loop: baseline, optimize, compare, guard against regressions.
When running in Codex, use
../vs-internal-shared/references/codex-goal.md
for standalone-goal rules.
Perf normally contributes measurement evidence to another workflow. If invoked
as the whole task, it may own a performance goal after the objective, metric,
evaluator, and pass contract are defined. Complete that goal when the result
reaches PASS, FAIL, WARN_NO_BASELINE, or BLOCKED with baseline/target
evidence and correctness guardrails reported.
PERF_READY, PASS, FAIL, WARN_NO_BASELINE, or BLOCKEDvs:shape-it for performance-shaped plans, vs:build-it before implementation, standalone optimization runsDo not optimize before you know how to measure. If there is no evaluator, create
or identify one first. If no evaluator is realistic, report WARN_NO_BASELINE
and frame the work as cleanup or architecture, not proven performance.
## Perf Result
- Status: PERF_READY | PASS | FAIL | WARN_NO_BASELINE | BLOCKED
- Objective: <performance goal>
- Metric: <what is measured>
- Evaluator: `<command or tool>`
- Baseline: <value or unavailable>
- Target: <pass contract>
- Evidence:
- <checkpoint results>
- Correctness guardrails:
- <tests/build/lint results>
Direct: emit Next only. Composed: return to caller.
Prev: /vs-shape-it | /vs-rfc-research | optimization request
Next: /vs-build-it
Relevant: /vs-verify | /vs-prototype