Tests Generator

v1.0.0

Generate deterministic unit/integration tests for critical behaviors.

0· 58·0 current·0 all-time
byMauricio Z.@mzfshark

Install

OpenClaw Prompt Flow

Install with OpenClaw

Best for remote or guided setup. Copy the exact prompt, then paste it into OpenClaw for mzfshark/axodus-test-generator.

Previewing Install & Setup.
Prompt PreviewInstall & Setup
Install the skill "Tests Generator" (mzfshark/axodus-test-generator) from ClawHub.
Skill page: https://clawhub.ai/mzfshark/axodus-test-generator
Keep the work scoped to this skill only.
After install, inspect the skill metadata and help me finish setup.
Use only the metadata you can verify from ClawHub; do not invent missing requirements.
Ask before making any broader environment changes.

Command Line

CLI Commands

Use the direct CLI path if you want to install manually and keep every step visible.

OpenClaw CLI

Bare skill slug

openclaw skills install axodus-test-generator

ClawHub CLI

Package manager switcher

npx clawhub@latest install axodus-test-generator
Security Scan
VirusTotalVirusTotal
Benign
View report →
OpenClawOpenClaw
Benign
high confidence
Purpose & Capability
Name, description, and the SKILL.md all describe generating deterministic tests. The skill requests no binaries, env vars, or installs — this aligns with an instruction-only test authoring helper.
Instruction Scope
Runtime instructions are limited to identifying behaviors, creating fixtures, writing/tests, and running/iterating them. They do not direct the agent to read unrelated files, collect credentials, contact external endpoints, or exfiltrate data. Safety guidance explicitly discourages using real credentials or external services by default.
Install Mechanism
There is no install spec and no code files. Being instruction-only means nothing is written to disk or downloaded by the skill itself, which is the lowest-risk pattern.
Credentials
The skill declares no required environment variables, credentials, or config paths. The guidance to avoid real credentials is appropriate. There is no disproportionate request for secrets or unrelated credentials.
Persistence & Privilege
The skill is not always: true and does not request persistent presence or modification of other skills/system settings. It is user-invocable and can be run autonomously by the agent (the platform default), which is normal for skills.
Assessment
This skill appears coherent and low-risk: it's an instruction-only test-generator with no installs or credential requests. Before installing, consider: 1) Trust and provenance — the package lists no homepage and source is unknown; verify you trust the owner. 2) Minor metadata mismatches — _meta.json lists a different ownerId and skill.yml has a stray 'System.Object[]' entry; these look like harmless metadata/serialization artifacts but you may want the publisher to clarify. 3) Runtime behavior depends on the agent invoking it — ensure the agent won't be given access to real credentials/environments when running generated tests (run in an isolated/test environment first). If you need stronger guarantees, ask the publisher for a README or example outputs and run the skill in a safe sandbox before using it on production code.

Like a lobster shell, security has layers — review code before you run it.

devvk971f4jnwrabdtr773049r8v0585et76latestvk971f4jnwrabdtr773049r8v0585et76
58downloads
0stars
1versions
Updated 3d ago
v1.0.0
MIT-0

SKILL: test-generator

Purpose

Generate deterministic unit/integration tests that protect behavior and enable safe refactors.

When to Use

  • A feature needs coverage.
  • A bug fix needs a regression test.
  • You want characterization tests before refactoring.

Inputs

  • target (required, string): function/module/endpoint/contract behavior to test.
  • test_type (optional, enum: unit|integration|e2e).
  • framework (optional, string): e.g., pytest, jest, vitest, foundry, hardhat.
  • constraints (optional, string[]): no network, deterministic time, limited mocks, etc.

Steps

  1. Identify observable behaviors and edge cases.
  2. Decide test boundaries:
    • unit: pure logic
    • integration: DB/service boundary
  3. Create fixtures:
    • deterministic data
    • stable clocks/UUIDs (mock only when required)
  4. Write tests:
    • happy path
    • failure paths
    • security/validation checks (where applicable)
  5. Run tests and iterate until they are stable.

Validation

  • Tests are deterministic (no flaky time/network dependencies).
  • Tests fail before the fix (for regressions) and pass after.
  • Coverage targets the acceptance criteria, not implementation details.

Output

  • Test files added/changed
  • How to run tests
  • Notes on fixtures/mocks used

Safety Rules

  • Do not add tests that require real credentials or real external services by default.
  • Avoid snapshot tests for highly variable outputs unless stabilized.

Example

Bug: “User creation accepts invalid email.” Output: a failing test asserting 400 on invalid input, then passes after fix.

Comments

Loading comments...