[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6X3K2E2DP8YVED9W7XTWXCX":3,"skill-same:01M6X3K2E2DP8YVED9W7XTWXCX":83},{"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":28,"publishedAt":49,"linkOnly":50,"markdownContent":51,"markdownBody":52,"frontMatter":53,"refName":62,"commitSha":63,"skillDirectory":64,"forksCount":14,"repositoryHtmlUrl":65,"repositoryHomepageUrl":66,"ownerHtmlUrl":67,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":68,"install":69,"resources":82},"01M6X3K2E2DP8YVED9W7XTWXCX","user-research",null,"Structures user research — planning sessions, synthesizing findings, and translating insights into product decisions. Use when planning user interviews, analyzing research data, creating personas or journey maps, or turning qualitative feedback into structured recommendations.","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.23.1\u002Fcontext\u002Fskills\u002Fproduct\u002Fuser-research\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000021","资料检索与研究","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000031","产品经理","PROFESSION","适用职业",[29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48],"user research","user","research","maps","when","v1","interviews","insights","user interviews","recommendations","journey","personas","use","decisions","work","feedback","analyzing","product","planning","sessions","2026-11-10 10:12:30",false,"---\nname: user-research\ndescription: |\n  Structures user research — planning sessions, synthesizing findings, and translating insights into product decisions. Use when planning user interviews, analyzing research data, creating personas or journey maps, or turning qualitative feedback into structured recommendations.\nmetadata:\n  processkit:\n    apiVersion: processkit.projectious.work\u002Fv1\n    id: SKILL-user-research\n    version: \"1.0.0\"\n    created: 2026-04-08T00:00:00Z\n    category: product\n    layer: 2\n---\n\n# User Research\n\n## Intro\n\nUser research is the practice of studying the people who use (or\nmight use) a product, to reduce the risk of building the wrong\nthing. Good research produces specific, evidence-backed findings —\nnot vague sentiments. The output of research is always a decision:\nwhat to build, what to change, or what to stop doing.\n\n## Overview\n\n### Research methods at a glance\n\n| Method | Good for | Sample size | Time |\n|---|---|---|---|\n| **User interviews** | Motivations, mental models, pain points | 5-8 per segment | 45-60 min each |\n| **Usability testing** | Identifying friction in an existing flow | 5 per flow | 30-45 min each |\n| **Survey** | Measuring prevalence, validating hypotheses | 100-500+ | Async |\n| **Diary study** | Longitudinal behavior, context of use | 10-20 | 1-4 weeks |\n| **Card sorting** | Information architecture | 20-30 | 20-30 min each |\n| **Analytics review** | Where users go, drop off, and struggle | N\u002FA — existing data | 1-4 hours |\n\nFor most product questions, **5 user interviews** reveals the\nmajority of usability issues (Nielsen's law). Add interviews until\nyou stop hearing new themes.\n\n### Planning a research session\n\n**Research brief** (write before starting):\n\n```markdown\n# Research Brief — [Topic]\n\n**Research question:** [The one question this research will answer]\n**Why now:** [What decision this informs, and when it's needed]\n**Method:** [Interview \u002F usability test \u002F survey \u002F etc.]\n**Participants:** [Segment, recruitment criteria, number]\n**Timeline:** [Sessions by date, synthesis by date, findings by date]\n**Constraints:** [Budget, access, confidentiality]\n```\n\n**Discussion guide for user interviews:**\n```markdown\n# Interview Guide — [Topic]\n\n## Warm-up (5 min)\n- Tell me a bit about your role and how you use [product\u002Fdomain].\n\n## Context exploration (15 min)\n- Walk me through the last time you [target activity].\n- What were you trying to accomplish?\n- What made it hard? What worked well?\n\n## Specific probes (15 min)\n- [Probe about specific hypothesis or area of interest]\n- Can you show me how you do that today?\n\n## Closing (5 min)\n- Is there anything about [topic] I didn't ask that you think is important?\n- Who else do you know who deals with this problem?\n```\n\nUse open questions, not leading questions. \"Walk me through\" and\n\"Tell me about\" over \"Would you say that...\" or \"Did you feel...\".\n\n### Synthesis: turning data into insights\n\nAfter sessions, work through these steps:\n\n**1. Raw notes → observations**\nFor each session, write observations in the format:\n`[Participant] [did\u002Fsaid\u002Ffelt] [specific thing] when [context].`\nObservations are factual, not interpreted.\n\n**2. Affinity mapping**\nGroup observations that express the same underlying experience.\nEach cluster becomes a theme.\n\n**3. Themes → insights**\nAn insight is a non-obvious conclusion drawn from multiple\nobservations. Format:\n`[User type] [wants\u002Fneeds\u002Fstruggles with] [specific thing] because [underlying reason].`\n\n**4. Insights → implications**\nWhat should change as a result of each insight?\n`Implication: [what the team should do \u002F stop doing \u002F investigate further]`\n\n### Deliverables\n\n**Research findings report** (after synthesis):\n```markdown\n# Research Findings — [Topic] — [Date]\n\n## What we learned (3-5 key insights)\n\n### Insight 1: [Title — a claim, not a topic]\n**Evidence:** [Quotes or observations supporting this]\n**Implication:** [What this means for the product]\n\n### Insight 2: [Title]\n...\n\n## What we still don't know\n- [Open question that emerged]\n- [Area needing further research]\n\n## Recommendations\n1. [Specific, actionable recommendation with priority]\n\n## Methodology\n- [N] participants, [segment description]\n- Sessions conducted [date range]\n- [Method: interview \u002F usability test \u002F etc.]\n```\n\n**Persona (when needed):**\nA persona is a composite of research findings — not a made-up character.\nOnly create a persona when you have enough research to make it\nevidence-backed. A persona without research behind it is fiction.\n\n```markdown\n# [Persona Name] — [Role]\n\n**Represents:** [User segment from research]\n\n**Goals:** [What they're trying to accomplish — from research]\n**Pain points:** [What frustrates them — from research]\n**Behaviors:** [How they actually work — from research]\n**Context:** [Environment, tools, constraints — from research]\n\n**Representative quote:** \"[Verbatim or synthesized quote that captures their view]\"\n```\n\n**Journey map:**\nA journey map shows a user's experience over time — not idealized,\nbut as it actually happens. Columns: stage, user action, thought,\nfeeling, pain point, opportunity.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Asking leading questions during interviews.** \"Was the checkout process confusing?\" primes the participant to say yes. \"Walk me through what happened when you tried to check out\" surfaces what they actually experienced. Review the discussion guide for leading questions before every session.\n- **Synthesizing too quickly into solutions.** Moving from \"users are frustrated with the checkout\" directly to \"we should simplify the checkout flow\" skips the why. Stay in the problem space longer — understand what specifically frustrates them, and what underlying need is unmet — before implying a solution.\n- **Creating personas from assumptions instead of research.** A persona built on what the team thinks users are like is not a research artifact — it's fiction with a name attached. Only create personas after conducting interviews; each attribute must trace back to a specific observation or pattern of observations.\n- **Reporting what participants said without interpreting what it means.** A findings report that is a collection of quotes is not analysis. Each insight must explain WHY the observation matters and WHAT it implies — a finding without an implication is incomplete.\n- **Recruiting participants who are too easy to reach.** Recruiting from your own network, your company's Slack, or existing power users skews the sample toward people who are already engaged. Recruit for the segment whose behavior you need to understand, which often means reaching people who don't already know you.\n- **Confusing usability findings with feature requests.** When a participant says \"I wish it had a bulk export,\" that's a feature request, not a finding. The underlying finding is \"participants are spending significant time exporting records one at a time.\" Research the behavior and the pain; let the team design the solution.\n- **Not closing the loop with the team.** Research that produces a report no one reads has no impact. Present findings in a session where the team can ask questions, share the report where decisions are made, and explicitly link each implication to a backlog item or decision record.\n\n## Full reference\n\n### Recruitment screener template\n\n```markdown\nWe're looking for [N] participants for a [30\u002F60]-minute [paid\u002Funpaid] research session.\n\nYou qualify if you:\n- [ ] [Criterion 1 — role, behavior, or experience]\n- [ ] [Criterion 2]\n- [ ] [Criterion 3]\n\nYou do NOT qualify if you:\n- [ ] [Disqualifying criterion — e.g., work at a competitor]\n```\n\n### Consent and confidentiality\n\nBefore recording any session:\n- Explain how the recording will be used\n- Get explicit verbal or written consent\n- Offer to continue without recording if they prefer\n- Do not share clips of individual participants without their consent\n\n### Linking to processkit context\n\nSave research artifacts in `context\u002Fartifacts\u002F`:\n- `context\u002Fartifacts\u002Fresearch-brief-[topic].md`\n- `context\u002Fartifacts\u002Fresearch-findings-[topic]-[date].md`\n- `context\u002Fartifacts\u002Fpersona-[name].md`\n\nCreate Note entities for quick observations captured during sessions.\nLink findings to the WorkItems or DecisionRecords they informed.\n\n### Signal-to-noise in qualitative data\n\n| Type of data | Weight |\n|---|---|\n| Unprompted behavior (what they did) | Highest |\n| Unprompted statement (what they said without being asked) | High |\n| Response to open question | Medium |\n| Response to leading question | Low |\n| What they say they \"would\" do | Very low |\n\nWeight observations accordingly when synthesizing. A participant\nwho struggled with a task unprompted is stronger evidence than one\nwho said \"that was kind of confusing\" when asked.\n","# User Research\n\n## Intro\n\nUser research is the practice of studying the people who use (or\nmight use) a product, to reduce the risk of building the wrong\nthing. Good research produces specific, evidence-backed findings —\nnot vague sentiments. The output of research is always a decision:\nwhat to build, what to change, or what to stop doing.\n\n## Overview\n\n### Research methods at a glance\n\n| Method | Good for | Sample size | Time |\n|---|---|---|---|\n| **User interviews** | Motivations, mental models, pain points | 5-8 per segment | 45-60 min each |\n| **Usability testing** | Identifying friction in an existing flow | 5 per flow | 30-45 min each |\n| **Survey** | Measuring prevalence, validating hypotheses | 100-500+ | Async |\n| **Diary study** | Longitudinal behavior, context of use | 10-20 | 1-4 weeks |\n| **Card sorting** | Information architecture | 20-30 | 20-30 min each |\n| **Analytics review** | Where users go, drop off, and struggle | N\u002FA — existing data | 1-4 hours |\n\nFor most product questions, **5 user interviews** reveals the\nmajority of usability issues (Nielsen's law). Add interviews until\nyou stop hearing new themes.\n\n### Planning a research session\n\n**Research brief** (write before starting):\n\n```markdown\n# Research Brief — [Topic]\n\n**Research question:** [The one question this research will answer]\n**Why now:** [What decision this informs, and when it's needed]\n**Method:** [Interview \u002F usability test \u002F survey \u002F etc.]\n**Participants:** [Segment, recruitment criteria, number]\n**Timeline:** [Sessions by date, synthesis by date, findings by date]\n**Constraints:** [Budget, access, confidentiality]\n```\n\n**Discussion guide for user interviews:**\n```markdown\n# Interview Guide — [Topic]\n\n## Warm-up (5 min)\n- Tell me a bit about your role and how you use [product\u002Fdomain].\n\n## Context exploration (15 min)\n- Walk me through the last time you [target activity].\n- What were you trying to accomplish?\n- What made it hard? What worked well?\n\n## Specific probes (15 min)\n- [Probe about specific hypothesis or area of interest]\n- Can you show me how you do that today?\n\n## Closing (5 min)\n- Is there anything about [topic] I didn't ask that you think is important?\n- Who else do you know who deals with this problem?\n```\n\nUse open questions, not leading questions. \"Walk me through\" and\n\"Tell me about\" over \"Would you say that...\" or \"Did you feel...\".\n\n### Synthesis: turning data into insights\n\nAfter sessions, work through these steps:\n\n**1. Raw notes → observations**\nFor each session, write observations in the format:\n`[Participant] [did\u002Fsaid\u002Ffelt] [specific thing] when [context].`\nObservations are factual, not interpreted.\n\n**2. Affinity mapping**\nGroup observations that express the same underlying experience.\nEach cluster becomes a theme.\n\n**3. Themes → insights**\nAn insight is a non-obvious conclusion drawn from multiple\nobservations. Format:\n`[User type] [wants\u002Fneeds\u002Fstruggles with] [specific thing] because [underlying reason].`\n\n**4. Insights → implications**\nWhat should change as a result of each insight?\n`Implication: [what the team should do \u002F stop doing \u002F investigate further]`\n\n### Deliverables\n\n**Research findings report** (after synthesis):\n```markdown\n# Research Findings — [Topic] — [Date]\n\n## What we learned (3-5 key insights)\n\n### Insight 1: [Title — a claim, not a topic]\n**Evidence:** [Quotes or observations supporting this]\n**Implication:** [What this means for the product]\n\n### Insight 2: [Title]\n...\n\n## What we still don't know\n- [Open question that emerged]\n- [Area needing further research]\n\n## Recommendations\n1. [Specific, actionable recommendation with priority]\n\n## Methodology\n- [N] participants, [segment description]\n- Sessions conducted [date range]\n- [Method: interview \u002F usability test \u002F etc.]\n```\n\n**Persona (when needed):**\nA persona is a composite of research findings — not a made-up character.\nOnly create a persona when you have enough research to make it\nevidence-backed. A persona without research behind it is fiction.\n\n```markdown\n# [Persona Name] — [Role]\n\n**Represents:** [User segment from research]\n\n**Goals:** [What they're trying to accomplish — from research]\n**Pain points:** [What frustrates them — from research]\n**Behaviors:** [How they actually work — from research]\n**Context:** [Environment, tools, constraints — from research]\n\n**Representative quote:** \"[Verbatim or synthesized quote that captures their view]\"\n```\n\n**Journey map:**\nA journey map shows a user's experience over time — not idealized,\nbut as it actually happens. Columns: stage, user action, thought,\nfeeling, pain point, opportunity.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Asking leading questions during interviews.** \"Was the checkout process confusing?\" primes the participant to say yes. \"Walk me through what happened when you tried to check out\" surfaces what they actually experienced. Review the discussion guide for leading questions before every session.\n- **Synthesizing too quickly into solutions.** Moving from \"users are frustrated with the checkout\" directly to \"we should simplify the checkout flow\" skips the why. Stay in the problem space longer — understand what specifically frustrates them, and what underlying need is unmet — before implying a solution.\n- **Creating personas from assumptions instead of research.** A persona built on what the team thinks users are like is not a research artifact — it's fiction with a name attached. Only create personas after conducting interviews; each attribute must trace back to a specific observation or pattern of observations.\n- **Reporting what participants said without interpreting what it means.** A findings report that is a collection of quotes is not analysis. Each insight must explain WHY the observation matters and WHAT it implies — a finding without an implication is incomplete.\n- **Recruiting participants who are too easy to reach.** Recruiting from your own network, your company's Slack, or existing power users skews the sample toward people who are already engaged. Recruit for the segment whose behavior you need to understand, which often means reaching people who don't already know you.\n- **Confusing usability findings with feature requests.** When a participant says \"I wish it had a bulk export,\" that's a feature request, not a finding. The underlying finding is \"participants are spending significant time exporting records one at a time.\" Research the behavior and the pain; let the team design the solution.\n- **Not closing the loop with the team.** Research that produces a report no one reads has no impact. Present findings in a session where the team can ask questions, share the report where decisions are made, and explicitly link each implication to a backlog item or decision record.\n\n## Full reference\n\n### Recruitment screener template\n\n```markdown\nWe're looking for [N] participants for a [30\u002F60]-minute [paid\u002Funpaid] research session.\n\nYou qualify if you:\n- [ ] [Criterion 1 — role, behavior, or experience]\n- [ ] [Criterion 2]\n- [ ] [Criterion 3]\n\nYou do NOT qualify if you:\n- [ ] [Disqualifying criterion — e.g., work at a competitor]\n```\n\n### Consent and confidentiality\n\nBefore recording any session:\n- Explain how the recording will be used\n- Get explicit verbal or written consent\n- Offer to continue without recording if they prefer\n- Do not share clips of individual participants without their consent\n\n### Linking to processkit context\n\nSave research artifacts in `context\u002Fartifacts\u002F`:\n- `context\u002Fartifacts\u002Fresearch-brief-[topic].md`\n- `context\u002Fartifacts\u002Fresearch-findings-[topic]-[date].md`\n- `context\u002Fartifacts\u002Fpersona-[name].md`\n\nCreate Note entities for quick observations captured during sessions.\nLink findings to the WorkItems or DecisionRecords they informed.\n\n### Signal-to-noise in qualitative data\n\n| Type of data | Weight |\n|---|---|\n| Unprompted behavior (what they did) | Highest |\n| Unprompted statement (what they said without being asked) | High |\n| Response to open question | Medium |\n| Response to leading question | Low |\n| What they say they \"would\" do | Very low |\n\nWeight observations accordingly when synthesizing. A participant\nwho struggled with a task unprompted is stronger evidence than one\nwho said \"that was kind of confusing\" when asked.\n",{"name":5,"metadata":54,"description":61},{"processkit":55},{"id":56,"layer":57,"created":58,"version":59,"category":46,"apiVersion":60},"SKILL-user-research",2,1775606400000,"1.0.0","processkit.projectious.work\u002Fv1","Structures user research — planning sessions, synthesizing findings, and translating insights into product decisions. Use when planning user interviews, analyzing research data, creating personas or journey maps, or turning qualitative feedback into structured recommendations.\n","main","4876a92620ee792aac2ac9a1a806322d8a572367","archive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.23.1\u002Fcontext\u002Fskills\u002Fproduct\u002Fuser-research","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":70,"prompt":80,"zipAvailable":81},[71,74,77],{"tool":72,"command":73},"npx","npx skills add projectious-work\u002Fprocesskit --skill user-research",{"tool":75,"command":76},"bunx","bunx skills add projectious-work\u002Fprocesskit --skill user-research",{"tool":78,"command":79},"pnpm","pnpm dlx skills add projectious-work\u002Fprocesskit --skill user-research","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.23.1\u002Fcontext\u002Fskills\u002Fproduct\u002Fuser-research\u002FSKILL.md",true,[],[84,108,128,149,166,184],{"skillNo":85,"name":86,"nameZh":6,"description":87,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":88,"categories":89,"keywords":93,"publishedAt":49},"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",[90],{"categoryNo":91,"categoryName":92,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[94,95,96,97,98,99,43,100,101,102,86,103,104,105,34,106,107],"management","skill management","create","update","package","alpha","list","manage","ontology","get","as","manifests","skill package","transition",{"skillNo":109,"name":110,"nameZh":6,"description":111,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":112,"categories":113,"keywords":115,"publishedAt":49},"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",[114],{"categoryNo":91,"categoryName":92,"taxonomyType":21,"taxonomyTypeDesc":22},[94,116,117,118,119,120,99,43,121,122,101,123,124,125,103,126,127],"schema","schema management","MCP","workflows","validation","generated","rebuild","contracts","wed","deterministic","contract","mode",{"skillNo":129,"name":130,"nameZh":6,"description":131,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":132,"categories":133,"keywords":134,"publishedAt":49},"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",[],[94,135,136,96,97,137,99,43,138,139,140,141,103,142,143,144,145,146,147,148],"proposition","proposition management","index","log","world","record","query","creation","event","interface","updates","facts","claims","WSJF",{"skillNo":150,"name":151,"nameZh":6,"description":152,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":153,"categories":154,"keywords":155,"publishedAt":49},"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",[],[94,102,156,96,99,157,158,121,159,138,101,160,161,103,162,163,143,164,34,165],"ontology management","lifecycle","archive","roadmap","do","domain","iteration","keep","measurement","generic",{"skillNo":167,"name":168,"nameZh":6,"description":169,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":170,"categories":171,"keywords":172,"publishedAt":49},"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",[],[173,174,175,176,99,177,178,179,43,180,181,182,183],"okf","compatibility","okf compatibility","validate","open","knowledge","format","export","bundles","bundle","import",{"skillNo":185,"name":186,"nameZh":6,"description":187,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":188,"categories":189,"keywords":190,"publishedAt":49},"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",[],[94,191,192,96,97,137,99,157,43,100,138,193,101,140,103,163,143,144,194,107],"capability","capability management","queries","changes"]