Initial release: triage and map-repo skills, zeus knowledge profile, Jira routing config
This commit is contained in:
Murphy Freelance
62
skills/map-repo/SKILL.md
Normal file
62
skills/map-repo/SKILL.md
Normal file
@@ -0,0 +1,62 @@
|
||||
---
|
||||
name: map-repo
|
||||
description: Use when generating or refreshing a codebase's triage profile for the gw-triage plugin — run from inside the repo to map. Triggers on /map-repo, "mappa questo repo", "aggiorna il profilo di triage".
|
||||
---
|
||||
|
||||
# Map-repo — profilo di triage del codebase
|
||||
|
||||
You generate a triage knowledge profile for the repo the user is in,
|
||||
and guide them to publish it to the gw-triage plugin repo.
|
||||
|
||||
**All interaction with the user happens in Italian.** The generated
|
||||
profile is written in English (it is read by the triage model, not by
|
||||
humans).
|
||||
|
||||
## Step 1 — Identify the repo
|
||||
|
||||
- `git rev-parse --show-toplevel` — if not a git repo, ask (Italian)
|
||||
to cd into the repo to map and stop.
|
||||
- Repo name = basename of the toplevel, lowercased.
|
||||
|
||||
## Step 2 — Survey
|
||||
|
||||
Read `${CLAUDE_PLUGIN_ROOT}/knowledge/README.md` (the profile format).
|
||||
Dispatch ONE exploration subagent with this prompt, filling <repo-path>:
|
||||
|
||||
> Survey the codebase at <repo-path> to build a triage profile.
|
||||
> Report back, with file evidence: (1) what the system does — main
|
||||
> responsibility in one line; (2) user-visible surfaces: screens /
|
||||
> pages / endpoints / dashboards a user might screenshot, with their
|
||||
> on-screen titles and labels; (3) error presentation: how failures
|
||||
> appear to users — banners, dialogs, toasts, their exact wording in
|
||||
> every language present, HTTP/gRPC codes surfaced, what a crash looks
|
||||
> like; (4) the domain vocabulary users see (menu labels, entity
|
||||
> names, Italian terms); (5) integrations that fail visibly (payments,
|
||||
> chat, auth, push notifications); (6) what this system does NOT do —
|
||||
> adjacent systems it talks to and symptoms that belong to them.
|
||||
> Return a structured report; do not write any file.
|
||||
|
||||
## Step 3 — Write the profile
|
||||
|
||||
Write `<repo-name>.md` following the six headings of
|
||||
`knowledge/README.md`, all sections non-empty, 100–200 lines, English.
|
||||
Write it to a temporary location first (the session scratchpad or
|
||||
/tmp). Present a short Italian summary to the user with the file path.
|
||||
|
||||
## Step 4 — Publish
|
||||
|
||||
Ask (Italian) for the local path of the user's gw-triage checkout;
|
||||
offer to `git clone <plugin-repo-url>` if they don't have one (read
|
||||
the URL from `git remote get-url origin` run in
|
||||
`${CLAUDE_PLUGIN_ROOT}` if available, otherwise ask).
|
||||
|
||||
With the user's confirmation, in the checkout:
|
||||
1. Copy the profile to `knowledge/<repo-name>.md` (overwrite if
|
||||
refreshing).
|
||||
2. Bump the patch version in `.claude-plugin/plugin.json`
|
||||
(e.g. 0.1.0 → 0.1.1).
|
||||
3. `git add knowledge/<repo-name>.md .claude-plugin/plugin.json`
|
||||
then `git commit -m "knowledge: add/update <repo-name> profile"`
|
||||
— ask before committing, and ask again before `git push`.
|
||||
4. Tell the user (Italian) that teammates receive the update with
|
||||
`/plugin marketplace update gw-triage`.
|
||||
127
skills/triage/SKILL.md
Normal file
127
skills/triage/SKILL.md
Normal file
@@ -0,0 +1,127 @@
|
||||
---
|
||||
name: triage
|
||||
description: Use when converting a bug report or feature request — a screenshot and/or a short message, typically forwarded from the company Telegram chat — into a Jira issue routed to the right developer. Triggers on /gw-triage:triage, "crea una issue da questo", "segnala questo bug", or a pasted/dropped Telegram report with intent to track it.
|
||||
---
|
||||
|
||||
# Triage — da segnalazione a issue Jira
|
||||
|
||||
You convert an informal report (screenshot + short message) into a
|
||||
well-formed Jira issue assigned to the right developer.
|
||||
|
||||
**All interaction with the user happens in Italian.** This file is
|
||||
English for precision; never quote it to the user.
|
||||
|
||||
The Atlassian MCP tools referenced below live under the
|
||||
`mcp__plugin_atlassian_atlassian__` prefix. If they are deferred, load
|
||||
them in ONE ToolSearch call before Step 0:
|
||||
`select:mcp__plugin_atlassian_atlassian__getAccessibleAtlassianResources,mcp__plugin_atlassian_atlassian__searchJiraIssuesUsingJql,mcp__plugin_atlassian_atlassian__createJiraIssue,mcp__plugin_atlassian_atlassian__addCommentToJiraIssue`
|
||||
|
||||
## Step 0 — Preflight
|
||||
|
||||
1. Call `getAccessibleAtlassianResources`. If the tool is missing or
|
||||
returns an authentication error, STOP and print this guide in
|
||||
Italian, then end the turn:
|
||||
- installa il plugin Atlassian: `/plugin install atlassian@claude-plugins-official`
|
||||
- esegui `/mcp`, seleziona `atlassian` e completa il login nel browser con l'account aziendale
|
||||
- poi rilancia `/gw-triage:triage`
|
||||
2. Run `test -n "$JIRA_EMAIL" && test -n "$JIRA_API_TOKEN" && echo ok || echo missing`.
|
||||
If `missing`: continue, but tell the user (Italian) that the
|
||||
screenshot cannot be attached automatically and point them to the
|
||||
"Token API Jira" section of the plugin README
|
||||
(`${CLAUDE_PLUGIN_ROOT}/README.md`) — show the 4 token steps inline,
|
||||
once, then proceed.
|
||||
|
||||
## Step 1 — Input
|
||||
|
||||
Expect a short message (usually Italian) and optionally a screenshot.
|
||||
- Screenshot given as a file path (dragged into the prompt): Read it
|
||||
for analysis and keep the path for Step 7.
|
||||
- Pasted image (no path): analyze it; warn (Italian) that the
|
||||
attachment will be skipped — it can be dragged into Jira manually.
|
||||
- No screenshot: proceed on the text alone.
|
||||
- Neither message nor screenshot: ask (Italian) for at least one.
|
||||
|
||||
## Step 2 — Load routing and knowledge
|
||||
|
||||
Read `${CLAUDE_PLUGIN_ROOT}/config/routing.json` and every `.md` file
|
||||
in `${CLAUDE_PLUGIN_ROOT}/knowledge/` except `README.md`.
|
||||
|
||||
## Step 3 — Classify
|
||||
|
||||
Decide, using the knowledge profiles (error fingerprints, symptom
|
||||
heuristics, glossaries, "not mine" sections):
|
||||
- **type**: `Bug` (something broken) or `Task` (feature request /
|
||||
change / improvement)
|
||||
- **area**: exactly one key from `routing.json` `areas`.
|
||||
|
||||
Platform rules for app issues: visible Android UI or device →
|
||||
`app-android`; visible iOS UI or device → `app-ios`; app issue with no
|
||||
platform signal → `app-shared`.
|
||||
|
||||
If genuinely uncertain between two areas, ask the user ONE targeted
|
||||
question in Italian (e.g. "Succede solo su iOS o anche su Android?").
|
||||
Never more than one question; otherwise decide and state the assumption
|
||||
in the draft.
|
||||
|
||||
If no knowledge profile covers the symptoms, classify using the routing.json area list alone and state the lower confidence explicitly in the draft.
|
||||
|
||||
## Step 4 — Duplicate check
|
||||
|
||||
Extract 2–4 distinctive keywords (include Italian and English variants
|
||||
of domain terms). Call `searchJiraIssuesUsingJql` with:
|
||||
`project = <projectKey> AND text ~ "<keywords>" AND statusCategory != Done ORDER BY created DESC`
|
||||
(maxResults 10). Judge similarity by symptom, not wording.
|
||||
|
||||
If a likely duplicate exists: show it (key, title, status) and ask
|
||||
(Italian) whether to comment on it instead of creating a new issue.
|
||||
If yes → `addCommentToJiraIssue` with the new report's details (and
|
||||
note the screenshot can't be attached to a comment automatically),
|
||||
report the link, stop.
|
||||
|
||||
## Step 5 — Draft (Italian)
|
||||
|
||||
Build and present:
|
||||
- **Titolo**: concise imperative, e.g. "Correggere overflow nella
|
||||
schermata prenotazioni su Android".
|
||||
- **Descrizione** with sections:
|
||||
- *Contesto* — source of the report (chat Telegram, date, reporter
|
||||
if known)
|
||||
- *Passi per riprodurre* — inferred from screenshot/message; mark
|
||||
inferred steps explicitly ("(dedotto dallo screenshot)")
|
||||
- *Comportamento atteso / osservato*
|
||||
- *Screenshot* — one line describing what it shows
|
||||
- **Tipo**: Bug or Task. **Epic**: from routing area. **Assegnatario**:
|
||||
from routing area.
|
||||
|
||||
Show the complete draft and ask ONE confirmation (sì / correggi …).
|
||||
Apply corrections; re-confirm only if the area changed (it changes
|
||||
epic and assignee).
|
||||
|
||||
## Step 6 — Create
|
||||
|
||||
Call `createJiraIssue` with: `cloudId`, `projectKey`, `issueTypeName`
|
||||
(`Bug` or `Task`), `summary`, `description`, the area's
|
||||
`assignee.accountId`, and `additional_fields: {"parent": {"key": "<area epic>"}}`.
|
||||
|
||||
If the call fails, report the raw error with a one-line Italian
|
||||
summary and stop — nothing partial to clean up (the attachment step
|
||||
only runs after successful creation).
|
||||
|
||||
## Step 7 — Attach screenshot
|
||||
|
||||
Only if Step 0 found the env vars AND the screenshot is a file path:
|
||||
|
||||
curl -s -o /tmp/gw-triage-attach.json -w "%{http_code}" -X POST \
|
||||
-H "X-Atlassian-Token: no-check" \
|
||||
-u "$JIRA_EMAIL:$JIRA_API_TOKEN" \
|
||||
-F "file=@<screenshot-path>" \
|
||||
"<site>/rest/api/3/issue/<ISSUE-KEY>/attachments"
|
||||
|
||||
`<site>` comes from routing.json. Success = HTTP 200. Any failure is
|
||||
non-fatal: tell the user (Italian) to drag the image into the Jira
|
||||
issue manually.
|
||||
|
||||
## Step 8 — Report
|
||||
|
||||
Print in Italian: issue key with link `<site>/browse/<KEY>`, type,
|
||||
epic, assignee, and whether the screenshot was attached.
|
||||
Reference in New Issue
Block a user