[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6X0HND2T3DCKDMS1SWTC5XR":3,"skill-same:01M6X0HND2T3DCKDMS1SWTC5XR":68},{"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":47,"commitSha":48,"skillDirectory":49,"forksCount":14,"repositoryHtmlUrl":50,"repositoryHomepageUrl":51,"ownerHtmlUrl":52,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":53,"install":54,"resources":67},"01M6X0HND2T3DCKDMS1SWTC5XR","retrospective",null,"Facilitates team or project retrospectives — what worked, what didn't, action items. Use at the end of a sprint, milestone, or project phase to reflect on what went well, what didn't, and what to try next.","projectious-work\u002Fprocesskit","projectious-work","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F263889726?v=4","01M6N97TJJ118WQ35CHRV8RD0E","projectious.work","01M6N97TPWJPF0BMKYQ4PBY5W8",0,"MIT","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.18.2\u002Fcontext\u002Fskills\u002Fproduct\u002Fretrospective\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33],"reflect","product","team","work","use","milestone","next","project","end","sprint","action","at","v1","what worked","phase","2026-11-10 10:12:30",false,"---\nname: retrospective\ndescription: |\n  Facilitates team or project retrospectives — what worked, what didn't, action items. Use at the end of a sprint, milestone, or project phase to reflect on what went well, what didn't, and what to try next.\nmetadata:\n  processkit:\n    apiVersion: processkit.projectious.work\u002Fv1\n    id: SKILL-retrospective\n    version: \"1.1.0\"\n    created: 2026-04-06T00:00:00Z\n    category: product\n    layer: 3\n---\n\n# Retrospective\n\n## Intro\n\nA retrospective is a short, structured reflection on a completed\nphase of work. Capture what worked, what didn't, and a small set\nof concrete experiments to try next — then act on them.\n\n## Overview\n\n### Set the scope\n\nBe explicit about the period under review: a sprint, a milestone,\na release, a project phase. A vague scope produces vague feedback;\na tight scope produces actionable items.\n\n### Gather input in three categories\n\n- **What worked well** — practices, tools, decisions that helped.\n- **What didn't work** — pain points, blockers, things that slowed\n  the team down.\n- **What to try next** — concrete experiments or changes for the\n  next iteration.\n\n### Format as a structured document\n\n```markdown\n## Retrospective — [date\u002Fmilestone]\n\n### What Worked\n- Item 1\n- Item 2\n\n### What Didn't Work\n- Item 1\n- Item 2\n\n### Action Items\n- [ ] Specific, assignable action 1\n- [ ] Specific, assignable action 2\n```\n\n### Action items must be specific, owned, and time-bound\n\nNot \"improve testing\" but \"add integration tests for the auth\nmodule by end of next sprint, owner @alice.\" If you cannot name\nthe owner and the date, the item will not happen.\n\n### Store it where the team will find it\n\nSave the retro in `context\u002F` or the project's designated location.\nLink to it from the next sprint's kickoff so the action items\nactually feed into planning.\n\n### Example\n\nUser says \"let's do a retro on the v0.3 release\". The agent asks\nwhat went well and what was painful, structures the findings into\nthe retro format with concrete action items, and saves it to\n`context\u002Fretros\u002Fv0.3.md`.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Action items with no owner or due date.** An action item that says \"improve testing\" with no owner and no date will not happen. Every action must name who is responsible and when it is due — otherwise it is a wish, not a commitment.\n- **Discussing the same blockers retro after retro.** If the same pain point appears in three consecutive retrospectives with no change, the problem is not the retro — it is that action items are not being followed through. Audit completion before the next retro starts.\n- **Letting the loudest voices dominate.** Verbal-first retros favor extroverts and senior voices. Use silent individual input gathering (sticky notes, async docs) before opening group discussion to surface the full range of experience.\n- **Skipping the retro because \"we are too busy\".** Busyness is the symptom that makes the retro most valuable. A team that never reflects never improves its throughput. Protect the retro time even at the cost of other meetings.\n- **Treating the retro as a complaint session.** The \"what didn't work\" section creates energy only if it leads to \"what to try next.\" If the output is a list of grievances with no action items, the retro has failed.\n- **Storing retros where nobody looks at them again.** A retrospective document in a folder no one revisits produces no learning. Link to the retro from the next sprint's kickoff so action items feed into planning.\n- **Vague scope for the retrospective.** \"Let's reflect on the project\" produces generic feedback. \"Let's reflect on the v0.5 release, specifically the last two weeks\" produces specific, actionable items.\n\n## Full reference\n\n### Facilitation patterns\n\nCommon formats besides the three-column default:\n\n- **Start \u002F Stop \u002F Continue** — what should we start doing, stop\n  doing, continue doing.\n- **Mad \u002F Sad \u002F Glad** — emotion-led, useful when team morale is\n  the topic.\n- **4 Ls** — Liked \u002F Learned \u002F Lacked \u002F Longed for.\n- **Sailboat** — wind (helpers), anchors (blockers), rocks\n  (risks), island (goal).\n\nPick a format that matches the question you actually want to\nanswer. Rotate formats so retros do not become routine.\n\n### Anti-patterns\n\n- Action items with no owner or due date\n- Discussing the same blockers retro after retro with no change\n- Treating the retro as a complaint session with no follow-through\n- Letting the loudest voices dominate; use silent input gathering\n  (sticky notes, async docs) before discussion\n- Skipping the retro \"because we are too busy\" — that is usually\n  exactly when you need it\n- Storing retros where nobody looks at them again\n","# Retrospective\n\n## Intro\n\nA retrospective is a short, structured reflection on a completed\nphase of work. Capture what worked, what didn't, and a small set\nof concrete experiments to try next — then act on them.\n\n## Overview\n\n### Set the scope\n\nBe explicit about the period under review: a sprint, a milestone,\na release, a project phase. A vague scope produces vague feedback;\na tight scope produces actionable items.\n\n### Gather input in three categories\n\n- **What worked well** — practices, tools, decisions that helped.\n- **What didn't work** — pain points, blockers, things that slowed\n  the team down.\n- **What to try next** — concrete experiments or changes for the\n  next iteration.\n\n### Format as a structured document\n\n```markdown\n## Retrospective — [date\u002Fmilestone]\n\n### What Worked\n- Item 1\n- Item 2\n\n### What Didn't Work\n- Item 1\n- Item 2\n\n### Action Items\n- [ ] Specific, assignable action 1\n- [ ] Specific, assignable action 2\n```\n\n### Action items must be specific, owned, and time-bound\n\nNot \"improve testing\" but \"add integration tests for the auth\nmodule by end of next sprint, owner @alice.\" If you cannot name\nthe owner and the date, the item will not happen.\n\n### Store it where the team will find it\n\nSave the retro in `context\u002F` or the project's designated location.\nLink to it from the next sprint's kickoff so the action items\nactually feed into planning.\n\n### Example\n\nUser says \"let's do a retro on the v0.3 release\". The agent asks\nwhat went well and what was painful, structures the findings into\nthe retro format with concrete action items, and saves it to\n`context\u002Fretros\u002Fv0.3.md`.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Action items with no owner or due date.** An action item that says \"improve testing\" with no owner and no date will not happen. Every action must name who is responsible and when it is due — otherwise it is a wish, not a commitment.\n- **Discussing the same blockers retro after retro.** If the same pain point appears in three consecutive retrospectives with no change, the problem is not the retro — it is that action items are not being followed through. Audit completion before the next retro starts.\n- **Letting the loudest voices dominate.** Verbal-first retros favor extroverts and senior voices. Use silent individual input gathering (sticky notes, async docs) before opening group discussion to surface the full range of experience.\n- **Skipping the retro because \"we are too busy\".** Busyness is the symptom that makes the retro most valuable. A team that never reflects never improves its throughput. Protect the retro time even at the cost of other meetings.\n- **Treating the retro as a complaint session.** The \"what didn't work\" section creates energy only if it leads to \"what to try next.\" If the output is a list of grievances with no action items, the retro has failed.\n- **Storing retros where nobody looks at them again.** A retrospective document in a folder no one revisits produces no learning. Link to the retro from the next sprint's kickoff so action items feed into planning.\n- **Vague scope for the retrospective.** \"Let's reflect on the project\" produces generic feedback. \"Let's reflect on the v0.5 release, specifically the last two weeks\" produces specific, actionable items.\n\n## Full reference\n\n### Facilitation patterns\n\nCommon formats besides the three-column default:\n\n- **Start \u002F Stop \u002F Continue** — what should we start doing, stop\n  doing, continue doing.\n- **Mad \u002F Sad \u002F Glad** — emotion-led, useful when team morale is\n  the topic.\n- **4 Ls** — Liked \u002F Learned \u002F Lacked \u002F Longed for.\n- **Sailboat** — wind (helpers), anchors (blockers), rocks\n  (risks), island (goal).\n\nPick a format that matches the question you actually want to\nanswer. Rotate formats so retros do not become routine.\n\n### Anti-patterns\n\n- Action items with no owner or due date\n- Discussing the same blockers retro after retro with no change\n- Treating the retro as a complaint session with no follow-through\n- Letting the loudest voices dominate; use silent input gathering\n  (sticky notes, async docs) before discussion\n- Skipping the retro \"because we are too busy\" — that is usually\n  exactly when you need it\n- Storing retros where nobody looks at them again\n",{"name":5,"metadata":39,"description":46},{"processkit":40},{"id":41,"layer":42,"created":43,"version":44,"category":20,"apiVersion":45},"SKILL-retrospective",3,1775433600000,"1.1.0","processkit.projectious.work\u002Fv1","Facilitates team or project retrospectives — what worked, what didn't, action items. Use at the end of a sprint, milestone, or project phase to reflect on what went well, what didn't, and what to try next.\n","main","4876a92620ee792aac2ac9a1a806322d8a572367","archive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.18.2\u002Fcontext\u002Fskills\u002Fproduct\u002Fretrospective","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit","https:\u002F\u002Fprojectious-work.github.io\u002Fprocesskit\u002F","https:\u002F\u002Fgithub.com\u002Fprojectious-work","2026-11-11 23:24:18",{"source":8,"skillName":5,"commands":55,"prompt":65,"zipAvailable":66},[56,59,62],{"tool":57,"command":58},"npx","npx skills add projectious-work\u002Fprocesskit --skill retrospective",{"tool":60,"command":61},"bunx","bunx skills add projectious-work\u002Fprocesskit --skill retrospective",{"tool":63,"command":64},"pnpm","pnpm dlx skills add projectious-work\u002Fprocesskit --skill retrospective","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.18.2\u002Fcontext\u002Fskills\u002Fproduct\u002Fretrospective\u002FSKILL.md",true,[],[69,95,115,136,153,171],{"skillNo":70,"name":71,"nameZh":6,"description":72,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":73,"categories":74,"keywords":80,"publishedAt":34},"01M6X5MTC89B4ZGXW3JVSQCPF8","skill-management","Manage Skill package manifests as v1 ontology entities.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fskill-management\u002FSKILL.md",[75],{"categoryNo":76,"categoryName":77,"taxonomyType":78,"taxonomyTypeDesc":79},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[81,82,83,84,85,86,22,87,88,89,71,90,91,92,31,93,94],"management","skill management","create","update","package","alpha","list","manage","ontology","get","as","manifests","skill package","transition",{"skillNo":96,"name":97,"nameZh":6,"description":98,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":99,"categories":100,"keywords":102,"publishedAt":34},"01M6X5MCV74NHW5MEDNHZRF2C8","schema-management","Manage generated processkit schema contracts through deterministic MCP rebuild and inspection workflows.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fschema-management\u002FSKILL.md",[101],{"categoryNo":76,"categoryName":77,"taxonomyType":78,"taxonomyTypeDesc":79},[81,103,104,105,106,107,86,22,108,109,88,110,111,112,90,113,114],"schema","schema management","MCP","workflows","validation","generated","rebuild","contracts","wed","deterministic","contract","mode",{"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":34},"01M6X5M5G6YJ96AMZGSCZJ1D13","proposition-management","Record claims, risks, beliefs, world facts, WSJF estimates, and assumptions through the Proposition interface.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fproposition-management\u002FSKILL.md",[],[81,122,123,83,84,124,86,22,125,126,127,128,90,129,130,131,132,133,134,135],"proposition","proposition management","index","log","world","record","query","creation","event","interface","updates","facts","claims","WSJF",{"skillNo":137,"name":138,"nameZh":6,"description":139,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":140,"categories":141,"keywords":142,"publishedAt":34},"01M6X5KMQ83QN9M6MPWZM7344F","ontology-management","Manage generated v1 ontology entities that do not require a dedicated domain server.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fontology-management\u002FSKILL.md",[],[81,89,143,83,86,144,145,108,146,125,88,147,148,90,149,150,130,151,31,152],"ontology management","lifecycle","archive","roadmap","do","domain","iteration","keep","measurement","generic",{"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":159,"publishedAt":34},"01M6X5KCY2DN3SM21RERSFNEBT","okf-compatibility","Import, export, and validate conformant Open Knowledge Format bundles.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fokf-compatibility\u002FSKILL.md",[],[160,161,162,163,86,164,165,166,22,167,168,169,170],"okf","compatibility","okf compatibility","validate","open","knowledge","format","export","bundles","bundle","import",{"skillNo":172,"name":173,"nameZh":6,"description":174,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":175,"categories":176,"keywords":177,"publishedAt":34},"01M6X5JA8S5PNGJVFW4EQY8T83","capability-management","Manage versioned Capability entities and their governed lifecycle.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fcapability-management\u002FSKILL.md",[],[81,178,179,83,84,124,86,144,22,87,125,180,88,127,90,150,130,131,181,94],"capability","capability management","queries","changes"]