performance-test

Codex compatibility note:

• Invoke $skill-name: load the registered .agents/skills/<name>/SKILL.md and execute it with Codex tools; no separate Skill tool or Claude mode switch is needed. When a workflow step or another skill names a skill, read that file in full yourself (every line, with no line limit; in parts only when output is cut off): a skill whose implicit invocation is off is never loaded for you. Author .claude/**; mirrors are generated.
• Track steps before execution and keep progress/evidence current. Explicit skill requests execute their protocol. Use the native question tool for required questions.
• Map foreign tool names to available host capabilities. A name mismatch needs no approval; an actually unavailable required capability stops with its step/evidence and a user question before adaptation.
• Subagent authorization: when a skill is user-invoked or AI-detected and its protocol requires subagents, that skill activation authorizes use of the required spawn_agent subagent(s) for that task.
• Preserve protocol order unless the user approves a deviation. Workflows use $start-workflow: gates stay fixed; other steps may flex with logged reasons and evidence.

Quick Summary

Goal: Build reusable, project-native performance tests and prove useful capacity under explicit data, workload and hardware limits.

Summary: Discover the project contract → research/bootstrap if needed → author realistic scenarios → static review/fix (three rounds maximum by default) → return AUTHORED. Only an explicit verification request continues to measurement/report analysis or the bounded green loop. Keep project preferences and honest evidence limits.

Key Rules:

• Define the workload/SLO and enforce the resource envelope before measuring; a user count alone proves no capacity.
• Write/init author only: no test execution, service startup, data seeding or smoke/load run. Automatically review/fix the authored artifacts statically, capped at three review rounds by default; offer verification through the host question tool afterward.
• Acceptance uses at least 100k rows per growable table and a 1,000-concurrent-user profile where applicable; smaller smoke runs prove only wiring.
• Green requires correctness, valid offered load, bounded memory/no observed OOM, query/search access-path evidence and recovery. Missing required evidence blocks PASS; preserve targets during repairs.