[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6RAKVHCP4QFP8HR8CF3ZAJ8":3,"skill-same:01M6RAKVHCP4QFP8HR8CF3ZAJ8":59},{"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":34,"linkOnly":35,"markdownContent":36,"markdownBody":37,"frontMatter":38,"refName":39,"commitSha":40,"skillDirectory":41,"forksCount":14,"repositoryHtmlUrl":42,"repositoryHomepageUrl":6,"ownerHtmlUrl":43,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":44,"install":45,"resources":58},"01M6RAKVHCP4QFP8HR8CF3ZAJ8","plan-change",null,"Use when planning a DevPulse feature, bug fix or refactor, clarifying ownership and edge cases, or deciding the implementation and acceptance checks.","shounakmulay\u002Fdev-pulse","shounakmulay","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F42094964?v=4","01M6RAGFC9XZKE4TP55KEREM1B","Shounak Mulay","01M6RAGFJM9FHY8W0D92D9YRF1",0,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fshounakmulay\u002Fdev-pulse\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fplan-change\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33],"change","plan","plan change","planning","acceptance","edge","refactor","bug fix","fix","use","bug","implementation","feature","ownership","when","2026-11-10 10:12:30",false,"---\nname: plan-change\ndescription: Use when planning a DevPulse feature, bug fix or refactor, clarifying ownership and edge cases, or deciding the implementation and acceptance checks.\n---\n\n# Plan a DevPulse change\n\nUse before changing behavior. For a small fix, keep the plan in the conversation; do not create a planning document just to follow this skill. Planning must lead into implementation and testing when the user requested implementation.\n\n## Inspect and decide\n\n1. Read AGENTS.md, CONTEXT.md, applicable scoped instructions and the current worktree status. Preserve unrelated edits. Read an existing task\u002Fspec if supplied; an absent spec is a gap, not permission to invent its contents.\n2. If .codegraph exists, use codegraph_explore with exact paths or symbols before scoped text searches. Trace the affected entry point, consumers, data boundary and tests. Exclude generated output and caches.\n3. Separate existing behavior, intended domain behavior and the requested change. CONTEXT.md describes feed ownership and processing intent; it is not proof that every behavior is implemented. Read active plans only when the requested work touches them.\n4. Describe the user action and expected outcome, exact classes\u002Ffunctions that will change, state\u002Fdata ownership, lifetime and failure behavior. Prefer extending the current path over adding a second refresh, paging or processing path. Inspect a neighboring action before proposing new machinery. Reuse its event, intent and use-case pattern; place behavior shared by multiple ViewModels in the existing feature interactor. Name the concrete requirement before adding an action processor, command hierarchy, pending-operation registry or synchronization.\n5. Identify schema, serialized-state, background-work and platform compatibility implications. Route to specialist skills below. Ask only for decisions the task and available evidence cannot resolve; continue independent authorized work.\n6. Define acceptance cases before implementation. Include relevant success, invalid input, failure, cancellation, stale\u002Fconcurrent work, empty data, restoration and offline\u002Freopen cases. Do not mechanically require every category for every change.\n\n## Ownership references\n\n- [Modules](..\u002F..\u002F..\u002FbuildSrc\u002Fsrc\u002Fmain\u002Fkotlin\u002Fdev\u002Fshounakmulay\u002Fdevpulse\u002Fbuildsrc\u002Fconstants\u002FModules.kt) and settings.gradle.kts identify actual modules. Presentation depends on domain use cases; current repository interfaces live in data modules. Feature-local interactors map domain streams into UI models. Do not relocate interfaces to fit generic Clean Architecture examples.\n- [SetSyncInBackgroundUseCase](..\u002F..\u002F..\u002Fcore\u002Fdomain\u002Fsettings\u002Fsrc\u002FcommonMain\u002Fkotlin\u002Fdev\u002Fshounakmulay\u002Fdevpulse\u002Fcore\u002Fdomain\u002Fsettings\u002Ffeed\u002FSetSyncInBackgroundUseCase.kt) calls [FeedSettingsRepositoryImpl](..\u002F..\u002F..\u002Fcore\u002Fdata\u002Fsettings\u002Fsrc\u002FcommonMain\u002Fkotlin\u002Fdev\u002Fshounakmulay\u002Fdevpulse\u002Fcore\u002Fdata\u002Fsettings\u002FFeedSettingsRepositoryImpl.kt) and [DatastoreDevPulsePreferences](..\u002F..\u002F..\u002Fcore\u002Fdata\u002Fpreferences\u002Fsrc\u002FcommonMain\u002Fkotlin\u002Fdev\u002Fshounakmulay\u002Fdevpulse\u002Fcore\u002Fdata\u002Fpreferences\u002FDatastoreDevPulsePreferences.kt). This is a useful settings persistence path; it is not evidence for a new database table or a second preference store.\n- [FeedListViewModel](..\u002F..\u002F..\u002Ffeature\u002Ffeed\u002Fsrc\u002FcommonMain\u002Fkotlin\u002Fdev\u002Fshounakmulay\u002Fdevpulse\u002Ffeature\u002Ffeed\u002Fscreens\u002Ffeedlist\u002Fui\u002FFeedListViewModel.kt) shows the state -> interactor -> cached paging stream relationship. Its ignored pin-write result is a limitation, not error-handling guidance.\n- [FeedDiscoveryDatabaseTest](..\u002F..\u002F..\u002Fcore\u002Fdata\u002Fdb\u002Fsrc\u002FjvmTest\u002Fkotlin\u002Fdev\u002Fshounakmulay\u002Fdevpulse\u002Fcore\u002Fdata\u002Fdb\u002FFeedDiscoveryDatabaseTest.kt) checks literal results through real storage. Use that kind of acceptance evidence for database behavior, with the current baseline policy.\n\n## Error-contract acceptance\n\nPlan the error boundary explicitly: repositories, DAOs, clients, parsers, mappers and other operations below use cases return plain T, Unit or Flow\u003CT> and let failures throw. Only use cases convert ordinary exceptions to Result\u003CT>\u002FFlow\u003CResult\u003CT>> with the injected DispatcherProvider helpers. Identify whether work is I\u002FO, CPU work or Flow collection, and how callers above the use case handle the Result. Treat existing lower-layer Result\u002Fcatch implementations as violations to correct within the requested scope, not alternative conventions. Acceptance cases distinguish lower-layer thrown failure, use-case failure conversion, upstream Flow failure and propagated cancellation.\n\n## Route by the actual change\n\n- Existing behavior: [implement-change](..\u002Fimplement-change\u002FSKILL.md); new screen\u002Fmodule: [add-screen](..\u002Fadd-screen\u002FSKILL.md) or [add-feature](..\u002Fadd-feature\u002FSKILL.md).\n- Routes, tab stacks or panes: [navigation-3](..\u002Fnavigation-3\u002FSKILL.md); database\u002Fquery\u002Fpersistence: [change-database](..\u002Fchange-database\u002FSKILL.md).\n- HTTP, decoding or catalog reconciliation: [change-network](..\u002Fchange-network\u002FSKILL.md); startup, DI or native\u002Fbackground work: [change-platform](..\u002Fchange-platform\u002FSKILL.md).\n- Behavioral assertions: [test-change](..\u002Ftest-change\u002FSKILL.md); execution scope and final evidence: [verify-change](..\u002Fverify-change\u002FSKILL.md).\n\n## Plan output and completion\n\nState the observable change, exact owners, cohesive file set, edge cases, smallest useful tests and platform\u002Fruntime checks. Name any baseline failure or unresolved decision. Respect an explicit preview-only request. Once authorized, continue with implement-change instead of stopping after a plan.\n\nPreview verification using `bash scripts\u002Fverify.sh --base \u003Creviewed-integration-ref> --plan`. This command plans checks; it does not validate the feature. Reuse existing canonical guidance on refresh instead of adding duplicate skills.\n","# Plan a DevPulse change\n\nUse before changing behavior. For a small fix, keep the plan in the conversation; do not create a planning document just to follow this skill. Planning must lead into implementation and testing when the user requested implementation.\n\n## Inspect and decide\n\n1. Read AGENTS.md, CONTEXT.md, applicable scoped instructions and the current worktree status. Preserve unrelated edits. Read an existing task\u002Fspec if supplied; an absent spec is a gap, not permission to invent its contents.\n2. If .codegraph exists, use codegraph_explore with exact paths or symbols before scoped text searches. Trace the affected entry point, consumers, data boundary and tests. Exclude generated output and caches.\n3. Separate existing behavior, intended domain behavior and the requested change. CONTEXT.md describes feed ownership and processing intent; it is not proof that every behavior is implemented. Read active plans only when the requested work touches them.\n4. Describe the user action and expected outcome, exact classes\u002Ffunctions that will change, state\u002Fdata ownership, lifetime and failure behavior. Prefer extending the current path over adding a second refresh, paging or processing path. Inspect a neighboring action before proposing new machinery. Reuse its event, intent and use-case pattern; place behavior shared by multiple ViewModels in the existing feature interactor. Name the concrete requirement before adding an action processor, command hierarchy, pending-operation registry or synchronization.\n5. Identify schema, serialized-state, background-work and platform compatibility implications. Route to specialist skills below. Ask only for decisions the task and available evidence cannot resolve; continue independent authorized work.\n6. Define acceptance cases before implementation. Include relevant success, invalid input, failure, cancellation, stale\u002Fconcurrent work, empty data, restoration and offline\u002Freopen cases. Do not mechanically require every category for every change.\n\n## Ownership references\n\n- [Modules](..\u002F..\u002F..\u002FbuildSrc\u002Fsrc\u002Fmain\u002Fkotlin\u002Fdev\u002Fshounakmulay\u002Fdevpulse\u002Fbuildsrc\u002Fconstants\u002FModules.kt) and settings.gradle.kts identify actual modules. Presentation depends on domain use cases; current repository interfaces live in data modules. Feature-local interactors map domain streams into UI models. Do not relocate interfaces to fit generic Clean Architecture examples.\n- [SetSyncInBackgroundUseCase](..\u002F..\u002F..\u002Fcore\u002Fdomain\u002Fsettings\u002Fsrc\u002FcommonMain\u002Fkotlin\u002Fdev\u002Fshounakmulay\u002Fdevpulse\u002Fcore\u002Fdomain\u002Fsettings\u002Ffeed\u002FSetSyncInBackgroundUseCase.kt) calls [FeedSettingsRepositoryImpl](..\u002F..\u002F..\u002Fcore\u002Fdata\u002Fsettings\u002Fsrc\u002FcommonMain\u002Fkotlin\u002Fdev\u002Fshounakmulay\u002Fdevpulse\u002Fcore\u002Fdata\u002Fsettings\u002FFeedSettingsRepositoryImpl.kt) and [DatastoreDevPulsePreferences](..\u002F..\u002F..\u002Fcore\u002Fdata\u002Fpreferences\u002Fsrc\u002FcommonMain\u002Fkotlin\u002Fdev\u002Fshounakmulay\u002Fdevpulse\u002Fcore\u002Fdata\u002Fpreferences\u002FDatastoreDevPulsePreferences.kt). This is a useful settings persistence path; it is not evidence for a new database table or a second preference store.\n- [FeedListViewModel](..\u002F..\u002F..\u002Ffeature\u002Ffeed\u002Fsrc\u002FcommonMain\u002Fkotlin\u002Fdev\u002Fshounakmulay\u002Fdevpulse\u002Ffeature\u002Ffeed\u002Fscreens\u002Ffeedlist\u002Fui\u002FFeedListViewModel.kt) shows the state -> interactor -> cached paging stream relationship. Its ignored pin-write result is a limitation, not error-handling guidance.\n- [FeedDiscoveryDatabaseTest](..\u002F..\u002F..\u002Fcore\u002Fdata\u002Fdb\u002Fsrc\u002FjvmTest\u002Fkotlin\u002Fdev\u002Fshounakmulay\u002Fdevpulse\u002Fcore\u002Fdata\u002Fdb\u002FFeedDiscoveryDatabaseTest.kt) checks literal results through real storage. Use that kind of acceptance evidence for database behavior, with the current baseline policy.\n\n## Error-contract acceptance\n\nPlan the error boundary explicitly: repositories, DAOs, clients, parsers, mappers and other operations below use cases return plain T, Unit or Flow\u003CT> and let failures throw. Only use cases convert ordinary exceptions to Result\u003CT>\u002FFlow\u003CResult\u003CT>> with the injected DispatcherProvider helpers. Identify whether work is I\u002FO, CPU work or Flow collection, and how callers above the use case handle the Result. Treat existing lower-layer Result\u002Fcatch implementations as violations to correct within the requested scope, not alternative conventions. Acceptance cases distinguish lower-layer thrown failure, use-case failure conversion, upstream Flow failure and propagated cancellation.\n\n## Route by the actual change\n\n- Existing behavior: [implement-change](..\u002Fimplement-change\u002FSKILL.md); new screen\u002Fmodule: [add-screen](..\u002Fadd-screen\u002FSKILL.md) or [add-feature](..\u002Fadd-feature\u002FSKILL.md).\n- Routes, tab stacks or panes: [navigation-3](..\u002Fnavigation-3\u002FSKILL.md); database\u002Fquery\u002Fpersistence: [change-database](..\u002Fchange-database\u002FSKILL.md).\n- HTTP, decoding or catalog reconciliation: [change-network](..\u002Fchange-network\u002FSKILL.md); startup, DI or native\u002Fbackground work: [change-platform](..\u002Fchange-platform\u002FSKILL.md).\n- Behavioral assertions: [test-change](..\u002Ftest-change\u002FSKILL.md); execution scope and final evidence: [verify-change](..\u002Fverify-change\u002FSKILL.md).\n\n## Plan output and completion\n\nState the observable change, exact owners, cohesive file set, edge cases, smallest useful tests and platform\u002Fruntime checks. Name any baseline failure or unresolved decision. Respect an explicit preview-only request. Once authorized, continue with implement-change instead of stopping after a plan.\n\nPreview verification using `bash scripts\u002Fverify.sh --base \u003Creviewed-integration-ref> --plan`. This command plans checks; it does not validate the feature. Reuse existing canonical guidance on refresh instead of adding duplicate skills.\n",{"name":5,"description":7},"main","0793a3a80d3c675dc6a6cbba3bf45282f4908ba8",".agents\u002Fskills\u002Fplan-change","https:\u002F\u002Fgithub.com\u002Fshounakmulay\u002Fdev-pulse","https:\u002F\u002Fgithub.com\u002Fshounakmulay","2026-11-04 00:07:33",{"source":8,"skillName":5,"commands":46,"prompt":56,"zipAvailable":57},[47,50,53],{"tool":48,"command":49},"npx","npx skills add shounakmulay\u002Fdev-pulse --skill plan-change",{"tool":51,"command":52},"bunx","bunx skills add shounakmulay\u002Fdev-pulse --skill plan-change",{"tool":54,"command":55},"pnpm","pnpm dlx skills add shounakmulay\u002Fdev-pulse --skill plan-change","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fshounakmulay\u002Fdev-pulse\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fplan-change\u002FSKILL.md",true,[],[60,77,100,105,120,135],{"skillNo":61,"name":62,"nameZh":6,"description":63,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":64,"categories":65,"keywords":66,"publishedAt":34},"01M6RAQ4Q5AT2M8ZMJCJZAR5SE","verify-change","Use when verifying DevPulse changes, choosing scoped Gradle checks, reviewing database or feed changes, or reporting platform verification gaps.","https:\u002F\u002Fgithub.com\u002Fshounakmulay\u002Fdev-pulse\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fverify-change\u002FSKILL.md",[],[19,67,68,33,69,70,71,72,73,74,28,75,76],"verify","verify change","gaps","scoped","changes","platform","gradle","verification","reporting","database",{"skillNo":78,"name":79,"nameZh":6,"description":80,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":81,"categories":82,"keywords":88,"publishedAt":34},"01M6RAPQ2X544N3R27SE4B05YC","test-change","Use when adding or reviewing behavioral tests for DevPulse features, state\u002Feffects, use cases, network boundaries, paging, persistence or coroutine lifetimes.","https:\u002F\u002Fgithub.com\u002Fshounakmulay\u002Fdev-pulse\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Ftest-change\u002FSKILL.md",[83],{"categoryNo":84,"categoryName":85,"taxonomyType":86,"taxonomyTypeDesc":87},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[89,19,90,91,92,93,28,94,95,96,97,98,99,33],"test","test change","persistence","state","network","behavioral","tests","lifetimes","for","features","effects",{"skillNo":101,"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":102,"categories":103,"keywords":104,"publishedAt":34},"01M6RAPKGMDSNA3SGHXHCXTC3F","https:\u002F\u002Fgithub.com\u002Fshounakmulay\u002Fdev-pulse\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fplan-change\u002FSKILL.md",[],[20,19,21,28,29,30,31,32,33,26,25,24,23,22,27],{"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":111,"publishedAt":34},"01M6RAPCNYVAT630PS59NZ5DET","navigation-3","Use when changing DevPulse Navigation3 routes, tab stacks, adaptive list\u002Fdetail metadata or back behavior.","https:\u002F\u002Fgithub.com\u002Fshounakmulay\u002Fdev-pulse\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fnavigation-3\u002FSKILL.md",[],[112,113,114,33,115,116,28,117,118,119],"navigation 3","navigation","back","adaptive","detail","behavior","list","metadata",{"skillNo":121,"name":122,"nameZh":6,"description":123,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":124,"categories":125,"keywords":126,"publishedAt":34},"01M6RAP8GK2PND12M3PEE8GB1Q","ktlint-fix","Use when explicitly asked to run the legacy ktlint workflow; first check whether formatting tasks actually exist.","https:\u002F\u002Fgithub.com\u002Fshounakmulay\u002Fdev-pulse\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fktlint-fix\u002FSKILL.md",[],[127,27,128,129,130,131,132,28,33,133,134],"ktlint fix","check","first","run","tasks","workflow","formatting","Legacy",{"skillNo":136,"name":137,"nameZh":6,"description":138,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":139,"categories":140,"keywords":141,"publishedAt":34},"01M6RAP50MQZHW4ZBA344H5TTV","implement-change","Use when implementing or refactoring existing DevPulse behavior across screens, state, use cases, repositories or shared utilities after establishing acceptance checks.","https:\u002F\u002Fgithub.com\u002Fshounakmulay\u002Fdev-pulse\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fimplement-change\u002FSKILL.md",[],[19,142,143,144,33,145,146,147,148,149,28,117,150,23,92],"implement change","implement","implementing","shared utilities","Existing","Utilities","shared","across","refactoring"]