[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6P8K2DZ1M76Q0W55H7J8NFB":3,"skill-same:01M6P8K2DZ1M76Q0W55H7J8NFB":74},{"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":31,"publishedAt":47,"linkOnly":48,"markdownContent":49,"markdownBody":50,"frontMatter":51,"refName":52,"commitSha":53,"skillDirectory":54,"forksCount":55,"repositoryHtmlUrl":56,"repositoryHomepageUrl":57,"ownerHtmlUrl":58,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":59,"install":60,"resources":73},"01M6P8K2DZ1M76Q0W55H7J8NFB","chatto-audit-api",null,"Audit Chatto API design for consistency, completeness, integration use, and future growth. Use for a whole-API review or a focused review of a service or workflow.","chattocorp\u002Fchatto","chattocorp","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F261891647?v=4","01M6P8ECJF78VVQ1TJBW2JAWQ8","ChattoCorp GmbH","01M6P8ECPWHQVQBB8XNCRR70B9",2968,"AGPL-3.0","https:\u002F\u002Fgithub.com\u002Fchattocorp\u002Fchatto\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fchatto-audit-api\u002FSKILL.md",[18,23,26],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[32,33,34,35,36,37,38,39,40,41,42,43,44,45,46],"audit","api","chatto audit api","design","review","workflow","api review","api design","integration","growth","use","service","completeness","consistency","for","2026-11-10 10:12:30",false,"---\nname: chatto-audit-api\ndescription: Audit Chatto API design for consistency, completeness, integration use, and future growth. Use for a whole-API review or a focused review of a service or workflow.\n---\n\n# Chatto API Design Audit\n\nAsk: **Can an independent integration use Chatto's supported features without\ncopying the bundled frontend's assumptions?**\n\nReview the public contract first. Inspect implementation only to confirm\nbehavior that the contract does not settle. Report implementation defects\nseparately from design gaps. This skill does not authorize fixes, issues,\ncommits, or PRs; those need a separate user instruction.\n\n## Scope and Sources\n\n- Follow root and path-specific `AGENTS.md`, including the current release\n  policy. Keep Chatto separate from Authling and shared framework modules.\n- Apply [API rules](..\u002Frules\u002Fchatto-api-rules\u002FSKILL.md). Use\n  [API compatibility](..\u002Fchatto-api-compatibility\u002FSKILL.md) for version and\n  migration effects. Link to those rules instead of copying them.\n- Start with public protobufs under `proto\u002Fchatto\u002F`, mounted services, and\n  generated API docs. Use [FDRs](..\u002F..\u002F..\u002F..\u002Fdocs\u002Ffdr\u002FINDEX.md) to identify\n  supported features and [interfaces](..\u002F..\u002F..\u002F..\u002Fdocs\u002Farchitecture\u002Finterfaces.md)\n  to check exposed surfaces. Use the [glossary](..\u002F..\u002F..\u002F..\u002Fdocs\u002FGLOSSARY.md)\n  for terms and relevant ADRs for intentional design choices.\n- For a full audit, cover integration, admin, auth, discovery, and realtime\n  contracts. Keep the local Operator API in a separate section if reviewed.\n  For a focused request, limit the audit and state what was not checked.\n- Check relevant callers, tests, and docs to confirm findings. The frontend\n  shows one use of the API; it does not define the full requirement.\n\n## Audit Method\n\n1. Map services to resources and supported features. Note available reads,\n   commands, collections, related IDs, and live events. Check that declared\n   operations are mounted and usable by their intended callers.\n2. Trace a few real workflows for the scope: a bot, an independent chat client,\n   an admin tool, or a JSON-only integration. Start with discovery and access;\n   follow the work through reads, writes, and refresh or reconnect as needed.\n3. Apply the checks below. Mark each area as checked, not applicable, or not\n   checked. Follow evidence; do not turn the checklist into a feature wish list.\n4. Compare apparent gaps with documented product limits and design decisions.\n   Confirm a concrete client problem before recommending a change.\n\n## Design Checks\n\n| Area | Questions |\n| --- | --- |\n| Names and ownership | Do service, method, field, and resource names have clear, consistent meanings? Are public, admin, self-only, and operator actions in the right scope? Are old aliases or duplicate operations still needed? |\n| Resource shapes | Is each resource represented by a canonical type where access and lifecycle match? Do summaries clearly identify previews? Can related IDs be resolved without parsing labels, URLs, or private data? |\n| Useful completeness | Can clients discover, read, change, and observe each supported feature? Can they read state they can write? Can they retrieve all members behind a count or preview? Are singular or batch reads needed for a real workflow? |\n| Integration independence | Can clients work without a browser session, sidebar model, frontend cache, or large bootstrap response where these are not inherent requirements? Can bots use the features allowed by their permissions? Are defaults based on product meaning rather than one screen? |\n| Updates and commands | Are masks, field presence, defaults, resets, nulls, and empty values clear? Are state updates distinct from commands? Does a successful write return useful resulting state or a clear way to read it? |\n| Collections | Are potentially large results bounded? Are page defaults, limits, filters, counts, ordering, tie-breakers, and continuation rules defined? Do batch reads define limits, duplicates, result order, missing targets, and partial failures? |\n| Access and privacy | Are caller identity, membership, permissions, and resource visibility clear? Are self-only fields kept private? Do counts, previews, batches, errors, and events respect the same visibility boundaries? |\n| Errors and retries | Can clients distinguish bad input, missing access, missing resources, conflicts, limits, and temporary failure? Are no-op behavior and retry safety clear? What happens if a write succeeds but its response is lost? |\n| Realtime and recovery | Can clients read current state, observe relevant changes, and recover after a gap? Can they resolve IDs from events? Are snapshot, event, ordering, cursor, and read-after-write contracts clear? Does live delivery complement explicit reads? |\n| Future growth | Can supported features grow without unbounded responses or repeated breaking redesigns? Are enums, unions, optional fields, and version boundaries deliberate? Are extension points justified by real needs rather than hypothetical flexibility? |\n| JSON and generated clients | Can both JSON and protobuf consumers express the same operations? Are masks, timestamps, integer counts, enums, and absence understandable? Are generated clients and public examples aligned with the contract? |\n| Documentation | Can an API user identify required IDs, access, defaults, side effects, response meaning, and important limits without reading server code? Do guides agree with schemas and behavior? |\n\n## Evidence and Verification\n\nUse source paths and line references for findings. Distinguish a confirmed\nproblem from an open question. A missing test alone is not a design defect.\n\nRun existing focused checks when they can resolve uncertainty. Schema lint\nand compatibility checks do not prove usability or behavior. Do not run a full\nsuite or start a server merely to inventory the API. Follow repository browser\ntooling rules when browser verification is needed. State what was verified.\n\nDo not require CRUD, batch methods, events, or configuration for every resource.\nRequire them only when a supported workflow needs them. Treat documented\nexceptions as choices to assess, not automatic violations.\n\n## Report and Stop\n\nLead with a short verdict on integration use, completeness, consistency, and\nfuture growth. State the scope and verification limits.\n\nFor each actionable finding, give:\n\n- Priority and affected service or workflow.\n- Source evidence and the concrete problem for an API consumer.\n- The smallest useful change and why it improves the contract.\n- Compatibility and caller migration effects; note stored-data effects separately.\n\nSeparate confirmed defects, design improvements, and open questions. Rank\nfindings by client impact, not naming preference. Group related findings into\nsmall, coherent changes and recommend one next step.\n\nDo not reopen explicitly deferred work unless new evidence changes its impact.\nDo not invent follow-up tasks to keep the audit going. If no meaningful gaps\nremain, say that the API is good enough for the reviewed scope and stop.\n","# Chatto API Design Audit\n\nAsk: **Can an independent integration use Chatto's supported features without\ncopying the bundled frontend's assumptions?**\n\nReview the public contract first. Inspect implementation only to confirm\nbehavior that the contract does not settle. Report implementation defects\nseparately from design gaps. This skill does not authorize fixes, issues,\ncommits, or PRs; those need a separate user instruction.\n\n## Scope and Sources\n\n- Follow root and path-specific `AGENTS.md`, including the current release\n  policy. Keep Chatto separate from Authling and shared framework modules.\n- Apply [API rules](..\u002Frules\u002Fchatto-api-rules\u002FSKILL.md). Use\n  [API compatibility](..\u002Fchatto-api-compatibility\u002FSKILL.md) for version and\n  migration effects. Link to those rules instead of copying them.\n- Start with public protobufs under `proto\u002Fchatto\u002F`, mounted services, and\n  generated API docs. Use [FDRs](..\u002F..\u002F..\u002F..\u002Fdocs\u002Ffdr\u002FINDEX.md) to identify\n  supported features and [interfaces](..\u002F..\u002F..\u002F..\u002Fdocs\u002Farchitecture\u002Finterfaces.md)\n  to check exposed surfaces. Use the [glossary](..\u002F..\u002F..\u002F..\u002Fdocs\u002FGLOSSARY.md)\n  for terms and relevant ADRs for intentional design choices.\n- For a full audit, cover integration, admin, auth, discovery, and realtime\n  contracts. Keep the local Operator API in a separate section if reviewed.\n  For a focused request, limit the audit and state what was not checked.\n- Check relevant callers, tests, and docs to confirm findings. The frontend\n  shows one use of the API; it does not define the full requirement.\n\n## Audit Method\n\n1. Map services to resources and supported features. Note available reads,\n   commands, collections, related IDs, and live events. Check that declared\n   operations are mounted and usable by their intended callers.\n2. Trace a few real workflows for the scope: a bot, an independent chat client,\n   an admin tool, or a JSON-only integration. Start with discovery and access;\n   follow the work through reads, writes, and refresh or reconnect as needed.\n3. Apply the checks below. Mark each area as checked, not applicable, or not\n   checked. Follow evidence; do not turn the checklist into a feature wish list.\n4. Compare apparent gaps with documented product limits and design decisions.\n   Confirm a concrete client problem before recommending a change.\n\n## Design Checks\n\n| Area | Questions |\n| --- | --- |\n| Names and ownership | Do service, method, field, and resource names have clear, consistent meanings? Are public, admin, self-only, and operator actions in the right scope? Are old aliases or duplicate operations still needed? |\n| Resource shapes | Is each resource represented by a canonical type where access and lifecycle match? Do summaries clearly identify previews? Can related IDs be resolved without parsing labels, URLs, or private data? |\n| Useful completeness | Can clients discover, read, change, and observe each supported feature? Can they read state they can write? Can they retrieve all members behind a count or preview? Are singular or batch reads needed for a real workflow? |\n| Integration independence | Can clients work without a browser session, sidebar model, frontend cache, or large bootstrap response where these are not inherent requirements? Can bots use the features allowed by their permissions? Are defaults based on product meaning rather than one screen? |\n| Updates and commands | Are masks, field presence, defaults, resets, nulls, and empty values clear? Are state updates distinct from commands? Does a successful write return useful resulting state or a clear way to read it? |\n| Collections | Are potentially large results bounded? Are page defaults, limits, filters, counts, ordering, tie-breakers, and continuation rules defined? Do batch reads define limits, duplicates, result order, missing targets, and partial failures? |\n| Access and privacy | Are caller identity, membership, permissions, and resource visibility clear? Are self-only fields kept private? Do counts, previews, batches, errors, and events respect the same visibility boundaries? |\n| Errors and retries | Can clients distinguish bad input, missing access, missing resources, conflicts, limits, and temporary failure? Are no-op behavior and retry safety clear? What happens if a write succeeds but its response is lost? |\n| Realtime and recovery | Can clients read current state, observe relevant changes, and recover after a gap? Can they resolve IDs from events? Are snapshot, event, ordering, cursor, and read-after-write contracts clear? Does live delivery complement explicit reads? |\n| Future growth | Can supported features grow without unbounded responses or repeated breaking redesigns? Are enums, unions, optional fields, and version boundaries deliberate? Are extension points justified by real needs rather than hypothetical flexibility? |\n| JSON and generated clients | Can both JSON and protobuf consumers express the same operations? Are masks, timestamps, integer counts, enums, and absence understandable? Are generated clients and public examples aligned with the contract? |\n| Documentation | Can an API user identify required IDs, access, defaults, side effects, response meaning, and important limits without reading server code? Do guides agree with schemas and behavior? |\n\n## Evidence and Verification\n\nUse source paths and line references for findings. Distinguish a confirmed\nproblem from an open question. A missing test alone is not a design defect.\n\nRun existing focused checks when they can resolve uncertainty. Schema lint\nand compatibility checks do not prove usability or behavior. Do not run a full\nsuite or start a server merely to inventory the API. Follow repository browser\ntooling rules when browser verification is needed. State what was verified.\n\nDo not require CRUD, batch methods, events, or configuration for every resource.\nRequire them only when a supported workflow needs them. Treat documented\nexceptions as choices to assess, not automatic violations.\n\n## Report and Stop\n\nLead with a short verdict on integration use, completeness, consistency, and\nfuture growth. State the scope and verification limits.\n\nFor each actionable finding, give:\n\n- Priority and affected service or workflow.\n- Source evidence and the concrete problem for an API consumer.\n- The smallest useful change and why it improves the contract.\n- Compatibility and caller migration effects; note stored-data effects separately.\n\nSeparate confirmed defects, design improvements, and open questions. Rank\nfindings by client impact, not naming preference. Group related findings into\nsmall, coherent changes and recommend one next step.\n\nDo not reopen explicitly deferred work unless new evidence changes its impact.\nDo not invent follow-up tasks to keep the audit going. If no meaningful gaps\nremain, say that the API is good enough for the reviewed scope and stop.\n",{"name":5,"description":7},"main","d3d21f4a4fb6c1315aa62df97a6cb6617680af95",".agents\u002Fskills\u002Fchatto-audit-api",152,"https:\u002F\u002Fgithub.com\u002Fchattocorp\u002Fchatto","https:\u002F\u002Fchatto.run","https:\u002F\u002Fgithub.com\u002Fchattocorp","2026-11-13 19:40:22",{"source":8,"skillName":5,"commands":61,"prompt":71,"zipAvailable":72},[62,65,68],{"tool":63,"command":64},"npx","npx skills add chattocorp\u002Fchatto --skill chatto-audit-api",{"tool":66,"command":67},"bunx","bunx skills add chattocorp\u002Fchatto --skill chatto-audit-api",{"tool":69,"command":70},"pnpm","pnpm dlx skills add chattocorp\u002Fchatto --skill chatto-audit-api","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fchattocorp\u002Fchatto\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fchatto-audit-api\u002FSKILL.md",true,[],[75,92,111,127,150,174],{"skillNo":76,"name":77,"nameZh":6,"description":78,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":79,"categories":80,"keywords":87,"publishedAt":47},"01M6P8S7F1NYMKD9PW2RGZ0B2P","writing-tests","Instructions and hints for writing tests.","https:\u002F\u002Fgithub.com\u002Fchattocorp\u002Fchatto\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fwriting-tests\u002FSKILL.md",[81,84],{"categoryNo":82,"categoryName":83,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":85,"categoryName":86,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000036","内容创作者",[88,89,90,91,46],"writing","writing tests","tests","instructions",{"skillNo":93,"name":94,"nameZh":6,"description":95,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":96,"categories":97,"keywords":101,"publishedAt":47},"01M6P8S131Q068WC04FS0YW3RR","update-project-dependencies","Update Chatto Go and frontend dependencies within their compatible version ranges, then run tests.","https:\u002F\u002Fgithub.com\u002Fchattocorp\u002Fchatto\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fupdate-project-dependencies\u002FSKILL.md",[98],{"categoryNo":99,"categoryName":100,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",[102,103,104,105,106,107,108,109,110,90],"dependencies","update","project","update project dependencies","frontend","go","run tests","run","version",{"skillNo":112,"name":113,"nameZh":6,"description":114,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":117,"publishedAt":47},"01M6P8RERB7E3KYD4PW98D94SR","svelte-docs","Look up official Svelte, SvelteKit, and Svelte CLI documentation.","https:\u002F\u002Fgithub.com\u002Fchattocorp\u002Fchatto\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fsvelte-docs\u002FSKILL.md",[],[118,119,120,121,122,123,124,125,126],"svelte","svelte docs","docs","look","cli","official","documentation","sveltekit","up",{"skillNo":128,"name":129,"nameZh":6,"description":130,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":131,"categories":132,"keywords":133,"publishedAt":47},"01M6P8RA0PS8DFAR8GXMB1CBFN","svelte-core-bestpractices","Guidance on writing fast, robust, modern Svelte code. Load this skill whenever in a Svelte project and asked to write\u002Fedit or analyze a Svelte component or module. Covers reactivity, event handling, styling, integration with libraries and more.","https:\u002F\u002Fgithub.com\u002Fchattocorp\u002Fchatto\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fsvelte-core-bestpractices\u002FSKILL.md",[],[118,134,135,136,137,138,104,139,140,141,142,143,144,145,146,40,147,148,88,149],"svelte core bestpractices","core","with","event","module","guidance","styling","edit","write","analyze","more","load","component","code","libraries","fast",{"skillNo":151,"name":152,"nameZh":6,"description":153,"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":160,"publishedAt":47},"01M6P8R685PAMMR1DD530NGY40","svelte-code-writer","CLI tools for Svelte 5 documentation lookup and code analysis. MUST be used whenever creating, editing or analyzing any Svelte component (.svelte) or Svelte module (.svelte.ts\u002F.svelte.js). If possible, this skill should be executed within the svelte-file-editor agent for optimal results.","https:\u002F\u002Fgithub.com\u002Fchattocorp\u002Fchatto\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fsvelte-code-writer\u002FSKILL.md",[156,159],{"categoryNo":157,"categoryName":158,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},[147,161,118,162,146,163,122,124,164,46,165,138,166,167,168,169,170,171,172,173],"svelte code writer","writer","editor","svelte 5","code analysis","results","editing","js","documentation lookup","analysis","Tools","analyzing","file",{"skillNo":175,"name":176,"nameZh":6,"description":177,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":178,"categories":179,"keywords":180,"publishedAt":47},"01M6P8QN03VSSHF538WV0E701T","session-wrap-up","Review a completed, paused, or blocked coding-agent session to identify friction, mistakes, near misses, missing context, and opportunities to improve future work. Use when the user asks to wrap up, run a retrospective, explain what issues the agent faced, capture lessons learned, or recommend improvements to repository instructions, documentation, skills, tooling, tests, or workflows. Produce an evidence-based, propose-only report; do not apply follow-up changes unless the user asks.","https:\u002F\u002Fgithub.com\u002Fchattocorp\u002Fchatto\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fsession-wrap-up\u002FSKILL.md",[],[181,182,126,183,184,185,186,187,188,189,190,191,192,193,194,195,196,197,109,124,198,36],"wrap","session wrap","session","session wrap up","wrap up","Coding-Agent","agent session","when","recommend","near","follow-up","learned","only","work","improve","repository","issues","workflows"]