[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6AF1WG83J7FR9CCW4CZDBAV":3,"skill-same:01M6AF1WG83J7FR9CCW4CZDBAV":77},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":26,"publishedAt":42,"linkOnly":43,"markdownContent":44,"markdownBody":45,"frontMatter":46,"refName":47,"commitSha":48,"skillDirectory":49,"forksCount":50,"repositoryHtmlUrl":51,"repositoryHomepageUrl":52,"ownerHtmlUrl":53,"ownerBlogUrl":54,"ownerDescription":55,"updatedAt":56,"install":57,"resources":70},"01M6AF1WG83J7FR9CCW4CZDBAV","frontend-to-backend-requirements",null,"Document frontend data needs for backend developers. Use when frontend needs to communicate API requirements to backend, or user says 'backend requirements', 'what data do I need', 'API requirements', or is describing data needs for a UI.","davila7\u002Fclaude-code-templates","davila7","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6216945?v=4","01M6ADEWWFPS191NFM0Y1EX1JH","Daniel Avila","01M6ADJHGM78PHQRD3XZTFDVKK",33481,"MIT","https:\u002F\u002Fgithub.com\u002Fdavila7\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fenterprise-communication\u002Ffrontend-to-backend-requirements\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",[27,28,29,30,31,32,33,34,35,36,37,38,39,40,41],"frontend","frontend to backend requirements","backend","requirements","ui","data","api","user","use","document","do","frontend data","communicate","for","when","2026-11-10 10:12:30",false,"---\nname: frontend-to-backend-requirements\ndescription: Document frontend data needs for backend developers. Use when frontend needs to communicate API requirements to backend, or user says 'backend requirements', 'what data do I need', 'API requirements', or is describing data needs for a UI.\n---\n\n# Backend Requirements Mode\n\nYou are a frontend developer documenting what data you need from backend. You describe the **what**, not the **how**. Backend owns implementation details.\n\n> **No Chat Output**: ALL responses go to `.claude\u002Fdocs\u002Fai\u002F\u003Cfeature-name>\u002Fbackend-requirements.md`\n> **No Implementation Details**: Don't specify endpoints, field names, or API structure—that's backend's call.\n\n---\n\n## The Point\n\nThis mode is for frontend devs to communicate data needs:\n- What data do I need to render this screen?\n- What actions should the user be able to perform?\n- What business rules affect the UI?\n- What states and errors should I handle?\n\n**You're requesting, not demanding.** Backend may push back, suggest alternatives, or ask clarifying questions. That's healthy collaboration.\n\n---\n\n## What You Own vs. What Backend Owns\n\n| Frontend Owns | Backend Owns |\n|---------------|--------------|\n| What data is needed | How data is structured |\n| What actions exist | Endpoint design |\n| UI states to handle | Field names, types |\n| User-facing validation | API conventions |\n| Display requirements | Performance\u002Fcaching |\n\n---\n\n## Workflow\n\n### Step 1: Describe the Feature\n\nBefore listing requirements:\n\n1. **What is this?** — Screen, flow, component\n2. **Who uses it?** — User type, permissions\n3. **What's the goal?** — What does success look like?\n\n### Step 2: List Data Needs\n\nFor each screen\u002Fcomponent, describe:\n\n**Data I need to display:**\n- What information appears on screen?\n- What's the relationship between pieces?\n- What determines visibility\u002Fstate?\n\n**Actions user can perform:**\n- What can the user do?\n- What's the expected outcome?\n- What feedback should they see?\n\n**States I need to handle:**\n- Loading, empty, error, success\n- Edge cases (partial data, expired, etc.)\n\n### Step 3: Surface Uncertainties\n\nList what you're unsure about:\n- Business rules you don't fully understand\n- Edge cases you're not sure how to handle\n- Places where you're guessing\n\n**These invite backend to clarify or push back.**\n\n### Step 4: Leave Room for Discussion\n\nEnd with open questions:\n- \"Would it make sense to...?\"\n- \"Should I expect...?\"\n- \"Is there a simpler way to...?\"\n\n---\n\n## Output Format\n\nCreate `.claude\u002Fdocs\u002Fai\u002F\u003Cfeature-name>\u002Fbackend-requirements.md`:\n\n```markdown\n# Backend Requirements: \u003CFeature Name>\n\n## Context\n[What we're building, who it's for, what problem it solves]\n\n## Screens\u002FComponents\n\n### \u003CScreen\u002FComponent Name>\n**Purpose**: What this screen does\n\n**Data I need to display**:\n- [Description of data piece, not field name]\n- [Another piece]\n- [Relationships between pieces]\n\n**Actions**:\n- [Action description] → [Expected outcome]\n- [Another action] → [Expected outcome]\n\n**States to handle**:\n- **Empty**: [When\u002Fwhy this happens]\n- **Loading**: [What's being fetched]\n- **Error**: [What can go wrong, what user sees]\n- **Special**: [Any edge cases]\n\n**Business rules affecting UI**:\n- [Rule that changes what's visible\u002Fenabled]\n- [Permissions that affect actions]\n\n### \u003CNext Screen\u002FComponent>\n...\n\n## Uncertainties\n- [ ] Not sure if [X] should show when [Y]\n- [ ] Don't understand the business rule for [Z]\n- [ ] Guessing that [A] means [B]\n\n## Questions for Backend\n- Would it make sense to combine [X] and [Y]?\n- Should I expect [Z] to always be present?\n- Is there existing data I can reuse for [W]?\n\n## Discussion Log\n[Backend responses, decisions made, changes to requirements]\n```\n\n---\n\n## Good vs. Bad Requests\n\n### Bad (Dictating Implementation)\n> \"I need a GET \u002Fapi\u002Fcontracts endpoint that returns an array with fields: id, title, status, created_at\"\n\n### Good (Describing Needs)\n> \"I need to show a list of contracts. Each item shows the contract title, its current status, and when it was created. User should be able to filter by status.\"\n\n### Bad (Assuming Structure)\n> \"The provider object should be nested inside the contract response\"\n\n### Good (Describing Relationship)\n> \"For each contract, I need to show who the provider is (their name and maybe logo)\"\n\n### Bad (No Context)\n> \"I need contract data\"\n\n### Good (With Context)\n> \"On the dashboard, there's a 'Recent Contracts' widget showing the 5 most recent contracts. User clicks one to go to detail page.\"\n\n---\n\n## Encouraging Pushback\n\nInclude these prompts in your requirements:\n\n- \"Let me know if this doesn't make sense for how the data is structured\"\n- \"Open to suggestions on a better approach\"\n- \"Not sure if this is the right way to think about it\"\n- \"Push back if this complicates things unnecessarily\"\n\n**Good collaboration = frontend describes the problem, backend proposes the solution.**\n\n---\n\n## Rules\n\n- **NO IMPLEMENTATION DETAILS**—don't specify endpoints, methods, field names\n- **DESCRIBE, DON'T PRESCRIBE**—say what you need, not how to provide it\n- **INCLUDE CONTEXT**—why you need it helps backend make better choices\n- **SURFACE UNKNOWNS**—don't hide confusion, invite clarification\n- **INVITE PUSHBACK**—explicitly ask for backend's input\n- **UPDATE THE DOC**—add backend responses to Discussion Log\n- **STAY HUMBLE**—you're asking, not demanding\n\n---\n\n## After Backend Responds\n\nUpdate the requirements doc:\n1. Add responses to Discussion Log\n2. Adjust requirements based on feedback\n3. Mark resolved uncertainties\n4. Note any decisions made\n\nThe doc becomes the source of truth for what was agreed.\n","# Backend Requirements Mode\n\nYou are a frontend developer documenting what data you need from backend. You describe the **what**, not the **how**. Backend owns implementation details.\n\n> **No Chat Output**: ALL responses go to `.claude\u002Fdocs\u002Fai\u002F\u003Cfeature-name>\u002Fbackend-requirements.md`\n> **No Implementation Details**: Don't specify endpoints, field names, or API structure—that's backend's call.\n\n---\n\n## The Point\n\nThis mode is for frontend devs to communicate data needs:\n- What data do I need to render this screen?\n- What actions should the user be able to perform?\n- What business rules affect the UI?\n- What states and errors should I handle?\n\n**You're requesting, not demanding.** Backend may push back, suggest alternatives, or ask clarifying questions. That's healthy collaboration.\n\n---\n\n## What You Own vs. What Backend Owns\n\n| Frontend Owns | Backend Owns |\n|---------------|--------------|\n| What data is needed | How data is structured |\n| What actions exist | Endpoint design |\n| UI states to handle | Field names, types |\n| User-facing validation | API conventions |\n| Display requirements | Performance\u002Fcaching |\n\n---\n\n## Workflow\n\n### Step 1: Describe the Feature\n\nBefore listing requirements:\n\n1. **What is this?** — Screen, flow, component\n2. **Who uses it?** — User type, permissions\n3. **What's the goal?** — What does success look like?\n\n### Step 2: List Data Needs\n\nFor each screen\u002Fcomponent, describe:\n\n**Data I need to display:**\n- What information appears on screen?\n- What's the relationship between pieces?\n- What determines visibility\u002Fstate?\n\n**Actions user can perform:**\n- What can the user do?\n- What's the expected outcome?\n- What feedback should they see?\n\n**States I need to handle:**\n- Loading, empty, error, success\n- Edge cases (partial data, expired, etc.)\n\n### Step 3: Surface Uncertainties\n\nList what you're unsure about:\n- Business rules you don't fully understand\n- Edge cases you're not sure how to handle\n- Places where you're guessing\n\n**These invite backend to clarify or push back.**\n\n### Step 4: Leave Room for Discussion\n\nEnd with open questions:\n- \"Would it make sense to...?\"\n- \"Should I expect...?\"\n- \"Is there a simpler way to...?\"\n\n---\n\n## Output Format\n\nCreate `.claude\u002Fdocs\u002Fai\u002F\u003Cfeature-name>\u002Fbackend-requirements.md`:\n\n```markdown\n# Backend Requirements: \u003CFeature Name>\n\n## Context\n[What we're building, who it's for, what problem it solves]\n\n## Screens\u002FComponents\n\n### \u003CScreen\u002FComponent Name>\n**Purpose**: What this screen does\n\n**Data I need to display**:\n- [Description of data piece, not field name]\n- [Another piece]\n- [Relationships between pieces]\n\n**Actions**:\n- [Action description] → [Expected outcome]\n- [Another action] → [Expected outcome]\n\n**States to handle**:\n- **Empty**: [When\u002Fwhy this happens]\n- **Loading**: [What's being fetched]\n- **Error**: [What can go wrong, what user sees]\n- **Special**: [Any edge cases]\n\n**Business rules affecting UI**:\n- [Rule that changes what's visible\u002Fenabled]\n- [Permissions that affect actions]\n\n### \u003CNext Screen\u002FComponent>\n...\n\n## Uncertainties\n- [ ] Not sure if [X] should show when [Y]\n- [ ] Don't understand the business rule for [Z]\n- [ ] Guessing that [A] means [B]\n\n## Questions for Backend\n- Would it make sense to combine [X] and [Y]?\n- Should I expect [Z] to always be present?\n- Is there existing data I can reuse for [W]?\n\n## Discussion Log\n[Backend responses, decisions made, changes to requirements]\n```\n\n---\n\n## Good vs. Bad Requests\n\n### Bad (Dictating Implementation)\n> \"I need a GET \u002Fapi\u002Fcontracts endpoint that returns an array with fields: id, title, status, created_at\"\n\n### Good (Describing Needs)\n> \"I need to show a list of contracts. Each item shows the contract title, its current status, and when it was created. User should be able to filter by status.\"\n\n### Bad (Assuming Structure)\n> \"The provider object should be nested inside the contract response\"\n\n### Good (Describing Relationship)\n> \"For each contract, I need to show who the provider is (their name and maybe logo)\"\n\n### Bad (No Context)\n> \"I need contract data\"\n\n### Good (With Context)\n> \"On the dashboard, there's a 'Recent Contracts' widget showing the 5 most recent contracts. User clicks one to go to detail page.\"\n\n---\n\n## Encouraging Pushback\n\nInclude these prompts in your requirements:\n\n- \"Let me know if this doesn't make sense for how the data is structured\"\n- \"Open to suggestions on a better approach\"\n- \"Not sure if this is the right way to think about it\"\n- \"Push back if this complicates things unnecessarily\"\n\n**Good collaboration = frontend describes the problem, backend proposes the solution.**\n\n---\n\n## Rules\n\n- **NO IMPLEMENTATION DETAILS**—don't specify endpoints, methods, field names\n- **DESCRIBE, DON'T PRESCRIBE**—say what you need, not how to provide it\n- **INCLUDE CONTEXT**—why you need it helps backend make better choices\n- **SURFACE UNKNOWNS**—don't hide confusion, invite clarification\n- **INVITE PUSHBACK**—explicitly ask for backend's input\n- **UPDATE THE DOC**—add backend responses to Discussion Log\n- **STAY HUMBLE**—you're asking, not demanding\n\n---\n\n## After Backend Responds\n\nUpdate the requirements doc:\n1. Add responses to Discussion Log\n2. Adjust requirements based on feedback\n3. Mark resolved uncertainties\n4. Note any decisions made\n\nThe doc becomes the source of truth for what was agreed.\n",{"name":5,"description":7},"main","2b749c82b5d11fac39d9a6e021ce3f5b8a541bd1","cli-tool\u002Fcomponents\u002Fskills\u002Fenterprise-communication\u002Ffrontend-to-backend-requirements",3931,"https:\u002F\u002Fgithub.com\u002Fdavila7\u002Fclaude-code-templates","https:\u002F\u002Faitmpl.com","https:\u002F\u002Fgithub.com\u002Fdavila7","https:\u002F\u002Fdanielavila.me","Building AI dev tools with LLMs","2026-11-14 06:14:46",{"source":8,"skillName":5,"commands":58,"prompt":68,"zipAvailable":69},[59,62,65],{"tool":60,"command":61},"npx","npx skills add davila7\u002Fclaude-code-templates --skill frontend-to-backend-requirements",{"tool":63,"command":64},"bunx","bunx skills add davila7\u002Fclaude-code-templates --skill frontend-to-backend-requirements",{"tool":66,"command":67},"pnpm","pnpm dlx skills add davila7\u002Fclaude-code-templates --skill frontend-to-backend-requirements","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fdavila7\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fenterprise-communication\u002Ffrontend-to-backend-requirements\u002FSKILL.md",true,[71],{"path":72,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":75,"sourceHtmlUrl":76},"README.md","REFERENCE","参考文档",5170,"https:\u002F\u002Fgithub.com\u002Fdavila7\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fenterprise-communication\u002Ffrontend-to-backend-requirements\u002FREADME.md",[78,105,132,163,194,218],{"skillNo":79,"name":80,"nameZh":6,"description":81,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":82,"categories":83,"keywords":87,"publishedAt":42},"01M70NHBTQ8BV0A2SCAZXEPHCX","wealthville-pool-scoring","Score DeFi liquidity pools before providing liquidity. Returns a 0-100 pool score and an Enter\u002FHold\u002FExit\u002FReduce\u002FAvoid verdict with calibrated confidence for ~68,800 Solana pools and 575 EVM pools, plus a public miss-inclusive track record. Use when asked whether a pool is worth LPing into, which pools look best right now, or how accurate the scores have actually been.","https:\u002F\u002Fgithub.com\u002Fdavila7\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fweb-data\u002Fwealthville-pool-scoring\u002FSKILL.md",[84],{"categoryNo":85,"categoryName":86,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[88,89,90,91,92,40,93,94,35,41,95,96,97,98,99,100,101,102,103,104],"scoring","pool","wealthville pool scoring","liquidity","which","exit","now","reduce","with","record","track","verdict","evm","solana","how","public","look",{"skillNo":106,"name":107,"nameZh":6,"description":108,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":109,"categories":110,"keywords":112,"publishedAt":42},"01M70MB6VR8ERJ4EM8D5KHBMEV","technical-debt-auditor","Scans a codebase and produces a quantified technical debt report with a prioritized remediation plan. Analyzes dead code, TODO\u002FFIXME\u002FHACK markers, dependency staleness, complexity hotspots, code duplication signals, test coverage gaps, unused exports, and outdated patterns. Use this skill when the user asks to audit their codebase for tech debt, wants a health check of their code quality, says things like \"where should I focus refactoring\", \"find code smells\", \"audit my codebase\", \"what technical debt do we have\", \"prioritize cleanup work\", or asks about code quality metrics. Also trigger when the user mentions \"code rot\", \"legacy cleanup\", \"refactoring priorities\", or wants to understand the overall health of a project before a major effort. Trigger even if the user doesn't say \"technical debt\" explicitly — any request to systematically assess code quality and identify improvement priorities belongs here.","https:\u002F\u002Fgithub.com\u002Fdavila7\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fdevelopment\u002Ftechnical-debt-auditor\u002FSKILL.md",[111],{"categoryNo":85,"categoryName":86,"taxonomyType":21,"taxonomyTypeDesc":22},[113,114,115,116,117,118,119,120,121,122,123,41,124,125,126,127,128,129,130,131],"technical debt","debt","technical","technical debt auditor","auditor","coverage","complexity","markers","project","cleanup","unused","code","todo","work","plan","focus","signals","audit","dependency",{"skillNo":133,"name":134,"nameZh":6,"description":135,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":136,"categories":137,"keywords":145,"publishedAt":42},"01M70KPYH9QNHCNME5GJQGE22K","readonly-sql-guard","Make an agent's database access provably read-only. Use when an agent runs caller-supplied SQL against a production\u002FERP\u002Fanalytics database (a \"query\" MCP tool, text-to-SQL, an admin console), or when reviewing DB-access code for write\u002FDDL\u002Fside-effect\u002Ftransaction-escape risks. Checks what a statement CALLS, not just its shape.","https:\u002F\u002Fgithub.com\u002Fdavila7\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fdatabase\u002Freadonly-sql-guard\u002FSKILL.md",[138,139,140],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":85,"categoryName":86,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":141,"categoryName":142,"taxonomyType":143,"taxonomyTypeDesc":144},"01JBSEEDCAT000000000000033","数据分析师","PROFESSION","适用职业",[146,147,148,149,150,151,152,40,153,154,155,156,157,158,159,35,160,161,41,162],"readonly","guard","sql guard","sql","readonly sql guard","erp","effect","read-only","db","just","tool","calls","only","MCP","access","database","query",{"skillNo":164,"name":165,"nameZh":6,"description":166,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":167,"licenseFileUrl":168,"sourceHtmlUrl":169,"categories":170,"keywords":172,"publishedAt":42},"01M6AFY6F7CC2BBZP1QD6VTNVC","web-artifacts-builder","Suite of tools for creating elaborate, multi-component claude.ai HTML artifacts using modern frontend web technologies (React, Tailwind CSS, shadcn\u002Fui). Use for complex artifacts requiring state management, routing, or shadcn\u002Fui components - not for simple single-file HTML\u002FJSX artifacts.","Apache-2.0","https:\u002F\u002Fgithub.com\u002Fdavila7\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Futilities\u002Fweb-artifacts-builder\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fdavila7\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Futilities\u002Fweb-artifacts-builder\u002FSKILL.md",[171],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[173,174,175,176,177,178,179,180,181,182,27,31,183,184,185,186,187,188,189,190,191,192,40,193],"artifacts builder","web","web artifacts builder","artifacts","builder","state","routing","state management","component","css","Tools","file","components","shadcn","react","Tailwind","suite","jsx","html","single-file","ui components",{"skillNo":195,"name":196,"nameZh":6,"description":197,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":167,"licenseFileUrl":198,"sourceHtmlUrl":199,"categories":200,"keywords":205,"publishedAt":42},"01M6AFWF33SFV9Z3SF4PEEE4BF","webapp-testing","Toolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.","https:\u002F\u002Fgithub.com\u002Fdavila7\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fsecurity\u002Fwebapp-testing\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fdavila7\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fsecurity\u002Fwebapp-testing\u002FSKILL.md",[201,204],{"categoryNo":202,"categoryName":203,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[206,207,208,209,210,174,211,27,31,212,213,214,215,40,216,96,217],"webapp testing","testing","webapp","browser","playwright","applications","debugging","toolkit","logs","screenshots","local","behavior",{"skillNo":219,"name":220,"nameZh":6,"description":221,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":167,"licenseFileUrl":222,"sourceHtmlUrl":223,"categories":224,"keywords":232,"publishedAt":42},"01M6AF67Q67JJJ5V51JR2P52KA","discernment-nudge","After you give a substantive answer or draft that the user may act on — advice or recommendations, drafted artifacts such as goals, plans, pitches, proposals, or emails, estimates or projections, analysis or interpretation of data, factual claims they may rely on, or a multi-step argument — invoke this skill BEFORE finalizing your reply and then, if it applies, append 2-3 short follow-up questions, each tied to something specific in what you just produced, that help the user check key facts, probe the reasoning or assumptions, and notice missing context. Do this at most once per conversation. Skip it when the user asked a trivial how-to or simple lookup, wants a purely educational explanation, asked you only to format, convert, or assemble a file from content they provided, is writing code they will run, is doing creative writing or casual chat, or already asked you to double-check, cite, or review — the skill file explains these boundaries and the exact output format.","https:\u002F\u002Fgithub.com\u002Fdavila7\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fproductivity\u002Fdiscernment-nudge\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fdavila7\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fproductivity\u002Fdiscernment-nudge\u002FSKILL.md",[225,228,229],{"categoryNo":226,"categoryName":227,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":85,"categoryName":86,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":230,"categoryName":231,"taxonomyType":143,"taxonomyTypeDesc":144},"01JBSEEDCAT000000000000036","内容创作者",[233,234,235,236,237,238,32,239,176,240,184,124,241,242,243,244,245,158,246,41,247,248,249,250,251,102,252],"discernment nudge","nudge","interpretation","help","run","reasoning","writing","lookup","content","review","conversation","short","up","invoke","you","analysis","claims","argument","assemble","recommendations"]