SenroAI/agent-skills

Senro Tests

Generate exactly the number of useful Senro test cases requested by the user from the repository containing the page they added to Senro. The coding agent does not run WebMCP or the generated tests; Senro runs the suite later against the registered page.

Workflow

1. Confirm that the current repository contains the page whose WebMCP behavior is being tested. Treat the repository as the source of truth.

2. Inspect the repository before generating anything. Exclude .git, dependency directories, build output, coverage output, and generated files.

3. Determine how the website exposes its WebMCP tools using the project's own source, framework, dependencies, tests, fixtures, and documentation. Do not assume a particular WebMCP API, framework, file layout, or registration pattern.

4. Build an internal inventory of each discovered tool's name, description, input schema, annotations, implementation, and available examples.

5. Stop and report clearly if no WebMCP tools can be established from the repository. If multiple unrelated sites or applications are present, identify them and ask which one to use.

6. Read the relevant routes, components, data files, fixtures, validation code, documentation, and existing tests to map real user journeys and visible success and failure states.

7. Read references/import-format-v1.md before writing test cases. Use only the fields and structures documented there.

8. Generate exactly the requested number of distinct test cases. Cover the repository's strongest journeys, including successful workflows, boundary conditions, invalid input, empty results, recovery, consequential actions, and visible state assertions where the source supports them.

9. If the repository cannot support the requested number of meaningful, source-grounded cases, report the limitation and stop. Do not pad the suite with invented scenarios, values, or behavior.

10. Use only tool names and arguments supported by the discovered source. Never invent IDs, accounts, products, enum values, or backend state. Use goal-only tests when a precise runtime value cannot be established safely.

11. Use expected tool calls only when the source supports the expected path. Do not force an exact trajectory onto a workflow where multiple valid paths are possible.

12. Create ./senro if needed. Write the suite to ./senro/test-cases.json. If that file exists on disk, use the next available numeric suffix, such as ./senro/test-cases-2.json. A deleted Git-tracked file is not a collision. Keep suites directly in ./senro; do not archive or move existing files.

13. Run the bundled structural preflight validator against the exact file you generated before reporting success:

    node <skill-root>/scripts/validate-tests.mjs <output-path>
    

14. Report the exact output path, test count, journey coverage, and any assumptions. Do not claim that a test is runtime-verified; Senro must run the suite against the live page.

Output Rules

• Write one JSON object with a tests array.
• Keep test names concise and under 70 characters.
• Write natural user requests. Include technical details only when essential to the behavior being tested.
• Where the source supports them, vary conversation modes, evaluation types, and journey complexity. Use scripted conversations for explicit requests and simulated conversations for clarification or multi-turn decisions. Do not force variety where it adds no useful coverage.
• Give scripted tests exactly one initial user message.
• Give simulated tests an empty authored message list and no authored follow-ups.
• Ensure every test has a goal, a required expected call, or a page check.
• Describe what the agent should accomplish in successful outcomes. Use tool-call expectations for necessary calls and arguments, and page checks for final page state. Do not prescribe an implementation path in an outcome when multiple valid paths exist.
• Keep setup calls concrete; never put matcher operators in setup arguments.
• Use stable selectors from the source for page checks.
• Assert stable final page state, not temporary messages that later valid actions may clear. Verify intermediate behavior through supported tool-call and result checks or the successful outcome.
• Use expectedCall: null when tool-call evaluation is disabled. It does not prohibit tool calls.
• Do not modify the website source while generating the suite.
• Do not write secrets, credentials, or private customer data into the suite.

References

• Import format