Ouroboros test plan author
Skill secondorderai/ouroboros/.agents/skills/ouroboros-test-plan-author
Ouroboros is an Agent Harness, CLI and Desktop App with Self-Improvement layer
npx -y skills add secondorderai/ouroboros --skill ouroboros-test-plan-authorAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Create intent-based Ouroboros desktop E2E Markdown test plans from a high-level goal, feature, module, bug, PRD, ticket, or UI area. Use when asked to generate, draft, author, improve, or expand files under test-plan/ for Agent Browser desktop testing.
SKILL.md
3.1 KB, as published. Nobody here has run it
Ouroboros Test Plan Author
Use this skill to turn a high-level feature, module, bug, or goal into one or
more executable Markdown charters under test-plan/.
Workflow
- Ground the plan in the repo before writing:
- Search relevant renderer components, stores, protocol types, existing E2E specs, and existing
test-plan/*.md. - Prefer current labels, UI names, domain language, and mock data patterns from the codebase.
- Search relevant renderer components, stores, protocol types, existing E2E specs, and existing
- Decide plan granularity:
- One plan for one user-centered workflow.
- Split broad modules into multiple charters only when the workflows have different setup, risks, or pass/fail oracles.
- Write the Markdown plan in
test-plan/<kebab-case-name>.md. - Keep the plan intent-based:
- Describe what the user is trying to accomplish.
- Avoid brittle CSS selectors, implementation details, or Playwright-style commands.
- Include enough observable outcomes for an Agent Browser runner to judge pass/fail.
- If the plan needs mock data, name the required scenario shape in plain language.
- Do not invent large fixture JSON unless the user explicitly asks for it.
- State when missing mock data should produce
INCONCLUSIVE.
Required Plan Shape
# Title Case Plan Name
## Mission
One or two sentences describing the user workflow and why it matters.
## Priority / Tags
p0, smoke, desktop, feature-name
## Initial State
- Fresh Electron user data directory, unless persistence is the subject.
- Mock CLI scenario requirements.
- Any required workspace, dialog response, policy response, or seeded data.
## Intent Steps
1. User-centered action.
2. Observable action or navigation.
3. Verification step.
## Expected Outcomes
- Concrete visible UI state.
- Relevant persisted/logged behavior when observable through test logs.
- Recovery or closing behavior where appropriate.
- No uncaught renderer error.
## Evidence Required
- Screenshot names or moments worth capturing.
- Console and page error output.
- Any mock CLI log evidence worth checking.
Quality Bar
- Use
p0for release-blocking smoke flows; usep1for important surfaces; usep2for edge cases and exploratory coverage. - Make each expected outcome externally observable from the running app, screenshots, logs, or console output.
- Prefer stable human-facing terms: accessible labels, menu names, panel titles, visible messages.
- Include negative or recovery checks for risky flows: cancellation, empty states, disabled actions, denied approvals, failed config, or restart.
- Keep each plan short enough for an agent to execute in one focused run.
Output
After writing or updating a plan, report:
- The file path.
- The workflow covered.
- Any mock scenario assumptions.
- The exact command to dry-run and execute it:
bun run test:intent:e2e -- test-plan/<name>.md --dry-runbun run test:intent:e2e -- test-plan/<name>.md