[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6WXKQHCWYKHBWFS0DMSJWSQ":3,"skill-same:01M6WXKQHCWYKHBWFS0DMSJWSQ":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":18,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":52,"commitSha":53,"skillDirectory":54,"forksCount":14,"repositoryHtmlUrl":55,"repositoryHomepageUrl":56,"ownerHtmlUrl":57,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":58,"install":59,"resources":72},"01M6WXKQHCWYKHBWFS0DMSJWSQ","auth-patterns",null,"Authentication and authorization patterns — OAuth2, JWT, sessions, RBAC\u002FABAC. Use when implementing login flows, securing APIs, managing tokens, designing permission systems, or reviewing auth code.","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.11.1\u002Fcontext\u002Fskills\u002Fengineering\u002Fauth-patterns\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"auth","auth patterns","patterns","when","sessions","implementing","v1","login","flows","systems","tokens","abac","permission","use","work","jwt","authorization","authentication","code","rbac","2026-11-10 10:12:30",false,"---\nname: auth-patterns\ndescription: |\n  Authentication and authorization patterns — OAuth2, JWT, sessions, RBAC\u002FABAC. Use when implementing login flows, securing APIs, managing tokens, designing permission systems, or reviewing auth code.\nmetadata:\n  processkit:\n    apiVersion: processkit.projectious.work\u002Fv1\n    id: SKILL-auth-patterns\n    version: \"1.1.0\"\n    created: 2026-04-06T00:00:00Z\n    category: engineering\n---\n\n# Authentication & Authorization Patterns\n\n## Intro\n\nAuthentication proves who a caller is; authorization decides what they\ncan do. Use industry-standard protocols (OAuth2, OIDC, JWT) and proven\npatterns (session cookies, RBAC, ABAC) rather than inventing your own.\n\n## Overview\n\n### OAuth2 flow selection\n\nPick the flow based on the client's ability to keep secrets:\n\n| Client type                | Flow                  | Token storage             |\n|----------------------------|-----------------------|---------------------------|\n| Server-side web app        | Authorization Code    | Server-side session       |\n| Single-page app (SPA)      | Auth Code + PKCE      | Memory (not localStorage) |\n| Mobile \u002F native app        | Auth Code + PKCE      | Secure device storage     |\n| Service-to-service         | Client Credentials    | Environment variable      |\n| CLI \u002F limited-input device | Device Authorization  | Display user code         |\n\nSee `references\u002Foauth-flows.md` for full flow diagrams and exchange\nparameters.\n\n### JWT essentials\n\n- Always validate signature, `exp`, `iss`, and `aud`.\n- Keep payloads small — JWTs ride on every request.\n- Never store secrets in payloads; base64 is encoding, not encryption.\n- Use short access-token expiry (5–15 min).\n- Prefer `RS256` or `ES256` for public APIs over `HS256`.\n- Rotate signing keys via a JWKS endpoint.\n\nSee `references\u002Fjwt-reference.md` for the structure, claims, and full\nvalidation checklist.\n\n### Session management\n\nFor server-rendered apps using session cookies:\n\n- Generate cryptographically random session IDs (≥128 bits).\n- Store session data server-side (Redis, database) — never inside the\n  cookie body.\n- Set `HttpOnly`, `Secure`, and `SameSite=Lax` (or `Strict`) on the\n  cookie.\n- Apply idle timeout (15–30 min) and absolute timeout (8–24 hours).\n- Regenerate the session ID after login to prevent session fixation.\n\n### RBAC vs ABAC\n\n**RBAC** assigns permissions to roles and roles to users. Simple and\nappropriate when access depends only on the user's job function.\n\n```python\nROLES = {\n    \"viewer\": [\"read:projects\", \"read:reports\"],\n    \"editor\": [\"read:projects\", \"read:reports\", \"write:projects\"],\n    \"admin\":  [\"read:projects\", \"read:reports\", \"write:projects\",\n               \"manage:users\", \"manage:settings\"],\n}\n\ndef has_permission(user, permission):\n    return any(permission in ROLES[role] for role in user.roles)\n```\n\n**ABAC** evaluates attributes of subject, resource, action, and\ncontext. Use it when access depends on ownership, department, time of\nday, or other context.\n\n```python\ndef can_access(subject, action, resource, context):\n    if action == \"edit\" and resource.owner_id == subject.id:\n        return True\n    if \"admin\" in subject.roles and resource.department == subject.department:\n        return True\n    if action == \"deploy\" and not context.is_maintenance_window:\n        return False\n    return False\n```\n\n### Token refresh\n\nAccess tokens should be short-lived. Refresh tokens trade themselves\nfor new access tokens at the auth server:\n\n```\nClient                    Auth Server                 API\n  |                           |                        |\n  |--- Request (access token) ----------------------->|\n  |\u003C-- 401 Unauthorized -------------------------------|\n  |--- Refresh token -------->|                        |\n  |\u003C-- New access + refresh --|                        |\n  |--- Retry (new access token) --------------------->|\n  |\u003C-- 200 OK ----------------------------------------|\n```\n\nRefresh tokens must be stored securely (httpOnly cookie or secure\ndevice storage), single-use (rotated on every refresh), and revocable\n(server-side denylist or family tracking).\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **JWT signature validation skipped or incomplete.** Accepting a JWT without verifying the signature, or without validating `exp` (expiry), `iss` (issuer), and `aud` (audience) claims, means any JWT — including expired, foreign, or forged ones — will be accepted. Always validate all four: signature, expiry, issuer, and audience. Explicitly specify the allowed algorithm list so an attacker cannot switch to `alg: none`.\n- **Storing access tokens in localStorage.** Tokens stored in `localStorage` are accessible to any JavaScript running on the page, including injected scripts via XSS. Keep access tokens in memory only; store refresh tokens in `httpOnly` cookies that JavaScript cannot read.\n- **Returning different error messages for \"user not found\" vs \"wrong password.\"** `\"User does not exist\"` vs `\"Incorrect password\"` allows an attacker to enumerate valid usernames by observing which error they receive. Always return the same generic message: `\"Invalid email or password.\"` regardless of which check failed.\n- **Not regenerating the session ID after login.** If a user has a session cookie before logging in (e.g., from a previous anonymous session) and the same session ID is reused after authentication, an attacker who captured the pre-login session cookie can now use it to access the authenticated session. Regenerate the session ID immediately after successful login.\n- **Using `HS256` for tokens consumed by clients you don't control.** `HS256` uses a shared symmetric key — anyone who knows the key can forge tokens. For public APIs where tokens are validated by multiple parties, use `RS256` or `ES256` (asymmetric), so clients can validate with the public key without being able to forge new tokens.\n- **No rate limiting on authentication endpoints.** A login or password-reset endpoint without rate limiting allows unlimited brute-force attempts. Apply progressive delays, lockout, or CAPTCHA after N failed attempts per IP or per account. Use a token-bucket or sliding-window rate limiter, not a simple counter.\n- **Granting blanket scopes or roles \"for now.\"** Giving every service or user admin-level access because it's easier to configure means a compromised credential gives the attacker the full blast radius. Apply least-privilege from the beginning: each service credential covers only the permissions that service legitimately needs.\n\n## Full reference\n\n### API key patterns\n\n- Prefix keys for identification: `sk_live_abc123` (secret),\n  `pk_live_xyz789` (public).\n- Hash keys before storage (SHA-256). Show the full key only once at\n  creation.\n- Scope keys to specific permissions; never grant full access by\n  default.\n- Embed a key ID in the key itself so lookups don't require hashing\n  every stored key.\n\n### CORS configuration\n\n```javascript\n\u002F\u002F Express.js example\napp.use(cors({\n  origin: [\"https:\u002F\u002Fapp.example.com\"],     \u002F\u002F Never use \"*\" with credentials\n  methods: [\"GET\", \"POST\", \"PUT\", \"DELETE\"],\n  allowedHeaders: [\"Authorization\", \"Content-Type\"],\n  credentials: true,                        \u002F\u002F Allow cookies\n  maxAge: 86400,                            \u002F\u002F Cache preflight 24h\n}));\n```\n\nNever set `Access-Control-Allow-Origin: *` together with credentials.\n\n### Security review checklist\n\n1. Auth tokens are transmitted only over HTTPS.\n2. Passwords are hashed with bcrypt or argon2 — never MD5\u002FSHA1.\n3. JWT signatures are validated; `alg: none` is rejected.\n4. Refresh tokens are rotated on use and revocable.\n5. Session IDs are regenerated after authentication.\n6. CORS origins are explicitly listed (no wildcards with credentials).\n7. Rate limiting is applied to login and token endpoints.\n8. Failed login attempts trigger progressive delays or lockout.\n\n### JWT validation in practice\n\nAlways specify allowed algorithms explicitly to prevent algorithm\nconfusion attacks (an attacker switching `RS256` to `HS256` and signing\nwith the public key):\n\n```python\nimport jwt\nfrom jwt import PyJWKClient\n\njwks_client = PyJWKClient(\"https:\u002F\u002Fauth.example.com\u002F.well-known\u002Fjwks.json\")\n\ndef validate_token(token: str) -> dict:\n    signing_key = jwks_client.get_signing_key_from_jwt(token)\n    return jwt.decode(\n        token,\n        signing_key.key,\n        algorithms=[\"RS256\"],       # Explicit allowlist\n        issuer=\"https:\u002F\u002Fauth.example.com\",\n        audience=\"https:\u002F\u002Fapi.example.com\",\n        options={\n            \"require\": [\"exp\", \"iss\", \"aud\", \"sub\"],\n            \"verify_exp\": True,\n            \"verify_iss\": True,\n            \"verify_aud\": True,\n        },\n    )\n```\n\n### Common JWT vulnerabilities\n\n- **Algorithm confusion** — fix by explicitly listing allowed\n  algorithms; never trust the token's `alg` header.\n- **Missing signature validation** — reject tokens with `alg: none`.\n- **Tokens stored in localStorage** — readable by XSS; keep access\n  tokens in memory and refresh tokens in httpOnly cookies.\n- **Long expirations** — keep access tokens short-lived (5–15 min).\n- **Sensitive data in payload** — base64 is encoding, not encryption.\n- **No revocation path** — maintain a server-side denylist for critical\n  invalidations and keep access-token lifetimes short.\n\n### Refresh-token rotation\n\nThe auth server issues a fresh refresh token on every use and\ninvalidates the old one. If a previously-rotated refresh token is\npresented again, treat it as theft and invalidate the entire token\nfamily.\n\n### Anti-patterns\n\n- Building your own crypto or password hashing.\n- Storing JWT access tokens in localStorage on a SPA.\n- Using `HS256` for tokens consumed by clients you don't control.\n- Granting blanket scopes or permissions because \"it's easier\".\n- Returning different errors for \"user not found\" vs \"wrong password\"\n  (enables enumeration).\n- Using GET requests for state-changing operations (CSRF surface).\n","# Authentication & Authorization Patterns\n\n## Intro\n\nAuthentication proves who a caller is; authorization decides what they\ncan do. Use industry-standard protocols (OAuth2, OIDC, JWT) and proven\npatterns (session cookies, RBAC, ABAC) rather than inventing your own.\n\n## Overview\n\n### OAuth2 flow selection\n\nPick the flow based on the client's ability to keep secrets:\n\n| Client type                | Flow                  | Token storage             |\n|----------------------------|-----------------------|---------------------------|\n| Server-side web app        | Authorization Code    | Server-side session       |\n| Single-page app (SPA)      | Auth Code + PKCE      | Memory (not localStorage) |\n| Mobile \u002F native app        | Auth Code + PKCE      | Secure device storage     |\n| Service-to-service         | Client Credentials    | Environment variable      |\n| CLI \u002F limited-input device | Device Authorization  | Display user code         |\n\nSee `references\u002Foauth-flows.md` for full flow diagrams and exchange\nparameters.\n\n### JWT essentials\n\n- Always validate signature, `exp`, `iss`, and `aud`.\n- Keep payloads small — JWTs ride on every request.\n- Never store secrets in payloads; base64 is encoding, not encryption.\n- Use short access-token expiry (5–15 min).\n- Prefer `RS256` or `ES256` for public APIs over `HS256`.\n- Rotate signing keys via a JWKS endpoint.\n\nSee `references\u002Fjwt-reference.md` for the structure, claims, and full\nvalidation checklist.\n\n### Session management\n\nFor server-rendered apps using session cookies:\n\n- Generate cryptographically random session IDs (≥128 bits).\n- Store session data server-side (Redis, database) — never inside the\n  cookie body.\n- Set `HttpOnly`, `Secure`, and `SameSite=Lax` (or `Strict`) on the\n  cookie.\n- Apply idle timeout (15–30 min) and absolute timeout (8–24 hours).\n- Regenerate the session ID after login to prevent session fixation.\n\n### RBAC vs ABAC\n\n**RBAC** assigns permissions to roles and roles to users. Simple and\nappropriate when access depends only on the user's job function.\n\n```python\nROLES = {\n    \"viewer\": [\"read:projects\", \"read:reports\"],\n    \"editor\": [\"read:projects\", \"read:reports\", \"write:projects\"],\n    \"admin\":  [\"read:projects\", \"read:reports\", \"write:projects\",\n               \"manage:users\", \"manage:settings\"],\n}\n\ndef has_permission(user, permission):\n    return any(permission in ROLES[role] for role in user.roles)\n```\n\n**ABAC** evaluates attributes of subject, resource, action, and\ncontext. Use it when access depends on ownership, department, time of\nday, or other context.\n\n```python\ndef can_access(subject, action, resource, context):\n    if action == \"edit\" and resource.owner_id == subject.id:\n        return True\n    if \"admin\" in subject.roles and resource.department == subject.department:\n        return True\n    if action == \"deploy\" and not context.is_maintenance_window:\n        return False\n    return False\n```\n\n### Token refresh\n\nAccess tokens should be short-lived. Refresh tokens trade themselves\nfor new access tokens at the auth server:\n\n```\nClient                    Auth Server                 API\n  |                           |                        |\n  |--- Request (access token) ----------------------->|\n  |\u003C-- 401 Unauthorized -------------------------------|\n  |--- Refresh token -------->|                        |\n  |\u003C-- New access + refresh --|                        |\n  |--- Retry (new access token) --------------------->|\n  |\u003C-- 200 OK ----------------------------------------|\n```\n\nRefresh tokens must be stored securely (httpOnly cookie or secure\ndevice storage), single-use (rotated on every refresh), and revocable\n(server-side denylist or family tracking).\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **JWT signature validation skipped or incomplete.** Accepting a JWT without verifying the signature, or without validating `exp` (expiry), `iss` (issuer), and `aud` (audience) claims, means any JWT — including expired, foreign, or forged ones — will be accepted. Always validate all four: signature, expiry, issuer, and audience. Explicitly specify the allowed algorithm list so an attacker cannot switch to `alg: none`.\n- **Storing access tokens in localStorage.** Tokens stored in `localStorage` are accessible to any JavaScript running on the page, including injected scripts via XSS. Keep access tokens in memory only; store refresh tokens in `httpOnly` cookies that JavaScript cannot read.\n- **Returning different error messages for \"user not found\" vs \"wrong password.\"** `\"User does not exist\"` vs `\"Incorrect password\"` allows an attacker to enumerate valid usernames by observing which error they receive. Always return the same generic message: `\"Invalid email or password.\"` regardless of which check failed.\n- **Not regenerating the session ID after login.** If a user has a session cookie before logging in (e.g., from a previous anonymous session) and the same session ID is reused after authentication, an attacker who captured the pre-login session cookie can now use it to access the authenticated session. Regenerate the session ID immediately after successful login.\n- **Using `HS256` for tokens consumed by clients you don't control.** `HS256` uses a shared symmetric key — anyone who knows the key can forge tokens. For public APIs where tokens are validated by multiple parties, use `RS256` or `ES256` (asymmetric), so clients can validate with the public key without being able to forge new tokens.\n- **No rate limiting on authentication endpoints.** A login or password-reset endpoint without rate limiting allows unlimited brute-force attempts. Apply progressive delays, lockout, or CAPTCHA after N failed attempts per IP or per account. Use a token-bucket or sliding-window rate limiter, not a simple counter.\n- **Granting blanket scopes or roles \"for now.\"** Giving every service or user admin-level access because it's easier to configure means a compromised credential gives the attacker the full blast radius. Apply least-privilege from the beginning: each service credential covers only the permissions that service legitimately needs.\n\n## Full reference\n\n### API key patterns\n\n- Prefix keys for identification: `sk_live_abc123` (secret),\n  `pk_live_xyz789` (public).\n- Hash keys before storage (SHA-256). Show the full key only once at\n  creation.\n- Scope keys to specific permissions; never grant full access by\n  default.\n- Embed a key ID in the key itself so lookups don't require hashing\n  every stored key.\n\n### CORS configuration\n\n```javascript\n\u002F\u002F Express.js example\napp.use(cors({\n  origin: [\"https:\u002F\u002Fapp.example.com\"],     \u002F\u002F Never use \"*\" with credentials\n  methods: [\"GET\", \"POST\", \"PUT\", \"DELETE\"],\n  allowedHeaders: [\"Authorization\", \"Content-Type\"],\n  credentials: true,                        \u002F\u002F Allow cookies\n  maxAge: 86400,                            \u002F\u002F Cache preflight 24h\n}));\n```\n\nNever set `Access-Control-Allow-Origin: *` together with credentials.\n\n### Security review checklist\n\n1. Auth tokens are transmitted only over HTTPS.\n2. Passwords are hashed with bcrypt or argon2 — never MD5\u002FSHA1.\n3. JWT signatures are validated; `alg: none` is rejected.\n4. Refresh tokens are rotated on use and revocable.\n5. Session IDs are regenerated after authentication.\n6. CORS origins are explicitly listed (no wildcards with credentials).\n7. Rate limiting is applied to login and token endpoints.\n8. Failed login attempts trigger progressive delays or lockout.\n\n### JWT validation in practice\n\nAlways specify allowed algorithms explicitly to prevent algorithm\nconfusion attacks (an attacker switching `RS256` to `HS256` and signing\nwith the public key):\n\n```python\nimport jwt\nfrom jwt import PyJWKClient\n\njwks_client = PyJWKClient(\"https:\u002F\u002Fauth.example.com\u002F.well-known\u002Fjwks.json\")\n\ndef validate_token(token: str) -> dict:\n    signing_key = jwks_client.get_signing_key_from_jwt(token)\n    return jwt.decode(\n        token,\n        signing_key.key,\n        algorithms=[\"RS256\"],       # Explicit allowlist\n        issuer=\"https:\u002F\u002Fauth.example.com\",\n        audience=\"https:\u002F\u002Fapi.example.com\",\n        options={\n            \"require\": [\"exp\", \"iss\", \"aud\", \"sub\"],\n            \"verify_exp\": True,\n            \"verify_iss\": True,\n            \"verify_aud\": True,\n        },\n    )\n```\n\n### Common JWT vulnerabilities\n\n- **Algorithm confusion** — fix by explicitly listing allowed\n  algorithms; never trust the token's `alg` header.\n- **Missing signature validation** — reject tokens with `alg: none`.\n- **Tokens stored in localStorage** — readable by XSS; keep access\n  tokens in memory and refresh tokens in httpOnly cookies.\n- **Long expirations** — keep access tokens short-lived (5–15 min).\n- **Sensitive data in payload** — base64 is encoding, not encryption.\n- **No revocation path** — maintain a server-side denylist for critical\n  invalidations and keep access-token lifetimes short.\n\n### Refresh-token rotation\n\nThe auth server issues a fresh refresh token on every use and\ninvalidates the old one. If a previously-rotated refresh token is\npresented again, treat it as theft and invalidate the entire token\nfamily.\n\n### Anti-patterns\n\n- Building your own crypto or password hashing.\n- Storing JWT access tokens in localStorage on a SPA.\n- Using `HS256` for tokens consumed by clients you don't control.\n- Granting blanket scopes or permissions because \"it's easier\".\n- Returning different errors for \"user not found\" vs \"wrong password\"\n  (enables enumeration).\n- Using GET requests for state-changing operations (CSRF surface).\n",{"name":5,"metadata":44,"description":51},{"processkit":45},{"id":46,"created":47,"version":48,"category":49,"apiVersion":50},"SKILL-auth-patterns",1775433600000,"1.1.0","engineering","processkit.projectious.work\u002Fv1","Authentication and authorization patterns — OAuth2, JWT, sessions, RBAC\u002FABAC. Use when implementing login flows, securing APIs, managing tokens, designing permission systems, or reviewing auth code.\n","main","4876a92620ee792aac2ac9a1a806322d8a572367","archive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.11.1\u002Fcontext\u002Fskills\u002Fengineering\u002Fauth-patterns","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":60,"prompt":70,"zipAvailable":71},[61,64,67],{"tool":62,"command":63},"npx","npx skills add projectious-work\u002Fprocesskit --skill auth-patterns",{"tool":65,"command":66},"bunx","bunx skills add projectious-work\u002Fprocesskit --skill auth-patterns",{"tool":68,"command":69},"pnpm","pnpm dlx skills add projectious-work\u002Fprocesskit --skill auth-patterns","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.11.1\u002Fcontext\u002Fskills\u002Fengineering\u002Fauth-patterns\u002FSKILL.md",true,[73,79],{"path":74,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":77,"sourceHtmlUrl":78},"references\u002Fjwt-reference.md","REFERENCE","参考文档",6439,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.11.1\u002Fcontext\u002Fskills\u002Fengineering\u002Fauth-patterns\u002Freferences\u002Fjwt-reference.md",{"path":80,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":81,"sourceHtmlUrl":82},"references\u002Foauth-flows.md",6358,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.11.1\u002Fcontext\u002Fskills\u002Fengineering\u002Fauth-patterns\u002Freferences\u002Foauth-flows.md",[84,110,130,151,168,186],{"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":95,"publishedAt":39},"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":93,"taxonomyTypeDesc":94},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[96,97,98,99,100,101,33,102,103,104,86,105,106,107,25,108,109],"management","skill management","create","update","package","alpha","list","manage","ontology","get","as","manifests","skill package","transition",{"skillNo":111,"name":112,"nameZh":6,"description":113,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":114,"categories":115,"keywords":117,"publishedAt":39},"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",[116],{"categoryNo":91,"categoryName":92,"taxonomyType":93,"taxonomyTypeDesc":94},[96,118,119,120,121,122,101,33,123,124,103,125,126,127,105,128,129],"schema","schema management","MCP","workflows","validation","generated","rebuild","contracts","wed","deterministic","contract","mode",{"skillNo":131,"name":132,"nameZh":6,"description":133,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":134,"categories":135,"keywords":136,"publishedAt":39},"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",[],[96,137,138,98,99,139,101,33,140,141,142,143,105,144,145,146,147,148,149,150],"proposition","proposition management","index","log","world","record","query","creation","event","interface","updates","facts","claims","WSJF",{"skillNo":152,"name":153,"nameZh":6,"description":154,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":155,"categories":156,"keywords":157,"publishedAt":39},"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",[],[96,104,158,98,101,159,160,123,161,140,103,162,163,105,164,165,145,166,25,167],"ontology management","lifecycle","archive","roadmap","do","domain","iteration","keep","measurement","generic",{"skillNo":169,"name":170,"nameZh":6,"description":171,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":172,"categories":173,"keywords":174,"publishedAt":39},"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",[],[175,176,177,178,101,179,180,181,33,182,183,184,185],"okf","compatibility","okf compatibility","validate","open","knowledge","format","export","bundles","bundle","import",{"skillNo":187,"name":188,"nameZh":6,"description":189,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":190,"categories":191,"keywords":192,"publishedAt":39},"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",[],[96,193,194,98,99,139,101,159,33,102,140,195,103,142,105,165,145,146,196,109],"capability","capability management","queries","changes"]