[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6WXP8F2CZR4R8MBR2HYYBF3":3,"skill-same:01M6WXP8F2CZR4R8MBR2HYYBF3":79},{"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},"01M6WXP8F2CZR4R8MBR2HYYBF3","grpc-protobuf",null,"Protobuf schema design and gRPC service patterns — streaming, error handling, backward compatibility. Use when designing .proto files, implementing gRPC services or clients, choosing a streaming pattern, handling gRPC errors, or evolving a schema without breaking consumers.","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\u002Fgrpc-protobuf\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"protobuf","grpc protobuf","grpc","when","design","implementing","v1","errors","clients","error","proto","service","pattern","files","schema","use","work","services","streaming","error handling","2026-11-10 10:12:30",false,"---\nname: grpc-protobuf\ndescription: |\n  Protobuf schema design and gRPC service patterns — streaming, error handling, backward compatibility. Use when designing .proto files, implementing gRPC services or clients, choosing a streaming pattern, handling gRPC errors, or evolving a schema without breaking consumers.\nmetadata:\n  processkit:\n    apiVersion: processkit.projectious.work\u002Fv1\n    id: SKILL-grpc-protobuf\n    version: \"1.1.0\"\n    created: 2026-04-06T00:00:00Z\n    category: engineering\n---\n\n# gRPC and Protocol Buffers\n\n## Intro\n\nProtobuf schemas are versioned, append-only contracts. gRPC services\nuse unary RPCs by default and streaming variants only when the\nworkload genuinely needs them. Field numbers are permanent, enum\nzero values are `UNSPECIFIED`, and every RPC gets its own\nRequest\u002FResponse wrapper.\n\n## Overview\n\n### Schema basics\n\n```protobuf\nsyntax = \"proto3\";\npackage myapp.orders.v1;\nimport \"google\u002Fprotobuf\u002Ftimestamp.proto\";\n\nmessage Order {\n  string order_id = 1;\n  string customer_id = 2;\n  repeated LineItem items = 3;\n  OrderStatus status = 4;\n  google.protobuf.Timestamp created_at = 5;\n}\n\nenum OrderStatus {\n  ORDER_STATUS_UNSPECIFIED = 0;  \u002F\u002F zero value = \"not set\"\n  ORDER_STATUS_PENDING = 1;\n  ORDER_STATUS_SHIPPED = 2;\n}\n```\n\n- Always `syntax = \"proto3\"`. Package format: `\u003Corg>.\u003Cservice>.\u003Cversion>`.\n- Enum zero value must be `UNSPECIFIED` so unset and \"explicit zero\"\n  are distinguishable.\n- Use `oneof` for mutually exclusive fields.\n- Prefer the well-known types (`google.protobuf.Timestamp`,\n  `Duration`, `FieldMask`) over hand-rolled equivalents.\n\nSee `references\u002Fproto-conventions.md` for the full naming rules,\nfield-numbering bands, and well-known type table.\n\n### gRPC service patterns\n\n| Pattern              | Use case                                       |\n|----------------------|------------------------------------------------|\n| Unary                | Standard request-response (CRUD, queries)      |\n| Server streaming     | Real-time feeds, long-poll replacement         |\n| Client streaming     | Bulk uploads, client-side event aggregation    |\n| Bidirectional        | Chat, collaborative editing, real-time sync    |\n\n```protobuf\nservice OrderService {\n  rpc CreateOrder(CreateOrderRequest) returns (CreateOrderResponse);\n  rpc WatchStatus(WatchStatusRequest) returns (stream StatusEvent);\n  rpc UploadItems(stream LineItem) returns (UploadItemsResponse);\n  rpc Chat(stream ChatMessage) returns (stream ChatMessage);\n}\n```\n\n### Request\u002Fresponse wrappers\n\nWrap every RPC in dedicated `XxxRequest` and `XxxResponse` messages.\nNever reuse domain types (`Order`) directly as request or response.\nThe wrapper lets you add fields (pagination tokens, field masks,\nmetadata) without touching the domain model.\n\n### Error handling\n\nReturn gRPC status codes — never return OK with an error payload.\n\n| Code              | When to use                                |\n|-------------------|--------------------------------------------|\n| INVALID_ARGUMENT  | Bad client input (validation failure)      |\n| NOT_FOUND         | Resource does not exist                    |\n| ALREADY_EXISTS    | Duplicate key conflict                     |\n| PERMISSION_DENIED | Authenticated but not authorized           |\n| UNAUTHENTICATED   | Missing or invalid credentials             |\n| UNAVAILABLE       | Transient failure — client should retry    |\n| DEADLINE_EXCEEDED | Operation took too long                    |\n\nFor richer errors, attach `google.rpc.BadRequest` or `ErrorInfo` in\nthe `details` field of `google.rpc.Status`.\n\n### Backward compatibility\n\n- **Safe:** add new fields (with new numbers), messages, RPCs, or\n  enum values.\n- **Breaking:** change a field type or number, reuse a deleted field\n  number, change enum numeric values, or remove an RPC.\n\nWhen removing a field, mark it `reserved` so future authors can't\naccidentally reuse the number or name:\n\n```protobuf\nmessage Order {\n  reserved 6, 7;\n  reserved \"legacy_status\";\n}\n```\n\n### Tooling\n\nPrefer **buf** over raw `protoc` — it bundles linting, breaking-change\ndetection, and code generation, and reads a single `buf.yaml`. Use\n**grpcurl** for command-line invocation during debugging. Wire\n`buf breaking` into CI to catch incompatible changes before merge.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Reusing a deleted field number.** Field numbers are permanent wire-format identifiers. Reusing a number that was previously assigned to a different field causes old binary-encoded messages to decode the field into the wrong destination. When removing a field, always mark it `reserved`.\n- **Enum zero value not named `UNSPECIFIED`.** In proto3, the zero value is the default for any unset enum field. If zero is a real semantic value (e.g., `STATUS_PENDING = 0`), unset and \"pending\" are indistinguishable on the wire. The zero value must always be `\u003CENUM_NAME>_UNSPECIFIED`.\n- **Using the same domain type as both request and response.** Passing an `Order` directly as a request body means adding request-specific metadata (pagination tokens, field masks, idempotency keys) requires modifying the domain type. Always wrap in `XxxRequest` \u002F `XxxResponse` messages.\n- **Returning status `OK` with an error payload in the response body.** Embedding error information inside an OK response breaks client error-handling libraries, monitoring dashboards, and retry logic. Return the appropriate gRPC status code and attach structured error detail using `google.rpc.Status`.\n- **No `buf breaking` check in CI.** Without automated breaking-change detection, it is easy to accidentally change a field type, reuse a field number, or remove an RPC and not notice until a client breaks in production. Add `buf breaking --against` to CI.\n- **Making every service bidirectionally streaming by default.** Bidirectional streaming holds a connection open for the entire duration of the stream, consuming server resources per client. Use unary RPCs by default and move to streaming only when the workload genuinely requires it.\n- **Hand-rolling `int64` timestamps instead of using `google.protobuf.Timestamp`.** Custom timestamp encoding (epoch seconds, epoch milliseconds, strings) produces inconsistency across services and loses timezone awareness. Use the well-known `Timestamp` type and let the SDK handle serialization.\n\n## Full reference\n\n### Naming conventions\n\n- **Files:** `lower_snake_case.proto`. One top-level service per\n  file. Directory mirrors the package\n  (`myapp\u002Forders\u002Fv1\u002Forder_service.proto`).\n- **Messages:** `UpperCamelCase` (`OrderLineItem`, `CreateUserRequest`).\n- **Fields:** `lower_snake_case`, repeated fields use plural names\n  (`repeated LineItem items = 3;`).\n- **Enums:** type `UpperCamelCase`, values\n  `\u003CENUM_NAME>_UPPER_SNAKE_CASE`. Zero is always `_UNSPECIFIED`.\n- **Services:** `UpperCamelCase` + `Service` suffix (`OrderService`).\n- **RPCs:** `UpperCamelCase` verb-noun (`CreateOrder`, `ListOrders`).\n\n### Field-numbering rules\n\n- **1-15** encode in one byte — reserve for the most frequent fields.\n- **16-2047** encode in two bytes — everything else.\n- **19000-19999** are reserved by protobuf itself; never use.\n- Field numbers are permanent. They are part of the wire format and\n  must never be changed or reused.\n- Group field numbers in bands (core 1-10, items 11-19, metadata\n  20-29) so future additions land in the right size class.\n\n### Compatibility rules\n\n| Change                     | Safe? | Notes                          |\n|----------------------------|-------|--------------------------------|\n| Add new field              | Yes   | Use a fresh field number       |\n| Add new enum value         | Yes   | Old clients ignore unknown     |\n| Add new RPC or message     | Yes   | No effect on existing clients  |\n| Rename a field             | Yes   | Wire uses numbers, not names   |\n| Change field type          | NO    | Wire encoding differs          |\n| Change field number        | NO    | Data maps to wrong field       |\n| Reuse deleted field number | NO    | Old data decodes wrong         |\n| Change enum numeric value  | NO    | Stored values decode wrong     |\n| Remove an RPC              | NO    | Clients get UNIMPLEMENTED      |\n\n**Migration strategy** for a breaking change:\n\n1. Add the new field alongside the old one with a new number.\n2. Server populates both fields.\n3. Migrate clients to read the new field.\n4. Mark the old field `reserved` once usage is zero.\n5. Run `buf breaking` in CI to enforce the rules.\n\n### Well-known types\n\n| Type             | Use for                                      |\n|------------------|----------------------------------------------|\n| `Timestamp`      | Points in time                               |\n| `Duration`       | Time spans                                   |\n| `Empty`          | RPCs with no request or response             |\n| `FieldMask`      | Partial updates (which fields to write)      |\n| `Any`            | Embedding arbitrary messages                 |\n| `Struct`\u002F`Value` | Untyped JSON-like data (use sparingly)       |\n\n### Common patterns\n\n**Pagination** (Google AIP-158 style):\n\n```protobuf\nmessage ListOrdersRequest {\n  int32 page_size = 1;\n  string page_token = 2;\n}\nmessage ListOrdersResponse {\n  repeated Order orders = 1;\n  string next_page_token = 2;\n}\n```\n\n**Partial updates with FieldMask:**\n\n```protobuf\nmessage UpdateOrderRequest {\n  Order order = 1;\n  google.protobuf.FieldMask update_mask = 2;\n}\n```\n\nThe server modifies only fields listed in `update_mask`, which lets\nclients send a full message without overwriting unrelated fields.\n\n**Resource names** (AIP-122):\n\n```protobuf\nmessage GetOrderRequest {\n  string name = 1;  \u002F\u002F \"projects\u002F{project}\u002Forders\u002F{order}\"\n}\n```\n\n### Interceptors\n\nCross-cutting concerns belong in interceptors, chained in this order:\n\n```\nauth -> logging -> metrics -> validation -> handler\n```\n\n- **Auth** validates tokens and sets user context.\n- **Logging** records method, duration, status code, request ID.\n- **Metrics** emit latency histograms and error rates per method.\n- **Validation** runs `buf validate` rules generated from proto\n  annotations, so the handler never sees invalid input.\n\nClient-side interceptors handle retries (only on `UNAVAILABLE` and\n`DEADLINE_EXCEEDED`, with exponential backoff and a propagated\ndeadline), connection pooling, and tracing headers.\n\n### Anti-patterns to avoid\n\n- Reusing domain types as request\u002Fresponse messages.\n- Skipping `_UNSPECIFIED` enum zero values.\n- Returning errors in the response body with status OK.\n- Reusing deleted field numbers (reserve them instead).\n- Making libraries streaming-by-default — pick unary unless the\n  workload genuinely needs streaming.\n- Hand-rolling timestamps as `int64` epoch seconds when\n  `google.protobuf.Timestamp` exists.\n","# gRPC and Protocol Buffers\n\n## Intro\n\nProtobuf schemas are versioned, append-only contracts. gRPC services\nuse unary RPCs by default and streaming variants only when the\nworkload genuinely needs them. Field numbers are permanent, enum\nzero values are `UNSPECIFIED`, and every RPC gets its own\nRequest\u002FResponse wrapper.\n\n## Overview\n\n### Schema basics\n\n```protobuf\nsyntax = \"proto3\";\npackage myapp.orders.v1;\nimport \"google\u002Fprotobuf\u002Ftimestamp.proto\";\n\nmessage Order {\n  string order_id = 1;\n  string customer_id = 2;\n  repeated LineItem items = 3;\n  OrderStatus status = 4;\n  google.protobuf.Timestamp created_at = 5;\n}\n\nenum OrderStatus {\n  ORDER_STATUS_UNSPECIFIED = 0;  \u002F\u002F zero value = \"not set\"\n  ORDER_STATUS_PENDING = 1;\n  ORDER_STATUS_SHIPPED = 2;\n}\n```\n\n- Always `syntax = \"proto3\"`. Package format: `\u003Corg>.\u003Cservice>.\u003Cversion>`.\n- Enum zero value must be `UNSPECIFIED` so unset and \"explicit zero\"\n  are distinguishable.\n- Use `oneof` for mutually exclusive fields.\n- Prefer the well-known types (`google.protobuf.Timestamp`,\n  `Duration`, `FieldMask`) over hand-rolled equivalents.\n\nSee `references\u002Fproto-conventions.md` for the full naming rules,\nfield-numbering bands, and well-known type table.\n\n### gRPC service patterns\n\n| Pattern              | Use case                                       |\n|----------------------|------------------------------------------------|\n| Unary                | Standard request-response (CRUD, queries)      |\n| Server streaming     | Real-time feeds, long-poll replacement         |\n| Client streaming     | Bulk uploads, client-side event aggregation    |\n| Bidirectional        | Chat, collaborative editing, real-time sync    |\n\n```protobuf\nservice OrderService {\n  rpc CreateOrder(CreateOrderRequest) returns (CreateOrderResponse);\n  rpc WatchStatus(WatchStatusRequest) returns (stream StatusEvent);\n  rpc UploadItems(stream LineItem) returns (UploadItemsResponse);\n  rpc Chat(stream ChatMessage) returns (stream ChatMessage);\n}\n```\n\n### Request\u002Fresponse wrappers\n\nWrap every RPC in dedicated `XxxRequest` and `XxxResponse` messages.\nNever reuse domain types (`Order`) directly as request or response.\nThe wrapper lets you add fields (pagination tokens, field masks,\nmetadata) without touching the domain model.\n\n### Error handling\n\nReturn gRPC status codes — never return OK with an error payload.\n\n| Code              | When to use                                |\n|-------------------|--------------------------------------------|\n| INVALID_ARGUMENT  | Bad client input (validation failure)      |\n| NOT_FOUND         | Resource does not exist                    |\n| ALREADY_EXISTS    | Duplicate key conflict                     |\n| PERMISSION_DENIED | Authenticated but not authorized           |\n| UNAUTHENTICATED   | Missing or invalid credentials             |\n| UNAVAILABLE       | Transient failure — client should retry    |\n| DEADLINE_EXCEEDED | Operation took too long                    |\n\nFor richer errors, attach `google.rpc.BadRequest` or `ErrorInfo` in\nthe `details` field of `google.rpc.Status`.\n\n### Backward compatibility\n\n- **Safe:** add new fields (with new numbers), messages, RPCs, or\n  enum values.\n- **Breaking:** change a field type or number, reuse a deleted field\n  number, change enum numeric values, or remove an RPC.\n\nWhen removing a field, mark it `reserved` so future authors can't\naccidentally reuse the number or name:\n\n```protobuf\nmessage Order {\n  reserved 6, 7;\n  reserved \"legacy_status\";\n}\n```\n\n### Tooling\n\nPrefer **buf** over raw `protoc` — it bundles linting, breaking-change\ndetection, and code generation, and reads a single `buf.yaml`. Use\n**grpcurl** for command-line invocation during debugging. Wire\n`buf breaking` into CI to catch incompatible changes before merge.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Reusing a deleted field number.** Field numbers are permanent wire-format identifiers. Reusing a number that was previously assigned to a different field causes old binary-encoded messages to decode the field into the wrong destination. When removing a field, always mark it `reserved`.\n- **Enum zero value not named `UNSPECIFIED`.** In proto3, the zero value is the default for any unset enum field. If zero is a real semantic value (e.g., `STATUS_PENDING = 0`), unset and \"pending\" are indistinguishable on the wire. The zero value must always be `\u003CENUM_NAME>_UNSPECIFIED`.\n- **Using the same domain type as both request and response.** Passing an `Order` directly as a request body means adding request-specific metadata (pagination tokens, field masks, idempotency keys) requires modifying the domain type. Always wrap in `XxxRequest` \u002F `XxxResponse` messages.\n- **Returning status `OK` with an error payload in the response body.** Embedding error information inside an OK response breaks client error-handling libraries, monitoring dashboards, and retry logic. Return the appropriate gRPC status code and attach structured error detail using `google.rpc.Status`.\n- **No `buf breaking` check in CI.** Without automated breaking-change detection, it is easy to accidentally change a field type, reuse a field number, or remove an RPC and not notice until a client breaks in production. Add `buf breaking --against` to CI.\n- **Making every service bidirectionally streaming by default.** Bidirectional streaming holds a connection open for the entire duration of the stream, consuming server resources per client. Use unary RPCs by default and move to streaming only when the workload genuinely requires it.\n- **Hand-rolling `int64` timestamps instead of using `google.protobuf.Timestamp`.** Custom timestamp encoding (epoch seconds, epoch milliseconds, strings) produces inconsistency across services and loses timezone awareness. Use the well-known `Timestamp` type and let the SDK handle serialization.\n\n## Full reference\n\n### Naming conventions\n\n- **Files:** `lower_snake_case.proto`. One top-level service per\n  file. Directory mirrors the package\n  (`myapp\u002Forders\u002Fv1\u002Forder_service.proto`).\n- **Messages:** `UpperCamelCase` (`OrderLineItem`, `CreateUserRequest`).\n- **Fields:** `lower_snake_case`, repeated fields use plural names\n  (`repeated LineItem items = 3;`).\n- **Enums:** type `UpperCamelCase`, values\n  `\u003CENUM_NAME>_UPPER_SNAKE_CASE`. Zero is always `_UNSPECIFIED`.\n- **Services:** `UpperCamelCase` + `Service` suffix (`OrderService`).\n- **RPCs:** `UpperCamelCase` verb-noun (`CreateOrder`, `ListOrders`).\n\n### Field-numbering rules\n\n- **1-15** encode in one byte — reserve for the most frequent fields.\n- **16-2047** encode in two bytes — everything else.\n- **19000-19999** are reserved by protobuf itself; never use.\n- Field numbers are permanent. They are part of the wire format and\n  must never be changed or reused.\n- Group field numbers in bands (core 1-10, items 11-19, metadata\n  20-29) so future additions land in the right size class.\n\n### Compatibility rules\n\n| Change                     | Safe? | Notes                          |\n|----------------------------|-------|--------------------------------|\n| Add new field              | Yes   | Use a fresh field number       |\n| Add new enum value         | Yes   | Old clients ignore unknown     |\n| Add new RPC or message     | Yes   | No effect on existing clients  |\n| Rename a field             | Yes   | Wire uses numbers, not names   |\n| Change field type          | NO    | Wire encoding differs          |\n| Change field number        | NO    | Data maps to wrong field       |\n| Reuse deleted field number | NO    | Old data decodes wrong         |\n| Change enum numeric value  | NO    | Stored values decode wrong     |\n| Remove an RPC              | NO    | Clients get UNIMPLEMENTED      |\n\n**Migration strategy** for a breaking change:\n\n1. Add the new field alongside the old one with a new number.\n2. Server populates both fields.\n3. Migrate clients to read the new field.\n4. Mark the old field `reserved` once usage is zero.\n5. Run `buf breaking` in CI to enforce the rules.\n\n### Well-known types\n\n| Type             | Use for                                      |\n|------------------|----------------------------------------------|\n| `Timestamp`      | Points in time                               |\n| `Duration`       | Time spans                                   |\n| `Empty`          | RPCs with no request or response             |\n| `FieldMask`      | Partial updates (which fields to write)      |\n| `Any`            | Embedding arbitrary messages                 |\n| `Struct`\u002F`Value` | Untyped JSON-like data (use sparingly)       |\n\n### Common patterns\n\n**Pagination** (Google AIP-158 style):\n\n```protobuf\nmessage ListOrdersRequest {\n  int32 page_size = 1;\n  string page_token = 2;\n}\nmessage ListOrdersResponse {\n  repeated Order orders = 1;\n  string next_page_token = 2;\n}\n```\n\n**Partial updates with FieldMask:**\n\n```protobuf\nmessage UpdateOrderRequest {\n  Order order = 1;\n  google.protobuf.FieldMask update_mask = 2;\n}\n```\n\nThe server modifies only fields listed in `update_mask`, which lets\nclients send a full message without overwriting unrelated fields.\n\n**Resource names** (AIP-122):\n\n```protobuf\nmessage GetOrderRequest {\n  string name = 1;  \u002F\u002F \"projects\u002F{project}\u002Forders\u002F{order}\"\n}\n```\n\n### Interceptors\n\nCross-cutting concerns belong in interceptors, chained in this order:\n\n```\nauth -> logging -> metrics -> validation -> handler\n```\n\n- **Auth** validates tokens and sets user context.\n- **Logging** records method, duration, status code, request ID.\n- **Metrics** emit latency histograms and error rates per method.\n- **Validation** runs `buf validate` rules generated from proto\n  annotations, so the handler never sees invalid input.\n\nClient-side interceptors handle retries (only on `UNAVAILABLE` and\n`DEADLINE_EXCEEDED`, with exponential backoff and a propagated\ndeadline), connection pooling, and tracing headers.\n\n### Anti-patterns to avoid\n\n- Reusing domain types as request\u002Fresponse messages.\n- Skipping `_UNSPECIFIED` enum zero values.\n- Returning errors in the response body with status OK.\n- Reusing deleted field numbers (reserve them instead).\n- Making libraries streaming-by-default — pick unary unless the\n  workload genuinely needs streaming.\n- Hand-rolling timestamps as `int64` epoch seconds when\n  `google.protobuf.Timestamp` exists.\n",{"name":5,"metadata":44,"description":51},{"processkit":45},{"id":46,"created":47,"version":48,"category":49,"apiVersion":50},"SKILL-grpc-protobuf",1775433600000,"1.1.0","engineering","processkit.projectious.work\u002Fv1","Protobuf schema design and gRPC service patterns — streaming, error handling, backward compatibility. Use when designing .proto files, implementing gRPC services or clients, choosing a streaming pattern, handling gRPC errors, or evolving a schema without breaking consumers.\n","main","4876a92620ee792aac2ac9a1a806322d8a572367","archive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.11.1\u002Fcontext\u002Fskills\u002Fengineering\u002Fgrpc-protobuf","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 grpc-protobuf",{"tool":65,"command":66},"bunx","bunx skills add projectious-work\u002Fprocesskit --skill grpc-protobuf",{"tool":68,"command":69},"pnpm","pnpm dlx skills add projectious-work\u002Fprocesskit --skill grpc-protobuf","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.11.1\u002Fcontext\u002Fskills\u002Fengineering\u002Fgrpc-protobuf\u002FSKILL.md",true,[73],{"path":74,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":77,"sourceHtmlUrl":78},"references\u002Fproto-conventions.md","REFERENCE","参考文档",4040,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.11.1\u002Fcontext\u002Fskills\u002Fengineering\u002Fgrpc-protobuf\u002Freferences\u002Fproto-conventions.md",[80,106,125,146,163,181],{"skillNo":81,"name":82,"nameZh":6,"description":83,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":84,"categories":85,"keywords":91,"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",[86],{"categoryNo":87,"categoryName":88,"taxonomyType":89,"taxonomyTypeDesc":90},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[92,93,94,95,96,97,35,98,99,100,82,101,102,103,25,104,105],"management","skill management","create","update","package","alpha","list","manage","ontology","get","as","manifests","skill package","transition",{"skillNo":107,"name":108,"nameZh":6,"description":109,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":110,"categories":111,"keywords":113,"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",[112],{"categoryNo":87,"categoryName":88,"taxonomyType":89,"taxonomyTypeDesc":90},[92,33,114,115,116,117,97,35,118,119,99,120,121,122,101,123,124],"schema management","MCP","workflows","validation","generated","rebuild","contracts","wed","deterministic","contract","mode",{"skillNo":126,"name":127,"nameZh":6,"description":128,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":129,"categories":130,"keywords":131,"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",[],[92,132,133,94,95,134,97,35,135,136,137,138,101,139,140,141,142,143,144,145],"proposition","proposition management","index","log","world","record","query","creation","event","interface","updates","facts","claims","WSJF",{"skillNo":147,"name":148,"nameZh":6,"description":149,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":150,"categories":151,"keywords":152,"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",[],[92,100,153,94,97,154,155,118,156,135,99,157,158,101,159,160,140,161,25,162],"ontology management","lifecycle","archive","roadmap","do","domain","iteration","keep","measurement","generic",{"skillNo":164,"name":165,"nameZh":6,"description":166,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":167,"categories":168,"keywords":169,"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",[],[170,171,172,173,97,174,175,176,35,177,178,179,180],"okf","compatibility","okf compatibility","validate","open","knowledge","format","export","bundles","bundle","import",{"skillNo":182,"name":183,"nameZh":6,"description":184,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":185,"categories":186,"keywords":187,"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",[],[92,188,189,94,95,134,97,154,35,98,135,190,99,137,101,160,140,141,191,105],"capability","capability management","queries","changes"]