RedHat Code Generation

v1.0.0

Generate production-ready code aligned to repo conventions and constraints.

0· 82·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-code-generation.

Previewing Install & Setup.
Prompt PreviewInstall & Setup
Install the skill "RedHat Code Generation" (mzfshark/axodus-code-generation) from ClawHub.
Skill page: https://clawhub.ai/mzfshark/axodus-code-generation
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-code-generation

ClawHub CLI

Package manager switcher

npx clawhub@latest install axodus-code-generation
Security Scan
VirusTotalVirusTotal
Benign
View report →
OpenClawOpenClaw
Benign
high confidence
Purpose & Capability
Name/description (generate repo-aligned TypeScript/JavaScript/Python code) align with the SKILL.md steps and inputs (spec, language, targets, constraints). There are no unrelated environment variables, binaries, or config paths requested.
Instruction Scope
Runtime instructions ask the agent to validate specs, inspect existing code style in the target area, generate code, add tests, and provide validation commands — all appropriate for a code-generation skill. The only file access implied is the target repo area, which is expected; the instructions do not ask for unrelated system files, credentials, or exfiltration endpoints.
Install Mechanism
No install spec and no code files beyond documentation — instruction-only reduces on-disk risk. Nothing is downloaded or written by an installer.
Credentials
The skill declares no required environment variables, credentials, or config paths. The SKILL.md explicitly forbids embedding secrets and recommends configurable external API usage, which is proportionate.
Persistence & Privilege
always is false (not force-included) and model invocation is allowed (normal). The skill does not request persistent system-wide changes or access to other skills' configurations.
Assessment
This skill appears coherent and focused on generating code in the repo area. Before installing, verify the skill will only be given access to the specific repository paths it needs (principle of least privilege), avoid providing any secrets in the 'spec' input, review any generated changes and run the provided validation commands (lint/test/build) before merging, and confirm the publisher/owner provenance if that matters to your organization (the package metadata shows no public homepage).

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

devvk979wb0pgeb8dr2yy1gq8qpx1d85envalatestvk979wb0pgeb8dr2yy1gq8qpx1d85enva
82downloads
0stars
1versions
Updated 4d ago
v1.0.0
MIT-0

SKILL: code-generation

Purpose

Generate production-ready code (TypeScript/JavaScript/Python) that matches the repo’s conventions, is testable, and is safe to run.

When to Use

  • You have an explicit spec and acceptance criteria.
  • A new module/component/function is needed.
  • Small-to-medium scoped implementation work is requested.

Inputs

  • spec (required, string|object): functional requirements + acceptance criteria.
  • language (required, enum: ts|js|py).
  • targets (optional, string[]): files/modules to create or modify.
  • constraints (optional, string[]): security/perf/compat requirements.
  • test_expectations (optional, string): tests to add/run.

Steps

  1. Validate the spec:
    • confirm inputs/outputs
    • confirm error handling
    • identify missing requirements (ask if material)
  2. Inspect existing code style and patterns in the target area.
  3. Generate minimal, modular code:
    • small functions
    • explicit types (TS) where useful
    • clear error paths
  4. Add or update tests aligned to acceptance criteria.
  5. Update docs/config only if required by the change.
  6. Provide a deterministic validation command sequence (lint/test/build).

Validation

  • Code is syntactically valid and follows project conventions.
  • Tests cover the critical behavior and fail before the fix (when applicable).
  • No secrets or credentials are introduced.
  • Any external API usage is explicit and configurable (env/config), with timeouts and retries.

Output

  • files_changed: list of paths
  • summary: what changed
  • validation_commands: ordered commands to run
  • notes: any assumptions or follow-ups

Safety Rules

  • Never embed secrets, private keys, or tokens.
  • Never introduce dynamic code execution (eval, runtime compilation) unless explicitly required and sandboxed.
  • Avoid network calls in tests unless explicitly controlled/mocked.
  • Prefer additive changes over risky rewrites.

Example

Input:

  • language: ts
  • spec: “Add parseUserId(input) that rejects non-UUID values.”

Output (excerpt):

  • files_changed: ["src/utils/ids.ts", "src/utils/ids.test.ts"]
  • validation_commands: ["pnpm test", "pnpm lint"]

Comments

Loading comments...