report-to-issues
Workflow
Phase 1: Locate Report
- If the user specifies a file path, use it directly.
- Otherwise, list available reports:
docs/evaluation/— software-evaluation reportsdocs/security-audit/— vulnerability-scan reports- If multiple exist, ask the user to select one.
- Detect report type by content:
- Contains
## Improvement Roadmap→ evaluation report - Contains
## Remediation Priority→ security-audit report
- Contains
Phase 2: Extract Tasks
Evaluation report — extract rows from ## Improvement Roadmap tables (P0–P3):
More from ymd38/dev-skills
spec-doc
>
13vulnerability-scan
>
12software-evaluation
>
9gh-issue-resolver
Implement and verify a fix for a GitHub Issue whose response plan has already been posted as a comment by gh-issue-planner. Creates a feature branch, applies the agreed plan, runs tests, and opens a Pull Request. Use when the user asks to implement/fix/resolve a planned GitHub Issue. Triggers include requests such as Issueを実装して / Issueを修正して / Issueを対応して, implement issue #N, fix issue #N, resolve issue #N, work on issue #N. Prerequisite: an agreed plan comment must exist on the issue (run gh-issue-planner first if not).
6progress-dashboard
>
2gh-issue-planner
Fetch a GitHub Issue by ID using the gh CLI, investigate related code, propose a structured response plan (policy, impact scope, implementation steps), and post the agreed plan as a comment on the issue. Implementation/PR creation is out of scope — use gh-issue-resolver for that. Use when the user provides a GitHub Issue ID or asks to investigate/analyze/plan a GitHub Issue. Triggers include issue IDs like #42 or 'issue 42', requests such as Issueを調査して / Issueの対応方針を立てて, analyze issue #N, plan issue #N, investigate issue, look at issue.
1