[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M754G1M7ME416A88V3EX42GD":3,"skill-same:01M754G1M7ME416A88V3EX42GD":61},{"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":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":27,"commitSha":28,"skillDirectory":29,"forksCount":30,"repositoryHtmlUrl":31,"repositoryHomepageUrl":32,"ownerHtmlUrl":33,"ownerBlogUrl":34,"ownerDescription":35,"updatedAt":36,"install":37,"resources":50},"01M754G1M7ME416A88V3EX42GD","perf-mcp-interpretation",null,"Interpret the mecatl perf MCP server's output to diagnose latency, goroutine leaks, GC pressure, allocation churn, and memory growth in a running mecatl harness. Use when connected to the mecatl perf MCP server (the perf:\u002F\u002F resources or the query_metric \u002F top_cpu_functions \u002F capture_cpu_profile \u002F top_allocations \u002F list_slow_turns \u002F capture_flight_recorder tools) and investigating why mecatl is slow, leaking, or growing. Covers tool routing\u002Fcost, reading pprof rankings and runtime metrics, and the leak\u002Fcontention\u002FGC signatures. NOT for generic Go profiling or non-mecatl MCP servers.","stacklok\u002Fmecatl","stacklok","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F110237746?v=4","01M754F1F8WJJZYJ0WZ73C7PBS","Stacklok","01M754F1GGDR6FG8K1RZ8SR2NA",309,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fstacklok\u002Fmecatl\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fperf-mcp-interpretation\u002FSKILL.md",[],[],"2026-11-12 13:55:43",false,"---\nname: perf-mcp-interpretation\ndescription: >-\n  Interpret the mecatl perf MCP server's output to diagnose latency, goroutine\n  leaks, GC pressure, allocation churn, and memory growth in a running mecatl\n  harness. Use when connected to the mecatl perf MCP server (the perf:\u002F\u002F resources\n  or the query_metric \u002F top_cpu_functions \u002F capture_cpu_profile \u002F top_allocations \u002F\n  list_slow_turns \u002F capture_flight_recorder tools) and investigating why mecatl is\n  slow, leaking, or growing. Covers tool routing\u002Fcost, reading pprof rankings and\n  runtime metrics, and the leak\u002Fcontention\u002FGC signatures. NOT for generic Go\n  profiling or non-mecatl MCP servers.\nmetadata:\n  audience: an AI agent driving or debugging a mecatl harness over the perf MCP server\ncompatibility: Requires a connection to the mecatl perf MCP server (mecated\u002Fmecatui --perf-mcp, mounted at \u002Fmcp on the loopback admin listener).\n---\n\n# Interpreting mecatl perf MCP output\n\nmecatl is a **streaming agentic loop**. Its time is dominated by *off-CPU* waiting\n(on the model and on tool I\u002FO), so the usual \"run a CPU profile first\" instinct\nmeasures the wrong thing. Diagnose by reading cheap numeric state first, and reach\nfor the perturbing CPU tools only with a hypothesis to confirm.\n\n## Cost discipline — what to call, in what order\n\n1. **Start cheap, read state.** `perf:\u002F\u002Fruntime\u002Fsummary` (goroutines, heap, GC,\n   RSS, uptime) and `perf:\u002F\u002Fmetrics\u002Fsummary` (latency-histogram quantiles) are\n   free, point-in-time reads. Read them first, and re-read `perf:\u002F\u002Fruntime\u002Fsummary`\n   a few times to see *trends* — a single snapshot rarely diagnoses anything.\n2. **Cheap tools next.** `query_metric` (one curated metric; omit `metric_name` to\n   list names), `top_allocations` (heap rankings, no profiling window),\n   `list_slow_turns` (per-turn timing) are all cheap and unlimited.\n3. **Perturbing tools last.** `top_cpu_functions` and `capture_cpu_profile` start a\n   live CPU profile that PERTURBS the process for `duration_seconds`, and are\n   **rate limited to one capture per cooldown window** across both tools. Call them\n   only to confirm a hypothesis, not to explore. A rate-limit hit comes back as an\n   `isError` result saying to retry — wait, do not retry-spam.\n4. **Never ingest raw blobs.** `capture_cpu_profile` (with `include_raw_link`) and\n   `capture_flight_recorder` return a **user-audience `resource_link`** to a\n   loopback `\u002Fdebug\u002F...` endpoint. That link now surfaces as a **TYPED BLOCK the\n   model can see** (URI + name + description) rather than a bare URI — but the\n   model still receives only the reduced summary, never the raw blob bytes. A human\n   downloads the linked artifact (with `go tool pprof` \u002F `go tool trace`); if the\n   link is `https:\u002F\u002F` the model MAY fetch it via the `FetchMcpResource` tool\n   (SSRF-validated through `ValidateMediaURL`). The `perf:\u002F\u002F` resources on this\n   server are NOT https and stay server-readonly via `ReadMcpResource`. Do NOT\n   try to read a linked raw artifact into model context; report the summary and\n   point the user at the link (or fetch an https link only if you genuinely need\n   its contents). If a perf tool's JSON result is large and you only need a subset\n   of fields, filter it **in memory** with `CallMcpWithQuery` (server + tool +\n   `jq_filter`) rather than narrowing the call — it runs the remote tool and\n   applies a jq filter before the result enters context.\n\n## The MCP surface (what is actually there)\n\n**Resources** (cheap, read-only, JSON):\n- `perf:\u002F\u002Fruntime\u002Fsummary` — goroutines, num_cpu, gomaxprocs, heap_allocs_total_bytes,\n  heap_objects, total_memory_bytes, heap_object_bytes, gc_pause_count,\n  `gc_pause_p99_upper_bound_ns`, `rss_bytes`, uptime_seconds, `available[]`.\n  Note: `heap_allocs_total_bytes` is a cumulative COUNTER (bytes ever allocated)\n  — a huge value (100+ GB on a long-lived process) is normal, not a leak; the\n  leak signal is the `rss_bytes` \u002F `heap_object_bytes` slope.\n- `perf:\u002F\u002Fruntime\u002Fmemstats` — memory-focused projection (heap_allocs_total_bytes,\n  heap_objects, heap_object_bytes, total_memory_bytes, rss_bytes, available[]).\n- `perf:\u002F\u002Fmetrics\u002Fsummary` — every curated metric reduced: histograms → count +\n  p50\u002Fp90\u002Fp99 **bucket upper bounds (seconds)**; counters\u002Fgauges → a scalar value.\n  Histograms and the `tool_calls_total`\u002F`tokens`\u002F`turns_total`\u002F`turn_empty_total`\u002F\n  `active_runs` counters also carry a bounded `by_role`\n  breakdown over the CLOSED engine role family\n  `main|subagent|member|parallel|usermodel|child` (the main engine vs the\n  delegation children — the axis for \"which agent family is burning\n  latency\u002Ftokens\"; never a session id or agent-def name).\n- `perf:\u002F\u002Fpprof\u002F{profile}` — template, `{profile}` ∈ `heap|goroutine|allocs|mutex|block`;\n  reduced top-15 functions (function, file basename, flat\u002Fcum values).\n\n**Tools** (all read-only):\n- `query_metric{metric_name?, quantile?, role?}` — one curated metric; aggregated\n  across all roles by default, or one role family's share with `role`.\n- `top_cpu_functions{duration_seconds?, limit?}` — **perturbs**, rate-limited.\n- `capture_cpu_profile{duration_seconds?, limit?, include_raw_link?}` — **perturbs**, rate-limited.\n- `top_allocations{limit?}` — heap top-N + total_heap_bytes.\n- `list_slow_turns{threshold_ms?, limit?, cursor?, role?}` — cursor-paginated,\n  newest first; each turn carries its bounded role family.\n- `capture_flight_recorder{}` — size + one-line summary + user link (needs `--flight-recorder`).\n\nSee [references\u002Foutput-shapes.md](references\u002Foutput-shapes.md) for the exact field\nnames of every tool's output (FuncStat, AllocStat, SlowTurn, MetricSummaryEntry).\n\n## Honest-precision caveat — do not over-trust the numbers\n\nEvery histogram quantile this server returns (in `perf:\u002F\u002Fmetrics\u002Fsummary`,\n`query_metric`, and `gc_pause_p99_upper_bound_ns`) is the **upper bound of the\nbucket the quantile rank falls in — NOT an interpolated exact quantile**. The\nfield is literally named `upper_bound` for this reason. Read p99 as \"at worst this\nbucket's ceiling,\" not an exact value. Report it as an upper bound.\n\n## Interpreting the signatures\n\nThe full signature → diagnosis → next-step table is in\n[references\u002Fsignatures.md](references\u002Fsignatures.md). Read it when you have a\nsymptom to match. The essentials:\n\n- **Off-CPU workload.** This loop mostly waits on the model\u002FIO, so high CPU in\n  **JSON decode\u002Fmarshal, markdown render, or chunk decode** is the real signal in\n  a CPU profile — that is on-CPU work on the hot streaming path. Rank by `flat`\n  (self time) for the hot leaf; use `cum` (includes callees) to find the\n  responsible caller.\n- **Goroutine leak.** `goroutines` rising monotonically across successive\n  `perf:\u002F\u002Fruntime\u002Fsummary` reads (not just spiking during a run) = a leak. Read\n  `perf:\u002F\u002Fpprof\u002Fgoroutine` to see which functions hold the stuck goroutines; this\n  corroborates the live goroutine watchdog.\n- **Off-heap growth (the WASM-leak signature).** `rss_bytes` climbing while\n  `heap_object_bytes` \u002F `total_memory_bytes` stay flat = growth **off the Go heap**,\n  invisible to pprof\u002Fheap and runtime metrics. (The historical cause was the\n  RepoMap\u002Ftree-sitter WASM tool, since **removed**, but the pattern still stands\n  for any off-heap consumer.)\n- **GC-driven jitter.** `gc_pause_p99_upper_bound_ns` spikes and a rising\n  `gc_pause_count`, alongside high `top_allocations` on the streaming\u002Fchunk-decode\n  path, explain inter-token jitter — GC pauses land between tokens.\n- **User-felt latency = TTFT vs inter-token, split.** Read `ttft_seconds` and\n  `inter_token_max_seconds` separately (the mean hides both). High `ttft` = slow\n  first byte; high `inter_token_max` = stutter the user feels mid-stream.\n- **Dispatch contention.** `mecatl_tool_queue_seconds` (short name `tool_queue_seconds`)\n  rising **together with** `tool_duration_seconds` p99 = the read-parallel \u002F\n  mutate-serial dispatcher is queueing: a slow mutating tool serially blocks\n  queued mutations. Queue time without duration is just load; both together is the\n  contention signal.\n- **Tail latency.** Averages lie. Use `list_slow_turns` to find the actual tail\n  turns, then `capture_flight_recorder` **right after a slow turn** to hand the\n  human a trace window covering it.\n\n## Presence vs a real zero\n\n`available[]` in the runtime\u002Fmemstats snapshots lists which runtime\u002Fmetrics fields\nwere actually published by this toolchain. A field absent from `available[]` was\n**not measured**; a field present with value 0 is a **real zero**. `gc_pause_count`\nis legitimately 0 before the first GC. `query_metric` returns an `isError`\n\"not present yet\" for a metric with no observations — that means no relevant\nactivity has happened, not that the metric is broken.\n\n## Workflow\n\n1. Read `perf:\u002F\u002Fruntime\u002Fsummary` and `perf:\u002F\u002Fmetrics\u002Fsummary`.\n2. Match the symptom against the signatures above \u002F `references\u002Fsignatures.md`.\n3. Confirm with the cheap tool for that signature (`top_allocations`, `query_metric`,\n   `list_slow_turns`, `perf:\u002F\u002Fpprof\u002Fgoroutine`).\n4. Only if you need function-level CPU attribution, spend the rate-limited\n   `top_cpu_functions` \u002F `capture_cpu_profile` once.\n5. Report findings as numbers + an upper-bound caveat; point the user at any raw\n   `resource_link` rather than ingesting it.\n","# Interpreting mecatl perf MCP output\n\nmecatl is a **streaming agentic loop**. Its time is dominated by *off-CPU* waiting\n(on the model and on tool I\u002FO), so the usual \"run a CPU profile first\" instinct\nmeasures the wrong thing. Diagnose by reading cheap numeric state first, and reach\nfor the perturbing CPU tools only with a hypothesis to confirm.\n\n## Cost discipline — what to call, in what order\n\n1. **Start cheap, read state.** `perf:\u002F\u002Fruntime\u002Fsummary` (goroutines, heap, GC,\n   RSS, uptime) and `perf:\u002F\u002Fmetrics\u002Fsummary` (latency-histogram quantiles) are\n   free, point-in-time reads. Read them first, and re-read `perf:\u002F\u002Fruntime\u002Fsummary`\n   a few times to see *trends* — a single snapshot rarely diagnoses anything.\n2. **Cheap tools next.** `query_metric` (one curated metric; omit `metric_name` to\n   list names), `top_allocations` (heap rankings, no profiling window),\n   `list_slow_turns` (per-turn timing) are all cheap and unlimited.\n3. **Perturbing tools last.** `top_cpu_functions` and `capture_cpu_profile` start a\n   live CPU profile that PERTURBS the process for `duration_seconds`, and are\n   **rate limited to one capture per cooldown window** across both tools. Call them\n   only to confirm a hypothesis, not to explore. A rate-limit hit comes back as an\n   `isError` result saying to retry — wait, do not retry-spam.\n4. **Never ingest raw blobs.** `capture_cpu_profile` (with `include_raw_link`) and\n   `capture_flight_recorder` return a **user-audience `resource_link`** to a\n   loopback `\u002Fdebug\u002F...` endpoint. That link now surfaces as a **TYPED BLOCK the\n   model can see** (URI + name + description) rather than a bare URI — but the\n   model still receives only the reduced summary, never the raw blob bytes. A human\n   downloads the linked artifact (with `go tool pprof` \u002F `go tool trace`); if the\n   link is `https:\u002F\u002F` the model MAY fetch it via the `FetchMcpResource` tool\n   (SSRF-validated through `ValidateMediaURL`). The `perf:\u002F\u002F` resources on this\n   server are NOT https and stay server-readonly via `ReadMcpResource`. Do NOT\n   try to read a linked raw artifact into model context; report the summary and\n   point the user at the link (or fetch an https link only if you genuinely need\n   its contents). If a perf tool's JSON result is large and you only need a subset\n   of fields, filter it **in memory** with `CallMcpWithQuery` (server + tool +\n   `jq_filter`) rather than narrowing the call — it runs the remote tool and\n   applies a jq filter before the result enters context.\n\n## The MCP surface (what is actually there)\n\n**Resources** (cheap, read-only, JSON):\n- `perf:\u002F\u002Fruntime\u002Fsummary` — goroutines, num_cpu, gomaxprocs, heap_allocs_total_bytes,\n  heap_objects, total_memory_bytes, heap_object_bytes, gc_pause_count,\n  `gc_pause_p99_upper_bound_ns`, `rss_bytes`, uptime_seconds, `available[]`.\n  Note: `heap_allocs_total_bytes` is a cumulative COUNTER (bytes ever allocated)\n  — a huge value (100+ GB on a long-lived process) is normal, not a leak; the\n  leak signal is the `rss_bytes` \u002F `heap_object_bytes` slope.\n- `perf:\u002F\u002Fruntime\u002Fmemstats` — memory-focused projection (heap_allocs_total_bytes,\n  heap_objects, heap_object_bytes, total_memory_bytes, rss_bytes, available[]).\n- `perf:\u002F\u002Fmetrics\u002Fsummary` — every curated metric reduced: histograms → count +\n  p50\u002Fp90\u002Fp99 **bucket upper bounds (seconds)**; counters\u002Fgauges → a scalar value.\n  Histograms and the `tool_calls_total`\u002F`tokens`\u002F`turns_total`\u002F`turn_empty_total`\u002F\n  `active_runs` counters also carry a bounded `by_role`\n  breakdown over the CLOSED engine role family\n  `main|subagent|member|parallel|usermodel|child` (the main engine vs the\n  delegation children — the axis for \"which agent family is burning\n  latency\u002Ftokens\"; never a session id or agent-def name).\n- `perf:\u002F\u002Fpprof\u002F{profile}` — template, `{profile}` ∈ `heap|goroutine|allocs|mutex|block`;\n  reduced top-15 functions (function, file basename, flat\u002Fcum values).\n\n**Tools** (all read-only):\n- `query_metric{metric_name?, quantile?, role?}` — one curated metric; aggregated\n  across all roles by default, or one role family's share with `role`.\n- `top_cpu_functions{duration_seconds?, limit?}` — **perturbs**, rate-limited.\n- `capture_cpu_profile{duration_seconds?, limit?, include_raw_link?}` — **perturbs**, rate-limited.\n- `top_allocations{limit?}` — heap top-N + total_heap_bytes.\n- `list_slow_turns{threshold_ms?, limit?, cursor?, role?}` — cursor-paginated,\n  newest first; each turn carries its bounded role family.\n- `capture_flight_recorder{}` — size + one-line summary + user link (needs `--flight-recorder`).\n\nSee [references\u002Foutput-shapes.md](references\u002Foutput-shapes.md) for the exact field\nnames of every tool's output (FuncStat, AllocStat, SlowTurn, MetricSummaryEntry).\n\n## Honest-precision caveat — do not over-trust the numbers\n\nEvery histogram quantile this server returns (in `perf:\u002F\u002Fmetrics\u002Fsummary`,\n`query_metric`, and `gc_pause_p99_upper_bound_ns`) is the **upper bound of the\nbucket the quantile rank falls in — NOT an interpolated exact quantile**. The\nfield is literally named `upper_bound` for this reason. Read p99 as \"at worst this\nbucket's ceiling,\" not an exact value. Report it as an upper bound.\n\n## Interpreting the signatures\n\nThe full signature → diagnosis → next-step table is in\n[references\u002Fsignatures.md](references\u002Fsignatures.md). Read it when you have a\nsymptom to match. The essentials:\n\n- **Off-CPU workload.** This loop mostly waits on the model\u002FIO, so high CPU in\n  **JSON decode\u002Fmarshal, markdown render, or chunk decode** is the real signal in\n  a CPU profile — that is on-CPU work on the hot streaming path. Rank by `flat`\n  (self time) for the hot leaf; use `cum` (includes callees) to find the\n  responsible caller.\n- **Goroutine leak.** `goroutines` rising monotonically across successive\n  `perf:\u002F\u002Fruntime\u002Fsummary` reads (not just spiking during a run) = a leak. Read\n  `perf:\u002F\u002Fpprof\u002Fgoroutine` to see which functions hold the stuck goroutines; this\n  corroborates the live goroutine watchdog.\n- **Off-heap growth (the WASM-leak signature).** `rss_bytes` climbing while\n  `heap_object_bytes` \u002F `total_memory_bytes` stay flat = growth **off the Go heap**,\n  invisible to pprof\u002Fheap and runtime metrics. (The historical cause was the\n  RepoMap\u002Ftree-sitter WASM tool, since **removed**, but the pattern still stands\n  for any off-heap consumer.)\n- **GC-driven jitter.** `gc_pause_p99_upper_bound_ns` spikes and a rising\n  `gc_pause_count`, alongside high `top_allocations` on the streaming\u002Fchunk-decode\n  path, explain inter-token jitter — GC pauses land between tokens.\n- **User-felt latency = TTFT vs inter-token, split.** Read `ttft_seconds` and\n  `inter_token_max_seconds` separately (the mean hides both). High `ttft` = slow\n  first byte; high `inter_token_max` = stutter the user feels mid-stream.\n- **Dispatch contention.** `mecatl_tool_queue_seconds` (short name `tool_queue_seconds`)\n  rising **together with** `tool_duration_seconds` p99 = the read-parallel \u002F\n  mutate-serial dispatcher is queueing: a slow mutating tool serially blocks\n  queued mutations. Queue time without duration is just load; both together is the\n  contention signal.\n- **Tail latency.** Averages lie. Use `list_slow_turns` to find the actual tail\n  turns, then `capture_flight_recorder` **right after a slow turn** to hand the\n  human a trace window covering it.\n\n## Presence vs a real zero\n\n`available[]` in the runtime\u002Fmemstats snapshots lists which runtime\u002Fmetrics fields\nwere actually published by this toolchain. A field absent from `available[]` was\n**not measured**; a field present with value 0 is a **real zero**. `gc_pause_count`\nis legitimately 0 before the first GC. `query_metric` returns an `isError`\n\"not present yet\" for a metric with no observations — that means no relevant\nactivity has happened, not that the metric is broken.\n\n## Workflow\n\n1. Read `perf:\u002F\u002Fruntime\u002Fsummary` and `perf:\u002F\u002Fmetrics\u002Fsummary`.\n2. Match the symptom against the signatures above \u002F `references\u002Fsignatures.md`.\n3. Confirm with the cheap tool for that signature (`top_allocations`, `query_metric`,\n   `list_slow_turns`, `perf:\u002F\u002Fpprof\u002Fgoroutine`).\n4. Only if you need function-level CPU attribution, spend the rate-limited\n   `top_cpu_functions` \u002F `capture_cpu_profile` once.\n5. Report findings as numbers + an upper-bound caveat; point the user at any raw\n   `resource_link` rather than ingesting it.\n",{"name":5,"metadata":24,"description":7,"compatibility":26},{"audience":25},"an AI agent driving or debugging a mecatl harness over the perf MCP server","Requires a connection to the mecatl perf MCP server (mecated\u002Fmecatui --perf-mcp, mounted at \u002Fmcp on the loopback admin listener).","main","c4ff786a7467eb2315de679ae78711d118775383",".claude\u002Fskills\u002Fperf-mcp-interpretation",29,"https:\u002F\u002Fgithub.com\u002Fstacklok\u002Fmecatl","https:\u002F\u002Fmecatl.dev","https:\u002F\u002Fgithub.com\u002Fstacklok","https:\u002F\u002Fstacklok.com","Open Source AI Innovation, Grounded in Trust.","2026-11-15 04:19:54",{"source":8,"skillName":5,"commands":38,"prompt":48,"zipAvailable":49},[39,42,45],{"tool":40,"command":41},"npx","npx skills add stacklok\u002Fmecatl --skill perf-mcp-interpretation",{"tool":43,"command":44},"bunx","bunx skills add stacklok\u002Fmecatl --skill perf-mcp-interpretation",{"tool":46,"command":47},"pnpm","pnpm dlx skills add stacklok\u002Fmecatl --skill perf-mcp-interpretation","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fstacklok\u002Fmecatl\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fperf-mcp-interpretation\u002FSKILL.md",true,[51,57],{"path":52,"resourceType":53,"resourceTypeDesc":54,"sizeBytes":55,"sourceHtmlUrl":56},"references\u002Foutput-shapes.md","REFERENCE","参考文档",7263,"https:\u002F\u002Fgithub.com\u002Fstacklok\u002Fmecatl\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fperf-mcp-interpretation\u002Freferences\u002Foutput-shapes.md",{"path":58,"resourceType":53,"resourceTypeDesc":54,"sizeBytes":59,"sourceHtmlUrl":60},"references\u002Fsignatures.md",4548,"https:\u002F\u002Fgithub.com\u002Fstacklok\u002Fmecatl\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fperf-mcp-interpretation\u002Freferences\u002Fsignatures.md",[62,69,76,83,90,97],{"skillNo":63,"name":64,"nameZh":6,"description":65,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":66,"categories":67,"keywords":68,"publishedAt":19},"01M754GX1DCZR950M0SJFD048A","repo-fact","Use when asked for this repository's registered fact or codeword. Loads the canonical answer format.","https:\u002F\u002Fgithub.com\u002Fstacklok\u002Fmecatl\u002Fblob\u002Fmain\u002Fe2e\u002Ffixtures\u002Fskills\u002Frepo-fact\u002FSKILL.md",[],[],{"skillNo":70,"name":71,"nameZh":6,"description":72,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":73,"categories":74,"keywords":75,"publishedAt":19},"01M754GSSV3ACG56M3XWT5F2PD","greet","Use when asked to greet someone with the ceremonial mecatl greeting. Loads the exact greeting format.","https:\u002F\u002Fgithub.com\u002Fstacklok\u002Fmecatl\u002Fblob\u002Fmain\u002Fe2e\u002Ffixtures\u002Fskills\u002Fgreet\u002FSKILL.md",[],[],{"skillNo":77,"name":78,"nameZh":6,"description":79,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":80,"categories":81,"keywords":82,"publishedAt":19},"01M754GPQN80V07DGCPCB7P2XX","go-table-tests","Write idiomatic table-driven Go tests that stay offline and follow this repo's conventions.","https:\u002F\u002Fgithub.com\u002Fstacklok\u002Fmecatl\u002Fblob\u002Fmain\u002Fdocs\u002Fexamples\u002Fskills\u002Fgo-table-tests\u002FSKILL.md",[],[],{"skillNo":84,"name":85,"nameZh":6,"description":86,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":87,"categories":88,"keywords":89,"publishedAt":19},"01M754GMQM60ARRZ0251WD6JN8","commit-style","Write Conventional-Commits messages for this repo, with the required Co-Authored-By trailer.","https:\u002F\u002Fgithub.com\u002Fstacklok\u002Fmecatl\u002Fblob\u002Fmain\u002Fdocs\u002Fexamples\u002Fskills\u002Fcommit-style\u002FSKILL.md",[],[],{"skillNo":91,"name":92,"nameZh":6,"description":93,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":94,"categories":95,"keywords":96,"publishedAt":19},"01M754GGFCQ3AWR3HHHSN3C91C","tech-writer","Use when writing or substantively editing user-facing documentation: drafting a new page, rewriting or restructuring an existing one, adding a major section, or turning engineering material (PR descriptions, specs, release notes, rough notes) into docs. Writes clear, focused technical documentation following the Diataxis framework and Mecatl's canonical style guide. Use it even when the request doesn't mention writing quality; it governs how documentation gets written. Not for editorial review of finished work.","https:\u002F\u002Fgithub.com\u002Fstacklok\u002Fmecatl\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Ftech-writer\u002FSKILL.md",[],[],{"skillNo":98,"name":99,"nameZh":6,"description":100,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":101,"categories":102,"keywords":103,"publishedAt":19},"01M754G7VD9JBS4NVFNGREHP64","perf-optimization","Profile-driven performance optimization of mecatl using the offline benchmark + scenario harness. Use when optimizing allocations or latency, reducing allocs\u002Fop or memory, profiling a Go benchmark, pinpointing a hotspot with pprof, proving a win with benchstat, adding a regression benchmark, wiring profile-guided optimization (PGO), or investigating \"why is this slow \u002F allocating\" or a suspected perf regression. Covers task bench, task perf:scenarios, memprofile -> pprof, benchstat A\u002FB, allocs-first gating, PGO setup, and the discipline (follow the profile not the hypothesis; keep pure-perf changes byte-identical; mutation-test cache guards; skip the wrong abstraction). NOT for the live perf MCP server (use perf-mcp-interpretation) or non-mecatl Go profiling.","https:\u002F\u002Fgithub.com\u002Fstacklok\u002Fmecatl\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fperf-optimization\u002FSKILL.md",[],[]]