[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6NQVR660KY2B0MAT5YSYEMD":3,"skill-same:01M6NQVR660KY2B0MAT5YSYEMD":76},{"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":37,"linkOnly":38,"markdownContent":39,"markdownBody":40,"frontMatter":41,"refName":50,"commitSha":51,"skillDirectory":52,"forksCount":14,"repositoryHtmlUrl":53,"repositoryHomepageUrl":54,"ownerHtmlUrl":55,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":56,"install":57,"resources":70},"01M6NQVR660KY2B0MAT5YSYEMD","estimation-planning",null,"Software estimation and planning — story points, velocity, scope negotiation, technical debt budgeting, and statistical forecasting. Use when estimating effort, planning a sprint, negotiating scope with stakeholders, budgeting for technical debt, or forecasting completion dates.","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\u002Fsrc\u002Fcontext\u002Fskills\u002Fproduct\u002Festimation-planning\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36],"estimation planning","estimation","planning","velocity","for","with","sprint","scope","software","technical debt","Story","budgeting","use","forecasting","technical","work","negotiation","product","2026-11-10 10:12:30",false,"---\nname: estimation-planning\ndescription: |\n  Software estimation and planning — story points, velocity, scope negotiation, technical debt budgeting, and statistical forecasting. Use when estimating effort, planning a sprint, negotiating scope with stakeholders, budgeting for technical debt, or forecasting completion dates.\nmetadata:\n  processkit:\n    apiVersion: processkit.projectious.work\u002Fv2\n    id: SKILL-estimation-planning\n    version: \"1.1.0\"\n    created: 2026-04-06T00:00:00Z\n    category: product\n    layer: 3\n---\n\n# Estimation and Planning\n\n## Intro\n\nEstimation is uncertainty management, not prediction. Use relative\nsizing for stories, track velocity over many sprints, and present\nforecasts as ranges. When dates and scope conflict, negotiate one;\nnever fix both.\n\n## Overview\n\n### Story points vs time estimates\n\nStory points measure relative complexity, accounting for effort,\nuncertainty, and risk in one number. Use the Fibonacci sequence\n(1, 2, 3, 5, 8, 13) — the gaps reflect rising uncertainty at\nlarger sizes. A \"1\" is the simplest well-understood task on the\nteam; everything is relative to it. Stories of 13+ must be split\nbefore estimation.\n\nTime estimates (hours\u002Fdays) are appropriate for fixed-scope\ncontracts, individual task tracking, or teams that prefer them.\nNeither approach is universally superior. Never convert story\npoints to hours — it defeats the purpose of relative sizing.\n\n### Planning poker\n\nEach estimator independently picks a card to prevent anchoring.\nDiscuss outliers (highest and lowest explain themselves), then\nre-vote. Converge within two rounds or take the higher estimate.\nSessions: 60-90 minutes, 15-20 stories max. The person doing the\nwork does not get extra weight — estimation is a team activity.\nFor remote teams, run async estimation first, then discuss\noutliers live.\n\n### Cone of uncertainty\n\nEarly estimates are inherently inaccurate: ~4x range at project\nstart, ~1.25x at late stages. Communicate as ranges (\"3-5\nsprints\"), not single numbers. Re-estimate as uncertainty\ndecreases — after design, after a spike, after the first\niteration. Never promise a single date at project start.\n\n### Velocity tracking\n\nVelocity = story points completed per sprint, counting only fully\ndone stories. Track at least 5-6 sprints before forecasting. Use\nthe average of the last 3-5 sprints for planning, not the best\nsprint. Velocity is a planning tool, not a performance metric;\nnever compare teams. When velocity drops, investigate (scope\nchanges, interruptions, debt, team changes) — don't assume it\nwill recover.\n\n### Scope negotiation\n\nPresent scope as a menu with trade-offs (\"A+B by March, or A+B+C\nby April\"). Use MoSCoW: Must-have, Should-have, Could-have,\nWon't-have (this time). Fixed date? Negotiate scope. Fixed scope?\nNegotiate date. Never fix both. Identify the MVP — the smallest\ndelivery that provides value. Document descoped items and the\nreason, to prevent later scope creep. Revisit scope at sprint\nboundaries, not mid-sprint.\n\n### Technical debt budgeting\n\nAllocate 15-20% of each sprint to debt and maintenance. Track\ndebt items in the same backlog as features so they compete for\npriority. Categorize debt as critical (blocks future work),\nimportant (slows development), or minor (cosmetic). Pay critical\ndebt immediately; schedule important debt each sprint. Frame debt\nfor stakeholders in business terms (\"this refactor will reduce\nbug rate by ~30%\"). Never let debt accumulate silently.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Single-number estimates at project start.** The cone of uncertainty is ~4x at project start — committing to a single date this early guarantees being wrong. Always present ranges; re-estimate as unknowns resolve.\n- **Promising fixed date AND fixed scope simultaneously.** When both are fixed, the only variable left is quality, and quality always loses. When stakeholders want a fixed date, negotiate scope; when they want fixed scope, negotiate the date. Never fix both.\n- **Converting story points to hours.** Story points measure relative complexity across a team; hours measure elapsed time for an individual. Converting destroys the relative signal and creates false precision. If hours are needed, use hours-based estimation from the start.\n- **Comparing velocity across teams.** Each team calibrates its \"1-point\" differently. Cross-team velocity comparison is not meaningful and creates perverse pressure to inflate estimates.\n- **Padding estimates secretly.** Hidden contingency destroys trust when discovered and eliminates the feedback loop that improves future estimates. Surface the risk explicitly: \"This estimate includes 20% buffer for the unknown authentication integration.\"\n- **Re-estimating done work to match actuals.** Retroactively adjusting estimates to make the velocity look better destroys the historical calibration that makes forecasting useful. Leave done work at its original estimate.\n- **Treating velocity as a performance metric.** Velocity is a planning tool, not a KPI. Using it to compare or rank engineers causes gaming, inflated estimates, and team dysfunction.\n\n## Full reference\n\n### Three-point estimation (PERT)\n\nFor each task, estimate Optimistic (O), Most Likely (M), and\nPessimistic (P).\n\n- **PERT estimate:** `(O + 4*M + P) \u002F 6`\n- **Standard deviation:** `(P - O) \u002F 6`\n\nUse for project-level estimates where individual task uncertainty\ncompounds. Pessimistic should assume things go wrong, but not\ncatastrophically. Sum the PERT estimates for project total; sum\nthe variances and take the square root for project uncertainty.\n\n### Monte Carlo simulation\n\nInputs: historical velocity data (points per sprint) and total\nbacklog size. Run 1000+ simulations: randomly sample a velocity\nfor each sprint, count sprints to complete. Output: a probability\ndistribution of completion dates.\n\nReport as: \"80% chance of completing by Sprint 12, 95% chance by\nSprint 14.\" More credible than single-point estimates because it\nuses real historical variation. Re-run as the backlog or velocity\ndata changes.\n\n### Worked examples\n\n**\"Stakeholder wants all 50 stories done by end of quarter.\"**\nCompute based on the team's average velocity (last 5 sprints) and\nremaining sprints. If velocity is 25 points\u002Fsprint and the 50\nstories total 180 points, that's 7.2 sprints — but only 5\nremain. Present options: descope to 120 points of must-haves\n(fits in 5), extend by 2 sprints, or add capacity. Use MoSCoW to\nidentify what's actually must-have.\n\n**\"Our estimates are always wrong.\"** Review recent sprints for\npatterns: stories consistently under-estimated (8-pointers\nspilling across sprints), mid-sprint scope creep, missing tasks.\nRecommend: split stories to 5 points or less, include code\nreview and testing time in estimates, track estimate-vs-actual\nfor calibration, use planning poker to surface hidden complexity.\n\n**\"When will this project be done? We have 400 points in the\nbacklog.\"** Run a three-point estimate: with velocity 20-35\npoints\u002Fsprint (O=12, M=16, P=25 sprints), PERT estimate is 17\nsprints. Present as a range: \"14-20 sprints with 80% confidence.\"\nOffer Monte Carlo for a more precise forecast using actual\nvelocity history.\n\n### Anti-patterns\n\n- **Single-number estimates at project start** — always a range.\n- **Comparing velocity across teams** — different baselines, not\n  comparable.\n- **Padding estimates secretly** — surface the risk explicitly\n  instead.\n- **Re-estimating done work to match actuals** — destroys the\n  feedback loop that improves future estimates.\n- **Treating story points as currency** — they exist to compare\n  stories within a team, not to bill against.\n","# Estimation and Planning\n\n## Intro\n\nEstimation is uncertainty management, not prediction. Use relative\nsizing for stories, track velocity over many sprints, and present\nforecasts as ranges. When dates and scope conflict, negotiate one;\nnever fix both.\n\n## Overview\n\n### Story points vs time estimates\n\nStory points measure relative complexity, accounting for effort,\nuncertainty, and risk in one number. Use the Fibonacci sequence\n(1, 2, 3, 5, 8, 13) — the gaps reflect rising uncertainty at\nlarger sizes. A \"1\" is the simplest well-understood task on the\nteam; everything is relative to it. Stories of 13+ must be split\nbefore estimation.\n\nTime estimates (hours\u002Fdays) are appropriate for fixed-scope\ncontracts, individual task tracking, or teams that prefer them.\nNeither approach is universally superior. Never convert story\npoints to hours — it defeats the purpose of relative sizing.\n\n### Planning poker\n\nEach estimator independently picks a card to prevent anchoring.\nDiscuss outliers (highest and lowest explain themselves), then\nre-vote. Converge within two rounds or take the higher estimate.\nSessions: 60-90 minutes, 15-20 stories max. The person doing the\nwork does not get extra weight — estimation is a team activity.\nFor remote teams, run async estimation first, then discuss\noutliers live.\n\n### Cone of uncertainty\n\nEarly estimates are inherently inaccurate: ~4x range at project\nstart, ~1.25x at late stages. Communicate as ranges (\"3-5\nsprints\"), not single numbers. Re-estimate as uncertainty\ndecreases — after design, after a spike, after the first\niteration. Never promise a single date at project start.\n\n### Velocity tracking\n\nVelocity = story points completed per sprint, counting only fully\ndone stories. Track at least 5-6 sprints before forecasting. Use\nthe average of the last 3-5 sprints for planning, not the best\nsprint. Velocity is a planning tool, not a performance metric;\nnever compare teams. When velocity drops, investigate (scope\nchanges, interruptions, debt, team changes) — don't assume it\nwill recover.\n\n### Scope negotiation\n\nPresent scope as a menu with trade-offs (\"A+B by March, or A+B+C\nby April\"). Use MoSCoW: Must-have, Should-have, Could-have,\nWon't-have (this time). Fixed date? Negotiate scope. Fixed scope?\nNegotiate date. Never fix both. Identify the MVP — the smallest\ndelivery that provides value. Document descoped items and the\nreason, to prevent later scope creep. Revisit scope at sprint\nboundaries, not mid-sprint.\n\n### Technical debt budgeting\n\nAllocate 15-20% of each sprint to debt and maintenance. Track\ndebt items in the same backlog as features so they compete for\npriority. Categorize debt as critical (blocks future work),\nimportant (slows development), or minor (cosmetic). Pay critical\ndebt immediately; schedule important debt each sprint. Frame debt\nfor stakeholders in business terms (\"this refactor will reduce\nbug rate by ~30%\"). Never let debt accumulate silently.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Single-number estimates at project start.** The cone of uncertainty is ~4x at project start — committing to a single date this early guarantees being wrong. Always present ranges; re-estimate as unknowns resolve.\n- **Promising fixed date AND fixed scope simultaneously.** When both are fixed, the only variable left is quality, and quality always loses. When stakeholders want a fixed date, negotiate scope; when they want fixed scope, negotiate the date. Never fix both.\n- **Converting story points to hours.** Story points measure relative complexity across a team; hours measure elapsed time for an individual. Converting destroys the relative signal and creates false precision. If hours are needed, use hours-based estimation from the start.\n- **Comparing velocity across teams.** Each team calibrates its \"1-point\" differently. Cross-team velocity comparison is not meaningful and creates perverse pressure to inflate estimates.\n- **Padding estimates secretly.** Hidden contingency destroys trust when discovered and eliminates the feedback loop that improves future estimates. Surface the risk explicitly: \"This estimate includes 20% buffer for the unknown authentication integration.\"\n- **Re-estimating done work to match actuals.** Retroactively adjusting estimates to make the velocity look better destroys the historical calibration that makes forecasting useful. Leave done work at its original estimate.\n- **Treating velocity as a performance metric.** Velocity is a planning tool, not a KPI. Using it to compare or rank engineers causes gaming, inflated estimates, and team dysfunction.\n\n## Full reference\n\n### Three-point estimation (PERT)\n\nFor each task, estimate Optimistic (O), Most Likely (M), and\nPessimistic (P).\n\n- **PERT estimate:** `(O + 4*M + P) \u002F 6`\n- **Standard deviation:** `(P - O) \u002F 6`\n\nUse for project-level estimates where individual task uncertainty\ncompounds. Pessimistic should assume things go wrong, but not\ncatastrophically. Sum the PERT estimates for project total; sum\nthe variances and take the square root for project uncertainty.\n\n### Monte Carlo simulation\n\nInputs: historical velocity data (points per sprint) and total\nbacklog size. Run 1000+ simulations: randomly sample a velocity\nfor each sprint, count sprints to complete. Output: a probability\ndistribution of completion dates.\n\nReport as: \"80% chance of completing by Sprint 12, 95% chance by\nSprint 14.\" More credible than single-point estimates because it\nuses real historical variation. Re-run as the backlog or velocity\ndata changes.\n\n### Worked examples\n\n**\"Stakeholder wants all 50 stories done by end of quarter.\"**\nCompute based on the team's average velocity (last 5 sprints) and\nremaining sprints. If velocity is 25 points\u002Fsprint and the 50\nstories total 180 points, that's 7.2 sprints — but only 5\nremain. Present options: descope to 120 points of must-haves\n(fits in 5), extend by 2 sprints, or add capacity. Use MoSCoW to\nidentify what's actually must-have.\n\n**\"Our estimates are always wrong.\"** Review recent sprints for\npatterns: stories consistently under-estimated (8-pointers\nspilling across sprints), mid-sprint scope creep, missing tasks.\nRecommend: split stories to 5 points or less, include code\nreview and testing time in estimates, track estimate-vs-actual\nfor calibration, use planning poker to surface hidden complexity.\n\n**\"When will this project be done? We have 400 points in the\nbacklog.\"** Run a three-point estimate: with velocity 20-35\npoints\u002Fsprint (O=12, M=16, P=25 sprints), PERT estimate is 17\nsprints. Present as a range: \"14-20 sprints with 80% confidence.\"\nOffer Monte Carlo for a more precise forecast using actual\nvelocity history.\n\n### Anti-patterns\n\n- **Single-number estimates at project start** — always a range.\n- **Comparing velocity across teams** — different baselines, not\n  comparable.\n- **Padding estimates secretly** — surface the risk explicitly\n  instead.\n- **Re-estimating done work to match actuals** — destroys the\n  feedback loop that improves future estimates.\n- **Treating story points as currency** — they exist to compare\n  stories within a team, not to bill against.\n",{"name":5,"metadata":42,"description":49},{"processkit":43},{"id":44,"layer":45,"created":46,"version":47,"category":36,"apiVersion":48},"SKILL-estimation-planning",3,1775433600000,"1.1.0","processkit.projectious.work\u002Fv2","Software estimation and planning — story points, velocity, scope negotiation, technical debt budgeting, and statistical forecasting. Use when estimating effort, planning a sprint, negotiating scope with stakeholders, budgeting for technical debt, or forecasting completion dates.\n","main","7231f100e266e30d2c1699ecde5c00602471dc3c","src\u002Fcontext\u002Fskills\u002Fproduct\u002Festimation-planning","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit","https:\u002F\u002Fprojectious-work.github.io\u002Fprocesskit\u002F","https:\u002F\u002Fgithub.com\u002Fprojectious-work","2026-11-09 00:53:29",{"source":8,"skillName":5,"commands":58,"prompt":68,"zipAvailable":69},[59,62,65],{"tool":60,"command":61},"npx","npx skills add projectious-work\u002Fprocesskit --skill estimation-planning",{"tool":63,"command":64},"bunx","bunx skills add projectious-work\u002Fprocesskit --skill estimation-planning",{"tool":66,"command":67},"pnpm","pnpm dlx skills add projectious-work\u002Fprocesskit --skill estimation-planning","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fproduct\u002Festimation-planning\u002FSKILL.md",true,[71],{"path":72,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":14,"sourceHtmlUrl":75},"scripts\u002F.gitkeep","SCRIPT","脚本","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fproduct\u002Festimation-planning\u002Fscripts\u002F.gitkeep",[77,104,124,145,162,180],{"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":37},"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",[83],{"categoryNo":84,"categoryName":85,"taxonomyType":86,"taxonomyTypeDesc":87},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[89,90,91,92,93,94,34,95,96,97,79,98,99,100,101,102,103],"management","skill management","create","update","package","alpha","list","manage","ontology","get","as","manifests","v1","skill package","transition",{"skillNo":105,"name":106,"nameZh":6,"description":107,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":108,"categories":109,"keywords":111,"publishedAt":37},"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",[110],{"categoryNo":84,"categoryName":85,"taxonomyType":86,"taxonomyTypeDesc":87},[89,112,113,114,115,116,94,34,117,118,96,119,120,121,98,122,123],"schema","schema management","MCP","workflows","validation","generated","rebuild","contracts","wed","deterministic","contract","mode",{"skillNo":125,"name":126,"nameZh":6,"description":127,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":128,"categories":129,"keywords":130,"publishedAt":37},"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",[],[89,131,132,91,92,133,94,34,134,135,136,137,98,138,139,140,141,142,143,144],"proposition","proposition management","index","log","world","record","query","creation","event","interface","updates","facts","claims","WSJF",{"skillNo":146,"name":147,"nameZh":6,"description":148,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":149,"categories":150,"keywords":151,"publishedAt":37},"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",[],[89,97,152,91,94,153,154,117,155,134,96,156,157,98,158,159,139,160,101,161],"ontology management","lifecycle","archive","roadmap","do","domain","iteration","keep","measurement","generic",{"skillNo":163,"name":164,"nameZh":6,"description":165,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":166,"categories":167,"keywords":168,"publishedAt":37},"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",[],[169,170,171,172,94,173,174,175,34,176,177,178,179],"okf","compatibility","okf compatibility","validate","open","knowledge","format","export","bundles","bundle","import",{"skillNo":181,"name":182,"nameZh":6,"description":183,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":184,"categories":185,"keywords":186,"publishedAt":37},"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",[],[89,187,188,91,92,133,94,153,34,95,134,189,96,136,98,159,139,140,190,103],"capability","capability management","queries","changes"]