メニュー
Create, manage, and track issues in GitHub, Linear, or GitLab. Use when the user asks to "create an issue", "file a bug", "check issues", "update a ticket", "create an epic", or anything about issue/ticket management.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Measure the token/cost/time efficiency of AI coding-agent work — per session, per role, per day, and per individual sub-agent — with every dollar metered by ccusage. Use when the user asks "what did this cost", cost per session/role/test case, which role/sub-agent burned the most, tool-call/skill/time breakdowns, "before vs after" cost comparisons, or wants to audit AI spend over time.
Per-role persistent memory — durable facts, preferences, decisions, and a daily log, as plain markdown. Use when the user says "remember this" or "log this", asks "what did you learn yesterday", or whenever you discover something worth keeping across sessions.
UI/E2E test automation with Playwright MCP. Use when the user asks to "test the UI", "automate browser tests", "check the page", "take a screenshot", "run Playwright", "write E2E tests", or anything about browser-based testing.
Turn a vague bug report into precise, repeatable steps with evidence and a CONFIRMED / CANNOT-REPRODUCE / PARTIAL verdict. Use when a bug is unclear or unconfirmed and needs reproduction before RCA or any fix. Reproduction and documentation only — does not fix code.
Generate AGENTS.md and .agents/ configuration files for a new project. Use when the user asks to "seed the project", "onboard this repo", "generate project config", "create AGENTS.md", or after the scout has explored the codebase.
Use when a TMS test case needs to become an automated test, or when automating a regression batch — "automate TC-NNN", "convert this case to a framework test", any flow from a manual case to green framework tests. Pluggable TMS (Zephyr/TestRail/Xray/Azure/markdown).
| name | issue-tracking |
| description | Create, manage, and track issues in GitHub, Linear, or GitLab. Use when the user asks to "create an issue", "file a bug", "check issues", "update a ticket", "create an epic", or anything about issue/ticket management. |
| license | Apache-2.0 |
| compatibility | Requires the tracker's CLI or MCP wired in — gh / glab / Atlassian MCP / Azure DevOps MCP / Linear CLI/MCP. Scout's Step 6.8 wires these per-agent on restrictive hosts. |
| allowed-tools | Bash(gh:*) Bash(linear:*) Bash(glab:*) |
| metadata | {"authors":["Artem Rozumenko <artem_rozumenko@epam.com>","Alexander Bychinskiy <alexander_bychinskiy@epam.com>"],"version":"0.2.0"} |
Create, query, comment on, and close tickets on whatever tracker the
project actually uses. This skill is tracker-aware — the same
operation lands in the right system because the dispatch reads
.agents/profile.md.
Before any command, open .agents/profile.md § Project systems §
Issue tracker. Scout's Step 0.7 records one of:
| Value (profile.md) | Default tooling |
|---|---|
github-issues (default) | gh CLI |
gitlab-issues | glab CLI |
jira | Atlassian MCP (create / comment / transition); body must be in ADF |
azure-devops | Azure DevOps MCP (az boards as a fallback) |
linear | Linear CLI (linear) or Linear MCP |
Unconfirmed | Default to gh; surface the gap to the operator so scout can fill the field |
On restrictive hosts (e.g. Copilot CLI), scout's Step 6.8 has already
wired the matching CLI/MCP into the calling agent's tools:
whitelist based on what's actually installed. If the named tracker
has no wired tool, stop and escalate rather than silently falling
back — the right ticket in the wrong tracker is worse than no ticket.
Body shapes are tracker-agnostic markdown — they live in
references/templates.md and are reused
across all trackers. Pick:
[INFO]
severityRender the markdown body, then hand it to the tracker-specific command below. Jira / Azure DevOps require ADF (Atlassian Document Format) rather than markdown — convert via whatever ADF-authoring capability your agent has wired.
Standard flow when the caller is filing a new defect:
.agents/profile.md § Project systems § Issue tracker (see
Step 0 above) and § Bug filing — the latter records:
github-issue (standalone) / story-subtask
(sub-task under a parent story; Jira / ADO only) / separate-ticket
(filed into a dedicated QA/bugs project)separate-ticket, the
destination project/board keyreferences/templates.md.story-subtask, the caller is responsible for
providing the parent story ID; pass it as the parent when invoking
the tracker's create command. For separate-ticket, target the
project named in § Bug filing target.This skill files tickets and posts/queries/closes them. It does not own the in-flight comment language a developer posts while fixing a bug (investigating / reproduced / root-cause / fixed) — that belongs to whatever dev-fix-lifecycle skill the project uses. Callers who need both file the initial defect through this skill, then drive the fix lifecycle separately.
github-issues)gh issue create --title "Short title" --body "$(cat <<'EOF'
<body from references/templates.md>
EOF
)" --label "bug,high-priority"
gitlab-issues)glab issue create --title "Short title" --description "$(cat <<'EOF'
<body from references/templates.md>
EOF
)" --label "bug,high-priority"
jira) — via Atlassian MCPCall the Atlassian MCP's create-issue tool with:
projectKey from .agents/profile.md § Issue tracker keyissueType (Bug / Task / Story / Sub-task)summary (title)description (body — must be ADF, not markdown; convert via the
agent's wired ADF-authoring capability before this call)parentKey for story-subtasklabels / priority per project conventionsazure-devops)Via Azure DevOps MCP or az boards work-item create --type Bug --title "..." --description "..." — same field shape as Jira.
linear)Via Linear MCP or linear issue create --title "..." --description "..." --team <team-key> --label "bug".
The shape is the same across trackers (list / view / search); the command differs. Default examples are GitHub; substitute per Step 0.
# GitHub — default
gh issue list --state open
gh issue list --label "bug" --state open
gh issue list --assignee "@me"
gh issue list --search "auth timeout"
gh issue view 123
# GitLab equivalents
glab issue list --state opened
glab issue list --label "bug"
glab issue list --assignee "@me"
glab issue list --search "auth timeout"
glab issue view 123
# Jira / ADO / Linear — drive list / get via the wired MCP. JQL /
# WIQL / Linear filter syntax replaces the CLI flags.
# GitHub
gh issue comment 123 --body "Status update: PR #456 submitted"
gh issue edit 123 --add-label "in-progress"
gh issue edit 123 --add-assignee username
gh issue close 123 --reason completed
# GitLab
glab issue note 123 -m "Status update: MR !456 submitted"
glab issue update 123 --label "in-progress"
glab issue update 123 --assignee username
glab issue close 123
# Jira — via Atlassian MCP
# - add_comment(issueKey, body_adf)
# - transition_issue(issueKey, transition="In Progress")
# - assign_issue(issueKey, accountId)
# - transition_issue(issueKey, transition="Done")
# Azure DevOps — via ADO MCP / `az boards work-item update`
# Linear — via Linear MCP / `linear issue update`
GitHub / GitLab / Linear have labels; Jira / ADO use components and/or workflow states. Create labels that map to the team's workflow:
# GitHub
gh label create "epic" --color "3E4B9E" --description "Feature epic"
gh label create "task" --color "0E8A16" --description "Implementation task"
gh label create "bug" --color "D73A4A" --description "Something isn't working"
gh label create "high-priority" --color "B60205" --description "Needs attention soon"
gh label create "blocked" --color "FBCA04" --description "Waiting on dependency"
# GitLab
glab label create --name "epic" --color "#3E4B9E" --description "Feature epic"
# … same shape for the rest
For Jira / ADO, labels are configured in the project once — no per- operation create needed. Linear has built-in workflow states; map your team's labels onto those rather than creating ad-hoc ones.
Every meaningful action gets a comment on the ticket — same discipline regardless of tracker.
| Event | Comment prefix |
|---|---|
| Start work | 🔧 **Started**: approach... |
| Progress update | 📝 **Update**: what changed... |
| Blocked | 🚫 **Blocked**: what's needed... |
| Complete | ✅ **Done**: summary, PR link |
| Testing | 🧪 **Testing**: plan... |
| Bug found | 🐛 **Bug**: severity, repro, evidence |
| Verified | ✅ **Verified**: what was tested |
| Assigned | 📬 **Assigned**: to whom |
| Decomposed | 🔨 **Decomposed**: task list |
# GitHub example
gh issue comment 103 --body "🔧 **Started**: Implementing login endpoint using existing auth middleware."
# GitLab example
glab issue note 103 -m "🔧 **Started**: Implementing login endpoint using existing auth middleware."
# Jira / ADO / Linear — same prefix discipline, body posted via the
# wired MCP's add-comment / add-work-item-comment tool.
See references/templates.md for the full
body templates (Bug Report, Task, Epic, Story, Clarification).