[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6P8QN03VSSHF538WV0E701T":3,"skill-same:01M6P8QN03VSSHF538WV0E701T":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":18,"publishedAt":41,"linkOnly":42,"markdownContent":43,"markdownBody":44,"frontMatter":45,"refName":46,"commitSha":47,"skillDirectory":48,"forksCount":49,"repositoryHtmlUrl":50,"repositoryHomepageUrl":51,"ownerHtmlUrl":52,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":53,"install":54,"resources":67},"01M6P8QN03VSSHF538WV0E701T","session-wrap-up",null,"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.","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\u002Fsession-wrap-up\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40],"wrap up","wrap","session wrap up","session","session wrap","up","only","agent session","when","recommend","near","follow-up","learned","Coding-Agent","review","work","improve","repository","issues","run","documentation","workflows","2026-11-10 10:12:30",false,"---\nname: session-wrap-up\ndescription: 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.\n---\n\n# Session Wrap-Up\n\nRun a candid, compact retrospective of the current session. Base it on the\nconversation, commands, tool output, edits, verification, and unresolved work;\ndo not invent friction to make the report look substantial.\n\n## Interrogate The Session\n\nAsk yourself:\n\n- Where did I lose time, take a false start, or repeat work?\n- What did I misunderstand or assume too early?\n- What did the user's questions or corrections reveal about unclear scope,\n  location, status, or explanation?\n- Which instructions were missing, hard to discover, ambiguous, or in tension?\n- Which code, documentation, architecture, or terminology did I have to\n  rediscover?\n- Which tool, dependency, environment, build, or test failure slowed the work?\n- What nearly went wrong, even if the final result was correct?\n- What remains incomplete, uncertain, or insufficiently verified?\n- What worked especially well and is worth preserving or standardising?\n- What single change would most improve a similar session next time?\n\nVerify the factual premise behind user questions and corrections against the\navailable evidence. Treat a correction as strong evidence of an expectation or\ncommunication gap even when its diagnosis is not confirmed.\n\nBefore reporting the outcome, perform only the cheap read-only checks needed to\nconfirm the current state. For repository work, normally inspect working-tree\nstatus and the changed-file summary, then reconcile them with verification\nalready recorded in the session. Do not rerun expensive tests solely for the\nwrap-up. State when relevant evidence is unavailable.\n\nDistinguish observed facts from diagnosis and speculation. Say \"No material\nfriction observed\" when that is the honest conclusion.\n\n## Classify Findings\n\nAssign each meaningful issue to the narrowest useful category:\n\n- **Agent practice**: planning, assumptions, sequencing, communication, tool\n  choice, or verification discipline.\n- **Repository knowledge**: `AGENTS.md`, documentation, architecture inventory,\n  glossary, examples, or code discoverability.\n- **Reusable workflow**: a missing or weak skill, script, task, template, check,\n  or automation.\n- **Environment or tooling**: dependencies, permissions, local setup, external\n  services, or product limitations.\n- **Task definition**: unclear scope, acceptance criteria, ownership, or product\n  boundary.\n\nKeep Chatto, Authling, shared-framework, and repository-wide recommendations\nseparate. Place a proposed improvement with the product or infrastructure that\nowns it.\n\n## Recommend Improvements\n\nFor each material finding, propose the smallest change likely to prevent the\nsame class of friction. Include:\n\n- the evidence and impact;\n- whether the root cause is known or inferred;\n- the concrete improvement and likely owner or location;\n- the expected payoff and any trade-off;\n- a priority of **now**, **soon**, or **only if repeated**.\n\nPrefer durable fixes over reminders. Examples include tightening a scoped\ninstruction, adding a focused test, exposing an existing task, improving an\nerror message, documenting a hidden invariant, or extending a relevant skill.\nDo not recommend new process or documentation when a simpler code or tooling\nfix would remove the problem.\n\nKeep the wrap-up propose-only. Do not edit files, create issues, send feedback,\nor start follow-up work unless the user explicitly asks.\n\n## Report Format\n\nReturn one concise report with these sections:\n\n### Outcome\n\nState the session goal, result, and verification level. Call out incomplete or\nunverified work without repeating the entire implementation handoff.\n\n### Friction And Near Misses\n\nList only evidence-backed findings. For each, give the category, what happened,\nand its practical impact. Separate agent mistakes from repository or tooling\nproblems. Treat direct user corrections as high-signal evidence of an\nexpectation or communication gap, not automatic proof of their diagnosis. Do\nnot infer dissatisfaction from tone alone.\n\n### What Worked\n\nCapture practices, instructions, tools, or repository affordances that made the\nsession more reliable or efficient.\n\n### Improvements\n\nPrioritise at most five concrete proposals. Name the likely owner or file when\nknown, and mark inferred diagnoses clearly.\n\n### Recommended Next Step\n\nChoose the single highest-leverage action. If no follow-up is warranted, say\nso. End with one short question only when the user's perspective would\nmaterially change the recommendation.\n\n## Guardrails\n\n- Be specific and candid without assigning blame or performing false humility.\n- Do not exaggerate routine exploration into a systemic problem.\n- Do not hide the agent's own errors behind tooling or instruction complaints.\n- Do not expose secrets, personal data, or sensitive command output.\n- Do not claim that a proposed improvement is validated when it has not been\n  tried.\n","# Session Wrap-Up\n\nRun a candid, compact retrospective of the current session. Base it on the\nconversation, commands, tool output, edits, verification, and unresolved work;\ndo not invent friction to make the report look substantial.\n\n## Interrogate The Session\n\nAsk yourself:\n\n- Where did I lose time, take a false start, or repeat work?\n- What did I misunderstand or assume too early?\n- What did the user's questions or corrections reveal about unclear scope,\n  location, status, or explanation?\n- Which instructions were missing, hard to discover, ambiguous, or in tension?\n- Which code, documentation, architecture, or terminology did I have to\n  rediscover?\n- Which tool, dependency, environment, build, or test failure slowed the work?\n- What nearly went wrong, even if the final result was correct?\n- What remains incomplete, uncertain, or insufficiently verified?\n- What worked especially well and is worth preserving or standardising?\n- What single change would most improve a similar session next time?\n\nVerify the factual premise behind user questions and corrections against the\navailable evidence. Treat a correction as strong evidence of an expectation or\ncommunication gap even when its diagnosis is not confirmed.\n\nBefore reporting the outcome, perform only the cheap read-only checks needed to\nconfirm the current state. For repository work, normally inspect working-tree\nstatus and the changed-file summary, then reconcile them with verification\nalready recorded in the session. Do not rerun expensive tests solely for the\nwrap-up. State when relevant evidence is unavailable.\n\nDistinguish observed facts from diagnosis and speculation. Say \"No material\nfriction observed\" when that is the honest conclusion.\n\n## Classify Findings\n\nAssign each meaningful issue to the narrowest useful category:\n\n- **Agent practice**: planning, assumptions, sequencing, communication, tool\n  choice, or verification discipline.\n- **Repository knowledge**: `AGENTS.md`, documentation, architecture inventory,\n  glossary, examples, or code discoverability.\n- **Reusable workflow**: a missing or weak skill, script, task, template, check,\n  or automation.\n- **Environment or tooling**: dependencies, permissions, local setup, external\n  services, or product limitations.\n- **Task definition**: unclear scope, acceptance criteria, ownership, or product\n  boundary.\n\nKeep Chatto, Authling, shared-framework, and repository-wide recommendations\nseparate. Place a proposed improvement with the product or infrastructure that\nowns it.\n\n## Recommend Improvements\n\nFor each material finding, propose the smallest change likely to prevent the\nsame class of friction. Include:\n\n- the evidence and impact;\n- whether the root cause is known or inferred;\n- the concrete improvement and likely owner or location;\n- the expected payoff and any trade-off;\n- a priority of **now**, **soon**, or **only if repeated**.\n\nPrefer durable fixes over reminders. Examples include tightening a scoped\ninstruction, adding a focused test, exposing an existing task, improving an\nerror message, documenting a hidden invariant, or extending a relevant skill.\nDo not recommend new process or documentation when a simpler code or tooling\nfix would remove the problem.\n\nKeep the wrap-up propose-only. Do not edit files, create issues, send feedback,\nor start follow-up work unless the user explicitly asks.\n\n## Report Format\n\nReturn one concise report with these sections:\n\n### Outcome\n\nState the session goal, result, and verification level. Call out incomplete or\nunverified work without repeating the entire implementation handoff.\n\n### Friction And Near Misses\n\nList only evidence-backed findings. For each, give the category, what happened,\nand its practical impact. Separate agent mistakes from repository or tooling\nproblems. Treat direct user corrections as high-signal evidence of an\nexpectation or communication gap, not automatic proof of their diagnosis. Do\nnot infer dissatisfaction from tone alone.\n\n### What Worked\n\nCapture practices, instructions, tools, or repository affordances that made the\nsession more reliable or efficient.\n\n### Improvements\n\nPrioritise at most five concrete proposals. Name the likely owner or file when\nknown, and mark inferred diagnoses clearly.\n\n### Recommended Next Step\n\nChoose the single highest-leverage action. If no follow-up is warranted, say\nso. End with one short question only when the user's perspective would\nmaterially change the recommendation.\n\n## Guardrails\n\n- Be specific and candid without assigning blame or performing false humility.\n- Do not exaggerate routine exploration into a systemic problem.\n- Do not hide the agent's own errors behind tooling or instruction complaints.\n- Do not expose secrets, personal data, or sensitive command output.\n- Do not claim that a proposed improvement is validated when it has not been\n  tried.\n",{"name":5,"description":7},"main","d3d21f4a4fb6c1315aa62df97a6cb6617680af95",".agents\u002Fskills\u002Fsession-wrap-up",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":55,"prompt":65,"zipAvailable":66},[56,59,62],{"tool":57,"command":58},"npx","npx skills add chattocorp\u002Fchatto --skill session-wrap-up",{"tool":60,"command":61},"bunx","bunx skills add chattocorp\u002Fchatto --skill session-wrap-up",{"tool":63,"command":64},"pnpm","pnpm dlx skills add chattocorp\u002Fchatto --skill session-wrap-up","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fchattocorp\u002Fchatto\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fsession-wrap-up\u002FSKILL.md",true,[68],{"path":69,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":72,"sourceHtmlUrl":73},"agents\u002Fopenai.yaml","REFERENCE","参考文档",222,"https:\u002F\u002Fgithub.com\u002Fchattocorp\u002Fchatto\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fsession-wrap-up\u002Fagents\u002Fopenai.yaml",[75,97,115,129,153,179],{"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":91,"publishedAt":41},"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,86],{"categoryNo":82,"categoryName":83,"taxonomyType":84,"taxonomyTypeDesc":85},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":87,"categoryName":88,"taxonomyType":89,"taxonomyTypeDesc":90},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[92,93,94,95,96],"tests","writing tests","writing","instructions","for",{"skillNo":98,"name":99,"nameZh":6,"description":100,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":101,"categories":102,"keywords":106,"publishedAt":41},"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",[103],{"categoryNo":104,"categoryName":105,"taxonomyType":84,"taxonomyTypeDesc":85},"01JBSEEDCAT000000000000009","前端开发",[107,108,109,110,111,112,113,38,114,92],"update","project","update project dependencies","dependencies","frontend","go","run tests","version",{"skillNo":116,"name":117,"nameZh":6,"description":118,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":119,"categories":120,"keywords":121,"publishedAt":41},"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",[],[122,123,124,125,126,39,127,24,128],"docs","svelte","svelte docs","cli","official","sveltekit","look",{"skillNo":130,"name":131,"nameZh":6,"description":132,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":133,"categories":134,"keywords":135,"publishedAt":41},"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",[],[136,137,123,138,139,140,141,108,142,143,144,94,145,146,147,148,149,150,151,152],"core","svelte core bestpractices","more","with","event","load","module","analyze","guidance","component","libraries","code","integration","fast","write","edit","styling",{"skillNo":154,"name":155,"nameZh":6,"description":156,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":157,"categories":158,"keywords":165,"publishedAt":41},"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",[159,162],{"categoryNo":160,"categoryName":161,"taxonomyType":84,"taxonomyTypeDesc":85},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":163,"categoryName":164,"taxonomyType":89,"taxonomyTypeDesc":90},"01JBSEEDCAT000000000000030","开发工程师",[166,123,167,147,168,125,169,145,39,170,171,172,173,174,175,176,177,142,178,96],"svelte code writer","writer","js","editor","file","analyzing","Tools","analysis","documentation lookup","editing","results","svelte 5","code analysis",{"skillNo":180,"name":181,"nameZh":6,"description":182,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":183,"categories":184,"keywords":186,"publishedAt":41},"01M6P8QHHWYSRZM2H4CEGND1GB","pr-tour","A skill that provides a guided tour of a pull request, highlighting key changes, walking the developer through the code, and explaining the purpose of each modification.","https:\u002F\u002Fgithub.com\u002Fchattocorp\u002Fchatto\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fpr-tour\u002FSKILL.md",[185],{"categoryNo":163,"categoryName":164,"taxonomyType":89,"taxonomyTypeDesc":90},[187,188,189,190,147,191,192,193,194],"pr","tour","pr tour","pull request","pull","developer","changes","request"]