[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6H808008XGYTBBXAVWN6YC2":3,"skill-same:01M6H808008XGYTBBXAVWN6YC2":90},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":26,"publishedAt":47,"linkOnly":48,"markdownContent":49,"markdownBody":50,"frontMatter":51,"refName":52,"commitSha":53,"skillDirectory":54,"forksCount":14,"repositoryHtmlUrl":55,"repositoryHomepageUrl":6,"ownerHtmlUrl":56,"ownerBlogUrl":57,"ownerDescription":58,"updatedAt":59,"install":60,"resources":73},"01M6H808008XGYTBBXAVWN6YC2","app-performance-testing",null,"Investigate why this app's HTTP API endpoints are slow and how to make them faster. Discovers the endpoints, measures their response times, works out which layer the time goes to (network, middleware, handler code, database, external calls, cache, serialization) using Grafana metrics, traces, logs and profiles plus the code, and produces a ranked list of fixes. Use whenever the user asks why the app or an endpoint is slow, wants the API to feel snappier, mentions latency, p95, slow queries, N+1, or wants a performance check or audit of the backend, even if they don't say \"performance testing\".","O-Marsters-1997\u002Fmy-claude-code","O-Marsters-1997","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F72571979?v=4","01M6H800V7V9BSXYZKDM0JXTJ2","Olly Marsters","01M6H800ZYDJR42TNRH0E6ZVZ7",0,"MIT","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fcode\u002Fapp-performance-testing\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",[27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46],"performance","app performance testing","app","testing","performance testing","why","which","http api","middleware","how to","time","performance check","code","how","api","network","logs","grafana","audit","database","2026-11-10 10:12:30",false,"---\nname: app-performance-testing\ndescription: >\n  Investigate why this app's HTTP API endpoints are slow and how to make them faster. Discovers\n  the endpoints, measures their response times, works out which layer the time goes to (network,\n  middleware, handler code, database, external calls, cache, serialization) using Grafana metrics,\n  traces, logs and profiles plus the code, and produces a ranked list of fixes. Use whenever the\n  user asks why the app or an endpoint is slow, wants the API to feel snappier, mentions latency,\n  p95, slow queries, N+1, or wants a performance check or audit of the backend, even if they\n  don't say \"performance testing\".\n---\n\n# App performance testing\n\nMeasure single-user endpoint speed, find the layer the time goes to, and rank fixes. The default\nis one request at a time after warm-up, not load. Everything is evidence-led: each conclusion is\nlabelled **measured** (with the evidence) or **inferred from code**, never one passed off as the\nother.\n\nGrafana work is delegated to the Grafana skills when installed (`promql`, `loki`, `tempo`, `k6`,\n`pyroscope`, `performance-rca`). Load the one for the query language you are about to write\ninstead of guessing syntax.\n\n## Per-repo files\n\nThe skill is generic; each app keeps its own facts under `\u003Crepo>\u002F.claude\u002Fperf\u002F`:\n\n| File | Holds |\n|---|---|\n| `app-context.md` | stack, how to start the app, base URLs, env detection, auth, service names, datasource UIDs, production log sources, seeder command, known findings |\n| `grafana-queries.md` | ready-to-run `gcx` commands checked against this app's real metric, label and service names |\n| `endpoints.json` | default endpoint list for `measure_endpoints.py` |\n| `gcx-env.sh` | optional wrapper that feeds `gcx` its credentials from `.env` |\n\nReports go to `\u003Crepo>\u002F.perf-reports\u002F` (gitignored), next to the seeder's `seed-manifest.json`.\n\n**No `app-context.md` yet?** Build it before measuring: read the code for framework, route\ndefinitions, start command, auth and telemetry (OpenTelemetry, Prometheus, Pyroscope,\n`service.name`); read `.env` variable **names** only; ask the user what the code can't show\n(Grafana Cloud or self-hosted, which signals Grafana receives, how to tell laptop from\nproduction, where production logs live). Run `gcx datasources list` and one real query per\nsignal, then write `app-context.md` and `grafana-queries.md` from what actually came back.\nSeeding (step 2) needs an app-side seeder; if there is none, offer to build one with the guard\nrules in *Safety*.\n\n## Workflow\n\n### 1. Load context and detect the environment\n\nRead `.claude\u002Fperf\u002Fapp-context.md`. Detect the mode with the method it records and say which at\nthe start of the run. If a fact is missing, find it or ask, then update the file.\n\n- **Local mode** (the laptop): the full workflow, including seeding, temporary instrumentation\n  (with the user's OK), light concurrency checks and applying fixes.\n- **Production mode** (the VPS, or whenever detection is unclear): read-only investigation with\n  real data. State the limits once, briefly:\n  - Allowed: single-user GET measurements with a small sample (3 warm-up + 5 measured); `gcx`\n    reads; the VPS-only log sources in `app-context.md`, read-only and time-boxed (`--since`,\n    `tail -n`, `grep -m`); `EXPLAIN` (never `EXPLAIN ANALYZE`) through a read-only client.\n  - Not allowed: load or concurrency tests, write requests, changing config, log levels or code,\n    restarts, temporary instrumentation, seeding.\n  - Fixes are **proposed, not applied**: code edited on the VPS conflicts with the git sync.\n    Put them in the report for the laptop to make.\n  - Never print secrets or personal data from logs; summarise instead.\n\n### 2. Prepare data (local mode only)\n\nCheck `.perf-reports\u002Fseed-manifest.json` and current row counts. If the database is empty, small,\nor at a different scale from the one the user wants, offer to reseed with the command in\n`app-context.md` (\"reseed at 10×? wipes dev data\"), and run it after one confirmation per run.\nRecord scale and seed in the report; only compare runs at the same scale and seed. Never seed in\nproduction mode; the seeder refuses too.\n\n### 3. Find endpoints\n\nList routes from the code (method, path, handler file). Start from `.claude\u002Fperf\u002Fendpoints.json`\nand add anything new. Fill path parameters:\n\n- Local: known IDs from the manifest, measuring each relevant endpoint for both the **typical**\n  and the **heavy** record. The heavy case is where slowdowns hide.\n- Production: IDs found read-only in Grafana or logs, or asked for.\n\nShow the list and let the user narrow it.\n\n### 4. Measure from the client side\n\n```bash\npython3 \u003Cskill-dir>\u002Fscripts\u002Fmeasure_endpoints.py .claude\u002Fperf\u002Fendpoints.json \\\n  --base-url \u003Cbase url from app-context.md> --manifest .perf-reports\u002Fseed-manifest.json \\\n  --warmup 3 --samples 10 -o .perf-reports\u002F\u003CYYYY-MM-DD-HHMM>-raw.json\n```\n\nIt records DNS, connect, TLS, TTFB, download and total per request, p50\u002Fp95\u002Fmax, size, status and\neach endpoint's UTC window (to query Grafana for the same window), and flags TTFB p50 >200 ms\nmedium, >500 ms high, >1000 ms critical. It refuses non-GET\u002FHEAD\u002FOPTIONS without\n`--allow-writes`, which it accepts only for local hosts. In production use\n`--warmup 3 --samples 5` and pass a session via `--cookie-env VAR` (the user sets the variable;\nnever echo it).\n\n### 5. Split the time into layers\n\nFor each flagged endpoint, take the best evidence available, in this order:\n\n1. **Client timings.** DNS\u002Fconnect\u002FTLS is network. A big TTFB-to-total gap with a large body\n   points to payload or serialization.\n2. **Traces** (`tempo` skill). Find traces for the route in the window; sum child-span time by\n   kind (DB, HTTP client, cache, other). The remainder is the handler's own code. Count DB spans\n   per request: many near-identical queries means N+1.\n3. **Metrics** (`promql` skill): request duration by route, DB time, pool waits, CPU, GC.\n4. **Profiles** (`performance-rca`, or `pyroscope`): when handler time dominates, find hot\n   functions and map them to files.\n5. **Logs** (`loki` skill): per-request access-log durations, slow-query lines, timeouts and\n   retries in the window. In production, access logs from real users are often better evidence\n   than this skill's handful of requests.\n6. **VPS-only logs** (production mode), from `app-context.md`.\n\nUse `-o json` and narrow windows (measurement window plus a small margin). Check flags with\n`gcx help-tree \u003Csignal> -o text` rather than guessing.\n\n**No telemetry for a layer?** Read the request path in code (route → middleware → service → data\naccess → external calls → serialization) with `references\u002Fbottleneck-checklist.md`, and `EXPLAIN`\nthe queries. Temporary query logging is allowed locally; revert it and list it in the report.\n\n### 6. Find causes and fixes\n\nUse `references\u002Fbottleneck-checklist.md`: N+1, missing indexes, sequential independent calls,\nmissing caching, over-fetching and big payloads, pool limits, CPU-heavy code, blocking I\u002FO. Each\nfix names the file and line, sketches the code, estimates the gain (\"21 queries → 1, roughly\n−150 ms\") and the effort (S\u002FM\u002FL).\n\n### 7. Write the report\n\n`.perf-reports\u002F\u003CYYYY-MM-DD-HHMM>-report.md`, with the raw JSON beside it:\n\n- **Header:** mode; in local mode, data scale and seed.\n- **Summary:** the top 3 wins.\n- **Endpoint table:** method, path, record (typical\u002Fheavy), p50, p95, dominant layer, severity.\n  Every measured endpoint has a p95.\n- **One section per finding**, ranked by impact against effort: evidence (measured or inferred)\n  → cause → fix (file path) → expected gain → effort.\n- **Temporary changes** made and reverted, if any.\n\n### 8. Optional checks (local mode, when asked)\n\n- **Before\u002Fafter:** re-measure after a fix at the same scale and seed.\n- **Scaling test:** seed 1×, measure, reseed 10×, measure; rank endpoints by growth. About 10×\n  slower at 10× data means work proportional to table size (missing index, no pagination, N+1);\n  roughly flat is fine. Often the clearest single signal.\n- **Light concurrency:** 1 → 5 → 10 users with k6 (`k6` skill) to spot pool or lock limits.\n- **Production-like resources:** run the app under the Compose override named in\n  `app-context.md` that caps CPU and memory to the VPS's size.\n\n## Safety\n\nThese protect production data and secrets, so they hold even when the user asks casually:\n\n- **Read-only methods by default.** GET, HEAD and OPTIONS need no permission. POST, PUT, PATCH and\n  DELETE change data: ask per run, local or dev only, test data only, never production. Asked to\n  benchmark writes against production, decline that part and offer local with seeded data.\n- **Single-user speed by default.** Load needs an explicit request and a confirmed local target.\n  Never put load on production.\n- **Seeding is local only.** It wipes data. Check the mode before calling the seeder; the seeder\n  itself must refuse unless the environment says local, the DB host is local and an explicit\n  wipe flag is passed.\n- **Grafana is read-only.** Only `gcx` query, label, list and help commands. Never `gcx\n  resources`, `api`, `alert`, `login`, `datasources create\u002Fupdate\u002Fdelete` or any `adaptive`\n  subcommand. Project deny rules and a Viewer token back this up.\n- **No secrets in output.** Never print `.env` values or session cookies; mask tokens in reports;\n  read credentials from the environment at runtime instead of copying them into files.\n- **Undo temporary changes** (logging flags, timing code) before finishing, and list them.\n","# App performance testing\n\nMeasure single-user endpoint speed, find the layer the time goes to, and rank fixes. The default\nis one request at a time after warm-up, not load. Everything is evidence-led: each conclusion is\nlabelled **measured** (with the evidence) or **inferred from code**, never one passed off as the\nother.\n\nGrafana work is delegated to the Grafana skills when installed (`promql`, `loki`, `tempo`, `k6`,\n`pyroscope`, `performance-rca`). Load the one for the query language you are about to write\ninstead of guessing syntax.\n\n## Per-repo files\n\nThe skill is generic; each app keeps its own facts under `\u003Crepo>\u002F.claude\u002Fperf\u002F`:\n\n| File | Holds |\n|---|---|\n| `app-context.md` | stack, how to start the app, base URLs, env detection, auth, service names, datasource UIDs, production log sources, seeder command, known findings |\n| `grafana-queries.md` | ready-to-run `gcx` commands checked against this app's real metric, label and service names |\n| `endpoints.json` | default endpoint list for `measure_endpoints.py` |\n| `gcx-env.sh` | optional wrapper that feeds `gcx` its credentials from `.env` |\n\nReports go to `\u003Crepo>\u002F.perf-reports\u002F` (gitignored), next to the seeder's `seed-manifest.json`.\n\n**No `app-context.md` yet?** Build it before measuring: read the code for framework, route\ndefinitions, start command, auth and telemetry (OpenTelemetry, Prometheus, Pyroscope,\n`service.name`); read `.env` variable **names** only; ask the user what the code can't show\n(Grafana Cloud or self-hosted, which signals Grafana receives, how to tell laptop from\nproduction, where production logs live). Run `gcx datasources list` and one real query per\nsignal, then write `app-context.md` and `grafana-queries.md` from what actually came back.\nSeeding (step 2) needs an app-side seeder; if there is none, offer to build one with the guard\nrules in *Safety*.\n\n## Workflow\n\n### 1. Load context and detect the environment\n\nRead `.claude\u002Fperf\u002Fapp-context.md`. Detect the mode with the method it records and say which at\nthe start of the run. If a fact is missing, find it or ask, then update the file.\n\n- **Local mode** (the laptop): the full workflow, including seeding, temporary instrumentation\n  (with the user's OK), light concurrency checks and applying fixes.\n- **Production mode** (the VPS, or whenever detection is unclear): read-only investigation with\n  real data. State the limits once, briefly:\n  - Allowed: single-user GET measurements with a small sample (3 warm-up + 5 measured); `gcx`\n    reads; the VPS-only log sources in `app-context.md`, read-only and time-boxed (`--since`,\n    `tail -n`, `grep -m`); `EXPLAIN` (never `EXPLAIN ANALYZE`) through a read-only client.\n  - Not allowed: load or concurrency tests, write requests, changing config, log levels or code,\n    restarts, temporary instrumentation, seeding.\n  - Fixes are **proposed, not applied**: code edited on the VPS conflicts with the git sync.\n    Put them in the report for the laptop to make.\n  - Never print secrets or personal data from logs; summarise instead.\n\n### 2. Prepare data (local mode only)\n\nCheck `.perf-reports\u002Fseed-manifest.json` and current row counts. If the database is empty, small,\nor at a different scale from the one the user wants, offer to reseed with the command in\n`app-context.md` (\"reseed at 10×? wipes dev data\"), and run it after one confirmation per run.\nRecord scale and seed in the report; only compare runs at the same scale and seed. Never seed in\nproduction mode; the seeder refuses too.\n\n### 3. Find endpoints\n\nList routes from the code (method, path, handler file). Start from `.claude\u002Fperf\u002Fendpoints.json`\nand add anything new. Fill path parameters:\n\n- Local: known IDs from the manifest, measuring each relevant endpoint for both the **typical**\n  and the **heavy** record. The heavy case is where slowdowns hide.\n- Production: IDs found read-only in Grafana or logs, or asked for.\n\nShow the list and let the user narrow it.\n\n### 4. Measure from the client side\n\n```bash\npython3 \u003Cskill-dir>\u002Fscripts\u002Fmeasure_endpoints.py .claude\u002Fperf\u002Fendpoints.json \\\n  --base-url \u003Cbase url from app-context.md> --manifest .perf-reports\u002Fseed-manifest.json \\\n  --warmup 3 --samples 10 -o .perf-reports\u002F\u003CYYYY-MM-DD-HHMM>-raw.json\n```\n\nIt records DNS, connect, TLS, TTFB, download and total per request, p50\u002Fp95\u002Fmax, size, status and\neach endpoint's UTC window (to query Grafana for the same window), and flags TTFB p50 >200 ms\nmedium, >500 ms high, >1000 ms critical. It refuses non-GET\u002FHEAD\u002FOPTIONS without\n`--allow-writes`, which it accepts only for local hosts. In production use\n`--warmup 3 --samples 5` and pass a session via `--cookie-env VAR` (the user sets the variable;\nnever echo it).\n\n### 5. Split the time into layers\n\nFor each flagged endpoint, take the best evidence available, in this order:\n\n1. **Client timings.** DNS\u002Fconnect\u002FTLS is network. A big TTFB-to-total gap with a large body\n   points to payload or serialization.\n2. **Traces** (`tempo` skill). Find traces for the route in the window; sum child-span time by\n   kind (DB, HTTP client, cache, other). The remainder is the handler's own code. Count DB spans\n   per request: many near-identical queries means N+1.\n3. **Metrics** (`promql` skill): request duration by route, DB time, pool waits, CPU, GC.\n4. **Profiles** (`performance-rca`, or `pyroscope`): when handler time dominates, find hot\n   functions and map them to files.\n5. **Logs** (`loki` skill): per-request access-log durations, slow-query lines, timeouts and\n   retries in the window. In production, access logs from real users are often better evidence\n   than this skill's handful of requests.\n6. **VPS-only logs** (production mode), from `app-context.md`.\n\nUse `-o json` and narrow windows (measurement window plus a small margin). Check flags with\n`gcx help-tree \u003Csignal> -o text` rather than guessing.\n\n**No telemetry for a layer?** Read the request path in code (route → middleware → service → data\naccess → external calls → serialization) with `references\u002Fbottleneck-checklist.md`, and `EXPLAIN`\nthe queries. Temporary query logging is allowed locally; revert it and list it in the report.\n\n### 6. Find causes and fixes\n\nUse `references\u002Fbottleneck-checklist.md`: N+1, missing indexes, sequential independent calls,\nmissing caching, over-fetching and big payloads, pool limits, CPU-heavy code, blocking I\u002FO. Each\nfix names the file and line, sketches the code, estimates the gain (\"21 queries → 1, roughly\n−150 ms\") and the effort (S\u002FM\u002FL).\n\n### 7. Write the report\n\n`.perf-reports\u002F\u003CYYYY-MM-DD-HHMM>-report.md`, with the raw JSON beside it:\n\n- **Header:** mode; in local mode, data scale and seed.\n- **Summary:** the top 3 wins.\n- **Endpoint table:** method, path, record (typical\u002Fheavy), p50, p95, dominant layer, severity.\n  Every measured endpoint has a p95.\n- **One section per finding**, ranked by impact against effort: evidence (measured or inferred)\n  → cause → fix (file path) → expected gain → effort.\n- **Temporary changes** made and reverted, if any.\n\n### 8. Optional checks (local mode, when asked)\n\n- **Before\u002Fafter:** re-measure after a fix at the same scale and seed.\n- **Scaling test:** seed 1×, measure, reseed 10×, measure; rank endpoints by growth. About 10×\n  slower at 10× data means work proportional to table size (missing index, no pagination, N+1);\n  roughly flat is fine. Often the clearest single signal.\n- **Light concurrency:** 1 → 5 → 10 users with k6 (`k6` skill) to spot pool or lock limits.\n- **Production-like resources:** run the app under the Compose override named in\n  `app-context.md` that caps CPU and memory to the VPS's size.\n\n## Safety\n\nThese protect production data and secrets, so they hold even when the user asks casually:\n\n- **Read-only methods by default.** GET, HEAD and OPTIONS need no permission. POST, PUT, PATCH and\n  DELETE change data: ask per run, local or dev only, test data only, never production. Asked to\n  benchmark writes against production, decline that part and offer local with seeded data.\n- **Single-user speed by default.** Load needs an explicit request and a confirmed local target.\n  Never put load on production.\n- **Seeding is local only.** It wipes data. Check the mode before calling the seeder; the seeder\n  itself must refuse unless the environment says local, the DB host is local and an explicit\n  wipe flag is passed.\n- **Grafana is read-only.** Only `gcx` query, label, list and help commands. Never `gcx\n  resources`, `api`, `alert`, `login`, `datasources create\u002Fupdate\u002Fdelete` or any `adaptive`\n  subcommand. Project deny rules and a Viewer token back this up.\n- **No secrets in output.** Never print `.env` values or session cookies; mask tokens in reports;\n  read credentials from the environment at runtime instead of copying them into files.\n- **Undo temporary changes** (logging flags, timing code) before finishing, and list them.\n",{"name":5,"description":7},"main","aede9f7bc29a2d9127fa7ce29682c242596c7759","skills\u002Fcode\u002Fapp-performance-testing","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997","https:\u002F\u002Fpersonal-portfolio-v2-phi.vercel.app","Go & TypeScript developer building tooling for AI-assisted development: git worktree workflows, Claude Code skills and agent orchestration.","2026-11-11 04:20:46",{"source":8,"skillName":5,"commands":61,"prompt":71,"zipAvailable":72},[62,65,68],{"tool":63,"command":64},"npx","npx skills add O-Marsters-1997\u002Fmy-claude-code --skill app-performance-testing",{"tool":66,"command":67},"bunx","bunx skills add O-Marsters-1997\u002Fmy-claude-code --skill app-performance-testing",{"tool":69,"command":70},"pnpm","pnpm dlx skills add O-Marsters-1997\u002Fmy-claude-code --skill app-performance-testing","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fcode\u002Fapp-performance-testing\u002FSKILL.md",true,[74,80,84],{"path":75,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":78,"sourceHtmlUrl":79},"evals\u002Fevals.json","REFERENCE","参考文档",2530,"https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fcode\u002Fapp-performance-testing\u002Fevals\u002Fevals.json",{"path":81,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":82,"sourceHtmlUrl":83},"references\u002Fbottleneck-checklist.md",3334,"https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fcode\u002Fapp-performance-testing\u002Freferences\u002Fbottleneck-checklist.md",{"path":85,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":88,"sourceHtmlUrl":89},"scripts\u002Fmeasure_endpoints.py","SCRIPT","脚本",7483,"https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fcode\u002Fapp-performance-testing\u002Fscripts\u002Fmeasure_endpoints.py",[91,118,146,173,194,213],{"skillNo":92,"name":93,"nameZh":6,"description":94,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":95,"categories":96,"keywords":97,"publishedAt":47},"01M6H88J6TYRV9T8RKWW569YM8","to-tickets","Breaks a source into independently-grabbable GitHub tickets. For a code feature the source is the plan (`docs\u002Fplans\u002F\u003Cfeature>.md`, from \u002Fto-plan) and every new or changed symbol lands in exactly one ticket, its signatures copied into the ticket body; a non-code feature is cut from the PRD's slices. Cuts tickets for one feature per run. If a code feature has no approved plan, offers \u002Fto-plan instead of cutting from prose. In a repo that runs command-centre, also emits `[[task]]` blocks into its config; in a plain treepad repo, emits a Batch Manifest instead so the tickets materialise as stacked worktrees.","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fto-tickets\u002FSKILL.md",[],[98,99,100,101,39,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117],"to tickets","tickets","github","run","batch","manifest","plan","repo","command","worktrees","task","signatures","feature","plans","as","cut","ticket","true","for","new",{"skillNo":119,"name":120,"nameZh":6,"description":121,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":122,"categories":123,"keywords":127,"publishedAt":47},"01M6H88E98X9KGGYBGSVDS1E8H","to-seams","Records an agreed-but-unlanded cross-repo interface as a seam: the file a consumer's agent gets pasted into its prompt as ground truth, plus the `[[seam]]` block command-centre reads for the retirement pointer. Use when two repos need to build against an interface neither has landed yet — \"record a seam for X\", \"we agreed on this schema, seam it\", \"add a seam so Y can build against Z's new field\". Halts for approval before writing either file.","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fto-seams\u002FSKILL.md",[124],{"categoryNo":125,"categoryName":126,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[128,129,130,131,105,132,106,133,134,135,136,137,138,112,139,140,141,142,115,143,116,144,145,117],"to seams","writing","repos","file","prompt","use","schema","build","but","either","record","records","it","block","interface","can","neither","when",{"skillNo":147,"name":148,"nameZh":6,"description":149,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":150,"categories":151,"keywords":157,"publishedAt":47},"01M6H889PSQM2E1ATS2JC10QRV","to-roadmap","Prioritises settled features into a Now \u002F Next \u002F Later kanban board, rendered as a self-contained .\u002Fideas\u002Froadmap.html. Each card is a feature, not a ticket — one card later becomes several tickets via \u002Fto-prd -> \u002Fto-plan -> \u002Fto-tickets. Boards the features in .\u002Fdocs\u002Fapproach.md, or the \"## Accepted ideas\" in .\u002Fideas\u002FCONTEXT.md when there is no approach doc. The approach doc is settled truth: this assigns tiers and reasons about ordering, it never re-litigates what was decided.","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fto-roadmap\u002FSKILL.md",[152],{"categoryNo":153,"categoryName":154,"taxonomyType":155,"taxonomyTypeDesc":156},"01JBSEEDCAT000000000000031","产品经理","PROFESSION","适用职业",[158,159,160,104,161,162,163,164,165,166,110,112,114,167,168,99,169,170,171,115,172,145],"roadmap","to roadmap","doc","board","never","later","next","self","ideas","via","card","now","about","re","features",{"skillNo":174,"name":175,"nameZh":6,"description":176,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":177,"categories":178,"keywords":180,"publishedAt":47},"01M6H885QAK839Q771ZBKBK1KA","to-prd","Turns one feature idea into a PRD built on journeys: a one-line problem, journeys (each ending in an observable state) and delivery slices that say what is usable after each. Interviews, explores the codebase, and saves to docs\u002Fprds\u002F\u003Cfeature>.md. Covers exactly one feature: given a multi-feature source, ask which one. Reads any approach doc or ideate report as priors so it doesn't re-ask what's settled, but needs none. Starts the per-feature spine (\u002Fto-prd -> \u002Fto-plan -> \u002Fto-tickets).","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fto-prd\u002FSKILL.md",[179],{"categoryNo":153,"categoryName":154,"taxonomyType":155,"taxonomyTypeDesc":156},[181,182,183,184,104,185,186,187,110,112,188,189,99,190,191,192,171,115,33,193],"to prd","prd","report","state","ask","say","delivery","line","problem","spine","multi","interviews","codebase",{"skillNo":195,"name":196,"nameZh":6,"description":197,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":198,"categories":199,"keywords":200,"publishedAt":47},"01M6H881QEEP49HPBMDYDFJQP9","to-plan","Turns one feature's PRD into a skimmable plan in docs\u002Fplans\u002F\u003Cfeature>.md: a short overview, then per phase a glossary, the journeys it satisfies, and its new and modified definitions (types, enums, ports, schema), with the project:\u003Cslug> label. No code, branch or PR; the user's review of the file is the gate. Use for \"plan this feature\", \"write the contract\", \"what are the types\". One feature per run. Slash-only.","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fto-plan\u002FSKILL.md",[],[104,201,202,39,131,203,204,205,206,207,133,134,208,209,210,110,111,211,115,116,212,117],"to plan","pr","ports","glossary","branch","short","overview","only","project","contract","types","\u003Cslug>",{"skillNo":214,"name":215,"nameZh":6,"description":216,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":217,"categories":218,"keywords":219,"publishedAt":47},"01M6H87XEQEXSGT0PR5QWQZZ5P","ticket-tracker","Use when the request is about the *current state* of GitHub issues rather than creating new ones: \"where are my tickets\", \"show the board\", \"what's in progress\", \"what's ready to pick up\", \"move issue N to in-review\", \"mark N done\", \"update the ticket status\". Live triage board over GitHub issues via the gh CLI, moving each between backlog -> ready -> in-progress -> in-review -> done using status labels. This is the ticket-level board; .\u002Fideas\u002Froadmap.html is the feature-level one. To file new tickets, use \u002Fto-tickets, file-issue for a single ad-hoc one, or \u002Fsweep for a batch of small fixes.","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fticket-tracker\u002FSKILL.md",[],[220,114,221,222,223,224,225,226,102,131,227,228,133,229,158,230,231,232,233,166,110,234,235,116,236,237,238,145,117],"tracker","ticket tracker","review","cli","current state","update","issues","gh","pick","ready","up","show","done","backlog","progress","move","fixes","labels","request"]