[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6X014JWH3RMCAP3FMNH39N9":3,"skill-same:01M6X014JWH3RMCAP3FMNH39N9":78},{"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":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":57,"commitSha":58,"skillDirectory":59,"forksCount":14,"repositoryHtmlUrl":60,"repositoryHomepageUrl":61,"ownerHtmlUrl":62,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":63,"install":64,"resources":77},"01M6X014JWH3RMCAP3FMNH39N9","terraform-basics",null,"Infrastructure-as-code with Terraform\u002FOpenTofu — resources, state, modules, plan\u002Fapply. Use when writing `.tf` files, managing cloud infrastructure with Terraform or OpenTofu, handling state and backends, or reviewing IaC 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.18.2\u002Fcontext\u002Fskills\u002Fdevops\u002Fterraform-basics\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000011","运维与部署","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"terraform","terraform basics","basics","when","writing","apply","v1","infrastructure-as","with","resources","as","files","modules","iac","use","work","plan","infrastructure-as-code","state","code","2026-11-10 10:12:30",false,"---\nname: terraform-basics\ndescription: |\n  Infrastructure-as-code with Terraform\u002FOpenTofu — resources, state, modules, plan\u002Fapply. Use when writing `.tf` files, managing cloud infrastructure with Terraform or OpenTofu, handling state and backends, or reviewing IaC code.\nmetadata:\n  processkit:\n    apiVersion: processkit.projectious.work\u002Fv1\n    id: SKILL-terraform-basics\n    version: \"1.1.0\"\n    created: 2026-04-06T00:00:00Z\n    category: devops\n---\n\n# Terraform Basics\n\n## Intro\n\nTerraform (and OpenTofu) describes cloud infrastructure declaratively\nand reconciles reality with `plan` and `apply`. Pin provider versions,\nuse a remote state backend, and never edit state by hand — get those\nthree right and the rest is just resource documentation.\n\n## Overview\n\n### Resources and providers\n\nEvery project starts with a provider configuration. Pin provider\nversions in a `required_providers` block:\n\n```hcl\nterraform {\n  required_version = \">= 1.5\"\n  required_providers {\n    aws = {\n      source  = \"hashicorp\u002Faws\"\n      version = \"~> 5.0\"\n    }\n  }\n}\n\nprovider \"aws\" {\n  region = \"eu-central-1\"\n}\n```\n\nResources are the core building blocks. Use descriptive names and set\ncritical arguments explicitly rather than relying on defaults.\n\n### Variables and outputs\n\nUse typed variables with descriptions and validation where\nappropriate:\n\n```hcl\nvariable \"instance_type\" {\n  type        = string\n  default     = \"t3.micro\"\n  description = \"EC2 instance size\"\n  validation {\n    condition     = can(regex(\"^t3\\\\.\", var.instance_type))\n    error_message = \"Only t3 instance types are allowed.\"\n  }\n}\n\noutput \"instance_ip\" {\n  value       = aws_instance.web.public_ip\n  description = \"Public IP of the web server\"\n}\n```\n\nVariable types: `string`, `number`, `bool`, `list(type)`, `map(type)`,\n`object({...})`. Use `terraform.tfvars` or `-var-file` for\nenvironment-specific values. Never hardcode secrets — use environment\nvariables or a secrets manager data source.\n\n### Data sources\n\nUse data sources to reference existing infrastructure without\nmanaging it:\n\n```hcl\ndata \"aws_ami\" \"ubuntu\" {\n  most_recent = true\n  owners      = [\"099720109477\"]\n  filter {\n    name   = \"name\"\n    values = [\"ubuntu\u002Fimages\u002Fhvm-ssd\u002Fubuntu-jammy-22.04-amd64-server-*\"]\n  }\n}\n```\n\n### State management\n\nState tracks the mapping between config and real infrastructure.\nConfigure a remote backend for team use:\n\n```hcl\nterraform {\n  backend \"s3\" {\n    bucket         = \"myproject-tfstate\"\n    key            = \"prod\u002Fterraform.tfstate\"\n    region         = \"eu-central-1\"\n    dynamodb_table = \"terraform-locks\"\n    encrypt        = true\n  }\n}\n```\n\nNever edit state files manually. Use `terraform state list`,\n`terraform state show`, and `terraform state mv` for inspection and\nrefactoring. Use `terraform import` to bring existing resources under\nmanagement.\n\n### Modules\n\nModules group related resources for reuse. Keep modules focused on a\nsingle concern:\n\n```hcl\nmodule \"vpc\" {\n  source  = \".\u002Fmodules\u002Fvpc\"\n  cidr    = \"10.0.0.0\u002F16\"\n  azs     = [\"eu-central-1a\", \"eu-central-1b\"]\n}\n```\n\nPublic modules from the registry use\n`source = \"terraform-aws-modules\u002Fvpc\u002Faws\"` with a `version` pin.\nAlways pin module versions in production.\n\n### Plan \u002F apply \u002F destroy\n\nAlways preview before applying:\n\n```bash\nterraform init               # download providers and modules\nterraform fmt -check         # check formatting\nterraform validate           # syntax and internal consistency\nterraform plan -out=tfplan   # preview changes, save plan\nterraform apply tfplan       # apply the saved plan exactly\n```\n\nUse `terraform destroy` with extreme caution — review the plan\noutput first. For targeted operations, use `-target=resource.name`\nsparingly and only for debugging.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **`terraform apply` without a saved plan.** Running `terraform plan` to review changes and then `terraform apply` (without `-auto-approve tfplan`) runs a fresh plan at apply time, which may differ from the plan you reviewed — a new resource may have appeared, or the plan may have changed due to drift. Always save the plan with `terraform plan -out=tfplan` and apply that exact file with `terraform apply tfplan`.\n- **Unpinned provider or module versions.** A provider block without a `version` constraint will download the latest version on the next `terraform init` on any machine, silently changing behavior. Use `version = \"~> 5.0\"` for providers (allow patch and minor bumps within the major version) and exact pins for production modules. Lock files (`terraform.lock.hcl`) enforce this in CI.\n- **Editing state files manually.** The state file is a JSON representation of Terraform's understanding of reality. Manual edits corrupt this mapping and cause `plan` to produce incorrect diffs. Use `terraform state mv`, `terraform state rm`, `terraform import`, and `moved` blocks for all state manipulation.\n- **Committing `terraform.tfstate` to version control.** A local state file checked into git will diverge between contributors, has no locking, and exposes sensitive resource attributes in plain text. Use a remote backend (S3 + DynamoDB, GCS, Terraform Cloud) with state locking from the first day of the project.\n- **Monolithic root module with everything in one directory.** A single module managing networking, compute, databases, and IAM in one `terraform apply` means a change to a Lambda function requires a plan that touches the VPC and RDS, increasing plan time and blast radius. Split by lifecycle: network infrastructure rarely changes; application resources change constantly. Separate state per lifecycle group.\n- **`terraform state rm` to \"fix\" drift instead of `import`.** Removing a resource from state tells Terraform \"this resource no longer exists under my management\" — the next apply will attempt to create a duplicate. To bring a manually-created resource under Terraform management, use `terraform import`. `state rm` is correct only when deliberately abandoning management of a resource.\n- **Hardcoded secrets in `.tf` files or `terraform.tfvars`.** Secrets committed to version control in Terraform files have the same exposure as any other code repository secret — and Terraform state files may also expose them in plaintext. Pass secrets via environment variables (`TF_VAR_db_password`), a secrets manager data source, or a vault provider — never as literal values in configuration files.\n\n## Full reference\n\n### Best practices\n\n- One state per environment (dev\u002Fstaging\u002Fprod) via workspaces or\n  separate directories\n- Use `lifecycle { prevent_destroy = true }` on critical resources\n  (databases, S3 buckets holding data you cannot recreate)\n- Tag all resources with project, environment, and owner\n- Run `terraform fmt` and `terraform validate` before committing\n- Use `moved` blocks for refactoring instead of destroy\u002Frecreate\n- Keep modules small and focused — a module for VPC, another for\n  IAM, another for RDS, rather than one \"everything\" module\n\n### Worked example: EC2 with security group\n\n```hcl\nresource \"aws_security_group\" \"web\" {\n  name_prefix = \"web-\"\n  ingress {\n    from_port   = 443\n    to_port     = 443\n    protocol    = \"tcp\"\n    cidr_blocks = [\"0.0.0.0\u002F0\"]\n  }\n  egress {\n    from_port   = 0\n    to_port     = 0\n    protocol    = \"-1\"\n    cidr_blocks = [\"0.0.0.0\u002F0\"]\n  }\n}\n\nresource \"aws_instance\" \"web\" {\n  ami                    = data.aws_ami.ubuntu.id\n  instance_type          = var.instance_type\n  vpc_security_group_ids = [aws_security_group.web.id]\n  tags = {\n    Name        = \"web-server\"\n    Environment = \"prod\"\n  }\n}\n```\n\n### Migrating state from local to S3\n\n```bash\n# 1. Add backend config to the terraform block\n# 2. Run init with migration flag\nterraform init -migrate-state\n# 3. Verify state is accessible\nterraform state list\n# 4. Delete local terraform.tfstate after confirming\n```\n\n### Importing an existing resource\n\n```bash\n# Find the resource ID in the cloud console or CLI\nterraform import aws_s3_bucket.logs my-existing-log-bucket\n# Write the matching resource block in .tf\nterraform plan  # should show no changes if config matches\n```\n\n### State surgery with `state mv`\n\nWhen you rename a resource or move it into a module, Terraform sees\nit as \"destroy old, create new\" unless you update state:\n\n```bash\nterraform state mv aws_instance.web module.web.aws_instance.this\nterraform state mv aws_instance.old aws_instance.new\n```\n\nPrefer a `moved` block in config when possible — it is checked into\nversion control and replayed automatically:\n\n```hcl\nmoved {\n  from = aws_instance.old\n  to   = aws_instance.new\n}\n```\n\n### Anti-patterns\n\n- **Hardcoded secrets in `.tf` files** — use env vars, `-var`, or a\n  secrets manager data source\n- **Unpinned providers or modules** — `version = \"~> 5.0\"` minimum;\n  prefer exact pins in production\n- **Blind `terraform apply` without a saved plan** — apply the plan\n  you reviewed, not a fresh one\n- **`terraform state rm` to \"fix\" drift** — you are lying to\n  Terraform about what exists; reach for `import` or `moved` instead\n- **`-target` as normal workflow** — it bypasses graph analysis and\n  produces partial applies\n- **Committing `terraform.tfstate`** — remote backend only; local\n  state is a collaboration hazard\n- **Monolithic root module** — split by lifecycle (network rarely\n  changes, app changes daily); separate state per lifecycle\n- **Destroy\u002Frecreate when a `moved` block would do** — destructive\n  changes should be explicit, not accidental\n","# Terraform Basics\n\n## Intro\n\nTerraform (and OpenTofu) describes cloud infrastructure declaratively\nand reconciles reality with `plan` and `apply`. Pin provider versions,\nuse a remote state backend, and never edit state by hand — get those\nthree right and the rest is just resource documentation.\n\n## Overview\n\n### Resources and providers\n\nEvery project starts with a provider configuration. Pin provider\nversions in a `required_providers` block:\n\n```hcl\nterraform {\n  required_version = \">= 1.5\"\n  required_providers {\n    aws = {\n      source  = \"hashicorp\u002Faws\"\n      version = \"~> 5.0\"\n    }\n  }\n}\n\nprovider \"aws\" {\n  region = \"eu-central-1\"\n}\n```\n\nResources are the core building blocks. Use descriptive names and set\ncritical arguments explicitly rather than relying on defaults.\n\n### Variables and outputs\n\nUse typed variables with descriptions and validation where\nappropriate:\n\n```hcl\nvariable \"instance_type\" {\n  type        = string\n  default     = \"t3.micro\"\n  description = \"EC2 instance size\"\n  validation {\n    condition     = can(regex(\"^t3\\\\.\", var.instance_type))\n    error_message = \"Only t3 instance types are allowed.\"\n  }\n}\n\noutput \"instance_ip\" {\n  value       = aws_instance.web.public_ip\n  description = \"Public IP of the web server\"\n}\n```\n\nVariable types: `string`, `number`, `bool`, `list(type)`, `map(type)`,\n`object({...})`. Use `terraform.tfvars` or `-var-file` for\nenvironment-specific values. Never hardcode secrets — use environment\nvariables or a secrets manager data source.\n\n### Data sources\n\nUse data sources to reference existing infrastructure without\nmanaging it:\n\n```hcl\ndata \"aws_ami\" \"ubuntu\" {\n  most_recent = true\n  owners      = [\"099720109477\"]\n  filter {\n    name   = \"name\"\n    values = [\"ubuntu\u002Fimages\u002Fhvm-ssd\u002Fubuntu-jammy-22.04-amd64-server-*\"]\n  }\n}\n```\n\n### State management\n\nState tracks the mapping between config and real infrastructure.\nConfigure a remote backend for team use:\n\n```hcl\nterraform {\n  backend \"s3\" {\n    bucket         = \"myproject-tfstate\"\n    key            = \"prod\u002Fterraform.tfstate\"\n    region         = \"eu-central-1\"\n    dynamodb_table = \"terraform-locks\"\n    encrypt        = true\n  }\n}\n```\n\nNever edit state files manually. Use `terraform state list`,\n`terraform state show`, and `terraform state mv` for inspection and\nrefactoring. Use `terraform import` to bring existing resources under\nmanagement.\n\n### Modules\n\nModules group related resources for reuse. Keep modules focused on a\nsingle concern:\n\n```hcl\nmodule \"vpc\" {\n  source  = \".\u002Fmodules\u002Fvpc\"\n  cidr    = \"10.0.0.0\u002F16\"\n  azs     = [\"eu-central-1a\", \"eu-central-1b\"]\n}\n```\n\nPublic modules from the registry use\n`source = \"terraform-aws-modules\u002Fvpc\u002Faws\"` with a `version` pin.\nAlways pin module versions in production.\n\n### Plan \u002F apply \u002F destroy\n\nAlways preview before applying:\n\n```bash\nterraform init               # download providers and modules\nterraform fmt -check         # check formatting\nterraform validate           # syntax and internal consistency\nterraform plan -out=tfplan   # preview changes, save plan\nterraform apply tfplan       # apply the saved plan exactly\n```\n\nUse `terraform destroy` with extreme caution — review the plan\noutput first. For targeted operations, use `-target=resource.name`\nsparingly and only for debugging.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **`terraform apply` without a saved plan.** Running `terraform plan` to review changes and then `terraform apply` (without `-auto-approve tfplan`) runs a fresh plan at apply time, which may differ from the plan you reviewed — a new resource may have appeared, or the plan may have changed due to drift. Always save the plan with `terraform plan -out=tfplan` and apply that exact file with `terraform apply tfplan`.\n- **Unpinned provider or module versions.** A provider block without a `version` constraint will download the latest version on the next `terraform init` on any machine, silently changing behavior. Use `version = \"~> 5.0\"` for providers (allow patch and minor bumps within the major version) and exact pins for production modules. Lock files (`terraform.lock.hcl`) enforce this in CI.\n- **Editing state files manually.** The state file is a JSON representation of Terraform's understanding of reality. Manual edits corrupt this mapping and cause `plan` to produce incorrect diffs. Use `terraform state mv`, `terraform state rm`, `terraform import`, and `moved` blocks for all state manipulation.\n- **Committing `terraform.tfstate` to version control.** A local state file checked into git will diverge between contributors, has no locking, and exposes sensitive resource attributes in plain text. Use a remote backend (S3 + DynamoDB, GCS, Terraform Cloud) with state locking from the first day of the project.\n- **Monolithic root module with everything in one directory.** A single module managing networking, compute, databases, and IAM in one `terraform apply` means a change to a Lambda function requires a plan that touches the VPC and RDS, increasing plan time and blast radius. Split by lifecycle: network infrastructure rarely changes; application resources change constantly. Separate state per lifecycle group.\n- **`terraform state rm` to \"fix\" drift instead of `import`.** Removing a resource from state tells Terraform \"this resource no longer exists under my management\" — the next apply will attempt to create a duplicate. To bring a manually-created resource under Terraform management, use `terraform import`. `state rm` is correct only when deliberately abandoning management of a resource.\n- **Hardcoded secrets in `.tf` files or `terraform.tfvars`.** Secrets committed to version control in Terraform files have the same exposure as any other code repository secret — and Terraform state files may also expose them in plaintext. Pass secrets via environment variables (`TF_VAR_db_password`), a secrets manager data source, or a vault provider — never as literal values in configuration files.\n\n## Full reference\n\n### Best practices\n\n- One state per environment (dev\u002Fstaging\u002Fprod) via workspaces or\n  separate directories\n- Use `lifecycle { prevent_destroy = true }` on critical resources\n  (databases, S3 buckets holding data you cannot recreate)\n- Tag all resources with project, environment, and owner\n- Run `terraform fmt` and `terraform validate` before committing\n- Use `moved` blocks for refactoring instead of destroy\u002Frecreate\n- Keep modules small and focused — a module for VPC, another for\n  IAM, another for RDS, rather than one \"everything\" module\n\n### Worked example: EC2 with security group\n\n```hcl\nresource \"aws_security_group\" \"web\" {\n  name_prefix = \"web-\"\n  ingress {\n    from_port   = 443\n    to_port     = 443\n    protocol    = \"tcp\"\n    cidr_blocks = [\"0.0.0.0\u002F0\"]\n  }\n  egress {\n    from_port   = 0\n    to_port     = 0\n    protocol    = \"-1\"\n    cidr_blocks = [\"0.0.0.0\u002F0\"]\n  }\n}\n\nresource \"aws_instance\" \"web\" {\n  ami                    = data.aws_ami.ubuntu.id\n  instance_type          = var.instance_type\n  vpc_security_group_ids = [aws_security_group.web.id]\n  tags = {\n    Name        = \"web-server\"\n    Environment = \"prod\"\n  }\n}\n```\n\n### Migrating state from local to S3\n\n```bash\n# 1. Add backend config to the terraform block\n# 2. Run init with migration flag\nterraform init -migrate-state\n# 3. Verify state is accessible\nterraform state list\n# 4. Delete local terraform.tfstate after confirming\n```\n\n### Importing an existing resource\n\n```bash\n# Find the resource ID in the cloud console or CLI\nterraform import aws_s3_bucket.logs my-existing-log-bucket\n# Write the matching resource block in .tf\nterraform plan  # should show no changes if config matches\n```\n\n### State surgery with `state mv`\n\nWhen you rename a resource or move it into a module, Terraform sees\nit as \"destroy old, create new\" unless you update state:\n\n```bash\nterraform state mv aws_instance.web module.web.aws_instance.this\nterraform state mv aws_instance.old aws_instance.new\n```\n\nPrefer a `moved` block in config when possible — it is checked into\nversion control and replayed automatically:\n\n```hcl\nmoved {\n  from = aws_instance.old\n  to   = aws_instance.new\n}\n```\n\n### Anti-patterns\n\n- **Hardcoded secrets in `.tf` files** — use env vars, `-var`, or a\n  secrets manager data source\n- **Unpinned providers or modules** — `version = \"~> 5.0\"` minimum;\n  prefer exact pins in production\n- **Blind `terraform apply` without a saved plan** — apply the plan\n  you reviewed, not a fresh one\n- **`terraform state rm` to \"fix\" drift** — you are lying to\n  Terraform about what exists; reach for `import` or `moved` instead\n- **`-target` as normal workflow** — it bypasses graph analysis and\n  produces partial applies\n- **Committing `terraform.tfstate`** — remote backend only; local\n  state is a collaboration hazard\n- **Monolithic root module** — split by lifecycle (network rarely\n  changes, app changes daily); separate state per lifecycle\n- **Destroy\u002Frecreate when a `moved` block would do** — destructive\n  changes should be explicit, not accidental\n",{"name":5,"metadata":49,"description":56},{"processkit":50},{"id":51,"created":52,"version":53,"category":54,"apiVersion":55},"SKILL-terraform-basics",1775433600000,"1.1.0","devops","processkit.projectious.work\u002Fv1","Infrastructure-as-code with Terraform\u002FOpenTofu — resources, state, modules, plan\u002Fapply. Use when writing `.tf` files, managing cloud infrastructure with Terraform or OpenTofu, handling state and backends, or reviewing IaC code.\n","main","4876a92620ee792aac2ac9a1a806322d8a572367","archive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.18.2\u002Fcontext\u002Fskills\u002Fdevops\u002Fterraform-basics","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":65,"prompt":75,"zipAvailable":76},[66,69,72],{"tool":67,"command":68},"npx","npx skills add projectious-work\u002Fprocesskit --skill terraform-basics",{"tool":70,"command":71},"bunx","bunx skills add projectious-work\u002Fprocesskit --skill terraform-basics",{"tool":73,"command":74},"pnpm","pnpm dlx skills add projectious-work\u002Fprocesskit --skill terraform-basics","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.18.2\u002Fcontext\u002Fskills\u002Fdevops\u002Fterraform-basics\u002FSKILL.md",true,[],[79,102,122,143,160,178],{"skillNo":80,"name":81,"nameZh":6,"description":82,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":83,"categories":84,"keywords":88,"publishedAt":44},"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",[85],{"categoryNo":86,"categoryName":87,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[89,90,91,92,93,94,39,95,96,97,81,98,34,99,30,100,101],"management","skill management","create","update","package","alpha","list","manage","ontology","get","manifests","skill package","transition",{"skillNo":103,"name":104,"nameZh":6,"description":105,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":106,"categories":107,"keywords":109,"publishedAt":44},"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",[108],{"categoryNo":86,"categoryName":87,"taxonomyType":21,"taxonomyTypeDesc":22},[89,110,111,112,113,114,94,39,115,116,96,117,118,119,98,120,121],"schema","schema management","MCP","workflows","validation","generated","rebuild","contracts","wed","deterministic","contract","mode",{"skillNo":123,"name":124,"nameZh":6,"description":125,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":126,"categories":127,"keywords":128,"publishedAt":44},"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",[],[89,129,130,91,92,131,94,39,132,133,134,135,98,136,137,138,139,140,141,142],"proposition","proposition management","index","log","world","record","query","creation","event","interface","updates","facts","claims","WSJF",{"skillNo":144,"name":145,"nameZh":6,"description":146,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":147,"categories":148,"keywords":149,"publishedAt":44},"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",[],[89,97,150,91,94,151,152,115,153,132,96,154,155,98,156,157,137,158,30,159],"ontology management","lifecycle","archive","roadmap","do","domain","iteration","keep","measurement","generic",{"skillNo":161,"name":162,"nameZh":6,"description":163,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":164,"categories":165,"keywords":166,"publishedAt":44},"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",[],[167,168,169,170,94,171,172,173,39,174,175,176,177],"okf","compatibility","okf compatibility","validate","open","knowledge","format","export","bundles","bundle","import",{"skillNo":179,"name":180,"nameZh":6,"description":181,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":182,"categories":183,"keywords":184,"publishedAt":44},"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",[],[89,185,186,91,92,131,94,151,39,95,132,187,96,134,98,157,137,138,188,101],"capability","capability management","queries","changes"]