| name | issue-report |
| description | 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>. |
| argument-hint | <description> |
| disable-model-invocation | true |
| allowed-tools | ["Bash(gh auth status)","Bash(gh issue list *)","Bash(zordon --version)","Bash(zordon -h)","Bash(uname *)"] |
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>
