[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6NPZTAC44G2C0TAA41R2M38":3,"skill-same:01M6NPZTAC44G2C0TAA41R2M38":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":51,"commitSha":52,"skillDirectory":53,"forksCount":14,"repositoryHtmlUrl":54,"repositoryHomepageUrl":55,"ownerHtmlUrl":56,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":57,"install":58,"resources":71},"01M6NPZTAC44G2C0TAA41R2M38","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\u002Fsrc\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","patterns","design","implementing","errors","clients","error","proto","service","pattern","streaming","files","schema","use","work","engineering","services","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\u002Fv2\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":50},{"processkit":45},{"id":46,"created":47,"version":48,"category":36,"apiVersion":49},"SKILL-grpc-protobuf",1775433600000,"1.1.0","processkit.projectious.work\u002Fv2","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","7231f100e266e30d2c1699ecde5c00602471dc3c","src\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":59,"prompt":69,"zipAvailable":70},[60,63,66],{"tool":61,"command":62},"npx","npx skills add projectious-work\u002Fprocesskit --skill grpc-protobuf",{"tool":64,"command":65},"bunx","bunx skills add projectious-work\u002Fprocesskit --skill grpc-protobuf",{"tool":67,"command":68},"pnpm","pnpm dlx skills add projectious-work\u002Fprocesskit --skill grpc-protobuf","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fengineering\u002Fgrpc-protobuf\u002FSKILL.md",true,[72,78],{"path":73,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":76,"sourceHtmlUrl":77},"references\u002Fproto-conventions.md","REFERENCE","参考文档",4040,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fengineering\u002Fgrpc-protobuf\u002Freferences\u002Fproto-conventions.md",{"path":79,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":14,"sourceHtmlUrl":82},"scripts\u002F.gitkeep","SCRIPT","脚本","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fengineering\u002Fgrpc-protobuf\u002Fscripts\u002F.gitkeep",[84,111,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,35,102,103,104,86,105,106,107,108,109,110],"management","skill management","create","update","package","alpha","list","manage","ontology","get","as","manifests","v1","skill package","transition",{"skillNo":112,"name":113,"nameZh":6,"description":114,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":118,"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",[117],{"categoryNo":91,"categoryName":92,"taxonomyType":93,"taxonomyTypeDesc":94},[96,33,119,120,121,122,101,35,123,124,103,125,126,127,105,128,129],"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,35,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,108,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,35,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,35,102,140,195,103,142,105,165,145,146,196,110],"capability","capability management","queries","changes"]