report-issue
Standardized procedure for reporting and diagnosing defects in the ModernTSF framework.
Install
mkdir -p .claude/skills/report-issue && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/14696" && unzip -o skill.zip -d .claude/skills/report-issue && rm skill.zipInstalls to .claude/skills/report-issue
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Diagnose and report a ModernTSF framework defect upstream, with user approval, as a GitHub issue or a small verified PR against Diaugeia/ModernTSF. Use after reproducing a crash in src/ or tool/, wrong output or shapes, a broken config or registry, a doc/CLI mismatch, or another repository defect rather than a problem in the user's data or code.Key capabilities
- →Diagnose ModernTSF framework defects
- →Minimize reproduction steps for defects
- →Draft GitHub issues with required information
- →Create small, verified pull requests for fixes
- →Check for existing issues or pull requests
How it works
This skill guides the user through diagnosing ModernTSF framework defects, collecting necessary information, and drafting a GitHub issue or pull request for upstream reporting.
Inputs & outputs
When to use report-issue
- →Report a crash in the framework
- →Create a PR for a verified defect
- →Compare expected vs actual behavior
About this skill
Guardrails
Confirm the defect belongs to ModernTSF, minimize the reproduction, and preserve the user's current work.
- Never publish, push, fork, or open an issue/PR without explicit user approval.
- Show the proposed title and complete body before asking for approval.
- Do not include secrets, private paths, credentials, proprietary data, or unnecessary logs.
- Report one defect at a time. Search open and closed issues/PRs first.
- Do not stage, commit, stash, reset, or otherwise alter unrelated user changes.
Diagnose and choose
Re-run the smallest failing command and compare expected with actual behavior. Prefer:
- Issue when the cause is unclear, the fix needs design input, or a verified fix is not available.
- PR for a small, understood fix that can be tested locally.
Before drafting, record:
- exact command and minimal config or input;
- expected and actual behavior;
- complete relevant traceback or logs;
bash scripts/detect_hardware.sh;- OS, Python, torch, uv,
UV_TORCH_BACKEND, andgit rev-parse --short HEAD; - whether the defect reproduces on current
origin/main.
Run these preflight checks without changing repository state:
git status --short --branch
git remote -v
gh auth status
gh search issues "<distinctive error or symptom>" --repo Diaugeia/ModernTSF --state open
gh search issues "<distinctive error or symptom>" --repo Diaugeia/ModernTSF --state closed
gh search prs "<distinctive error or symptom>" --repo Diaugeia/ModernTSF --state open
If authentication, network access, or latest-main reproduction is unavailable, disclose that in the draft rather than claiming it was checked.
File an issue
Follow .github/ISSUE_TEMPLATE/bug_report.yml, including its duplicate-search and latest-main checklist. Use the full traceback requested by the template; redact only sensitive or irrelevant material.
Draft the body in a temporary file so shell quoting cannot corrupt Markdown:
cat > /tmp/moderntsf-issue.md <<'EOF'
## What happened?
<actual behavior and expected behavior>
## Config to reproduce
```toml
<minimal config>
```
## Command
```shell
<exact command>
```
## Full traceback / logs
```text
<complete relevant output>
```
## Environment
```text
<hardware report, OS, Python, torch, uv, UV_TORCH_BACKEND>
```
## Git commit / version
`<commit>`
## Checklist
- [x] I searched existing issues for a duplicate.
- [x] I reproduced this on the latest `main`.
EOF
Leave a checklist item unchecked and explain why if it was not verified. After the user approves the exact title and body:
gh issue create --repo Diaugeia/ModernTSF \
--title "[Bug] <short symptom>" \
--label bug \
--body-file /tmp/moderntsf-issue.md
Open a PR
Use a separate worktree when the current worktree is dirty or contains unrelated work. Base it on the commit used for verification, preferably a freshly fetched origin/main:
git fetch origin main
git worktree add /tmp/moderntsf-fix-<slug> -b fix/<slug> origin/main
Make only the defect fix in that worktree. Verify with the smallest reproduction, then the affected smoke test or another focused check. Review git diff --check, git status --short, and the full diff before committing.
Follow .github/PULL_REQUEST_TEMPLATE.md in the PR body: summary, type of change, exact test commands/results, and applicable checklist items. Clearly mark non-applicable or unverified items. Show the user the final diff summary, title, body, branch, and push destination before asking for approval.
After approval:
git commit -m "fix(<area>): <symptom>"
git push -u <fork-or-writeable-remote> fix/<slug>
gh pr create --repo Diaugeia/ModernTSF \
--base main \
--head <github-user>:fix/<slug> \
--title "fix(<area>): <symptom>" \
--body-file /tmp/moderntsf-pr.md
If the user lacks upstream write access, create or reuse their fork only after approval. Prefer a named fork remote such as fork; do not silently rename or replace origin.
Finish
Return the created URL and resume the original task. If publication fails, report the exact failed step and preserve the draft, branch, and worktree for recovery.
When not to use it
- →When the problem is in the user's data or code
- →When the defect belongs to a different repository
- →When publishing, pushing, forking, or opening an issue/PR without explicit user approval
Limitations
- →Requires explicit user approval for any external action.
- →Does not include secrets, private paths, credentials, or proprietary data.
- →Reports one defect at a time.
How it compares
This skill provides a structured, guarded process for reporting framework defects, ensuring all required information is collected and user approval is obtained before any external action, unlike ad-hoc reporting.
Compared to similar skills
report-issue side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| report-issue (this skill) | 0 | 2mo | Review | Intermediate |
| python-testing-patterns | 77 | 2mo | Review | Intermediate |
| chrome-devtools | 41 | 7mo | Review | Intermediate |
| bats | 9 | 7mo | Review | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
You might also like
python-testing-patterns
wshobson
Implement comprehensive testing strategies with pytest, fixtures, mocking, and test-driven development. Use when writing Python tests, setting up test suites, or implementing testing best practices.
chrome-devtools
mrgoonie
Browser automation, debugging, and performance analysis using Puppeteer CLI scripts. Use for automating browsers, taking screenshots, analyzing performance, monitoring network traffic, web scraping, form automation, and JavaScript debugging.
bats
OleksandrKucherenko
Bash Automated Testing System (BATS) for TDD-style testing of shell scripts. Use when: (1) Writing unit or integration tests for Bash scripts, (2) Testing CLI tools or shell functions, (3) Setting up test infrastructure with setup/teardown hooks, (4) Mocking external commands (curl, git, docker), (5) Generating JUnit reports for CI/CD, (6) Debugging test failures or flaky tests, (7) Implementing test-driven development for shell scripts.
browser-daemon
noiv
Persistent browser automation via Playwright daemon. Keep a browser window open and send it commands (navigate, execute JS, inspect console). Perfect for interactive debugging, development, and testing web applications. Use when you need to interact with a browser repeatedly without opening/closing it.
performance-profiling
davila7
Performance profiling principles. Measurement, analysis, and optimization techniques.
obsidian-local-dev-loop
jeremylongshore
Configure Obsidian plugin development with hot-reload and fast iteration. Use when setting up development workflow, configuring test vaults, or establishing a rapid development cycle. Trigger with phrases like "obsidian dev loop", "obsidian hot reload", "obsidian development workflow", "develop obsidian plugin".