devskill 2.0.6 → 2.0.8

package/skills/import-infrastructure-as-code/SKILL.md

@@ -0,0 +1,367 @@
+---
+name: import-infrastructure-as-code
+description: 'Import existing Azure resources into Terraform using Azure CLI discovery and Azure Verified Modules (AVM). Use when asked to reverse-engineer live Azure infrastructure, generate Infrastructure as Code from existing subscriptions/resource groups/resource IDs, map dependencies, derive exact import addresses from downloaded module source, prevent configuration drift, and produce AVM-based Terraform files ready for validation and planning across any Azure resource type.'
+---
+
+# Import Infrastructure as Code (Azure -> Terraform with AVM)
+
+Convert existing Azure infrastructure into maintainable Terraform code using discovery data and Azure Verified Modules.
+
+## When to Use This Skill
+
+Use this skill when the user asks to:
+
+- Import existing Azure resources into Terraform
+- Generate IaC from live Azure environments
+- Handle any Azure resource type supported by AVM (and document justified non-AVM fallbacks)
+- Recreate infrastructure from a subscription or resource group
+- Map dependencies between discovered Azure resources
+- Use AVM modules instead of handwritten `azurerm_*` resources
+
+## Prerequisites
+
+- Azure CLI installed and authenticated (`az login`)
+- Access to the target subscription or resource group
+- Terraform CLI installed
+- Network access to Terraform Registry and AVM index sources
+
+## Inputs
+
+| Parameter | Required | Default | Description |
+|---|---|---|---|
+| `subscription-id` | No | Active CLI context | Azure subscription used for subscription-scope discovery and context setting |
+| `resource-group-name` | No | None | Azure resource group used for resource-group-scope discovery |
+| `resource-id` | No | None | One or more Azure ARM resource IDs used for specific-resource-scope discovery |
+
+At least one of `subscription-id`, `resource-group-name`, or `resource-id` is required.
+
+## Step-by-Step Workflows
+
+### 1) Collect Required Scope (Mandatory)
+
+Request one of these scopes before running discovery commands:
+
+- Subscription scope: `<subscription-id>`
+- Resource group scope: `<resource-group-name>`
+- Specific resources scope: one or more `<resource-id>` values
+
+Scope handling rules:
+
+- Treat Azure ARM resource IDs (for example `/subscriptions/.../providers/...`) as cloud resource identifiers, not local file system paths.
+- Use resource IDs only with Azure CLI `--ids` arguments (for example `az resource show --ids <resource-id>`).
+- Never pass resource IDs to file-reading commands (`cat`, `ls`, `read_file`, glob searches) unless the user explicitly says they are local file paths.
+- If the user already provided one valid scope, do not ask for additional scope inputs unless required by a failing command.
+- Do not ask follow-up questions that can be answered from already-provided scope values.
+
+If scope is missing, ask for it explicitly and stop.
+
+### 2) Authenticate and Set Context
+
+Run only the commands required for the selected scope.
+
+For subscription scope:
+
+```bash
+az login
+az account set --subscription <subscription-id>
+az account show --query "{subscriptionId:id, name:name, tenantId:tenantId}" -o json
+```
+
+Expected output: JSON object with `subscriptionId`, `name`, and `tenantId`.
+
+For resource group or specific resource scope, `az login` is still required but `az account set` is optional if the active context is already correct.
+
+When using specific resource scope, prefer direct `--ids`-based commands first and avoid extra discovery prompts for subscription or resource group unless needed for a concrete command.
+
+### 3) Run Discovery Commands
+
+Discover resources using the selected scopes. Ensure to fetch all necessary information for accurate Terraform generation.
+
+```bash
+# Subscription scope
+az resource list --subscription <subscription-id> -o json
+
+# Resource group scope
+az resource list --resource-group <resource-group-name> -o json
+
+# Specific resource scope
+az resource show --ids <resource-id-1> <resource-id-2> ... -o json
+```
+
+Expected output: JSON object or array containing Azure resource metadata (`id`, `type`, `name`, `location`, `tags`, `properties`).
+
+### 4) Resolve Dependencies Before Code Generation
+
+Parse exported JSON and map:
+
+- Parent-child relationships (for example: NIC -> Subnet -> VNet)
+- Cross-resource references in `properties`
+- Ordering for Terraform creation
+
+IMPORTANT: Generate the following documentation and save it to a docs folder in the root of the project.
+- `exported-resources.json` with all discovered resources and their metadata, including dependencies and references.
+- `EXPORTED-ARCHITECTURE.MD` file with a human-readable architecture overview based on the discovered resources and their relationships.
+
+### 5) Select Azure Verified Modules (Required)
+
+Use the latest AVM version for each resource type.
+
+### Terraform Registry
+
+- Search for "avm" + resource name
+- Filter by "Partner" tag to find official AVM modules
+- Example: Search "avm storage account" → filter by Partner
+
+### Official AVM Index
+
+> **Note:** The following links always point to the latest version of the CSV files on the main branch. As intended, this means the files may change over time. If you require a point-in-time version, consider using a specific release tag in the URL.
+
+- **Terraform Resource Modules**: `https://raw.githubusercontent.com/Azure/Azure-Verified-Modules/refs/heads/main/docs/static/module-indexes/TerraformResourceModules.csv`
+- **Terraform Pattern Modules**: `https://raw.githubusercontent.com/Azure/Azure-Verified-Modules/refs/heads/main/docs/static/module-indexes/TerraformPatternModules.csv`
+- **Terraform Utility Modules**: `https://raw.githubusercontent.com/Azure/Azure-Verified-Modules/refs/heads/main/docs/static/module-indexes/TerraformUtilityModules.csv`
+
+### Individual Module information
+
+Use the `web` tool or another suitable MCP method to get module information if not available locally in the `.terraform` folder.
+
+Use AVM sources:
+
+- Registry: `https://registry.terraform.io/modules/Azure/<module>/azurerm/latest`
+- GitHub: `https://github.com/Azure/terraform-azurerm-avm-res-<service>-<resource>`
+
+Prefer AVM modules over handwritten `azurerm_*` resources when an AVM module exists.
+
+When fetching module information from GitHub repositories, the README.md file in the root of the repository typically contains all detailed information about the module, for example: https://raw.githubusercontent.com/Azure/terraform-azurerm-avm-res-<service>-<resource>/refs/heads/main/README.md
+
+### 5a) Read the Module README Before Writing Any Code (Mandatory)
+
+**This step is not optional.** Before writing a single line of HCL for a module, fetch and
+read the full README for that module. Do not rely on knowledge of the raw `azurerm` provider
+or prior experience with other AVM modules.
+
+For each selected AVM module, fetch its README:
+
+```text
+https://raw.githubusercontent.com/Azure/terraform-azurerm-avm-res-<service>-<resource>/refs/heads/main/README.md
+```
+
+Or if the module is already downloaded after `terraform init`:
+
+```bash
+cat .terraform/modules/<module_key>/README.md
+```
+
+From the README, extract and record **before writing code**:
+
+1. **Required Inputs** — every input the module requires. Any child resource listed here
+	 (NICs, extensions, subnets, public IPs) is managed **inside** the module. Do **not**
+	 create standalone module blocks for those resources.
+2. **Optional Inputs** — the exact Terraform variable names and their declared `type`.
+	 Do not assume they match the raw `azurerm` provider argument names or block shapes.
+3. **Usage examples** — check what resource group identifier is used (`parent_id` vs
+	 `resource_group_name`), how child resources are expressed (inline map vs separate module),
+	 and what syntax each input expects.
+
+#### Apply module rules as patterns, not assumptions
+
+Use the lessons below as examples of the *type* of mismatch that often causes imports to fail.
+Do not assume these exact names apply to every AVM module. Always verify each selected module's
+README and `variables.tf`.
+
+**`avm-res-compute-virtualmachine` (any version)**
+
+- `network_interfaces` is a **Required Input**. NICs are owned by the VM module. Never
+	create standalone `avm-res-network-networkinterface` modules alongside a VM module —
+	define every NIC inline under `network_interfaces`.
+- TrustedLaunch is expressed through the top-level booleans `secure_boot_enabled = true`
+	and `vtpm_enabled = true`. The `security_type` argument exists only under `os_disk` for
+	Confidential VM disk encryption and must not be used for TrustedLaunch.
+- `boot_diagnostics` is a `bool`, not an object. Use `boot_diagnostics = true`; use the
+	separate `boot_diagnostics_storage_account_uri` variable if a storage URI is needed.
+- Extensions are managed inside the module via the `extensions` map. Do not create
+	standalone extension resources.
+
+**`avm-res-network-virtualnetwork` (any version)**
+
+- This module is backed by the AzAPI provider, not `azurerm`. Use `parent_id` (the full
+	resource group resource ID string) to specify the resource group, not `resource_group_name`.
+- Every example in the README shows `parent_id`; none show `resource_group_name`.
+
+Generalized takeaway for all AVM modules:
+
+- Determine child resource ownership from **Required Inputs** before creating sibling modules.
+- Determine accepted variable names and types from **Optional Inputs** and `variables.tf`.
+- Determine identifier style and input shape from README usage examples.
+- Do not infer argument names from raw `azurerm_*` resources.
+
+### 6) Generate Terraform Files
+
+### Before Writing Import Blocks — Inspect Module Source (Mandatory)
+
+After `terraform init` downloads the modules, inspect each module's source files to determine
+the exact Terraform resource addresses before writing any `import {}` blocks. Never write
+import addresses from memory.
+
+#### Step A — Identify the provider and resource label
+
+```bash
+grep "^resource" .terraform/modules/<module_key>/main*.tf
+```
+
+This reveals whether the module uses `azurerm_*` or `azapi_resource` labels. For example,
+`avm-res-network-virtualnetwork` exposes `azapi_resource "vnet"`, not
+`azurerm_virtual_network "this"`.
+
+#### Step B — Identify child modules and nested paths
+
+```bash
+grep "^module" .terraform/modules/<module_key>/main*.tf
+```
+
+If child resources are managed in a sub-module (subnets, extensions, etc.), the import
+address must include every intermediate module label:
+
+```text
+module.<root_module_key>.module.<child_module_key>["<map_key>"].<resource_type>.<label>[<index>]
+```
+
+#### Step C — Check for `count` vs `for_each`
+
+```bash
+grep -n "count\|for_each" .terraform/modules/<module_key>/main*.tf
+```
+
+Any resource using `count` requires an index in the import address. When `count = 1` (e.g.,
+conditional Linux vs Windows selection), the address must end with `[0]`. Resources using
+`for_each` use string keys, not numeric indexes.
+
+#### Known import address patterns (examples from lessons learned)
+
+These are examples only. Use them as templates for reasoning, then derive the exact addresses
+from the downloaded source code for the modules in your current import.
+
+| Resource | Correct import `to` address pattern |
+|---|---|
+| AzAPI-backed VNet | `module.<vnet_key>.azapi_resource.vnet` |
+| Subnet (nested, count-based) | `module.<vnet_key>.module.subnet["<subnet_name>"].azapi_resource.subnet[0]` |
+| Linux VM (count-based) | `module.<vm_key>.azurerm_linux_virtual_machine.this[0]` |
+| VM NIC | `module.<vm_key>.azurerm_network_interface.virtualmachine_network_interfaces["<nic_key>"]` |
+| VM extension (default deploy_sequence=5) | `module.<vm_key>.module.extension["<ext_name>"].azurerm_virtual_machine_extension.this` |
+| VM extension (deploy_sequence=1–4) | `module.<vm_key>.module.extension_<n>["<ext_name>"].azurerm_virtual_machine_extension.this` |
+| NSG-NIC association | `module.<vm_key>.azurerm_network_interface_security_group_association.this["<nic_key>-<nsg_key>"]` |
+
+Produce:
+
+- `providers.tf` with `azurerm` provider and required version constraints
+- `main.tf` with AVM module blocks and explicit dependencies
+- `variables.tf` for environment-specific values
+- `outputs.tf` for key IDs and endpoints
+- `terraform.tfvars.example` with placeholder values
+
+### Diff Live Properties Against Module Defaults (Mandatory)
+
+After writing the initial configuration, compare every non-zero property of each discovered
+live resource against the default value declared in the corresponding AVM module's
+`variables.tf`. Any property where the live value differs from the module default must be
+set explicitly in the Terraform configuration.
+
+Pay particular attention to the following property categories, which are common sources
+of silent configuration drift:
+
+- **Timeout values** (e.g., Public IP `idle_timeout_in_minutes` defaults to `4`; live
+	deployments often use `30`)
+- **Network policy flags** (e.g., subnet `private_endpoint_network_policies` defaults to
+	`"Enabled"`; existing subnets often have `"Disabled"`)
+- **SKU and allocation** (e.g., Public IP `sku`, `allocation_method`)
+- **Availability zones** (e.g., VM zone, Public IP zone)
+- **Redundancy and replication** settings on storage and database resources
+
+Retrieve full live properties with explicit `az` commands, for example:
+
+```bash
+az network public-ip show --ids <resource_id> --query "{idleTimeout:idleTimeoutInMinutes, sku:sku.name, zones:zones}" -o json
+az network vnet subnet show --ids <resource_id> --query "{privateEndpointPolicies:privateEndpointNetworkPolicies, delegation:delegations}" -o json
+```
+
+Do not rely solely on `az resource list` output, which may omit nested or computed properties.
+
+Pin module versions explicitly:
+
+```hcl
+module "example" {
+	source  = "Azure/<module>/azurerm"
+	version = "<latest-compatible-version>"
+}
+```
+
+### 7) Validate Generated Code
+
+Run:
+
+```bash
+terraform init
+terraform fmt -recursive
+terraform validate
+terraform plan
+```
+
+Expected output: no syntax errors, no validation errors, and a plan that matches discovered infrastructure intent.
+
+## Troubleshooting
+
+| Problem | Likely Cause | Action |
+|---|---|---|
+| `az` command fails with authorization errors | Wrong tenant/subscription or missing RBAC role | Re-run `az login`, verify subscription context, confirm required permissions |
+| Discovery output is empty | Incorrect scope or no resources in scope | Re-check scope input and run scoped list/show command again |
+| No AVM module found for a resource type | Resource type not yet covered by AVM | Use native `azurerm_*` resource for that type and document the gap |
+| `terraform validate` fails | Missing variables or unresolved dependencies | Add required variables and explicit dependencies, then re-run validation |
+| Unknown argument or variable not found in module | AVM variable name differs from `azurerm` provider argument name | Read the module README `variables.tf` or Optional Inputs section for the correct name |
+| Import block fails — resource not found at address | Wrong provider label (`azurerm_` vs `azapi_`), missing sub-module path, or missing `[0]` index | Run `grep "^resource" .terraform/modules/<key>/main*.tf` and `grep "^module"` to find exact address |
+| `terraform plan` shows unexpected `~ update` on imported resource | Live value differs from AVM module default | Fetch live property with `az <resource> show`, compare to module default, add explicit value |
+| Child-resource module gives "provider configuration not present" | Child resources declared as standalone modules even though parent module owns them | Check Required Inputs in README, remove incorrect standalone modules, and model child resources using the parent module's documented input structure |
+| Nested child resource import fails with "resource not found" | Missing intermediate module path, wrong map key, or missing index | Inspect module blocks and `count`/`for_each` in source; build full nested import address including all module segments and required key/index |
+| Tool tries to read ARM resource ID as file path or asks repeated scope questions | Resource ID not treated as `--ids` input, or agent did not trust already-provided scope | Treat ARM IDs strictly as cloud identifiers, use `az ... --ids ...`, and stop re-prompting once one valid scope is present |
+
+## Response Contract
+
+When returning results, provide:
+
+1. Scope used (subscription, resource group, or resource IDs)
+2. Discovery files created
+3. Resource types detected
+4. AVM modules selected with versions
+5. Terraform files generated or updated
+6. Validation command results
+7. Open gaps requiring user input (if any)
+
+## Execution Rules for the Agent
+
+- Do not continue if scope is missing.
+- Do not claim successful import without listing discovered files and validation output.
+- Do not skip dependency mapping before generating Terraform.
+- Prefer AVM modules first; justify each non-AVM fallback explicitly.
+- **Read the README for every AVM module before writing code.** Required Inputs identify
+	which child resources the module owns. Optional Inputs document exact variable names and
+	types. Usage examples show provider-specific conventions (`parent_id` vs
+	`resource_group_name`). Skipping the README is the single most common cause of
+	code errors in AVM-based imports.
+- **Never assume NIC, extension, or public IP resources are standalone.** For
+	any AVM module, treat child resources as parent-owned unless the README explicitly indicates
+	a separate module is required. Check Required Inputs before creating sibling modules.
+- **Never write import addresses from memory.** After `terraform init`, grep the downloaded
+	module source to discover the actual provider (`azurerm` vs `azapi`), resource labels,
+	sub-module nesting, and `count` vs `for_each` usage before writing any `import {}` block.
+- **Never treat ARM resource IDs as file paths.** Resource IDs belong in Azure CLI `--ids`
+	arguments and API queries, not file IO tools. Only read local files when a real workspace
+	path is provided.
+- **Minimize prompts when scope is already known.** If subscription, resource group, or
+	specific resource IDs are already provided, proceed with commands directly and only ask a
+	follow-up when a command fails due to missing required context.
+- **Do not declare the import complete until `terraform plan` shows 0 destroys and 0
+	unwanted changes.** Telemetry `+ create` resources are acceptable. Any `~ update` or
+	`- destroy` on real infrastructure resources must be resolved.
+
+## References
+
+- [Azure Verified Modules index (Terraform)](https://github.com/Azure/Azure-Verified-Modules/tree/main/docs/static/module-indexes)
+- [Terraform AVM Registry namespace](https://registry.terraform.io/namespaces/Azure)

package/skills/import-infrastructure-as-code/SYNC.md

@@ -0,0 +1,5 @@
+# Sync Info
+
+- **Source:** `vendor/awesome-copilot/skills/import-infrastructure-as-code`
+- **Git SHA:** `23fb7006c132a0bba75b0e5af7a35cab11272812`
+- **Synced:** 2026-03-24

package/skills/internal-comms/LICENSE.txt

@@ -0,0 +1,202 @@
+
+                                 Apache License
+                           Version 2.0, January 2004
+                        http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+      "License" shall mean the terms and conditions for use, reproduction,
+      and distribution as defined by Sections 1 through 9 of this document.
+
+      "Licensor" shall mean the copyright owner or entity authorized by
+      the copyright owner that is granting the License.
+
+      "Legal Entity" shall mean the union of the acting entity and all
+      other entities that control, are controlled by, or are under common
+      control with that entity. For the purposes of this definition,
+      "control" means (i) the power, direct or indirect, to cause the
+      direction or management of such entity, whether by contract or
+      otherwise, or (ii) ownership of fifty percent (50%) or more of the
+      outstanding shares, or (iii) beneficial ownership of such entity.
+
+      "You" (or "Your") shall mean an individual or Legal Entity
+      exercising permissions granted by this License.
+
+      "Source" form shall mean the preferred form for making modifications,
+      including but not limited to software source code, documentation
+      source, and configuration files.
+
+      "Object" form shall mean any form resulting from mechanical
+      transformation or translation of a Source form, including but
+      not limited to compiled object code, generated documentation,
+      and conversions to other media types.
+
+      "Work" shall mean the work of authorship, whether in Source or
+      Object form, made available under the License, as indicated by a
+      copyright notice that is included in or attached to the work
+      (an example is provided in the Appendix below).
+
+      "Derivative Works" shall mean any work, whether in Source or Object
+      form, that is based on (or derived from) the Work and for which the
+      editorial revisions, annotations, elaborations, or other modifications
+      represent, as a whole, an original work of authorship. For the purposes
+      of this License, Derivative Works shall not include works that remain
+      separable from, or merely link (or bind by name) to the interfaces of,
+      the Work and Derivative Works thereof.
+
+      "Contribution" shall mean any work of authorship, including
+      the original version of the Work and any modifications or additions
+      to that Work or Derivative Works thereof, that is intentionally
+      submitted to Licensor for inclusion in the Work by the copyright owner
+      or by an individual or Legal Entity authorized to submit on behalf of
+      the copyright owner. For the purposes of this definition, "submitted"
+      means any form of electronic, verbal, or written communication sent
+      to the Licensor or its representatives, including but not limited to
+      communication on electronic mailing lists, source code control systems,
+      and issue tracking systems that are managed by, or on behalf of, the
+      Licensor for the purpose of discussing and improving the Work, but
+      excluding communication that is conspicuously marked or otherwise
+      designated in writing by the copyright owner as "Not a Contribution."
+
+      "Contributor" shall mean Licensor and any individual or Legal Entity
+      on behalf of whom a Contribution has been received by Licensor and
+      subsequently incorporated within the Work.
+
+   2. Grant of Copyright License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      copyright license to reproduce, prepare Derivative Works of,
+      publicly display, publicly perform, sublicense, and distribute the
+      Work and such Derivative Works in Source or Object form.
+
+   3. Grant of Patent License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      (except as stated in this section) patent license to make, have made,
+      use, offer to sell, sell, import, and otherwise transfer the Work,
+      where such license applies only to those patent claims licensable
+      by such Contributor that are necessarily infringed by their
+      Contribution(s) alone or by combination of their Contribution(s)
+      with the Work to which such Contribution(s) was submitted. If You
+      institute patent litigation against any entity (including a
+      cross-claim or counterclaim in a lawsuit) alleging that the Work
+      or a Contribution incorporated within the Work constitutes direct
+      or contributory patent infringement, then any patent licenses
+      granted to You under this License for that Work shall terminate
+      as of the date such litigation is filed.
+
+   4. Redistribution. You may reproduce and distribute copies of the
+      Work or Derivative Works thereof in any medium, with or without
+      modifications, and in Source or Object form, provided that You
+      meet the following conditions:
+
+      (a) You must give any other recipients of the Work or
+          Derivative Works a copy of this License; and
+
+      (b) You must cause any modified files to carry prominent notices
+          stating that You changed the files; and
+
+      (c) You must retain, in the Source form of any Derivative Works
+          that You distribute, all copyright, patent, trademark, and
+          attribution notices from the Source form of the Work,
+          excluding those notices that do not pertain to any part of
+          the Derivative Works; and
+
+      (d) If the Work includes a "NOTICE" text file as part of its
+          distribution, then any Derivative Works that You distribute must
+          include a readable copy of the attribution notices contained
+          within such NOTICE file, excluding those notices that do not
+          pertain to any part of the Derivative Works, in at least one
+          of the following places: within a NOTICE text file distributed
+          as part of the Derivative Works; within the Source form or
+          documentation, if provided along with the Derivative Works; or,
+          within a display generated by the Derivative Works, if and
+          wherever such third-party notices normally appear. The contents
+          of the NOTICE file are for informational purposes only and
+          do not modify the License. You may add Your own attribution
+          notices within Derivative Works that You distribute, alongside
+          or as an addendum to the NOTICE text from the Work, provided
+          that such additional attribution notices cannot be construed
+          as modifying the License.
+
+      You may add Your own copyright statement to Your modifications and
+      may provide additional or different license terms and conditions
+      for use, reproduction, or distribution of Your modifications, or
+      for any such Derivative Works as a whole, provided Your use,
+      reproduction, and distribution of the Work otherwise complies with
+      the conditions stated in this License.
+
+   5. Submission of Contributions. Unless You explicitly state otherwise,
+      any Contribution intentionally submitted for inclusion in the Work
+      by You to the Licensor shall be under the terms and conditions of
+      this License, without any additional terms or conditions.
+      Notwithstanding the above, nothing herein shall supersede or modify
+      the terms of any separate license agreement you may have executed
+      with Licensor regarding such Contributions.
+
+   6. Trademarks. This License does not grant permission to use the trade
+      names, trademarks, service marks, or product names of the Licensor,
+      except as required for reasonable and customary use in describing the
+      origin of the Work and reproducing the content of the NOTICE file.
+
+   7. Disclaimer of Warranty. Unless required by applicable law or
+      agreed to in writing, Licensor provides the Work (and each
+      Contributor provides its Contributions) on an "AS IS" BASIS,
+      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+      implied, including, without limitation, any warranties or conditions
+      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+      PARTICULAR PURPOSE. You are solely responsible for determining the
+      appropriateness of using or redistributing the Work and assume any
+      risks associated with Your exercise of permissions under this License.
+
+   8. Limitation of Liability. In no event and under no legal theory,
+      whether in tort (including negligence), contract, or otherwise,
+      unless required by applicable law (such as deliberate and grossly
+      negligent acts) or agreed to in writing, shall any Contributor be
+      liable to You for damages, including any direct, indirect, special,
+      incidental, or consequential damages of any character arising as a
+      result of this License or out of the use or inability to use the
+      Work (including but not limited to damages for loss of goodwill,
+      work stoppage, computer failure or malfunction, or any and all
+      other commercial damages or losses), even if such Contributor
+      has been advised of the possibility of such damages.
+
+   9. Accepting Warranty or Additional Liability. While redistributing
+      the Work or Derivative Works thereof, You may choose to offer,
+      and charge a fee for, acceptance of support, warranty, indemnity,
+      or other liability obligations and/or rights consistent with this
+      License. However, in accepting such obligations, You may act only
+      on Your own behalf and on Your sole responsibility, not on behalf
+      of any other Contributor, and only if You agree to indemnify,
+      defend, and hold each Contributor harmless for any liability
+      incurred by, or claims asserted against, such Contributor by reason
+      of your accepting any such warranty or additional liability.
+
+   END OF TERMS AND CONDITIONS
+
+   APPENDIX: How to apply the Apache License to your work.
+
+      To apply the Apache License to your work, attach the following
+      boilerplate notice, with the fields enclosed by brackets "[]"
+      replaced with your own identifying information. (Don't include
+      the brackets!)  The text should be enclosed in the appropriate
+      comment syntax for the file format. We also recommend that a
+      file or class name and description of purpose be included on the
+      same "printed page" as the copyright notice for easier
+      identification within third-party archives.
+
+   Copyright [yyyy] [name of copyright owner]
+
+   Licensed under the Apache License, Version 2.0 (the "License");
+   you may not use this file except in compliance with the License.
+   You may obtain a copy of the License at
+
+       http://www.apache.org/licenses/LICENSE-2.0
+
+   Unless required by applicable law or agreed to in writing, software
+   distributed under the License is distributed on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+   See the License for the specific language governing permissions and
+   limitations under the License.

package/skills/internal-comms/SKILL.md

@@ -0,0 +1,32 @@
+---
+name: internal-comms
+description: A set of resources to help me write all kinds of internal communications, using the formats that my company likes to use. Claude should use this skill whenever asked to write some sort of internal communications (status reports, leadership updates, 3P updates, company newsletters, FAQs, incident reports, project updates, etc.).
+license: Complete terms in LICENSE.txt
+---
+
+## When to use this skill
+To write internal communications, use this skill for:
+- 3P updates (Progress, Plans, Problems)
+- Company newsletters
+- FAQ responses
+- Status reports
+- Leadership updates
+- Project updates
+- Incident reports
+
+## How to use this skill
+
+To write any internal communication:
+
+1. **Identify the communication type** from the request
+2. **Load the appropriate guideline file** from the `examples/` directory:
+    - `examples/3p-updates.md` - For Progress/Plans/Problems team updates
+    - `examples/company-newsletter.md` - For company-wide newsletters
+    - `examples/faq-answers.md` - For answering frequently asked questions
+    - `examples/general-comms.md` - For anything else that doesn't explicitly match one of the above
+3. **Follow the specific instructions** in that file for formatting, tone, and content gathering
+
+If the communication type doesn't match any existing guideline, ask for clarification or more context about the desired format.
+
+## Keywords
+3P updates, company newsletter, company comms, weekly update, faqs, common questions, updates, internal comms

package/skills/internal-comms/SYNC.md

@@ -0,0 +1,5 @@
+# Sync Info
+
+- **Source:** `vendor/anthropics/skills/internal-comms`
+- **Git SHA:** `887114fd09f8f24a7e6c907f9ee505348498ab6a`
+- **Synced:** 2026-03-24

package/skills/internal-comms/examples/3p-updates.md

@@ -0,0 +1,47 @@
+## Instructions
+You are being asked to write a 3P update. 3P updates stand for "Progress, Plans, Problems." The main audience is for executives, leadership, other teammates, etc. They're meant to be very succinct and to-the-point: think something you can read in 30-60sec or less. They're also for people with some, but not a lot of context on what the team does.
+
+3Ps can cover a team of any size, ranging all the way up to the entire company. The bigger the team, the less granular the tasks should be. For example, "mobile team" might have "shipped feature" or "fixed bugs," whereas the company might have really meaty 3Ps, like "hired 20 new people" or "closed 10 new deals." 
+
+They represent the work of the team across a time period, almost always one week. They include three sections:
+1) Progress: what the team has accomplished over the next time period. Focus mainly on things shipped, milestones achieved, tasks created, etc.
+2) Plans: what the team plans to do over the next time period. Focus on what things are top-of-mind, really high priority, etc. for the team.
+3) Problems: anything that is slowing the team down. This could be things like too few people, bugs or blockers that are preventing the team from moving forward, some deal that fell through, etc.
+
+Before writing them, make sure that you know the team name. If it's not specified, you can ask explicitly what the team name you're writing for is.
+
+
+## Tools Available
+Whenever possible, try to pull from available sources to get the information you need:
+- Slack: posts from team members with their updates - ideally look for posts in large channels with lots of reactions
+- Google Drive: docs written from critical team members with lots of views
+- Email: emails with lots of responses of lots of content that seems relevant
+- Calendar: non-recurring meetings that have a lot of importance, like product reviews, etc.
+
+
+Try to gather as much context as you can, focusing on the things that covered the time period you're writing for:
+- Progress: anything between a week ago and today
+- Plans: anything from today to the next week
+- Problems: anything between a week ago and today
+
+
+If you don't have access, you can ask the user for things they want to cover. They might also include these things to you directly, in which case you're mostly just formatting for this particular format.
+
+## Workflow
+
+1. **Clarify scope**: Confirm the team name and time period (usually past week for Progress/Problems, next
+week for Plans)
+2. **Gather information**: Use available tools or ask the user directly
+3. **Draft the update**: Follow the strict formatting guidelines
+4. **Review**: Ensure it's concise (30-60 seconds to read) and data-driven
+
+## Formatting
+
+The format is always the same, very strict formatting. Never use any formatting other than this. Pick an emoji that is fun and captures the vibe of the team and update.
+
+[pick an emoji] [Team Name] (Dates Covered, usually a week)
+Progress: [1-3 sentences of content]
+Plans: [1-3 sentences of content]
+Problems: [1-3 sentences of content]
+
+Each section should be no more than 1-3 sentences: clear, to the point. It should be data-driven, and generally include metrics where possible. The tone should be very matter-of-fact, not super prose-heavy.