メニュー
When you notice something wrong or suboptimal in a skill or agent definition -- file a GitHub issue on joshrotenberg/agent-tools rather than silently proceeding.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | agent-feedback |
| description | When you notice something wrong or suboptimal in a skill or agent definition -- file a GitHub issue on joshrotenberg/agent-tools rather than silently proceeding. |
When an agent detects a problem in a skill or agent definition during real use, that observation is valuable. This skill describes when and how to file a GitHub issue so it isn't lost.
File an issue when you notice:
Do NOT file for stylistic preferences or minor wording nits.
File when either condition is true:
If neither condition applies, continue without filing.
fix: <skill-name> -- <one-line description>
feat: <skill-name> -- <one-line description>
Use fix: for incorrect or outdated instructions. Use feat: for missing coverage of a real situation.
Examples:
fix: sandbox-preflight -- blocked tool check silently no-ops when gh is missing
feat: orchestration-prompt-template -- no guidance for runner prompt when issue has no acceptance criteria
gh issue create \
--repo joshrotenberg/agent-tools \
--title "fix: <skill-name> -- <one-line description>" \
--body "$(cat <<'EOF'
**What the skill says**
<quote or paraphrase>
**What actually happened / what is missing**
<specific description>
**Suggested fix or question**
<proposed change or question>
EOF
)"
Add relevant labels with --label to match the severity and component of the observation.
Available labels: skills, agents, ci, docs, fix, feat, field-feedback, p1, p2, p3.
Example: --label "skills,fix,p2" for a skill bug of moderate severity.
Check for duplicates before filing:
gh issue list --repo joshrotenberg/agent-tools --state open
Don't bundle multiple unrelated findings into one issue. If you have two distinct observations, file two issues.
Continue the current task. Do not wait for the issue to be resolved. Include the issue URL in your return summary to the dispatcher or human.
gh issue listfield-feedback -- for wrapper bugs, sandbox gaps, unexpected
dispatch behaviors, and findings that route to repos other than joshrotenberg/agent-toolsrunner-issue-authority -- gh issue view as the authoritative
source for task inputspiral-diagnosis -- when a dispatched session is stuck
(a different kind of feedback loop)Use when deciding whether to dispatch a runner or a worker for a subtask. Describes the decision boundary, the failure mode when runner is used where worker is intended, and the safe composition pattern.
When a repo has no GitHub remote (or is not yet a git repo) -- use this to route survey, sweep, and dispatch off the GitHub-centric path. Detect with `git remote` empty; treat blank GitHub columns as expected, not an error; route work to commits + CLAUDE.md instead of issues + PRs; degrade a maintenance sweep to the local-only axes.
When the directive is "status check," "what's new across my projects," or "sweep maintenance" -- run a per-project, read-mostly, non-PR sweep. For each project under the owner-prefixed layout, gather stars/forks, open issues/PRs split into mine vs community vs bots, package downloads, release-due (unreleased conventional commits), a test run, a stale-CLAUDE.md flag, and branch-cleanup candidates. Emit a fresh per-project report every sweep; NEVER cache status back into a workspace/manager CLAUDE.md.
Before making any non-trivial code, docs, or config change -- create a feature branch first, then open a PR. Never commit directly to main. Apply by default before any edit; this is the baseline branch discipline that all other git skills build on.
When the issue or PR queue has open unlabeled items -- run a read-only triage pass that labels each one by component, category, priority, and size, flags duplicates, closes noise, and reports the p1 queue before runners are dispatched.
When writing any issue, PR, or commit message, use this for the authoring standard. Covers structure (headings, lists, tables, fenced blocks, the bug block, the before/after) and voice (factual, no emdashes, no editorializing labels, conventional-commit prefixes, no commit trailers).