[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M780FHB90ZFW7PCDF4T2CZWJ":3,"skill-same:01M780FHB90ZFW7PCDF4T2CZWJ":51},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":18,"linkOnly":19,"markdownContent":20,"markdownBody":21,"frontMatter":22,"refName":23,"commitSha":24,"skillDirectory":25,"forksCount":26,"repositoryHtmlUrl":27,"repositoryHomepageUrl":28,"ownerHtmlUrl":29,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":30,"install":31,"resources":44},"01M780FHB90ZFW7PCDF4T2CZWJ","todo-list",null,"Establish and maintain a lightweight project task list in docs\u002FTODO.md. Use when the user asks to track todos, maintain a TODO.md, preserve follow-up work while implementing features, or keep an agent-readable list of outstanding project tasks.","scrapbotengine\u002Fscrapbot","scrapbotengine","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F299915117?v=4","01M780DWPZF6KY1RNA11SYVNWG","01M780DWQSDY0XMHV21KGMAVX6",6,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fscrapbotengine\u002Fscrapbot\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Ftodo-list\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: todo-list\ndescription: Establish and maintain a lightweight project task list in docs\u002FTODO.md. Use when the user asks to track todos, maintain a TODO.md, preserve follow-up work while implementing features, or keep an agent-readable list of outstanding project tasks.\n---\n\n# Todo List\n\nMaintain `docs\u002FTODO.md` as the project's concise list of outstanding work.\n\n## Core Rules\n\n- Store the list at `docs\u002FTODO.md`. Create `docs\u002F` if needed.\n- Use one todo per line in GitHub Flavored Markdown task syntax:\n\n```markdown\n- [ ] Short task description\n```\n\n- Keep each task short enough to scan. Put details, discussion, acceptance criteria, screenshots, logs, and implementation notes in an external system such as GitHub issues, Linear tickets, ADRs, FDRs, or docs, then link from the task when useful.\n- Do not duplicate a full issue tracker. `docs\u002FTODO.md` is an index of outstanding work, not the place where the work is specified in depth.\n- Preserve user wording when reasonable, but normalize formatting and remove duplicates.\n- Prefer current outstanding tasks only. Remove tasks once they are completed unless the user explicitly asks for completed-task history.\n\n## Workflow\n\n1. Read `docs\u002FTODO.md` before editing it if it exists.\n2. Create the file when the user asks for todo tracking or when this skill is invoked and no file exists.\n3. Add or update tasks as new follow-up work is discovered during planning, implementation, review, or verification.\n4. Remove completed tasks as the work is finished. If a partially completed task still has remaining work, rewrite it to describe only the remaining work.\n5. Re-read the final file before finishing and verify that every todo line is short, actionable, and formatted as `- [ ]`.\n\n## Sections and Milestones\n\nUse optional second-level headings when the user requests grouping or when an existing file already has groups:\n\n```markdown\n# TODO\n\n## Milestone Name\n\n- [ ] Add the missing export button ([issue](https:\u002F\u002Fexample.com))\n- [ ] Document the retry behavior\n```\n\nKeep section names user-facing and stable. Avoid creating elaborate hierarchies; use only `##` headings unless the user asks for more structure.\n\n## Task Wording\n\nGood tasks:\n\n- `- [ ] Add tests for failed webhook retries`\n- `- [ ] Link billing export work to the GitHub issue`\n- `- [ ] Decide whether archived projects appear in search`\n\nAvoid tasks that are too vague or too detailed:\n\n- `- [ ] Fix stuff`\n- `- [ ] Implement the entire multi-step database migration plan with all edge cases described inline`\n\n## Agent Maintenance\n\nWhen working on features, keep `docs\u002FTODO.md` synchronized with reality. Capture legitimate follow-up work instead of burying it in chat, and remove tasks that your current work resolves. Mention material TODO changes in the final response when they affect what remains to do.\n","# Todo List\n\nMaintain `docs\u002FTODO.md` as the project's concise list of outstanding work.\n\n## Core Rules\n\n- Store the list at `docs\u002FTODO.md`. Create `docs\u002F` if needed.\n- Use one todo per line in GitHub Flavored Markdown task syntax:\n\n```markdown\n- [ ] Short task description\n```\n\n- Keep each task short enough to scan. Put details, discussion, acceptance criteria, screenshots, logs, and implementation notes in an external system such as GitHub issues, Linear tickets, ADRs, FDRs, or docs, then link from the task when useful.\n- Do not duplicate a full issue tracker. `docs\u002FTODO.md` is an index of outstanding work, not the place where the work is specified in depth.\n- Preserve user wording when reasonable, but normalize formatting and remove duplicates.\n- Prefer current outstanding tasks only. Remove tasks once they are completed unless the user explicitly asks for completed-task history.\n\n## Workflow\n\n1. Read `docs\u002FTODO.md` before editing it if it exists.\n2. Create the file when the user asks for todo tracking or when this skill is invoked and no file exists.\n3. Add or update tasks as new follow-up work is discovered during planning, implementation, review, or verification.\n4. Remove completed tasks as the work is finished. If a partially completed task still has remaining work, rewrite it to describe only the remaining work.\n5. Re-read the final file before finishing and verify that every todo line is short, actionable, and formatted as `- [ ]`.\n\n## Sections and Milestones\n\nUse optional second-level headings when the user requests grouping or when an existing file already has groups:\n\n```markdown\n# TODO\n\n## Milestone Name\n\n- [ ] Add the missing export button ([issue](https:\u002F\u002Fexample.com))\n- [ ] Document the retry behavior\n```\n\nKeep section names user-facing and stable. Avoid creating elaborate hierarchies; use only `##` headings unless the user asks for more structure.\n\n## Task Wording\n\nGood tasks:\n\n- `- [ ] Add tests for failed webhook retries`\n- `- [ ] Link billing export work to the GitHub issue`\n- `- [ ] Decide whether archived projects appear in search`\n\nAvoid tasks that are too vague or too detailed:\n\n- `- [ ] Fix stuff`\n- `- [ ] Implement the entire multi-step database migration plan with all edge cases described inline`\n\n## Agent Maintenance\n\nWhen working on features, keep `docs\u002FTODO.md` synchronized with reality. Capture legitimate follow-up work instead of burying it in chat, and remove tasks that your current work resolves. Mention material TODO changes in the final response when they affect what remains to do.\n",{"name":5,"description":7},"main","9127ecf5d9735db333cd08b4d01de9f48208df57",".agents\u002Fskills\u002Ftodo-list",1,"https:\u002F\u002Fgithub.com\u002Fscrapbotengine\u002Fscrapbot","https:\u002F\u002Fscrapbot.dev","https:\u002F\u002Fgithub.com\u002Fscrapbotengine","2026-10-07 16:25:44",{"source":8,"skillName":5,"commands":32,"prompt":42,"zipAvailable":43},[33,36,39],{"tool":34,"command":35},"npx","npx skills add scrapbotengine\u002Fscrapbot --skill todo-list",{"tool":37,"command":38},"bunx","bunx skills add scrapbotengine\u002Fscrapbot --skill todo-list",{"tool":40,"command":41},"pnpm","pnpm dlx skills add scrapbotengine\u002Fscrapbot --skill todo-list","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fscrapbotengine\u002Fscrapbot\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Ftodo-list\u002FSKILL.md",true,[45],{"path":46,"resourceType":47,"resourceTypeDesc":48,"sizeBytes":49,"sourceHtmlUrl":50},"agents\u002Fopenai.yaml","REFERENCE","参考文档",219,"https:\u002F\u002Fgithub.com\u002Fscrapbotengine\u002Fscrapbot\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Ftodo-list\u002Fagents\u002Fopenai.yaml",[52,59,66,73,80,87],{"skillNo":53,"name":54,"nameZh":6,"description":55,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":56,"categories":57,"keywords":58,"publishedAt":18},"01M780FDCA3A3V1MFHC7WBBH1V","technical-writing","Invoke this skill whenever you need to create, update, review, restructure, or audit technical documentation such as README files, user manuals, API documentation, architecture notes, setup guides, troubleshooting guides, or developer docs. Use it to align docs with source code, existing project conventions, and the intended audience.","https:\u002F\u002Fgithub.com\u002Fscrapbotengine\u002Fscrapbot\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Ftechnical-writing\u002FSKILL.md",[],[],{"skillNo":60,"name":61,"nameZh":6,"description":62,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":63,"categories":64,"keywords":65,"publishedAt":18},"01M780F8P241XCW3QBSTHGDMGT","scrapbot-ui-development","Use when adding, changing, debugging, reviewing, or documenting Scrapbot ECS UI components, layout, controls, interaction state, styling, reconciliation, project TOML UI, Luau UI APIs, native UI payloads, or editor UI composition. Enforces one reusable public UI contract across projects and the editor.","https:\u002F\u002Fgithub.com\u002Fscrapbotengine\u002Fscrapbot\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fscrapbot-ui-development\u002FSKILL.md",[],[],{"skillNo":67,"name":68,"nameZh":6,"description":69,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":70,"categories":71,"keywords":72,"publishedAt":18},"01M780F3BX29AFTG4HVCMYNNZH","scrapbot-testing","Use when testing or verifying Scrapbot changes, especially scene persistence and authoring savepoints, lifecycle integrity, CLI behavior, generated Luau types, example projects, ECS rendering, WGPU smoke tests, headless framegrabs, PNG artifacts, documentation builds, or before committing.","https:\u002F\u002Fgithub.com\u002Fscrapbotengine\u002Fscrapbot\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fscrapbot-testing\u002FSKILL.md",[],[],{"skillNo":74,"name":75,"nameZh":6,"description":76,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":77,"categories":78,"keywords":79,"publishedAt":18},"01M780EYF176V19ZPJJJSHKS01","scrapbot-feature-development","Use when adding, changing, documenting, or auditing Scrapbot engine features, public APIs, ECS components, rendering, scripting, native extensions, examples, or project tooling. Covers cross-surface implementation, component documentation, generated types, and verification expectations.","https:\u002F\u002Fgithub.com\u002Fscrapbotengine\u002Fscrapbot\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fscrapbot-feature-development\u002FSKILL.md",[],[],{"skillNo":81,"name":82,"nameZh":6,"description":83,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":84,"categories":85,"keywords":86,"publishedAt":18},"01M780ERXV207J7X3VD3RNJM7H","scrapbot-architecture-inventory","Maintain and audit Scrapbot's source-oriented architecture inventory in docs\u002Farchitecture. Use when adding, removing, renaming, or changing engine systems, component registrations, component ownership\u002Flifecycle, project resources, runtime registries, UUID\u002Fhandle\u002Fversion semantics, load\u002Fspawn\u002Fplayback\u002Fpersistence\u002Fhot-reload lifecycles, authoritative or derived state, dirty queues\u002Frevisions\u002Fcaches, frame\u002Frender\u002FUI data flows, package responsibilities, or architectural documentation; also use for architecture overviews and inventory drift audits.","https:\u002F\u002Fgithub.com\u002Fscrapbotengine\u002Fscrapbot\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fscrapbot-architecture-inventory\u002FSKILL.md",[],[],{"skillNo":88,"name":89,"nameZh":6,"description":90,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":91,"categories":92,"keywords":93,"publishedAt":18},"01M780EN88Y59XE1QNEN545ZEF","odin-language","Work effectively in Odin programming language codebases. Use when reading, writing, reviewing, testing, refactoring, or documenting `.odin` files; when choosing idiomatic Odin syntax, packages, allocators, error handling, foreign bindings, tests, build flags, or data-oriented designs; or when translating concepts from C, C++, Go, Lua, or scripting languages into Odin.","https:\u002F\u002Fgithub.com\u002Fscrapbotengine\u002Fscrapbot\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fodin-language\u002FSKILL.md",[],[]]