Issue report

Skill piotrkowalczuk/zordon/skills/issue-report

File a bug report or feature request against the zordon project (github.com/piotrkowalczuk/zordon) from a short description. Distills a generic, reproducible essence and strips anything specific to the user's local setup — absolute paths, usernames, hostnames, internal service/company names, concrete ports, secrets — before opening the issue. Invoke as /zordon:issue-report <description>.From its SKILL.md

Install

npx -y skills add piotrkowalczuk/zordon --skill issue-report

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

4 stars4 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.

SKILL.md

3.5 KB, as published. Nobody here has run it

Report a zordon issue upstream

Open a bug report or feature request against github.com/piotrkowalczuk/zordon from the user's <description>, after reducing it to a generic, reproducible essence and stripping anything specific to their local setup.

Steps

Classify the report from the description and the conversation: bug, feature request, or question.
Collect safe environment only — zordon version (zordon --version, else the zordon -h header) and OS/arch (uname -sm). Never collect paths, env values, or secrets.
Draft a sanitized title and body (templates below), reducing the user's situation to the smallest generic reproduction expressed in zordon terms.
Check for duplicates: gh issue list --repo piotrkowalczuk/zordon --search "<keywords>" --state all. If a close match exists, show it and ask whether to comment there instead of opening a new one.
Confirm before filing. Show the user the full drafted issue (title + body) and get explicit approval; let them edit it. Never run gh issue create without a clear yes — this opens a public issue on a third-party repository.
File it: gh issue create --repo piotrkowalczuk/zordon --title "<title>" --body "<body>". If gh is not authenticated (gh auth status fails), tell the user to run gh auth login first and stop.
Return the created issue URL.

Sanitize — strip local details, keep the generic essence

This is the point of the skill: the upstream maintainer needs the shape of the problem, not the user's environment.

Remove and replace with neutral placeholders:

Absolute paths and home dirs (/Users/<name>/…, /home/<name>/…) → <path>.
Usernames, hostnames, IPs (except loopback), emails, and org / company / product / internal service names → service-a, app, <host>.
Concrete dynamic ports, content hashes, temp dirs, and any environment-variable values → placeholders.
Secrets, tokens, and connection strings → never include, under any circumstances.
The user's own repository URLs and git remotes.

Keep (these are generic and genuinely useful):

zordon subcommands, flags, toolchains (go / rust / ruby / nodejs / pkg), and config helpers (net::pickport(), fs::tmp(), fs::etc(), …).
Error text, with paths redacted.
zordon version and OS/arch.

Rewrite any reproduction Alphasfile with generic service names and only the helpers/fields actually involved — not the user's real manifest.

Bug template

### Environment
- zordon: <version>
- OS/arch: <os>/<arch>

### What happens
<one generic paragraph>

### Expected
<what should happen instead>

### Minimal repro
<sanitized Alphasfile snippet + the command run>

### Logs
<relevant lines, paths redacted>

Feature template

### Problem
<the generic need, not the user's specific project>

### Proposed behavior
<what zordon could do>

### Alternatives considered
<optional>