Menu
Help prepare and, only with explicit user approval, file a sanitized Moraine bug report for reproducible defects in Moraine itself.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Run isolated Moraine dev sandbox validation. Use when testing ingest, MCP, monitor, ClickHouse schema, source formats, stack behavior, or any change where QA must not touch the developer's host ~/.moraine install; use before reporting completion for stack-facing changes.
Use Moraine realtime session data to inspect active agent work across harnesses when the user asks what is happening now or what another agent is doing.
Use Moraine MCP tools to recover prior agent-session context when the user refers to earlier work, decisions, failures, branches, files, or other agents.
Cut and publish Moraine releases from a version argument such as /release X.Y.Z or a request to use $moraine-dev:release. Use when Codex is asked to run Moraine's release process, bump release-managed versions, create and merge the release PR, push the vX.Y.Z tag, update GitHub release notes for a general audience, verify the release-moraine workflow, and confirm the PyPI moraine-cli package. Start or continue a Codex goal for the release.
Use Moraine MCP tools to recover prior agent-session context when the user refers to earlier work, decisions, failures, branches, files, or other agents.
Create Moraine pull requests on GitHub. Use when the branch is ready to open a PR; when the user asks to create, push, or open a PR; after local changes are committed; or when documenting user-facing features, bug fixes, performance optimizations, validation, changelog impact, or operational impact in a PR that follows repository conventions without AI attribution.
| name | bug-report |
| description | Help prepare and, only with explicit user approval, file a sanitized Moraine bug report for reproducible defects in Moraine itself. |
Use this skill when the user hit a likely Moraine defect and wants help turning it into a useful GitHub issue. A Moraine bug is a reproducible problem in the Moraine CLI, ingest, monitor, MCP server, setup flow, packaging, documentation, or bundled plugins.
Do not use this skill for general support, one-off local setup help, unrelated agent-harness issues, or private debugging that cannot be generalized into a Moraine repository issue. Troubleshoot those locally instead, and file a report only if the evidence points to a fixable Moraine defect.
The Moraine repository is:
https://github.com/eric-tramel/moraine
New bug reports go through GitHub Issues:
https://github.com/eric-tramel/moraine/issues/new
If a GitHub issue tool, browser, or gh is available, use it only after the
user explicitly confirms the final redacted report. If no posting tool is
available, provide the issue URL and the prepared report body.
Never silently post an issue on the user's behalf. Even if the user says "file it", first show the final sanitized title and body, then ask for explicit confirmation before creating the issue. If the user declines, stop after providing the draft.
Do not upload logs, configs, screenshots, session transcripts, or command output without the same explicit confirmation.
All bug reports must anonymize PII and host-specific details before they leave the user's machine.
Redact or generalize:
Use placeholders such as <home>, <repo>, <project>, <host>,
<workspace>, <token>, and <private transcript omitted>.
Before drafting a report, determine whether the issue belongs in the Moraine repo:
Draft reports in this shape:
## Summary
One or two sentences describing the Moraine bug and affected surface.
## Affected Area
- Moraine component: CLI | setup | ingest | monitor | MCP | packaging | docs | plugin
- Harness, if relevant: Codex | Claude Code | Hermes | OpenCode | Cursor | Kimi CLI | Pi Coding Agent | other
- Install method, if relevant: release bundle | uv tool | Homebrew | source checkout | unknown
## Version
- Moraine version: output of `moraine --version`, if available
- Broad platform: sanitized OS and architecture category only
## Steps To Reproduce
1. Minimal first step.
2. Minimal second step.
3. Command or action that triggers the bug, with paths and private names replaced.
## Expected Behavior
What Moraine should have done.
## Actual Behavior
What happened instead, including the sanitized error message or symptom.
## Sanitized Evidence
Short redacted excerpts only. Replace private values with placeholders.
## Workaround
Known workaround, if any.
## Notes
Any suspected regression range, related issue, or additional context that does
not expose private data.
Ask before running commands that may read local state. Prefer narrow commands whose output can be summarized and redacted, such as:
moraine --version
moraine status
moraine logs --lines 100
When logs are useful, include only the shortest sanitized excerpt that explains the failure. Do not include full session content or full config files. Summarize config shape instead of posting exact values.
If prior agent context matters and Moraine MCP tools are available, use the current harness's Moraine search tools to recover the relevant session or error, then apply the same redaction rules before drafting the issue.