[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CP3VG0B2HGD6AM6BTNGG7Y":3,"skill-same:01M6CP3VG0B2HGD6AM6BTNGG7Y":76},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":48,"linkOnly":49,"markdownContent":50,"markdownBody":51,"frontMatter":52,"refName":53,"commitSha":54,"skillDirectory":55,"forksCount":56,"repositoryHtmlUrl":57,"repositoryHomepageUrl":58,"ownerHtmlUrl":59,"ownerBlogUrl":60,"ownerDescription":6,"updatedAt":61,"install":62,"resources":75},"01M6CP3VG0B2HGD6AM6BTNGG7Y","project-doc",null,"Track any non-trivial task through a doc placed in the right domain directory under docs\u002F (models\u002F\u003Cline>\u002F, subsystems\u002F\u003Carea>\u002F, playbooks\u002F, lessons\u002F, etc.). Covers the full lifecycle: read docs first, write a plan, wait for approval, log execution, and capture lessons learned. Use this skill whenever the user gives a concrete task — not just Q&A or casual discussion. Even if the task seems straightforward, if it involves doing something (not just answering something), open or reuse a domain doc. Bias toward using this skill. When in doubt, use it.","pegainfer-project\u002Fpegainfer","pegainfer-project","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F292134277?v=4","01M6CP3N2567A4DACEYMN5W8S0","01M6CP3N66CWB0M39SGYE63S7D",739,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fpegainfer-project\u002Fpegainfer\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fproject-doc-bootstrap\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47],"doc","project","project doc","use","when","track","for","q&a","wait","line","learned","full","domain","task","models","log","directory","approval","user","write","read","capture","just","wait for","plan","open","lifecycle","first","execution","docs","2026-11-10 10:12:30",false,"---\nname: project-doc\ndescription: >\n  Track any non-trivial task through a doc placed in the right domain directory\n  under docs\u002F (models\u002F\u003Cline>\u002F, subsystems\u002F\u003Carea>\u002F, playbooks\u002F, lessons\u002F, etc.).\n  Covers the full lifecycle: read docs first, write a plan, wait for approval,\n  log execution, and capture lessons learned.\n  Use this skill whenever the user gives a concrete task — not just Q&A or\n  casual discussion. Even if the task seems straightforward, if it involves\n  doing something (not just answering something), open or reuse a domain doc.\n  Bias toward using this skill. When in doubt, use it.\n---\n\n# Project Doc\n\n## Why This Exists\n\nEvery task is an opportunity to learn something or repeat a past mistake.\nThis skill ensures three things:\n\n1. **You read before you act.** The repo has accumulated knowledge in docs\u002F.\n   Ignoring it means rediscovering problems that were already solved.\n2. **The human approves before you execute.** This is an async workflow —\n   the human needs to see and approve the plan before work begins.\n3. **What happened gets recorded.** After execution, the doc captures what\n   worked, what didn't, and what to remember next time.\n\n## When To Use\n\nUse this skill when the user gives a task that involves *doing* something —\nwriting code, running commands, debugging, deploying, refactoring, setting up,\nfixing, creating, modifying, testing, or investigating.\n\nDo not use it for:\n- Pure questions (\"what does this function do?\")\n- Casual discussion or brainstorming with no action item\n- Continuing work on a task that already has an active project doc open in context\n\nWhen in doubt, use it. An unnecessary project doc costs a minute.\nA missed one costs repeated mistakes.\n\n## Lifecycle\n\n```\nPrepare → Review Gate → Execute → Debrief\n```\n\nYou must not skip phases or combine them. Each phase ends with a clear\nhandoff to the user.\n\n---\n\n## Phase 1: Prepare\n\n### 1.1 Read the index\n\nRead `docs\u002Findex.md`. Every time, no exceptions. Use it to identify which\nother documents are relevant to this task.\n\n### 1.2 Read relevant docs\n\nBased on the index, read the minimal set of documents that could inform\nthis task. Think about:\n\n- Is there a doc about the model line or subsystem being touched\n  (`docs\u002Fmodels\u002F\u003Cline>\u002F`, `docs\u002Fsubsystems\u002F\u003Carea>\u002F`)?\n- Is there a relevant playbook or lesson (`docs\u002Fplaybooks\u002F`, `docs\u002Flessons\u002F`)?\n- Is there a past task doc on similar work in the same domain directory?\n- If writing code or scripts, are there existing implementations to learn from?\n\nBe honest about what you read. Only list files you actually opened.\n\n### 1.3 Find or create the task doc\n\nDecide where the doc belongs using the classification rule in `CLAUDE.md`\n(model line \u002F subsystem \u002F playbook \u002F lesson \u002F benchmark \u002F roadmap). If a doc\nin that directory already covers this task, reuse it.\n\n- Exists and active → reuse it, update the Preparation section.\n- Nothing matches → create a new file with a descriptive slug in the\n  appropriate directory.\n  Examples:\n    - `docs\u002Fmodels\u002Fqwen35\u002Ffix-decode-state-leak.md`\n    - `docs\u002Fsubsystems\u002Fscheduler\u002Fchunked-prefill.md`\n    - `docs\u002Fplaybooks\u002Fnsys-trace-collection.md`\n\n### 1.4 Write the Preparation section\n\n```markdown\n## Preparation\n\n- **Read**:\n  - `path\u002Fto\u002Fdoc` — what it told us\n  - `path\u002Fto\u002Fdoc` — what it told us\n- **Relevant history**:\n  - `docs\u002F\u003Cdomain>\u002Fpast-task.md` — learned that X causes Y\n  - (or: no relevant past docs found)\n- **Plan**:\n  1. Concrete step with specifics (files, commands, resources)\n  2. Concrete step\n  3. Concrete step\n- **Risks \u002F open questions**:\n  - What could go wrong or what's still unknown\n  - (omit section if genuinely none)\n```\n\nRules:\n- **Read** — only files you actually opened. No padding.\n- **Relevant history** — past project docs, known pitfalls, lessons learned.\n  This is how you avoid repeating mistakes. Look for them.\n- **Plan** — concrete and specific. \"Investigate the issue\" is not a plan step.\n  *How* will you investigate? What will you look at? What commands will you run?\n- **Risks** — if something might go wrong or you're unsure about something,\n  say so now. It's much cheaper to catch it here than during execution.\n\n### 1.5 Stop and ask for review\n\nPresent a short summary and explicitly ask the user to approve before\nyou do anything.\n\nFormat:\n\n```\n? Task doc: `docs\u002F\u003Cdomain>\u002F\u003Cname>.md`\n\nRead:\n- `docs\u002Findex.md`\n- `\u003Cother files>`\n\nPlan:\n1. ...\n2. ...\n\nRisks: \u003Cone-liner or \"none identified\">\n\nPlease review before I start.\n```\n\n**Do not proceed until the user explicitly approves.**\n\n---\n\n## Phase 2: Execute\n\nOnce approved, do the work. As you go, maintain an execution log in\nthe project doc:\n\n```markdown\n## Execution Log\n\n### Step 1: \u003Cwhat you planned>\n- What you actually did\n- Commands run, files modified\n- Result: success \u002F partial \u002F failed\n\n### Step 2: ...\n\n### Unexpected\n- Anything that surprised you or deviated from the plan\n- Errors encountered and how you resolved them\n- Things that were harder or easier than expected\n```\n\nRules:\n- Log as you go, not after the fact.\n- Be specific: include actual error messages, actual file paths,\n  actual command output (abbreviated if very long).\n- If you deviate from the plan, note why.\n- If you hit a problem that blocks progress, stop and ask the user\n  rather than guessing.\n\n---\n\n## Phase 3: Debrief\n\nAfter execution is complete (or if you're blocked and stopping), write\nthe debrief section:\n\n```markdown\n## Debrief\n\n- **Outcome**: What was accomplished (or not)\n- **Pitfalls encountered**:\n  - What went wrong or was unexpectedly tricky\n  - Root cause if known\n- **Lessons learned**:\n  - What should be remembered for next time\n  - What docs should be updated\n- **Follow-ups**:\n  - Any remaining work or related tasks\n  - (omit if none)\n```\n\nThis is the most important section for long-term value. A project doc\nwithout a debrief is just a to-do list. The debrief is what prevents\nthe same mistake from happening twice.\n\nPresent the debrief to the user as a summary when the task is done.\n\n---\n\n## File Template\n\nWhen creating a new task doc, use this structure:\n\n```markdown\n# \u003CTask Title>\n\n> **TL;DR:** One-line summary. Keep it true as the task progresses — that's\n> the only thing readers can rely on.\n>\n> **Last touched:** YYYY-MM   \u003C!-- only for docs\u002Fmodels\u002F and docs\u002Fsubsystems\u002F -->\n\n## Preparation\n\n(filled in Phase 1)\n\n## Execution Log\n\n(filled in Phase 2)\n\n## Debrief\n\n(filled in Phase 3)\n```\n\nUpdate the **TL;DR** whenever the headline state of the work changes. Bump\n**Last touched** when you do real work on the doc (skip it for typo fixes).\nAdd a new row to `docs\u002Findex.md` when creating the doc; only update an\nexisting row if its TL;DR has become actively misleading.\n\n---\n\n## Principles\n\n- **Read first, act second.** The cost of reading a doc is minutes.\n  The cost of not reading it is hours of debugging something already solved.\n- **Be honest about what you don't know.** Flagging uncertainty in\n  Preparation is a feature, not a weakness.\n- **Log the ugly parts.** The errors, the wrong turns, the surprises —\n  these are the most valuable things to record.\n- **The debrief is not optional.** Even for tasks that went smoothly,\n  write one. \"Everything went as planned, no issues\" is a valid debrief.\n  But write it.\n","# Project Doc\n\n## Why This Exists\n\nEvery task is an opportunity to learn something or repeat a past mistake.\nThis skill ensures three things:\n\n1. **You read before you act.** The repo has accumulated knowledge in docs\u002F.\n   Ignoring it means rediscovering problems that were already solved.\n2. **The human approves before you execute.** This is an async workflow —\n   the human needs to see and approve the plan before work begins.\n3. **What happened gets recorded.** After execution, the doc captures what\n   worked, what didn't, and what to remember next time.\n\n## When To Use\n\nUse this skill when the user gives a task that involves *doing* something —\nwriting code, running commands, debugging, deploying, refactoring, setting up,\nfixing, creating, modifying, testing, or investigating.\n\nDo not use it for:\n- Pure questions (\"what does this function do?\")\n- Casual discussion or brainstorming with no action item\n- Continuing work on a task that already has an active project doc open in context\n\nWhen in doubt, use it. An unnecessary project doc costs a minute.\nA missed one costs repeated mistakes.\n\n## Lifecycle\n\n```\nPrepare → Review Gate → Execute → Debrief\n```\n\nYou must not skip phases or combine them. Each phase ends with a clear\nhandoff to the user.\n\n---\n\n## Phase 1: Prepare\n\n### 1.1 Read the index\n\nRead `docs\u002Findex.md`. Every time, no exceptions. Use it to identify which\nother documents are relevant to this task.\n\n### 1.2 Read relevant docs\n\nBased on the index, read the minimal set of documents that could inform\nthis task. Think about:\n\n- Is there a doc about the model line or subsystem being touched\n  (`docs\u002Fmodels\u002F\u003Cline>\u002F`, `docs\u002Fsubsystems\u002F\u003Carea>\u002F`)?\n- Is there a relevant playbook or lesson (`docs\u002Fplaybooks\u002F`, `docs\u002Flessons\u002F`)?\n- Is there a past task doc on similar work in the same domain directory?\n- If writing code or scripts, are there existing implementations to learn from?\n\nBe honest about what you read. Only list files you actually opened.\n\n### 1.3 Find or create the task doc\n\nDecide where the doc belongs using the classification rule in `CLAUDE.md`\n(model line \u002F subsystem \u002F playbook \u002F lesson \u002F benchmark \u002F roadmap). If a doc\nin that directory already covers this task, reuse it.\n\n- Exists and active → reuse it, update the Preparation section.\n- Nothing matches → create a new file with a descriptive slug in the\n  appropriate directory.\n  Examples:\n    - `docs\u002Fmodels\u002Fqwen35\u002Ffix-decode-state-leak.md`\n    - `docs\u002Fsubsystems\u002Fscheduler\u002Fchunked-prefill.md`\n    - `docs\u002Fplaybooks\u002Fnsys-trace-collection.md`\n\n### 1.4 Write the Preparation section\n\n```markdown\n## Preparation\n\n- **Read**:\n  - `path\u002Fto\u002Fdoc` — what it told us\n  - `path\u002Fto\u002Fdoc` — what it told us\n- **Relevant history**:\n  - `docs\u002F\u003Cdomain>\u002Fpast-task.md` — learned that X causes Y\n  - (or: no relevant past docs found)\n- **Plan**:\n  1. Concrete step with specifics (files, commands, resources)\n  2. Concrete step\n  3. Concrete step\n- **Risks \u002F open questions**:\n  - What could go wrong or what's still unknown\n  - (omit section if genuinely none)\n```\n\nRules:\n- **Read** — only files you actually opened. No padding.\n- **Relevant history** — past project docs, known pitfalls, lessons learned.\n  This is how you avoid repeating mistakes. Look for them.\n- **Plan** — concrete and specific. \"Investigate the issue\" is not a plan step.\n  *How* will you investigate? What will you look at? What commands will you run?\n- **Risks** — if something might go wrong or you're unsure about something,\n  say so now. It's much cheaper to catch it here than during execution.\n\n### 1.5 Stop and ask for review\n\nPresent a short summary and explicitly ask the user to approve before\nyou do anything.\n\nFormat:\n\n```\n? Task doc: `docs\u002F\u003Cdomain>\u002F\u003Cname>.md`\n\nRead:\n- `docs\u002Findex.md`\n- `\u003Cother files>`\n\nPlan:\n1. ...\n2. ...\n\nRisks: \u003Cone-liner or \"none identified\">\n\nPlease review before I start.\n```\n\n**Do not proceed until the user explicitly approves.**\n\n---\n\n## Phase 2: Execute\n\nOnce approved, do the work. As you go, maintain an execution log in\nthe project doc:\n\n```markdown\n## Execution Log\n\n### Step 1: \u003Cwhat you planned>\n- What you actually did\n- Commands run, files modified\n- Result: success \u002F partial \u002F failed\n\n### Step 2: ...\n\n### Unexpected\n- Anything that surprised you or deviated from the plan\n- Errors encountered and how you resolved them\n- Things that were harder or easier than expected\n```\n\nRules:\n- Log as you go, not after the fact.\n- Be specific: include actual error messages, actual file paths,\n  actual command output (abbreviated if very long).\n- If you deviate from the plan, note why.\n- If you hit a problem that blocks progress, stop and ask the user\n  rather than guessing.\n\n---\n\n## Phase 3: Debrief\n\nAfter execution is complete (or if you're blocked and stopping), write\nthe debrief section:\n\n```markdown\n## Debrief\n\n- **Outcome**: What was accomplished (or not)\n- **Pitfalls encountered**:\n  - What went wrong or was unexpectedly tricky\n  - Root cause if known\n- **Lessons learned**:\n  - What should be remembered for next time\n  - What docs should be updated\n- **Follow-ups**:\n  - Any remaining work or related tasks\n  - (omit if none)\n```\n\nThis is the most important section for long-term value. A project doc\nwithout a debrief is just a to-do list. The debrief is what prevents\nthe same mistake from happening twice.\n\nPresent the debrief to the user as a summary when the task is done.\n\n---\n\n## File Template\n\nWhen creating a new task doc, use this structure:\n\n```markdown\n# \u003CTask Title>\n\n> **TL;DR:** One-line summary. Keep it true as the task progresses — that's\n> the only thing readers can rely on.\n>\n> **Last touched:** YYYY-MM   \u003C!-- only for docs\u002Fmodels\u002F and docs\u002Fsubsystems\u002F -->\n\n## Preparation\n\n(filled in Phase 1)\n\n## Execution Log\n\n(filled in Phase 2)\n\n## Debrief\n\n(filled in Phase 3)\n```\n\nUpdate the **TL;DR** whenever the headline state of the work changes. Bump\n**Last touched** when you do real work on the doc (skip it for typo fixes).\nAdd a new row to `docs\u002Findex.md` when creating the doc; only update an\nexisting row if its TL;DR has become actively misleading.\n\n---\n\n## Principles\n\n- **Read first, act second.** The cost of reading a doc is minutes.\n  The cost of not reading it is hours of debugging something already solved.\n- **Be honest about what you don't know.** Flagging uncertainty in\n  Preparation is a feature, not a weakness.\n- **Log the ugly parts.** The errors, the wrong turns, the surprises —\n  these are the most valuable things to record.\n- **The debrief is not optional.** Even for tasks that went smoothly,\n  write one. \"Everything went as planned, no issues\" is a valid debrief.\n  But write it.\n",{"name":5,"description":7},"main","2246b2ac1ed98ec92c408ff51ce7b33d4b255971",".agents\u002Fskills\u002Fproject-doc-bootstrap",120,"https:\u002F\u002Fgithub.com\u002Fpegainfer-project\u002Fpegainfer","https:\u002F\u002Fpegainfer.org\u002F","https:\u002F\u002Fgithub.com\u002Fpegainfer-project","https:\u002F\u002Fopen-infer.org\u002F","2026-11-12 03:48:06",{"source":8,"skillName":5,"commands":63,"prompt":73,"zipAvailable":74},[64,67,70],{"tool":65,"command":66},"npx","npx skills add pegainfer-project\u002Fpegainfer --skill project-doc",{"tool":68,"command":69},"bunx","bunx skills add pegainfer-project\u002Fpegainfer --skill project-doc",{"tool":71,"command":72},"pnpm","pnpm dlx skills add pegainfer-project\u002Fpegainfer --skill project-doc","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fpegainfer-project\u002Fpegainfer\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fproject-doc-bootstrap\u002FSKILL.md",true,[],[77,85,119,143,149],{"skillNo":78,"name":79,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":80,"categories":81,"keywords":82,"publishedAt":48},"01M6CP47ZZ9G8N4YW1AEW11QRQ","nsys-profiling","https:\u002F\u002Fgithub.com\u002Fpegainfer-project\u002Fpegainfer\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Fnsys-profiling\u002FSKILL.md",[],[83,84],"nsys profiling","profiling",{"skillNo":86,"name":87,"nameZh":6,"description":88,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":89,"categories":90,"keywords":96,"publishedAt":48},"01M6CP44T5R6WV38NVEEXAJ5RV","vllm-bench","Use vllm-bench to benchmark OpenAI-compatible or vLLM serving endpoints, especially multi-turn chat load tests. Use when the user asks for vllm bench, vllm-bench, multi-turn benchmark, chat serving benchmark, TTFT\u002FTPOT\u002Fthroughput measurement, concurrency sweep, load test, 压测, 多轮压测, or wants help installing, running --help, choosing flags, validating a local PegaInfer\u002FvLLM server, saving JSON results, or interpreting vllm-bench metrics.","https:\u002F\u002Fgithub.com\u002Fpegainfer-project\u002Fpegainfer\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fvllm-bench\u002FSKILL.md",[91],{"categoryNo":92,"categoryName":93,"taxonomyType":94,"taxonomyTypeDesc":95},"01JBSEEDCAT000000000000010","后端与接口","SCENARIO","使用场景",[97,98,99,100,101,102,103,104,105,106,107,108,22,24,109,110,111,112,113,114,115,116,21,36,117,118],"vllm bench","vLLM","concurrency","server","metrics","openai","help","benchmark","test","json","tests","running","load","vllm server","measurement","openai-compatible","throughput","local","flags","endpoints","results","sweep",{"skillNo":120,"name":79,"nameZh":6,"description":121,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":122,"categories":123,"keywords":125,"publishedAt":48},"01M6CP41N22W0PPT3F3T032JQZ","Profile GPU workloads with NVIDIA Nsight Systems (nsys). Use this skill when the user says 'profile', 'nsys', 'capture a trace', 'GPU profiling', 'kernel breakdown', 'where is time spent', 'decode is slow', 'prefill is slow', 'TPOT regression', 'TTFT regression', or wants to understand where GPU time is going. Also trigger when the user pastes nsys output and asks for help interpreting it. This skill covers the full lifecycle: capturing traces with the right flags, analyzing kernel\u002FAPI summaries, detecting tail latency problems, and diagnosing performance regressions.","https:\u002F\u002Fgithub.com\u002Fpegainfer-project\u002Fpegainfer\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fnsys-profiling\u002FSKILL.md",[124],{"categoryNo":92,"categoryName":93,"taxonomyType":94,"taxonomyTypeDesc":95},[83,84,126,127,22,128,129,24,130,131,132,29,133,115,21,134,36,39,135,136,137,44,138,139,140,103,141,142],"breakdown","prefill","gpu profiling","summaries","detecting","systems","latency","regression","profile","trace","time","api","analyzing","NVIDIA","gpu","performance","kernel",{"skillNo":144,"name":87,"nameZh":6,"description":88,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":145,"categories":146,"keywords":148,"publishedAt":48},"01M6CP3YKSBD68R742QN3915C9","https:\u002F\u002Fgithub.com\u002Fpegainfer-project\u002Fpegainfer\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fvllm-bench\u002FSKILL.md",[147],{"categoryNo":92,"categoryName":93,"taxonomyType":94,"taxonomyTypeDesc":95},[97,98,103,105,104,100,22,24,109,110,111,112,113,107,114,108,115,116,21,36,117,118,106,99,102,101],{"skillNo":150,"name":79,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":151,"categories":152,"keywords":153,"publishedAt":48},"01M6CP3QVJ2MHXRM1SBXVGQNTK","https:\u002F\u002Fgithub.com\u002Fpegainfer-project\u002Fpegainfer\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fnsys-profiling\u002FSKILL.md",[],[83,84]]