[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71SR1A1FRWWTP6YA84TSEVQ":3,"skill-same:01M71SR1A1FRWWTP6YA84TSEVQ":56},{"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":29,"linkOnly":30,"markdownContent":31,"markdownBody":32,"frontMatter":33,"refName":35,"commitSha":36,"skillDirectory":37,"forksCount":38,"repositoryHtmlUrl":39,"repositoryHomepageUrl":6,"ownerHtmlUrl":40,"ownerBlogUrl":6,"ownerDescription":41,"updatedAt":42,"install":43,"resources":55},"01M71SR1A1FRWWTP6YA84TSEVQ","tech-spec",null,"Write a typed call-stack architecture handoff.","sanurb\u002F.dotfiles","sanurb","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F60886336?v=4","01M71SKJS17F5YPRE27CVMEH1X","Santiago U","01M71SKJSTGEXEQ82HMAQP4ZAF",2,"MIT","https:\u002F\u002Fgithub.com\u002Fsanurb\u002F.dotfiles\u002Fblob\u002Fmain\u002Fconfig\u002Fpi\u002Fagent\u002Fskills\u002Ftech-spec\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28],"tech","spec","tech spec","true","call","architecture","stack","architecture handoff","write","handoff","2026-11-10 13:02:02",false,"---\nname: tech-spec\ndescription: Write a typed call-stack architecture handoff.\ndisable-model-invocation: true\n---\n\n# Tech Spec\n\nA tech spec is a **typed call-stack architecture handoff**: code-shaped contracts plus execution flows. Prefer TypeScript pseudocode over prose wherever precision matters.\n\nThis skill is design-only. Do not implement. Save a file only when the user asks for a file; otherwise return the spec inline.\n\n## Branch selection\n\n1. Use **Path A: Convert context to spec** when the conversation, docs, or codebase already contain enough background to describe the change.\n2. Use **Path B: Grill first** when the user wants a new spec but has not provided enough problem, constraints, design direction, affected code, or acceptance criteria.\n\nIf a question can be answered by exploring the codebase, inspect the codebase instead of asking.\n\nCompletion criterion: the branch is chosen from actual available context; missing architectural decisions are not invented.\n\n## Path A: Convert context to spec\n\n### 1. Load standards and local context\n\nInspect existing code and docs for local vocabulary, module layout, domain concepts, errors, adapters, observability, runtime patterns, and test style.\n\nCompletion criterion: the spec uses project vocabulary and does not introduce a pattern, library, adapter, schema style, or test strategy before checking local precedent.\n\n### 2. Extract the design problem\n\nCapture:\n\n- current state;\n- problem;\n- users\u002Fcallers;\n- goals;\n- non-goals;\n- constraints;\n- invariants;\n- affected systems;\n- likely entrypoints;\n- operational\u002Fruntime concerns;\n- risks;\n- open questions.\n\nMark unknowns as open questions instead of filling gaps with plausible design.\n\nCompletion criterion: every claimed requirement or constraint is grounded in conversation, code, docs, or an explicit open question.\n\n### 3. Explore design alternatives\n\nProduce materially different alternatives before choosing the recommended design. Alternatives should differ in interface shape, seam placement, ownership, call stack, runtime topology, or module boundaries — not just names.\n\nFor each alternative, sketch:\n\n- domain types and state model;\n- public\u002Fmodule interfaces and APIs;\n- input\u002Foutput types;\n- expected failure types;\n- seams, boundaries, and adapters;\n- entrypoint-to-side-effect call stack;\n- parsing\u002Fprojection strategy;\n- authorization, observability, cancellation, idempotency, and transaction flow when reachable;\n- test seam strategy;\n- tradeoffs.\n\nCompare alternatives on:\n\n- caller burden;\n- module depth and leverage;\n- locality of invariants and change;\n- seam placement;\n- boundary parsing and projections;\n- error and cancellation model;\n- testability through real seams;\n- operational\u002Fruntime fit;\n- implementation complexity.\n\nCompletion criterion: the recommendation is chosen after comparing alternatives, not before.\n\n### 4. Specify the recommended typed contracts\n\nFor the recommended design, outline every new, changed, or deleted:\n\n- domain value;\n- branded\u002Frefined type;\n- state machine variant;\n- input\u002Foutput type;\n- request\u002Fresponse shape;\n- function signature;\n- class or module interface;\n- expected-failure\u002Fcustom-error type;\n- adapter interface;\n- protocol DTO;\n- persistence DTO\u002Fprojection;\n- runtime-boundary codec;\n- public API.\n\nName seams, adapters, implementations, ownership boundaries, and what crosses each boundary. State what each layer may know and what must not leak across the seam.\n\nCompletion criterion: every new or changed boundary has a concrete type\u002Finterface\u002FAPI sketch, or an explicit reason no new contract is needed.\n\n### 5. Specify call stacks and data flow\n\nFor every new, changed, or deleted behavior, show the call stack from entrypoint to side effects and response.\n\nInclude type\u002Fdata flow:\n\n```txt\nraw input\n  -> boundary DTO \u002F unknown\n  -> parser\n  -> canonical domain\u002Fapplication input\n  -> service\u002Fmodule interface\n  -> adapter call\n  -> typed result\u002Ferror\n  -> projection\n  -> serialized output\n```\n\nInclude current vs proposed flow when changing existing behavior. Include failure, retry, cancellation, transactionality, idempotency, observability, authorization, and runtime-hop flow when reachable.\n\nCompletion criterion: every affected behavior has an end-to-end call stack and type\u002Fdata-flow trace.\n\n### 6. Map files and modules\n\nList:\n\n- files\u002Fmodules to add;\n- files\u002Fmodules to change;\n- files\u002Fmodules to delete, if any;\n- test files;\n- config\u002Fmigration\u002Fruntime files, if any.\n\nFor each file, state the contract, code path, boundary, adapter, domain concept, or test responsibility it owns.\n\nCompletion criterion: every contract and call-stack step maps to a file\u002Fmodule or an open question.\n\n### 7. Write the RGR TDD test plan\n\nUse the sibling TDD workflow and testing standards. Plan vertical Red-Green-Refactor slices: one failing behavior test, minimal implementation, repeat. Do not write a horizontal \"all tests first, all code later\" plan.\n\nFavor behavior through public interfaces and real seams over implementation-coupled mocks.\n\nCover proportionately:\n\n- happy paths;\n- failure paths;\n- parser rejection and accepted shapes;\n- domain invariants and state transitions;\n- adapter contracts;\n- persistence\u002Fruntime semantics;\n- cancellation\u002Fretry\u002Fidempotency paths;\n- observability and safe summaries where relevant;\n- end-to-end flows for high-consequence behavior.\n\nCompletion criterion: every public behavior, invariant, important failure path, changed boundary, and changed seam has a red test slice or an explicit reason not to test it.\n\n### 8. Produce the spec\n\nReturn the spec inline unless the user requested a file path. If a file was requested, save it there.\n\nDo not implement and do not ask to implement by default.\n\nCompletion criterion: the output follows the outline below and is implementation-ready for another engineer.\n\n## Path B: Grill first\n\n1. Do not write a full spec yet.\n   - State that there is not enough context for an implementation-ready tech spec.\n   - Completion criterion: the agent has not invented requirements, APIs, files, or call stacks.\n2. Start a grilling interview.\n   - Ask one question at a time and provide the recommended answer with each question.\n   - If a question can be answered by exploring the codebase, inspect the codebase instead of asking.\n   - Completion criterion: the interview has enough context for Path A: problem, users\u002Fcallers, constraints, affected systems, desired behavior, boundaries, likely APIs, invariants, risks, and acceptance tests.\n3. Convert to the spec.\n   - Once grilling context is sufficient, run Path A.\n   - Completion criterion: the final artifact is a typed call-stack architecture handoff, not interview notes.\n\n## Required spec outline\n\nUse this shape unless the task is tiny enough to compress without losing contracts or call stacks:\n\n```md\n# \u003CTitle>\n\n## Summary\n\n## Context \u002F Current State\n\n## Goals\n\n## Non-Goals\n\n## Invariants\n\n## Design Constraints\n\n## Alternatives Considered\n\n### Option 1: \u003Cname>\n\n### Option 2: \u003Cname>\n\n### Option 3: \u003Cname>\n\n## Recommendation\n\n## Proposed Design\n\n## Domain Model and Types\n\n## Types, Interfaces, and APIs\n\n## Seams, Boundaries, Adapters, and Implementations\n\n## Call Stacks and Data Flow\n\n### Current \u002F Old Flow\n\n### Proposed \u002F New Flow\n\n### Failure Flow\n\n### Retry \u002F Cancellation \u002F Idempotency Flow\n\n### Observability Flow\n\n## Files to Add \u002F Change \u002F Delete\n\n## RGR TDD Test Plan\n\n## Risks and Open Questions\n```\n\nOmit sections that truly do not apply, but do not omit typed contracts, seams, call stacks, or tests merely because they are hard to specify.\n\n## Writing rules\n\n- Code first: TypeScript pseudocode defines contracts, APIs, and data flow.\n- Prose explains why; types and call stacks define what changes.\n- Focus on types, interfaces, APIs, inputs\u002Foutputs, seams, boundaries, adapters, domain modules, service modules, external adapters, and call stacks.\n- Prefer precise domain values over strings, booleans, nullable bags, and loosely shaped objects.\n- Keep seams real: adapters translate framework, persistence, network, time, randomness, telemetry, runtime, or platform boundaries.\n- Avoid speculative abstraction; every seam earns its existence through invariants, locality, leverage, testing, or a real boundary.\n- Keep a single source of truth; do not restate the same rule in multiple sections unless one section points to the other.\n- Unknowns stay open questions. Do not invent product requirements, domain rules, APIs, or call stacks to make the spec feel complete.\n","# Tech Spec\n\nA tech spec is a **typed call-stack architecture handoff**: code-shaped contracts plus execution flows. Prefer TypeScript pseudocode over prose wherever precision matters.\n\nThis skill is design-only. Do not implement. Save a file only when the user asks for a file; otherwise return the spec inline.\n\n## Branch selection\n\n1. Use **Path A: Convert context to spec** when the conversation, docs, or codebase already contain enough background to describe the change.\n2. Use **Path B: Grill first** when the user wants a new spec but has not provided enough problem, constraints, design direction, affected code, or acceptance criteria.\n\nIf a question can be answered by exploring the codebase, inspect the codebase instead of asking.\n\nCompletion criterion: the branch is chosen from actual available context; missing architectural decisions are not invented.\n\n## Path A: Convert context to spec\n\n### 1. Load standards and local context\n\nInspect existing code and docs for local vocabulary, module layout, domain concepts, errors, adapters, observability, runtime patterns, and test style.\n\nCompletion criterion: the spec uses project vocabulary and does not introduce a pattern, library, adapter, schema style, or test strategy before checking local precedent.\n\n### 2. Extract the design problem\n\nCapture:\n\n- current state;\n- problem;\n- users\u002Fcallers;\n- goals;\n- non-goals;\n- constraints;\n- invariants;\n- affected systems;\n- likely entrypoints;\n- operational\u002Fruntime concerns;\n- risks;\n- open questions.\n\nMark unknowns as open questions instead of filling gaps with plausible design.\n\nCompletion criterion: every claimed requirement or constraint is grounded in conversation, code, docs, or an explicit open question.\n\n### 3. Explore design alternatives\n\nProduce materially different alternatives before choosing the recommended design. Alternatives should differ in interface shape, seam placement, ownership, call stack, runtime topology, or module boundaries — not just names.\n\nFor each alternative, sketch:\n\n- domain types and state model;\n- public\u002Fmodule interfaces and APIs;\n- input\u002Foutput types;\n- expected failure types;\n- seams, boundaries, and adapters;\n- entrypoint-to-side-effect call stack;\n- parsing\u002Fprojection strategy;\n- authorization, observability, cancellation, idempotency, and transaction flow when reachable;\n- test seam strategy;\n- tradeoffs.\n\nCompare alternatives on:\n\n- caller burden;\n- module depth and leverage;\n- locality of invariants and change;\n- seam placement;\n- boundary parsing and projections;\n- error and cancellation model;\n- testability through real seams;\n- operational\u002Fruntime fit;\n- implementation complexity.\n\nCompletion criterion: the recommendation is chosen after comparing alternatives, not before.\n\n### 4. Specify the recommended typed contracts\n\nFor the recommended design, outline every new, changed, or deleted:\n\n- domain value;\n- branded\u002Frefined type;\n- state machine variant;\n- input\u002Foutput type;\n- request\u002Fresponse shape;\n- function signature;\n- class or module interface;\n- expected-failure\u002Fcustom-error type;\n- adapter interface;\n- protocol DTO;\n- persistence DTO\u002Fprojection;\n- runtime-boundary codec;\n- public API.\n\nName seams, adapters, implementations, ownership boundaries, and what crosses each boundary. State what each layer may know and what must not leak across the seam.\n\nCompletion criterion: every new or changed boundary has a concrete type\u002Finterface\u002FAPI sketch, or an explicit reason no new contract is needed.\n\n### 5. Specify call stacks and data flow\n\nFor every new, changed, or deleted behavior, show the call stack from entrypoint to side effects and response.\n\nInclude type\u002Fdata flow:\n\n```txt\nraw input\n  -> boundary DTO \u002F unknown\n  -> parser\n  -> canonical domain\u002Fapplication input\n  -> service\u002Fmodule interface\n  -> adapter call\n  -> typed result\u002Ferror\n  -> projection\n  -> serialized output\n```\n\nInclude current vs proposed flow when changing existing behavior. Include failure, retry, cancellation, transactionality, idempotency, observability, authorization, and runtime-hop flow when reachable.\n\nCompletion criterion: every affected behavior has an end-to-end call stack and type\u002Fdata-flow trace.\n\n### 6. Map files and modules\n\nList:\n\n- files\u002Fmodules to add;\n- files\u002Fmodules to change;\n- files\u002Fmodules to delete, if any;\n- test files;\n- config\u002Fmigration\u002Fruntime files, if any.\n\nFor each file, state the contract, code path, boundary, adapter, domain concept, or test responsibility it owns.\n\nCompletion criterion: every contract and call-stack step maps to a file\u002Fmodule or an open question.\n\n### 7. Write the RGR TDD test plan\n\nUse the sibling TDD workflow and testing standards. Plan vertical Red-Green-Refactor slices: one failing behavior test, minimal implementation, repeat. Do not write a horizontal \"all tests first, all code later\" plan.\n\nFavor behavior through public interfaces and real seams over implementation-coupled mocks.\n\nCover proportionately:\n\n- happy paths;\n- failure paths;\n- parser rejection and accepted shapes;\n- domain invariants and state transitions;\n- adapter contracts;\n- persistence\u002Fruntime semantics;\n- cancellation\u002Fretry\u002Fidempotency paths;\n- observability and safe summaries where relevant;\n- end-to-end flows for high-consequence behavior.\n\nCompletion criterion: every public behavior, invariant, important failure path, changed boundary, and changed seam has a red test slice or an explicit reason not to test it.\n\n### 8. Produce the spec\n\nReturn the spec inline unless the user requested a file path. If a file was requested, save it there.\n\nDo not implement and do not ask to implement by default.\n\nCompletion criterion: the output follows the outline below and is implementation-ready for another engineer.\n\n## Path B: Grill first\n\n1. Do not write a full spec yet.\n   - State that there is not enough context for an implementation-ready tech spec.\n   - Completion criterion: the agent has not invented requirements, APIs, files, or call stacks.\n2. Start a grilling interview.\n   - Ask one question at a time and provide the recommended answer with each question.\n   - If a question can be answered by exploring the codebase, inspect the codebase instead of asking.\n   - Completion criterion: the interview has enough context for Path A: problem, users\u002Fcallers, constraints, affected systems, desired behavior, boundaries, likely APIs, invariants, risks, and acceptance tests.\n3. Convert to the spec.\n   - Once grilling context is sufficient, run Path A.\n   - Completion criterion: the final artifact is a typed call-stack architecture handoff, not interview notes.\n\n## Required spec outline\n\nUse this shape unless the task is tiny enough to compress without losing contracts or call stacks:\n\n```md\n# \u003CTitle>\n\n## Summary\n\n## Context \u002F Current State\n\n## Goals\n\n## Non-Goals\n\n## Invariants\n\n## Design Constraints\n\n## Alternatives Considered\n\n### Option 1: \u003Cname>\n\n### Option 2: \u003Cname>\n\n### Option 3: \u003Cname>\n\n## Recommendation\n\n## Proposed Design\n\n## Domain Model and Types\n\n## Types, Interfaces, and APIs\n\n## Seams, Boundaries, Adapters, and Implementations\n\n## Call Stacks and Data Flow\n\n### Current \u002F Old Flow\n\n### Proposed \u002F New Flow\n\n### Failure Flow\n\n### Retry \u002F Cancellation \u002F Idempotency Flow\n\n### Observability Flow\n\n## Files to Add \u002F Change \u002F Delete\n\n## RGR TDD Test Plan\n\n## Risks and Open Questions\n```\n\nOmit sections that truly do not apply, but do not omit typed contracts, seams, call stacks, or tests merely because they are hard to specify.\n\n## Writing rules\n\n- Code first: TypeScript pseudocode defines contracts, APIs, and data flow.\n- Prose explains why; types and call stacks define what changes.\n- Focus on types, interfaces, APIs, inputs\u002Foutputs, seams, boundaries, adapters, domain modules, service modules, external adapters, and call stacks.\n- Prefer precise domain values over strings, booleans, nullable bags, and loosely shaped objects.\n- Keep seams real: adapters translate framework, persistence, network, time, randomness, telemetry, runtime, or platform boundaries.\n- Avoid speculative abstraction; every seam earns its existence through invariants, locality, leverage, testing, or a real boundary.\n- Keep a single source of truth; do not restate the same rule in multiple sections unless one section points to the other.\n- Unknowns stay open questions. Do not invent product requirements, domain rules, APIs, or call stacks to make the spec feel complete.\n",{"name":5,"description":7,"disable-model-invocation":34},true,"main","5acbba39180bbea80204d1a58db40ccbd813a13a","config\u002Fpi\u002Fagent\u002Fskills\u002Ftech-spec",0,"https:\u002F\u002Fgithub.com\u002Fsanurb\u002F.dotfiles","https:\u002F\u002Fgithub.com\u002Fsanurb","Building things","2026-11-12 05:25:20",{"source":8,"skillName":5,"commands":44,"prompt":54,"zipAvailable":34},[45,48,51],{"tool":46,"command":47},"npx","npx skills add sanurb\u002F.dotfiles --skill tech-spec",{"tool":49,"command":50},"bunx","bunx skills add sanurb\u002F.dotfiles --skill tech-spec",{"tool":52,"command":53},"pnpm","pnpm dlx skills add sanurb\u002F.dotfiles --skill tech-spec","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fsanurb\u002F.dotfiles\u002Fblob\u002Fmain\u002Fconfig\u002Fpi\u002Fagent\u002Fskills\u002Ftech-spec\u002FSKILL.md",[],[57,83,110,138,156,184],{"skillNo":58,"name":59,"nameZh":6,"description":60,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":61,"categories":62,"keywords":73,"publishedAt":29},"01M71SS19VAM2YZ2SA7HD0PT2P","writing-great-skills","Reference for writing and editing skills well — the vocabulary and principles that make a skill predictable.","https:\u002F\u002Fgithub.com\u002Fsanurb\u002F.dotfiles\u002Fblob\u002Fmain\u002Fconfig\u002Fpi\u002Fagent\u002Fskills\u002Fwriting-great-skills\u002FSKILL.md",[63,68],{"categoryNo":64,"categoryName":65,"taxonomyType":66,"taxonomyTypeDesc":67},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":69,"categoryName":70,"taxonomyType":71,"taxonomyTypeDesc":72},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[74,75,76,77,78,79,22,80,81,82],"writing great skills","writing","principles","for","editing","a skill","reference","make","vocabulary",{"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":92,"publishedAt":29},"01M71SRXKJN6RYXPN9GFRVYSR3","write-discoverable-code","Rules for writing code that coding agents (and humans) can find and understand through\nplain-text search. Apply whenever writing or renaming code: functions, types, constants,\nfiles, error messages, doc comments.\n\nGrounded in measurement: agents navigate by plain-text search, not by AST or\nlanguage server, so every identifier is a search query and every search miss\ncosts wasted reads.","https:\u002F\u002Fgithub.com\u002Fsanurb\u002F.dotfiles\u002Fblob\u002Fmain\u002Fconfig\u002Fpi\u002Fagent\u002Fskills\u002Fwrite-discoverable-code\u002FSKILL.md",[89],{"categoryNo":90,"categoryName":91,"taxonomyType":71,"taxonomyTypeDesc":72},"01JBSEEDCAT000000000000030","开发工程师",[93,94,95,27,96,97,98,99,77,100,101,102,103,104,75,105,106,107,108,109],"write discoverable code","code","discoverable code","measurement","error","types","error messages","search","messages","constants","plain-text","files","Rules","query","apply","comments","can",{"skillNo":111,"name":112,"nameZh":6,"description":113,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":114,"categories":115,"keywords":119,"publishedAt":29},"01M71SRT760335ES5WSEAAQDN2","wrangler","Cloudflare Workers CLI for deploying, developing, and managing Workers, KV, R2, D1, Vectorize, Hyperdrive, Workers AI, Containers, Queues, Workflows, Pipelines, and Secrets Store. Load before running wrangler commands to ensure correct syntax and best practices. Biases towards retrieval from Cloudflare docs over pre-trained knowledge.","https:\u002F\u002Fgithub.com\u002Fsanurb\u002F.dotfiles\u002Fblob\u002Fmain\u002Fconfig\u002Fpi\u002Fagent\u002Fskills\u002Fwrangler\u002FSKILL.md",[116],{"categoryNo":117,"categoryName":118,"taxonomyType":66,"taxonomyTypeDesc":67},"01JBSEEDCAT000000000000010","后端与接口",[112,120,121,122,123,124,125,126,127,128,129,130,131,77,132,133,134,135,136,137],"cloudflare","d1","knowledge","workflows","cli","secrets","commands","syntax","cloudflare workers","r2","queues","running","containers","correct","load","workers","best practices","store",{"skillNo":139,"name":140,"nameZh":6,"description":141,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":142,"categories":143,"keywords":144,"publishedAt":29},"01M71SRPHE452V400HD2EZC4XG","workers-best-practices","Reviews and authors Cloudflare Workers code against production best practices. Load when writing new Workers, reviewing Worker code, configuring wrangler.jsonc, or checking for common Workers anti-patterns (streaming, floating promises, global state, secrets, bindings, observability). Biases towards retrieval from Cloudflare docs over pre-trained knowledge.","https:\u002F\u002Fgithub.com\u002Fsanurb\u002F.dotfiles\u002Fblob\u002Fmain\u002Fconfig\u002Fpi\u002Fagent\u002Fskills\u002Fworkers-best-practices\u002FSKILL.md",[],[145,135,136,146,147,148,77,120,149,122,150,112,75,134,151,94,152,153,154,155],"workers best practices","observability","reviews","promises","worker","new","when","common","streaming","state","anti-patterns",{"skillNo":157,"name":158,"nameZh":6,"description":159,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":160,"categories":161,"keywords":165,"publishedAt":29},"01M71SRJ36HWMTQ9ZMQ2RB008S","web-perf","Analyzes web performance using Chrome DevTools MCP. Measures Core Web Vitals (LCP, INP, CLS) and supplementary metrics (FCP, TBT, Speed Index), identifies render-blocking resources, network dependency chains, layout shifts, caching issues, and accessibility gaps. Use when asked to audit, profile, debug, or optimize page load performance, Lighthouse scores, or site speed. Biases towards retrieval from current documentation over pre-trained knowledge.","https:\u002F\u002Fgithub.com\u002Fsanurb\u002F.dotfiles\u002Fblob\u002Fmain\u002Fconfig\u002Fpi\u002Fagent\u002Fskills\u002Fweb-perf\u002FSKILL.md",[162],{"categoryNo":163,"categoryName":164,"taxonomyType":66,"taxonomyTypeDesc":67},"01JBSEEDCAT000000000000023","Skill与智能体开发",[166,167,168,169,170,171,172,173,174,175,122,176,151,177,178,179,180,181,182,183],"web perf","perf","web","resources","vitals","chrome devtools","performance","render","issues","devtools","MCP","caching","documentation","optimize","layout","audit","dependency","network",{"skillNo":185,"name":186,"nameZh":6,"description":187,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":188,"categories":189,"keywords":190,"publishedAt":29},"01M71SREWXFKFN6DM80YCCQZ46","wayfinder","Plan a huge chunk of work — more than one agent session can hold — as a shared map of decision tickets on your issue tracker, and resolve them one at a time until the way to the destination is clear.","https:\u002F\u002Fgithub.com\u002Fsanurb\u002F.dotfiles\u002Fblob\u002Fmain\u002Fconfig\u002Fpi\u002Fagent\u002Fskills\u002Fwayfinder\u002FSKILL.md",[],[186,191,192,193,194,195,196,22,197,198,199,200,109,201,202,203,204,205,206,207],"shared","as","chunk","time","session","decision","more","map","one","one at a time","agent session","work","plan","tracker","tickets","at","destination"]