[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6WZKPY021TPZBQHZ58VJM08":3,"skill-same:01M6WZKPY021TPZBQHZ58VJM08":72},{"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":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":51,"commitSha":52,"skillDirectory":53,"forksCount":14,"repositoryHtmlUrl":54,"repositoryHomepageUrl":55,"ownerHtmlUrl":56,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":57,"install":58,"resources":71},"01M6WZKPY021TPZBQHZ58VJM08","threat-modeling",null,"Threat modeling with STRIDE — data flow diagrams, trust boundaries, risk. Use when designing a new system, reviewing architecture for security, conducting a security review, or prioritizing security work by risk.","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.1\u002Fcontext\u002Fskills\u002Fengineering\u002Fthreat-modeling\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,5,35,36,37],"threat modeling","modeling","threat","when","review","data flow","for","v1","with","trust","diagrams","use","work","system","stride","risk","flow","security review","architecture","2026-11-10 10:12:30",false,"---\nname: threat-modeling\ndescription: |\n  Threat modeling with STRIDE — data flow diagrams, trust boundaries, risk. Use when designing a new system, reviewing architecture for security, conducting a security review, or prioritizing security work by risk.\nmetadata:\n  processkit:\n    apiVersion: processkit.projectious.work\u002Fv1\n    id: SKILL-threat-modeling\n    version: \"1.1.0\"\n    created: 2026-04-06T00:00:00Z\n    category: engineering\n---\n\n# Threat Modeling\n\n## Intro\n\nA threat model is a structured analysis of how a system could be\nattacked. STRIDE walks each component and data flow through six\nthreat categories, producing a prioritized list of risks and\nmitigations.\n\n## Overview\n\n### STRIDE categories\n\n| Category                   | Threat                        | Property violated |\n|----------------------------|-------------------------------|-------------------|\n| **S**poofing               | Pretending to be someone else | Authentication    |\n| **T**ampering              | Modifying data or code        | Integrity         |\n| **R**epudiation            | Denying an action occurred    | Non-repudiation   |\n| **I**nformation Disclosure | Exposing data                 | Confidentiality   |\n| **D**enial of Service      | Making the system unavailable | Availability      |\n| **E**levation of Privilege | Gaining unauthorized access   | Authorization     |\n\n### Step 1 — Draw a data flow diagram\n\nMap processes, data stores, data flows, and external entities. Mark\ntrust boundaries where data crosses between trust levels.\n\n```\n                    Trust Boundary\n                    +---------------------------------+\n  [User Browser] ---|---> [Web Server] ---> [App Server] ---> [Database]\n                    |         |                  |\n                    |         v                  v\n                    |    [Static Files]    [Cache (Redis)]\n                    +---------------------------------+\n                           |\n                           v\n                    [External Auth Provider]\n```\n\n- **Processes** — web server, app server, background workers.\n- **Data stores** — database, cache, file system, message queue.\n- **Data flows** — HTTP requests, database queries, API calls.\n- **External entities** — users, third-party services, admins.\n- **Trust boundaries** — network segments, process boundaries,\n  privilege levels.\n\n### Step 2 — Identify trust boundaries\n\nEach crossing is a potential attack point:\n\n- Internet to DMZ.\n- DMZ to internal network.\n- Application to database.\n- Service to service in a microservice mesh.\n- Regular user vs admin privilege levels.\n\n### Step 3 — Apply STRIDE to each element\n\nFor every process, data store, and data flow, ask:\n\n- **Spoofing** — can an attacker impersonate a legitimate entity?\n- **Tampering** — can data be modified in transit or at rest?\n- **Repudiation** — can a user deny performing an action?\n- **Information disclosure** — can sensitive data leak?\n- **Denial of service** — can this component be overwhelmed?\n- **Elevation of privilege** — can a user gain higher privileges?\n\n### Step 4 — Risk assessment\n\nRate each threat by likelihood and impact:\n\n| Rating | Likelihood                      | Impact                           |\n|--------|---------------------------------|----------------------------------|\n| High   | Exploitable with public tools   | Data breach, full compromise     |\n| Medium | Requires some skill or access   | Partial data exposure, downtime  |\n| Low    | Requires insider access or luck | Minor data exposure, degradation |\n\n**Risk = Likelihood × Impact**\n\n| Likelihood \\ Impact | High     | Medium | Low    |\n|---------------------|----------|--------|--------|\n| High                | Critical | High   | Medium |\n| Medium              | High     | Medium | Low    |\n| Low                 | Medium   | Low    | Low    |\n\n### Step 5 — Mitigations\n\nMap each STRIDE category to common mitigations:\n\n| STRIDE category        | Common mitigations                                |\n|------------------------|---------------------------------------------------|\n| Spoofing               | MFA, certificate pinning, mutual TLS              |\n| Tampering              | Digital signatures, checksums, immutable logs     |\n| Repudiation            | Audit logging, tamper-evident logs, signatures    |\n| Information Disclosure | Encryption (TLS, AES), access controls, masking   |\n| Denial of Service      | Rate limiting, autoscaling, CDN, circuit breakers |\n| Elevation of Privilege | Least privilege, input validation, sandboxing     |\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Skipping the data flow diagram and jumping straight to a threat list.** Without a data flow diagram with trust boundaries, threats are enumerated without knowing where data crosses between trust levels — the points where attackers actually operate. The DFD is not optional; it determines which threats are relevant to which components.\n- **Threat modeling once at design time and never revisiting.** A system that has grown to include new external integrations, new microservices, or new data flows has a different attack surface than it did at initial design. A threat model that is not updated when the architecture changes is a threat model of a system that no longer exists.\n- **Treating \"low likelihood\" as \"permanently ignore.\"** A threat rated low likelihood because it requires insider access or sophisticated skill is not safe to dismiss forever. Circumstances change: attackers gain new capabilities, insiders become disgruntled, and \"low likelihood\" events happen. Re-rate risks annually or when the environment changes.\n- **Mitigations with no owner or ticket.** A threat model that lists 15 mitigations in a document with no associated tasks means zero of them will be implemented. Every mitigation must be tracked to a ticket or commit with an owner. A mitigation that is only in the threat model document has not been mitigated.\n- **Modeling the intended architecture, not the production system.** The diagram shows a load balancer in front of the API, but production has a debug port open directly to the application server. The threat model of the intended architecture misses the actual attack surface. Threat model what is deployed, not what was planned.\n- **Confusing authentication threats with authorization threats.** Spoofing (STRIDE-S) is about impersonating an identity — a weak login mechanism. Elevation of privilege (STRIDE-E) is about gaining capabilities beyond what the identity is authorized for — a broken access control check. Fixing authentication does not fix authorization. Apply both categories separately to each component.\n- **Stopping at the application boundary and ignoring CI\u002FCD and cloud infrastructure.** The CI\u002FCD pipeline, container registry, cloud console, and IAM configuration are part of the attack surface — a compromised build pipeline can inject code into every deployment. Include infrastructure, supply chain, and human entry points in the attack surface mapping.\n\n## Full reference\n\n### Attack surface mapping\n\nEnumerate every entry point an attacker could use:\n\n- **Network** — open ports, exposed services, public endpoints.\n- **Application** — API endpoints, file upload, search, user input\n  fields.\n- **Authentication** — login, password reset, session management.\n- **Data** — database access, file storage, backups, logs.\n- **Infrastructure** — cloud console, CI\u002FCD pipeline, container\n  registry.\n- **Human** — phishing targets, social engineering, insider threats.\n\n### Output format\n\nStructure the threat model as a single document:\n\n```\n## Threat Model: [System Name]\n\n### System Description\nBrief description of the system and its purpose.\n\n### Data Flow Diagram\nASCII diagram showing components and trust boundaries.\n\n### Assets\nList of valuable data and resources to protect.\n\n### Threats\n| ID | STRIDE | Component | Threat | Risk | Mitigation |\n|----|--------|-----------|--------|------|------------|\n| T1 | S      | Login API | Credential stuffing | High | Rate limiting, MFA |\n| T2 | I      | Database  | SQL injection leaks PII | Critical | Parameterized queries |\n\n### Recommendations\nPrioritized list of security improvements.\n```\n\n### When to threat model\n\n- During initial design of any system handling sensitive data.\n- Before adding a new external integration or trust boundary.\n- After an incident, to find adjacent risks.\n- On a periodic schedule for high-value systems (annually or per\n  major release).\n\n### Anti-patterns\n\n- Threat modeling once at design time and never revisiting.\n- Skipping the data flow diagram and going straight to a threat list.\n- Treating \"low likelihood\" as \"ignore forever\".\n- Producing a document nobody reads. The output should drive a\n  prioritized punch list of work, not sit in a wiki.\n- Modeling abstract systems instead of the actual architecture in\n  production.\n\n### Tips for sharper models\n\n- Walk the diagram with someone who didn't build the system; gaps\n  surface fast.\n- Track every mitigation back to a ticket or commit. A mitigation\n  with no owner is a mitigation that won't happen.\n- Re-rate risks after mitigations land — residual risk is what\n  matters for prioritization.\n","# Threat Modeling\n\n## Intro\n\nA threat model is a structured analysis of how a system could be\nattacked. STRIDE walks each component and data flow through six\nthreat categories, producing a prioritized list of risks and\nmitigations.\n\n## Overview\n\n### STRIDE categories\n\n| Category                   | Threat                        | Property violated |\n|----------------------------|-------------------------------|-------------------|\n| **S**poofing               | Pretending to be someone else | Authentication    |\n| **T**ampering              | Modifying data or code        | Integrity         |\n| **R**epudiation            | Denying an action occurred    | Non-repudiation   |\n| **I**nformation Disclosure | Exposing data                 | Confidentiality   |\n| **D**enial of Service      | Making the system unavailable | Availability      |\n| **E**levation of Privilege | Gaining unauthorized access   | Authorization     |\n\n### Step 1 — Draw a data flow diagram\n\nMap processes, data stores, data flows, and external entities. Mark\ntrust boundaries where data crosses between trust levels.\n\n```\n                    Trust Boundary\n                    +---------------------------------+\n  [User Browser] ---|---> [Web Server] ---> [App Server] ---> [Database]\n                    |         |                  |\n                    |         v                  v\n                    |    [Static Files]    [Cache (Redis)]\n                    +---------------------------------+\n                           |\n                           v\n                    [External Auth Provider]\n```\n\n- **Processes** — web server, app server, background workers.\n- **Data stores** — database, cache, file system, message queue.\n- **Data flows** — HTTP requests, database queries, API calls.\n- **External entities** — users, third-party services, admins.\n- **Trust boundaries** — network segments, process boundaries,\n  privilege levels.\n\n### Step 2 — Identify trust boundaries\n\nEach crossing is a potential attack point:\n\n- Internet to DMZ.\n- DMZ to internal network.\n- Application to database.\n- Service to service in a microservice mesh.\n- Regular user vs admin privilege levels.\n\n### Step 3 — Apply STRIDE to each element\n\nFor every process, data store, and data flow, ask:\n\n- **Spoofing** — can an attacker impersonate a legitimate entity?\n- **Tampering** — can data be modified in transit or at rest?\n- **Repudiation** — can a user deny performing an action?\n- **Information disclosure** — can sensitive data leak?\n- **Denial of service** — can this component be overwhelmed?\n- **Elevation of privilege** — can a user gain higher privileges?\n\n### Step 4 — Risk assessment\n\nRate each threat by likelihood and impact:\n\n| Rating | Likelihood                      | Impact                           |\n|--------|---------------------------------|----------------------------------|\n| High   | Exploitable with public tools   | Data breach, full compromise     |\n| Medium | Requires some skill or access   | Partial data exposure, downtime  |\n| Low    | Requires insider access or luck | Minor data exposure, degradation |\n\n**Risk = Likelihood × Impact**\n\n| Likelihood \\ Impact | High     | Medium | Low    |\n|---------------------|----------|--------|--------|\n| High                | Critical | High   | Medium |\n| Medium              | High     | Medium | Low    |\n| Low                 | Medium   | Low    | Low    |\n\n### Step 5 — Mitigations\n\nMap each STRIDE category to common mitigations:\n\n| STRIDE category        | Common mitigations                                |\n|------------------------|---------------------------------------------------|\n| Spoofing               | MFA, certificate pinning, mutual TLS              |\n| Tampering              | Digital signatures, checksums, immutable logs     |\n| Repudiation            | Audit logging, tamper-evident logs, signatures    |\n| Information Disclosure | Encryption (TLS, AES), access controls, masking   |\n| Denial of Service      | Rate limiting, autoscaling, CDN, circuit breakers |\n| Elevation of Privilege | Least privilege, input validation, sandboxing     |\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Skipping the data flow diagram and jumping straight to a threat list.** Without a data flow diagram with trust boundaries, threats are enumerated without knowing where data crosses between trust levels — the points where attackers actually operate. The DFD is not optional; it determines which threats are relevant to which components.\n- **Threat modeling once at design time and never revisiting.** A system that has grown to include new external integrations, new microservices, or new data flows has a different attack surface than it did at initial design. A threat model that is not updated when the architecture changes is a threat model of a system that no longer exists.\n- **Treating \"low likelihood\" as \"permanently ignore.\"** A threat rated low likelihood because it requires insider access or sophisticated skill is not safe to dismiss forever. Circumstances change: attackers gain new capabilities, insiders become disgruntled, and \"low likelihood\" events happen. Re-rate risks annually or when the environment changes.\n- **Mitigations with no owner or ticket.** A threat model that lists 15 mitigations in a document with no associated tasks means zero of them will be implemented. Every mitigation must be tracked to a ticket or commit with an owner. A mitigation that is only in the threat model document has not been mitigated.\n- **Modeling the intended architecture, not the production system.** The diagram shows a load balancer in front of the API, but production has a debug port open directly to the application server. The threat model of the intended architecture misses the actual attack surface. Threat model what is deployed, not what was planned.\n- **Confusing authentication threats with authorization threats.** Spoofing (STRIDE-S) is about impersonating an identity — a weak login mechanism. Elevation of privilege (STRIDE-E) is about gaining capabilities beyond what the identity is authorized for — a broken access control check. Fixing authentication does not fix authorization. Apply both categories separately to each component.\n- **Stopping at the application boundary and ignoring CI\u002FCD and cloud infrastructure.** The CI\u002FCD pipeline, container registry, cloud console, and IAM configuration are part of the attack surface — a compromised build pipeline can inject code into every deployment. Include infrastructure, supply chain, and human entry points in the attack surface mapping.\n\n## Full reference\n\n### Attack surface mapping\n\nEnumerate every entry point an attacker could use:\n\n- **Network** — open ports, exposed services, public endpoints.\n- **Application** — API endpoints, file upload, search, user input\n  fields.\n- **Authentication** — login, password reset, session management.\n- **Data** — database access, file storage, backups, logs.\n- **Infrastructure** — cloud console, CI\u002FCD pipeline, container\n  registry.\n- **Human** — phishing targets, social engineering, insider threats.\n\n### Output format\n\nStructure the threat model as a single document:\n\n```\n## Threat Model: [System Name]\n\n### System Description\nBrief description of the system and its purpose.\n\n### Data Flow Diagram\nASCII diagram showing components and trust boundaries.\n\n### Assets\nList of valuable data and resources to protect.\n\n### Threats\n| ID | STRIDE | Component | Threat | Risk | Mitigation |\n|----|--------|-----------|--------|------|------------|\n| T1 | S      | Login API | Credential stuffing | High | Rate limiting, MFA |\n| T2 | I      | Database  | SQL injection leaks PII | Critical | Parameterized queries |\n\n### Recommendations\nPrioritized list of security improvements.\n```\n\n### When to threat model\n\n- During initial design of any system handling sensitive data.\n- Before adding a new external integration or trust boundary.\n- After an incident, to find adjacent risks.\n- On a periodic schedule for high-value systems (annually or per\n  major release).\n\n### Anti-patterns\n\n- Threat modeling once at design time and never revisiting.\n- Skipping the data flow diagram and going straight to a threat list.\n- Treating \"low likelihood\" as \"ignore forever\".\n- Producing a document nobody reads. The output should drive a\n  prioritized punch list of work, not sit in a wiki.\n- Modeling abstract systems instead of the actual architecture in\n  production.\n\n### Tips for sharper models\n\n- Walk the diagram with someone who didn't build the system; gaps\n  surface fast.\n- Track every mitigation back to a ticket or commit. A mitigation\n  with no owner is a mitigation that won't happen.\n- Re-rate risks after mitigations land — residual risk is what\n  matters for prioritization.\n",{"name":5,"metadata":43,"description":50},{"processkit":44},{"id":45,"created":46,"version":47,"category":48,"apiVersion":49},"SKILL-threat-modeling",1775433600000,"1.1.0","engineering","processkit.projectious.work\u002Fv1","Threat modeling with STRIDE — data flow diagrams, trust boundaries, risk. Use when designing a new system, reviewing architecture for security, conducting a security review, or prioritizing security work by risk.\n","main","4876a92620ee792aac2ac9a1a806322d8a572367","archive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.18.1\u002Fcontext\u002Fskills\u002Fengineering\u002Fthreat-modeling","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":59,"prompt":69,"zipAvailable":70},[60,63,66],{"tool":61,"command":62},"npx","npx skills add projectious-work\u002Fprocesskit --skill threat-modeling",{"tool":64,"command":65},"bunx","bunx skills add projectious-work\u002Fprocesskit --skill threat-modeling",{"tool":67,"command":68},"pnpm","pnpm dlx skills add projectious-work\u002Fprocesskit --skill threat-modeling","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.18.1\u002Fcontext\u002Fskills\u002Fengineering\u002Fthreat-modeling\u002FSKILL.md",true,[],[73,99,119,140,157,175],{"skillNo":74,"name":75,"nameZh":6,"description":76,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":77,"categories":78,"keywords":84,"publishedAt":38},"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",[79],{"categoryNo":80,"categoryName":81,"taxonomyType":82,"taxonomyTypeDesc":83},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[85,86,87,88,89,90,31,91,92,93,75,94,95,96,26,97,98],"management","skill management","create","update","package","alpha","list","manage","ontology","get","as","manifests","skill package","transition",{"skillNo":100,"name":101,"nameZh":6,"description":102,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":103,"categories":104,"keywords":106,"publishedAt":38},"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",[105],{"categoryNo":80,"categoryName":81,"taxonomyType":82,"taxonomyTypeDesc":83},[85,107,108,109,110,111,90,31,112,113,92,114,115,116,94,117,118],"schema","schema management","MCP","workflows","validation","generated","rebuild","contracts","wed","deterministic","contract","mode",{"skillNo":120,"name":121,"nameZh":6,"description":122,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":123,"categories":124,"keywords":125,"publishedAt":38},"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",[],[85,126,127,87,88,128,90,31,129,130,131,132,94,133,134,135,136,137,138,139],"proposition","proposition management","index","log","world","record","query","creation","event","interface","updates","facts","claims","WSJF",{"skillNo":141,"name":142,"nameZh":6,"description":143,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":144,"categories":145,"keywords":146,"publishedAt":38},"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",[],[85,93,147,87,90,148,149,112,150,129,92,151,152,94,153,154,134,155,26,156],"ontology management","lifecycle","archive","roadmap","do","domain","iteration","keep","measurement","generic",{"skillNo":158,"name":159,"nameZh":6,"description":160,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":161,"categories":162,"keywords":163,"publishedAt":38},"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",[],[164,165,166,167,90,168,169,170,31,171,172,173,174],"okf","compatibility","okf compatibility","validate","open","knowledge","format","export","bundles","bundle","import",{"skillNo":176,"name":177,"nameZh":6,"description":178,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":179,"categories":180,"keywords":181,"publishedAt":38},"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",[],[85,182,183,87,88,128,90,148,31,91,129,184,92,131,94,154,134,135,185,98],"capability","capability management","queries","changes"]