[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6KMDJNF2XFW5VKNHT5KGA7M":3,"skill-same:01M6KMDJNF2XFW5VKNHT5KGA7M":75},{"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":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":52,"repositoryHtmlUrl":53,"repositoryHomepageUrl":6,"ownerHtmlUrl":54,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":55,"install":56,"resources":68},"01M6KMDJNF2XFW5VKNHT5KGA7M","velocity",null,"Systematic DX improvement hunt — find friction, inconsistency, and missing abstractions across PRs, code, or tickets, then feed findings into \u002Fimprove. Use when looking for ways to accelerate development or compound Claude Code's utility.","Tetra-Research\u002Fjig","Tetra-Research","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F146581685?v=4","01M6KM4EG0ZAWRDQPSJZ4T4CWN","Tetra Research","01M6KM4EMC95A68J3CRCKTDNZD",6,"MIT","https:\u002F\u002Fgithub.com\u002FTetra-Research\u002Fjig\u002Fblob\u002Fmain\u002Fskills\u002Fvelocity\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"module","improvement","for","true","Accelerate","utility","ticket","missing","scope","id","component","across","hunt","dx","use","improve","Bash","code","development","2026-11-10 10:12:30",false,"---\nname: velocity\ndescription: Systematic DX improvement hunt — find friction, inconsistency, and missing abstractions across PRs, code, or tickets, then feed findings into \u002Fimprove. Use when looking for ways to accelerate development or compound Claude Code's utility.\nallowed-tools: Read Write Edit Glob Grep Bash Agent WebFetch AskUserQuestion\ndisable-model-invocation: true\nargument-hint: [scope — e.g. \"my PRs\", \"backend\u002Fmodule\u002Fcomponent\", \"\u003Cticket-id>\"]\n---\n\n# Velocity Hunt\n\nSystematically find DX friction, inconsistency, and missing abstractions — then turn findings into Claude Code extensions via `\u002Fimprove`.\n\n## Step 1: Scope the Hunt\n\nBefore investigating anything, interview the user to define a clear scope. Do not start exploring until you have agreement on what to look at.\n\nAsk: **\"What do you want me to look at?\"**\n\nOffer concrete options based on what's available:\n\n- **Your recent PRs** — `gh pr list --author=@me --state=merged --limit=20`\n- **A specific PR** — user provides a URL or number\n- **Recent team PRs** — `gh pr list --state=merged --limit=30`\n- **A codebase area** — user points at a directory or domain\n- **CODEOWNERS domain** — pick a team\u002Farea from CODEOWNERS and cover what they own\n- **Linear tickets** — look at recent tickets for a team or label for recurring pain\n\nIf `$ARGUMENTS` is provided, use it to seed the conversation — but still confirm scope before investigating.\n\n### If the user pushes back on scoping\n\nExplain why: *\"Without a scope, I'll either look at everything superficially or go deep on the wrong thing. A velocity hunt works best when it's focused — we can always run another one on a different area. What's been causing you the most friction lately?\"*\n\n### Ask about themes\n\nOnce you have the scope, ask: **\"Are there any themes you care about most within that area?\"** Examples:\n\n- Error handling consistency\n- Testing patterns\n- API endpoint structure\n- Missing documentation or conventions\n- Onboarding friction for new developers\n- Repeated manual workflows\n\nIf they have themes, focus the investigation there. If not, explore broadly within the scope.\n\n### Calibrate depth\n\nAsk how deep they want to go:\n- **Quick scan** — skim for obvious patterns (10-15 min of investigation)\n- **Thorough hunt** — read code, trace patterns across files, check for consistency (30+ min)\n\n## Step 2: Investigate\n\n**Use subagents aggressively.** Every distinct theme or codebase area should be explored by its own subagent via the Agent tool. This preserves the main session's context window for synthesis and the user conversation. Launch subagents in parallel whenever the areas are independent.\n\nExamples:\n- Scope is \"recent PRs\" with 3 themes → 3 parallel subagents, one per theme\n- Scope is a codebase area → subagent per subdirectory or per concern (patterns, consistency, tooling gaps)\n- Scope is CODEOWNERS domain → subagent per owned path\n\nEach subagent should return a structured summary: what it found, where (file:line), frequency, and a one-sentence friction assessment. You synthesize and rank the results in the main session.\n\nYou're looking for:\n\n- **Repeated patterns** — same boilerplate appearing 3+ times that could be a skill, generator, or abstraction\n- **Inconsistency** — the same thing done 3 different ways across the codebase\n- **Missing tooling** — workflows where Claude (or the developer) has to do manual steps that could be automated\n- **Convention drift** — established patterns that newer code isn't following\n- **Friction points** — things that are tedious, error-prone, or require tribal knowledge\n- **Skills\u002Frules gaps** — places where a Claude Code extension would prevent recurring mistakes\n\nRead `${CLAUDE_SKILL_DIR}\u002Freferences\u002Fevaluation.md` for heuristics on evaluating what you find.\n\n### What you're NOT looking for\n\n- Bugs (that's triage)\n- Performance problems (that's profiling)\n- One-off code smells (not worth systematizing)\n- Patterns that have appeared only 1-2 times (wait for the third)\n\n## Step 3: Present Findings\n\nPresent each finding in conversation with this structure:\n\n**Finding: [title]**\n- **Pattern**: What you observed (with file\u002Fline references)\n- **Frequency**: How often this appears \u002F how many instances\n- **Friction**: What this costs in time, consistency, or correctness\n- **Extension type**: What kind of Claude Code extension would fix this (skill, rule, agent, hook, CLAUDE.md)\n- **Effort**: Low \u002F Medium \u002F High to implement the extension\n\nRank findings by impact. Lead with the most valuable ones.\n\n## Step 4: Handoff to \u002Fimprove\n\nThis is where findings become real. The approach depends on how many actionable findings there are.\n\n### Single finding\n\nOffer to feed it directly into `\u002Fimprove` in the current session. You already have the context — the problem statement, code references, and frequency data. Transition naturally: present the finding, ask if they want to act on it, then shift into the improve workflow.\n\n### Multiple findings (2+)\n\nRecommend this workflow:\n\n1. **Write a temporary findings doc** — create `.claude\u002Fvelocity-findings.md` with all findings and a pre-built `\u002Fimprove` prompt for each one. Format each prompt so the user can copy-paste it into a new Claude session:\n\n```markdown\n## Finding: [title]\n[problem statement, references, frequency data]\n\n### Improve prompt\n> \u002Fimprove [concise description of the problem, what extension type to create, and which files\u002FPRs to use as references]\n```\n\n2. **Create a branch** — `git checkout -b velocity\u002FYYYY-MM-DD`\n3. **Work through findings** — the user runs `\u002Fimprove` for each finding (either in this session or new ones), creating extensions one at a time\n4. **PR description** — when they're ready to merge, include the findings summary in the PR description so reviewers understand the motivation\n5. **Clean up** — delete `.claude\u002Fvelocity-findings.md` before merging. The findings doc is scaffolding, not a permanent artifact. The extensions themselves are the durable output.\n\n### Always offer both paths\n\nSome users will want to knock out one finding and come back later. Others will want to batch. Let them choose.\n\n## Gotchas\n\n- **Don't codify tech debt.** You're investigating the codebase to find friction, not to find \"good examples.\" When you spot a pattern, evaluate whether it's a good pattern worth systematizing or a bad pattern worth replacing. If in doubt, ask the user.\n- **3+ occurrences is the threshold.** If a pattern has appeared once or twice, it's not worth abstracting yet. Note it and move on. The cost of premature abstraction is higher than the cost of a little duplication.\n- **Velocity is not refactoring.** The output is Claude Code extensions (skills, rules, hooks, agents), not code changes. If a finding suggests \"refactor this module,\" reframe it: \"What Claude Code extension would prevent this pattern from recurring or make the refactor easier?\"\n- **The findings doc is temporary.** Never let it survive past the PR. The extensions are the permanent output; the findings doc is just a work queue.\n- **Scope creep kills hunts.** If the investigation surface area keeps expanding, stop and re-scope with the user. A focused hunt that produces 3 actionable findings beats a broad survey that produces 15 vague observations.\n","# Velocity Hunt\n\nSystematically find DX friction, inconsistency, and missing abstractions — then turn findings into Claude Code extensions via `\u002Fimprove`.\n\n## Step 1: Scope the Hunt\n\nBefore investigating anything, interview the user to define a clear scope. Do not start exploring until you have agreement on what to look at.\n\nAsk: **\"What do you want me to look at?\"**\n\nOffer concrete options based on what's available:\n\n- **Your recent PRs** — `gh pr list --author=@me --state=merged --limit=20`\n- **A specific PR** — user provides a URL or number\n- **Recent team PRs** — `gh pr list --state=merged --limit=30`\n- **A codebase area** — user points at a directory or domain\n- **CODEOWNERS domain** — pick a team\u002Farea from CODEOWNERS and cover what they own\n- **Linear tickets** — look at recent tickets for a team or label for recurring pain\n\nIf `$ARGUMENTS` is provided, use it to seed the conversation — but still confirm scope before investigating.\n\n### If the user pushes back on scoping\n\nExplain why: *\"Without a scope, I'll either look at everything superficially or go deep on the wrong thing. A velocity hunt works best when it's focused — we can always run another one on a different area. What's been causing you the most friction lately?\"*\n\n### Ask about themes\n\nOnce you have the scope, ask: **\"Are there any themes you care about most within that area?\"** Examples:\n\n- Error handling consistency\n- Testing patterns\n- API endpoint structure\n- Missing documentation or conventions\n- Onboarding friction for new developers\n- Repeated manual workflows\n\nIf they have themes, focus the investigation there. If not, explore broadly within the scope.\n\n### Calibrate depth\n\nAsk how deep they want to go:\n- **Quick scan** — skim for obvious patterns (10-15 min of investigation)\n- **Thorough hunt** — read code, trace patterns across files, check for consistency (30+ min)\n\n## Step 2: Investigate\n\n**Use subagents aggressively.** Every distinct theme or codebase area should be explored by its own subagent via the Agent tool. This preserves the main session's context window for synthesis and the user conversation. Launch subagents in parallel whenever the areas are independent.\n\nExamples:\n- Scope is \"recent PRs\" with 3 themes → 3 parallel subagents, one per theme\n- Scope is a codebase area → subagent per subdirectory or per concern (patterns, consistency, tooling gaps)\n- Scope is CODEOWNERS domain → subagent per owned path\n\nEach subagent should return a structured summary: what it found, where (file:line), frequency, and a one-sentence friction assessment. You synthesize and rank the results in the main session.\n\nYou're looking for:\n\n- **Repeated patterns** — same boilerplate appearing 3+ times that could be a skill, generator, or abstraction\n- **Inconsistency** — the same thing done 3 different ways across the codebase\n- **Missing tooling** — workflows where Claude (or the developer) has to do manual steps that could be automated\n- **Convention drift** — established patterns that newer code isn't following\n- **Friction points** — things that are tedious, error-prone, or require tribal knowledge\n- **Skills\u002Frules gaps** — places where a Claude Code extension would prevent recurring mistakes\n\nRead `${CLAUDE_SKILL_DIR}\u002Freferences\u002Fevaluation.md` for heuristics on evaluating what you find.\n\n### What you're NOT looking for\n\n- Bugs (that's triage)\n- Performance problems (that's profiling)\n- One-off code smells (not worth systematizing)\n- Patterns that have appeared only 1-2 times (wait for the third)\n\n## Step 3: Present Findings\n\nPresent each finding in conversation with this structure:\n\n**Finding: [title]**\n- **Pattern**: What you observed (with file\u002Fline references)\n- **Frequency**: How often this appears \u002F how many instances\n- **Friction**: What this costs in time, consistency, or correctness\n- **Extension type**: What kind of Claude Code extension would fix this (skill, rule, agent, hook, CLAUDE.md)\n- **Effort**: Low \u002F Medium \u002F High to implement the extension\n\nRank findings by impact. Lead with the most valuable ones.\n\n## Step 4: Handoff to \u002Fimprove\n\nThis is where findings become real. The approach depends on how many actionable findings there are.\n\n### Single finding\n\nOffer to feed it directly into `\u002Fimprove` in the current session. You already have the context — the problem statement, code references, and frequency data. Transition naturally: present the finding, ask if they want to act on it, then shift into the improve workflow.\n\n### Multiple findings (2+)\n\nRecommend this workflow:\n\n1. **Write a temporary findings doc** — create `.claude\u002Fvelocity-findings.md` with all findings and a pre-built `\u002Fimprove` prompt for each one. Format each prompt so the user can copy-paste it into a new Claude session:\n\n```markdown\n## Finding: [title]\n[problem statement, references, frequency data]\n\n### Improve prompt\n> \u002Fimprove [concise description of the problem, what extension type to create, and which files\u002FPRs to use as references]\n```\n\n2. **Create a branch** — `git checkout -b velocity\u002FYYYY-MM-DD`\n3. **Work through findings** — the user runs `\u002Fimprove` for each finding (either in this session or new ones), creating extensions one at a time\n4. **PR description** — when they're ready to merge, include the findings summary in the PR description so reviewers understand the motivation\n5. **Clean up** — delete `.claude\u002Fvelocity-findings.md` before merging. The findings doc is scaffolding, not a permanent artifact. The extensions themselves are the durable output.\n\n### Always offer both paths\n\nSome users will want to knock out one finding and come back later. Others will want to batch. Let them choose.\n\n## Gotchas\n\n- **Don't codify tech debt.** You're investigating the codebase to find friction, not to find \"good examples.\" When you spot a pattern, evaluate whether it's a good pattern worth systematizing or a bad pattern worth replacing. If in doubt, ask the user.\n- **3+ occurrences is the threshold.** If a pattern has appeared once or twice, it's not worth abstracting yet. Note it and move on. The cost of premature abstraction is higher than the cost of a little duplication.\n- **Velocity is not refactoring.** The output is Claude Code extensions (skills, rules, hooks, agents), not code changes. If a finding suggests \"refactor this module,\" reframe it: \"What Claude Code extension would prevent this pattern from recurring or make the refactor easier?\"\n- **The findings doc is temporary.** Never let it survive past the PR. The extensions are the permanent output; the findings doc is just a work queue.\n- **Scope creep kills hunts.** If the investigation surface area keeps expanding, stop and re-scope with the user. A focused hunt that produces 3 actionable findings beats a broad survey that produces 15 vague observations.\n",{"name":5,"description":7,"allowed-tools":43,"argument-hint":44,"disable-model-invocation":48},"Read Write Edit Glob Grep Bash Agent WebFetch AskUserQuestion",[45,46,47],"scope — e.g. \"my PRs\"","backend\u002Fmodule\u002Fcomponent","\u003Cticket-id>",true,"main","ab37f4809db1129e69d61246bd7a5d3b21b7f79b","skills\u002Fvelocity",0,"https:\u002F\u002Fgithub.com\u002FTetra-Research\u002Fjig","https:\u002F\u002Fgithub.com\u002FTetra-Research","2026-04-10 09:57:50",{"source":8,"skillName":5,"commands":57,"prompt":67,"zipAvailable":48},[58,61,64],{"tool":59,"command":60},"npx","npx skills add Tetra-Research\u002Fjig --skill velocity",{"tool":62,"command":63},"bunx","bunx skills add Tetra-Research\u002Fjig --skill velocity",{"tool":65,"command":66},"pnpm","pnpm dlx skills add Tetra-Research\u002Fjig --skill velocity","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FTetra-Research\u002Fjig\u002Fblob\u002Fmain\u002Fskills\u002Fvelocity\u002FSKILL.md",[69],{"path":70,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":73,"sourceHtmlUrl":74},"references\u002Fevaluation.md","REFERENCE","参考文档",5710,"https:\u002F\u002Fgithub.com\u002FTetra-Research\u002Fjig\u002Fblob\u002Fmain\u002Fskills\u002Fvelocity\u002Freferences\u002Fevaluation.md",[76,101,117,137,151,161],{"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":87,"publishedAt":38},"01M6KMDF2VAYVDDQWM4A2HDZ5P","upgrade","Upgrade an existing skill or agent by auditing it, gathering user references, and rewriting it with real content. Use when a skill is thin, sloppy, missing gotchas, or needs improvement. Different from \u002Fimprove which creates new extensions.","https:\u002F\u002Fgithub.com\u002FTetra-Research\u002Fjig\u002Fblob\u002Fmain\u002Fskills\u002Fupgrade\u002FSKILL.md",[82],{"categoryNo":83,"categoryName":84,"taxonomyType":85,"taxonomyTypeDesc":86},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[78,88,33,20,89,90,91,92,26,93,94,95,96,97,98,99,100,34,35],"Existing","extensions","which","with","it","existing skill","references","content","user","edit","write","read","grep",{"skillNo":102,"name":34,"nameZh":6,"description":103,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":104,"categories":105,"keywords":107,"publishedAt":38},"01M6KMDABCDDRWHCPVGRJ7G3N1","Deliberately improve Claude Code by creating or updating skills, agents, hooks, rules, or MCP servers. Use when Claude keeps making the same mistake, a workflow is tedious, a new pattern needs enforcement, or you want to compound Claude's utility.","https:\u002F\u002Fgithub.com\u002FTetra-Research\u002Fjig\u002Fblob\u002Fmain\u002Fskills\u002Fimprove\u002FSKILL.md",[106],{"categoryNo":83,"categoryName":84,"taxonomyType":85,"taxonomyTypeDesc":86},[34,35,24,108,109,110,111,112,33,97,98,99,100,113,114,115,116,36],"pattern","compound","enforcement","you","hooks","Rules","mcp servers","MCP","workflow",{"skillNo":118,"name":119,"nameZh":6,"description":120,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":121,"categories":122,"keywords":123,"publishedAt":38},"01M6KMD6HSWSET1HRR5AHT9HFT","clean-copy","Recreate the current branch with a clean, narrative commit history. Use before creating a PR from a messy development branch, after exploratory coding with WIP commits, or when commit history is hard to review.","https:\u002F\u002Fgithub.com\u002FTetra-Research\u002Fjig\u002Fblob\u002Fmain\u002Fskills\u002Fclean-copy\u002FSKILL.md",[],[124,125,126,37,127,128,129,130,35,131,132,100,133,99,33,134,135,91,22,136],"copy","clean","clean copy","pr","commit","review","commits","gh","history","branch","name","narrative","branch-name",{"skillNo":138,"name":139,"nameZh":6,"description":140,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":141,"categories":142,"keywords":143,"publishedAt":38},"01M6KMD10AN05R0Q0PQPP8ZF16","audit","Audit installed skills and agents against best practices. Use when reviewing skill quality, checking for common problems, or before upgrading existing skills. Read-only — produces a report, changes nothing.","https:\u002F\u002Fgithub.com\u002FTetra-Research\u002Fjig\u002Fblob\u002Fmain\u002Fskills\u002Faudit\u002FSKILL.md",[],[139,144,88,145,21,146,33,99,100,147,148,149,150],"only","changes","read-only","common","quality","best practices","report",{"skillNo":152,"name":153,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":154,"categories":155,"keywords":156,"publishedAt":38},"01M6KMCX8WE6FFXZ9X50ESNHAF","typescript-update-model","https:\u002F\u002Fgithub.com\u002FTetra-Research\u002Fjig\u002Fblob\u002Fmain\u002Fexamples\u002Ftypescript-update-model\u002FSKILL.md",[],[157,158,159,160],"typescript update model","model","update","typescript",{"skillNo":162,"name":163,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":164,"categories":165,"keywords":166,"publishedAt":38},"01M6KMCRCNM9P0C5GD5CP407QG","typescript-update-endpoint-workflow","https:\u002F\u002Fgithub.com\u002FTetra-Research\u002Fjig\u002Fblob\u002Fmain\u002Fexamples\u002Ftypescript-update-endpoint-workflow\u002FSKILL.md",[],[116,160,167,168,159],"typescript update endpoint workflow","endpoint"]