skilldrop-cli 0.16.3__py3-none-any.whl

skilldrop_cli/data/packs/grc/skills/soc2-evidence-map/examples/northwind-type2-security.md

@@ -0,0 +1,127 @@
+# Worked example: Northwind Analytics, first SOC 2 Type II (Security)
+
+A fictional 60-person SaaS company. The input is what its Head of Security might send; the
+output is the summary and the CSV, shortened where rows repeat a pattern.
+
+## Input given to the skill
+
+> We're Northwind Analytics. A big customer wants a SOC 2 Type II, Security only, and our
+> auditor has proposed a six-month period, 1 January to 30 June 2027. We don't have a formal
+> controls list. What we do today:
+> - Okta SSO with MFA for everyone. Access is requested by Jira ticket with manager approval
+>   and granted through role-based Okta groups (Dev Rao, IT Lead).
+> - BambooHR terminations deactivate Okta automatically, within the day.
+> - Background checks through Certn before start, KnowBe4 training within 30 days (Ola
+>   Brandt, People Ops).
+> - Laptops in Kandji with FileVault and malware protection. Four contractors use their own
+>   laptops.
+> - Snyk scans weekly; criticals fixed in 14 days, highs in 30 (Rui Costa, Platform Lead).
+> - Datadog security alerts page the PagerDuty on-call.
+> - All deploys go through GitHub PRs with one approval and CI, but two admins can bypass
+>   branch protection (Kim Novak, VP Engineering).
+> - RDS daily backups. Never tested a restore.
+> - We wrote security policies in 2025, CEO approved them. Nobody has acknowledged them.
+> - Incident response plan exists, never tested. We have a vendor list in Vanta.
+> - Engineering managers "look at" AWS and GitHub admin access now and then.
+> - We're on AWS; no production data in the office.
+> I'm Sam Ito, Head of Security.
+
+No question was needed: scope, type, period, systems and most owners were given.
+
+---
+
+## Scope
+
+SOC 2 Type II, Security (common criteria CC1–CC9), Northwind Analytics production platform,
+period 1 January 2027 to 30 June 2027. AWS is treated as a carved-out subservice
+organisation `[assumption: confirm with the auditor]`.
+
+> Prepared for Northwind's compliance lead and auditor to review; not audit advice. The
+> auditor decides what evidence is sufficient.
+
+## Coverage by criterion
+
+| Criteria | Controls | Status |
+|---|---|---|
+| CC1.1, CC5.3 | GOV-01 policy approval and acknowledgement | partial |
+| CC1.4 | HR-01 background checks and training | in place |
+| CC1.2, CC1.3, CC1.5 | none | **gap**: GOV-02, GOV-03 proposed |
+| CC2.1, CC2.2, CC2.3 | none (GOV-01 covers part of CC2.2) | **gap**: COM-01 proposed |
+| CC3.1–CC3.4, CC5.1 | RISK-01 risk assessment | **gap**: RISK-01 not yet run |
+| CC4.1, CC4.2 | none | **gap**: MON-02 proposed |
+| CC5.2 | none mapped yet | **gap**: map once technology controls are confirmed |
+| CC6.1 | AC-04 SSO with MFA | in place |
+| CC6.2 | AC-01 joiners, AC-02 leavers | in place |
+| CC6.3 | AC-01 role groups; AC-03 access review | partial (AC-03 is a gap) |
+| CC6.4 | AWS (carved out); office holds no production data | subservice `[to confirm]` |
+| CC6.5, CC6.6, CC6.7 | none | **gap**: EP-02, NET-01, ENC-01 proposed |
+| CC6.8 | EP-01 managed laptops | partial |
+| CC7.1 | VM-01 vulnerability scanning | in place |
+| CC7.2 | MON-01 alert routing | in place |
+| CC7.3, CC7.4 | IR-01 incident response | partial |
+| CC7.5 | IR-01; BC-01 restore tests | partial |
+| CC8.1 | CHG-01 pull request review | partial |
+| CC9.1 | none | **gap**: BC-02 proposed |
+| CC9.2 | VEN-01 vendor reviews | partial |
+
+## Evidence map (selected rows; full set in the CSV)
+
+| Control | Criteria | Type II population (source) | Per-sample record | System | Owner | Frequency | Status |
+|---|---|---|---|---|---|---|---|
+| AC-02 IT removes all access within 24 hours of termination, triggered from BambooHR | CC6.2 | All terminations in the period (BambooHR report) | Okta deactivation timestamp within 24 hours of termination date | BambooHR; Okta | IT Lead (Dev Rao) | per event | in place |
+| AC-03 Engineering managers review AWS and GitHub admin access quarterly; removals ticketed | CC6.3 | The two quarterly reviews in the period (Jira) | Signed-off access list and a ticket per removal | Jira; AWS IAM Identity Center; GitHub | VP Engineering (Kim Novak) | quarterly | **gap** |
+| CHG-01 Production deploys only via PR with a non-author approval and passing CI | CC8.1 | All production deployments (GitHub Actions) | PR with non-author approval and green checks | GitHub | VP Engineering (Kim Novak) | per event | partial |
+| EP-01 All laptops managed in Kandji with encryption and malware protection | CC6.8 | Device compliance reports for the period | Sampled devices encrypted and protected | Kandji | IT Lead (Dev Rao) `[to confirm]` | continuous | partial |
+| BC-01 Daily RDS backups; restore tested every six months | CC7.5 | Restore tests in the period (Jira) | Restore record with date and outcome | AWS RDS; Jira | Platform Lead (Rui Costa) `[to confirm]` | semi-annually | proposed |
+
+For a **Type I** on the same scope, the CHG-01 evidence would be the branch protection
+settings export dated on the report date plus one merged PR, with no population. Here the
+auditor will sample deployments from all six months, so the bypass rights matter for every
+day of the period.
+
+## Gaps, ordered by audit risk
+
+1. **CHG-01 branch protection bypass** (CC8.1). Every bypassed deploy is an exception the
+   auditor finds by sampling. Remove bypass rights, or log and review each bypass, before
+   1 January. *Owner: Kim Novak. Due 2026-11-15.*
+2. **AC-03 no access review record** (CC6.3). Schedule a quarterly review ticket and run the
+   first before the period starts so Q1 and Q2 both have evidence. *Owner: Kim Novak. Due 2026-12-15.*
+3. **RISK-01 no risk assessment** (CC3.1–CC3.4). Run one in January and minute leadership's
+   review. *Owner: Sam Ito. Due 2027-01-31.*
+4. **GOV-01 no acknowledgements** (CC1.1). Run the acknowledgement cycle in December so every
+   person in the population has a date. *Owner: Sam Ito. Due 2026-12-15.*
+5. **EP-01 four unmanaged contractor laptops** (CC6.8). Enrol or replace. *Owner: Dev Rao `[to confirm]`. Due 2026-11-30.*
+6. **IR-01 untested plan, BC-01 untested restore** (CC7.4, CC7.5). Each needs one recorded
+   test inside the period. *Owners: Sam Ito, Rui Costa `[to confirm]`.*
+7. **No control yet** for CC1.2, CC1.3, CC1.5, CC2.x, CC4.x, CC5.2, CC6.5–CC6.7 and CC9.1.
+   Proposed controls are listed below; each needs an owner from Sam Ito.
+
+Proposed controls (`proposed` until Northwind confirms):
+- GOV-02: leadership reviews security posture and open risks quarterly, minuted (CC1.2).
+- GOV-03: security roles and responsibilities documented in the org chart and job descriptions; policy breaches handled under the disciplinary policy (CC1.3, CC1.5).
+- COM-01: security commitments published to customers and in contracts; internal security updates sent quarterly (CC2.1–CC2.3).
+- MON-02: Head of Security reviews control operation quarterly and tracks deficiencies to closure (CC4.1, CC4.2).
+- EP-02: laptops wiped and recorded before disposal or reassignment (CC6.5).
+- NET-01: AWS security groups and WAF rules managed in code and reviewed on change (CC6.6).
+- ENC-01: TLS enforced on all external endpoints; data at rest encrypted with KMS (CC6.7, CC6.1).
+- BC-02: business continuity plan reviewed annually and tested by tabletop (CC9.1).
+
+## Vendor SOC reports to collect
+
+- AWS SOC 2 Type II covering the period, plus a bridge letter if it ends before 30 June 2027.
+- Okta SOC 2 Type II.
+- Complementary user entity controls to state in the system description: customers manage
+  their own users' access and roles in Northwind's product `[to confirm]`.
+
+## CSV
+
+[`northwind-evidence-map.csv`](northwind-evidence-map.csv): 16 rows, one per
+control-criterion pair, in the columns of the template.
+
+---
+
+**Why this is a passing output:** every common criterion is either covered or listed as a
+gap; evidence names the population and source system for Type II; IDs used are only those in
+the reference; owners are the people the user named, owners the skill inferred are marked
+`[to confirm]`, and proposed controls are left for Sam to assign; the mid-period and untested controls are not marked `in place`; and AWS
+is handled as a carve-out with the reports to collect.

skilldrop_cli/data/packs/grc/skills/soc2-evidence-map/manifest.json

@@ -0,0 +1,41 @@
+{
+  "name": "soc2-evidence-map",
+  "version": "0.1.0",
+  "description": "Map an organisation's controls to the SOC 2 Trust Services Criteria in scope (Security always, plus Availability, Confidentiality, Processing Integrity or Privacy if chosen), and for each control list the evidence an auditor will ask for, the system it lives in, the owner, how often it is produced, and the gaps — distinguishing Type I (designed and in place at a date) from Type II (operating over a period, sampled from a full population) — as a table and a CSV the team can work from. Use when the user is preparing for a SOC 2 audit or readiness assessment, says \"SOC 2 evidence\", \"map our controls to the TSC\", \"what will the auditor ask for\", \"SOC 2 gap analysis\".",
+  "entrypoint": "SKILL.md",
+  "deps": {
+    "npm": [],
+    "pip": []
+  },
+  "env": {
+    "required": [],
+    "optional": []
+  },
+  "related": [
+    "ai-usage-policy",
+    "dpia",
+    "nfr-spec",
+    "risk-register",
+    "threat-model"
+  ],
+  "handoff": [
+    {
+      "to": "risk-register",
+      "when": "the company has no risk assessment, which the risk assessment criteria expect",
+      "purpose": "Produce the scored, owned risk register the auditor will ask to see.",
+      "fallback": "If risk-register is absent, list the top risks with likelihood, impact, owner and treatment inline and mark the risk assessment control partial."
+    }
+  ],
+  "tags": [
+    "soc2",
+    "audit",
+    "compliance",
+    "grc",
+    "controls",
+    "evidence"
+  ],
+  "model": {
+    "tier": "standard",
+    "rationale": "Maps controls against a fixed criteria set and a known Type I vs Type II evidence pattern. Judgment is needed on coverage and gap status, but the structure is bounded by the reference."
+  }
+}

skilldrop_cli/data/packs/grc/skills/soc2-evidence-map/reference.md

@@ -0,0 +1,156 @@
+# soc2-evidence-map reference
+
+A drafting aid for SOC 2 preparation, based on the AICPA's 2017 Trust Services Criteria
+(TSC), as revised in 2022 (the revision updated points of focus, not the criteria
+numbering). It is not audit advice; the service auditor decides what is sufficient. Confirm
+wording against the AICPA publication the auditor is using.
+
+## Structure
+
+SOC 2 reports on up to five **Trust Services Categories**:
+
+| Category | Always in scope? | Criteria |
+|---|---|---|
+| Security | yes | The **common criteria**, CC1 to CC9 |
+| Availability | optional | A1 series |
+| Confidentiality | optional | C1 series |
+| Processing Integrity | optional | PI1 series |
+| Privacy | optional | The privacy criteria series |
+
+The common criteria apply to every report. CC1 to CC5 follow the 17 principles of the COSO
+2013 internal control framework; CC6 to CC9 add criteria specific to technology and security.
+
+## Criteria IDs this skill uses
+
+Use only these IDs. For any other point, describe the area in words.
+
+**CC1 Control environment**
+- CC1.1 commitment to integrity and ethical values
+- CC1.2 board independence and oversight of internal control
+- CC1.3 structures, reporting lines, authorities and responsibilities
+- CC1.4 commitment to attract, develop and retain competent people
+- CC1.5 holding people accountable for their internal control responsibilities
+
+**CC2 Communication and information**
+- CC2.1 obtaining and using relevant, quality information
+- CC2.2 internal communication of objectives and responsibilities
+- CC2.3 communication with external parties
+
+**CC3 Risk assessment**
+- CC3.1 objectives specified clearly enough to identify risks
+- CC3.2 identifying and analysing risks
+- CC3.3 considering the potential for fraud
+- CC3.4 identifying and assessing changes that could affect internal control
+
+**CC4 Monitoring activities**
+- CC4.1 ongoing and separate evaluations of controls
+- CC4.2 evaluating and communicating deficiencies
+
+**CC5 Control activities**
+- CC5.1 selecting and developing control activities
+- CC5.2 general control activities over technology
+- CC5.3 deploying controls through policies and procedures
+
+**CC6 Logical and physical access controls**
+- CC6.1 logical access security over information assets
+- CC6.2 registering and authorising users before issuing credentials, and removing them when access is no longer authorised
+- CC6.3 authorising, modifying and removing access based on roles, least privilege and segregation of duties
+- CC6.4 restricting physical access to facilities and protected assets
+- CC6.5 discontinuing protections over physical assets only after data is removed (disposal)
+- CC6.6 protecting against threats from outside the system boundary
+- CC6.7 restricting the transmission, movement and removal of information
+- CC6.8 preventing or detecting unauthorised or malicious software
+
+**CC7 System operations**
+- CC7.1 detecting configuration changes and new vulnerabilities
+- CC7.2 monitoring system components for anomalies
+- CC7.3 evaluating security events to decide whether they are incidents
+- CC7.4 responding to identified security incidents
+- CC7.5 recovering from identified security incidents
+
+**CC8 Change management**
+- CC8.1 authorising, designing, developing, configuring, documenting, testing, approving and implementing changes
+
+**CC9 Risk mitigation**
+- CC9.1 risk mitigation for business disruption
+- CC9.2 assessing and managing risks from vendors and business partners
+
+**A1 Availability**
+- A1.1 managing capacity to meet objectives
+- A1.2 environmental protections, software, data backup and recovery infrastructure
+- A1.3 testing recovery plan procedures
+
+**C1 Confidentiality**
+- C1.1 identifying and maintaining confidential information
+- C1.2 disposing of confidential information
+
+**Processing Integrity** (describe by area): definitions of the data processed and the
+service's specifications; complete and accurate inputs; complete, accurate and timely
+processing; complete and accurate outputs; and storage of inputs, items in process and
+outputs.
+
+**Privacy** (describe by area): notice; choice and consent; collection; use, retention and
+disposal; access by data subjects; disclosure and notification, including breaches;
+quality; and monitoring and enforcement.
+
+## Baseline controls by area
+
+A starting set for Security when the company has no controls list. Every one is written as
+who, what, how often, with what record. Mark them `proposed` until the company confirms.
+
+| Area | Control | Usual criteria |
+|---|---|---|
+| Governance | Leadership approves security policies annually; staff acknowledge them at hire and annually | CC1.1, CC5.3 |
+| People | Background checks before start; security training at hire and annually, completion tracked | CC1.4 |
+| Risk | Annual risk assessment with a register, reviewed by leadership | CC3.2, CC3.4 |
+| Vendors | Critical vendors assessed at onboarding and annually; their SOC reports reviewed | CC9.2 |
+| Joiners | Access granted by ticket with manager approval, by role | CC6.2, CC6.3 |
+| Leavers | Access removed within a stated time of termination, triggered from HR | CC6.2 |
+| Access review | Quarterly review of production and admin access, with removals recorded | CC6.3 |
+| Authentication | SSO with MFA enforced for all workforce accounts | CC6.1 |
+| Encryption | Data encrypted at rest and in transit, configured centrally | CC6.1, CC6.7 |
+| Endpoints | Managed devices with disk encryption and malware protection | CC6.8 |
+| Vulnerabilities | Scans on a schedule; findings fixed within SLAs by severity | CC7.1 |
+| Monitoring | Security alerts routed to an on-call rotation | CC7.2, CC7.3 |
+| Incidents | Incident response plan, tested annually; incidents ticketed with post-incident review | CC7.3, CC7.4, CC7.5 |
+| Change | Production changes through pull requests with peer review and passing tests; no self-approval | CC8.1 |
+| Backups | Automated backups; restore tested at least annually | A1.2, A1.3 (if Availability in scope), CC7.5 |
+| Business continuity | Continuity and disaster recovery plan, reviewed and tested annually | CC9.1, A1.3 |
+| Monitoring of controls | Internal review of control operation, deficiencies tracked to closure | CC4.1, CC4.2 |
+
+## Type I vs Type II evidence
+
+| | Type I | Type II |
+|---|---|---|
+| What the auditor opines on | Whether controls are suitably designed and implemented **as of a date** | Whether controls are suitably designed **and operated effectively throughout a period** |
+| Period | One date | A period agreed with the auditor; commonly 6 or 12 months, sometimes 3 for a first report |
+| Typical evidence | Policy or procedure; configuration export or dated screenshot; one example of the control running | The **full population** of occurrences in the period from the system of record, then the record for each sample the auditor picks |
+| What fails | No design, or not implemented on the date | Missed occurrences, late occurrences, or no record for a sample |
+
+### Populations and sampling
+
+For Type II, the auditor needs a complete, system-generated list of every time the control
+should have run, so it can select samples and confirm none are missing.
+
+| Control | Population | Source | Per-sample record |
+|---|---|---|---|
+| Leaver access removal | All terminations in the period | HR system report | Identity provider deactivation timestamp vs termination date |
+| Joiner access | All new accounts in the period | Identity provider | Approved access ticket before the account was created |
+| Change management | All production deployments in the period | CI/CD or code hosting | Pull request with an approver other than the author, and passing checks |
+| Quarterly access review | The four quarterly reviews | Ticketing or GRC tool | Review sign-off, list reviewed, removals actioned |
+| Vulnerability remediation | All high and critical findings in the period | Scanner | Fix date within the SLA, or an approved exception |
+
+The control's **frequency** drives how many samples the auditor draws: a per-event or daily
+control gets more samples than a quarterly one. The auditor sets the sample sizes.
+
+## Subservice organisations and complementary controls
+
+- A **subservice organisation** (a cloud provider, a payment processor) runs controls the
+  company relies on. The report either **carves it out** (the usual approach: its controls
+  are excluded and the company points to the vendor's own SOC report) or includes it.
+- For carve-outs, the report lists **complementary subservice organisation controls**: what
+  the company expects the vendor to do. Collect the vendor's current SOC 2 report and its
+  bridge letter if the period doesn't line up.
+- **Complementary user entity controls** are controls the company expects its customers to
+  run, such as managing their own users' access in the product. List them so the system
+  description can state them.

skilldrop_cli/data/packs/grc/skills/soc2-evidence-map/templates/evidence-map.csv

@@ -0,0 +1,2 @@
+control_id,control,criteria,category,type1_evidence,type2_population,type2_sample_record,system,owner,frequency,status,gap,remediation,due_date
+AC-02,"<who> <does what> <how often>, recorded in <system>",CC6.2,Security,<policy + dated config export + one example>,<every occurrence in the period and the report it comes from>,<what each sampled item must show>,<tool the evidence is exported from>,<named person or role>,per event|daily|weekly|monthly|quarterly|annually,in place|partial|gap|proposed,<what is missing; blank if in place>,<the fix>,YYYY-MM-DD

skilldrop_cli/data/packs/infra-as-code/pack.json

@@ -0,0 +1,51 @@
+{
+  "description": "Terraform you can hand to another team and plans you can trust before apply: reusable modules with secure defaults, and a plan review that catches destroys, data loss, access widening and drift.",
+  "display_name": "Infrastructure as code",
+  "keywords": ["terraform", "infrastructure-as-code", "iac", "module", "plan", "aws", "gcp", "azure"],
+  "links": {
+    "documentation": "https://sananthanarayan.github.io/skilldrop/packs/infra-as-code/"
+  },
+  "maintainers": [
+    {
+      "name": "sananthanarayan"
+    }
+  ],
+  "first-value": {
+    "audience-posture": "technical",
+    "prerequisites": ["A Terraform project or a described piece of infrastructure", "Terraform installed locally if you want to validate and plan the result"],
+    "starter-task": "Write a module, then review its plan before the first apply",
+    "starter-prompt": "Write a Terraform module for an S3 bucket that stores our access logs for a year. Several teams will call it. Then, once I've run terraform plan on the example, review the plan before I apply.",
+    "verification": "terraform-module writes versions.tf, variables.tf, main.tf, outputs.tf, a basic example and a README with inputs and outputs tables, with encryption on and public access off by default. terraform-plan-review returns SAFE TO APPLY, APPLY WITH CARE or DO NOT APPLY with every destroy and replace named.",
+    "recovery": "If terraform validate fails, paste the error back and ask terraform-module to fix that file. If terraform-plan-review does not activate, ask for it by name (\"use terraform-plan-review\") and give it the output of terraform show -json tfplan."
+  },
+  "requires": ["core"],
+  "journey": {
+    "when": "You need new infrastructure as a reusable Terraform module, or you have a plan in front of you and want to know whether it is safe to apply.",
+    "you_bring": [
+      "what the infrastructure is for and which cloud it runs on",
+      "who will call the module",
+      "the output of terraform plan, ideally terraform show -json tfplan",
+      "one sentence on what the change is meant to do"
+    ],
+    "time": "20 to 45 minutes",
+    "steps": [
+      {
+        "skill": "terraform-module",
+        "you_do": "Describe the need, the cloud and the callers.",
+        "you_get": "A module with versions.tf, typed and validated variables, secure defaults, a tags variable, a basic example, a README, and the commands to check it."
+      },
+      {
+        "skill": "terraform-plan-review",
+        "you_do": "Run terraform plan, save it with terraform show -json, and hand it over with the intent of the change.",
+        "you_get": "Counts, every destroy and replace with its cause, stateful and access changes, drift, out-of-scope changes and a verdict.",
+        "decide": "Apply, apply after the listed checks, or fix the code and re-plan."
+      },
+      {
+        "skill": "doc-critique",
+        "you_do": "Optionally, run it on the module README before you publish the module to other teams.",
+        "you_get": "Severity-tagged findings on gaps and unclear inputs, with a fix for each."
+      }
+    ],
+    "you_end_with": "A reusable module with safe defaults, and a reviewed plan with a clear apply decision."
+  }
+}

skilldrop_cli/data/packs/infra-as-code/skills/terraform-module/SKILL.md

@@ -0,0 +1,85 @@
+---
+name: terraform-module
+description: Generate a Terraform module from a described need, with main.tf, variables.tf, outputs.tf and versions.tf, typed and validated variables, secure defaults (encryption on, public access off, least-privilege IAM), a merged tags variable, a basic usage example and a README with inputs and outputs tables. Use when the user says "write a terraform module for", "create terraform for an S3 bucket / VPC / database", "turn this into a reusable module", or "scaffold infrastructure as code for".
+---
+
+# terraform-module
+
+Writes a Terraform module someone else can call without reading its insides: typed inputs that reject bad values at plan time, defaults that are safe if nobody changes them, and a README that says what goes in and what comes out. The module is a reusable building block, not a root configuration with a provider and backend baked in. Reviewing the plan it produces before apply is `terraform-plan-review`. Analysing the security of the wider system is `threat-model`.
+
+## How to respond
+
+1. **Get the need, the cloud and the callers, asking once for what is missing.** Three inputs matter: what the infrastructure is for ("a bucket for ALB access logs, kept a year"), which provider (AWS, Google Cloud, Azure), and who calls the module (one team, many teams, a registry). Ask for any that are missing in one message, at most two questions. Default everything else and state the defaults at the top of the output: Terraform `>= 1.5.0`, the current major version of the provider as a bounded range, one module per logical resource group.
+
+2. **Lay out the standard module structure.** Always produce these files, even when one is short:
+   - `versions.tf`: `required_version` and `required_providers` with `source` and a bounded `version` constraint. ✅ `version = ">= 5.0, < 7.0"` or `"~> 5.40"`. ❌ no constraint, or `">= 5.0"` with no upper bound, which lets a breaking major version in on the next `init`.
+   - `variables.tf`: every input.
+   - `main.tf`: resources, data sources and `locals`.
+   - `outputs.tf`: every value a caller needs, each with a `description`.
+   - `<module>/examples/basic/main.tf`: a working call to the module with a provider block, using placeholder names.
+   - `README.md`: purpose, usage snippet, inputs table, outputs table, and what it creates. Use [`templates/module-readme.md`](templates/module-readme.md).
+   No `provider` block and no `backend` block inside the module. The caller owns region, credentials and state.
+
+3. **Type and validate every variable.** Each variable gets `type`, `description` and, where a bad value is possible, a `validation` block with an `error_message` that tells the caller how to fix it. ✅ `type = number` plus `validation { condition = var.retention_days >= 1 ... }`. ❌ `type = any`, or a string that silently takes "ture". Prefer `object({...})` with `optional()` over loose maps for structured input. Checks that span two variables go in a resource `lifecycle { precondition { ... } }`, which works on every supported Terraform version. Patterns are in [`reference.md`](reference.md).
+
+4. **Make the defaults the secure choice.** A caller who sets only the required inputs gets: encryption at rest on, public access off, TLS required, deletion protection or `force_destroy = false` on anything stateful, versioning or backups on where the service has them, and IAM statements scoped to named actions and resources. Each insecure option is an explicit opt-in variable with a description that says what it opens. ✅ `force_destroy` default `false`. ❌ `acl = "public-read"` as a default, `Action = "*"` in a policy, `0.0.0.0/0` ingress by default. The per-cloud checklist is in [`reference.md`](reference.md).
+
+5. **Tag everything through one variable.** Add `variable "tags"` of type `map(string)`, default `{}`, merge it over a small set of module defaults in `locals` (`merge(local.default_tags, var.tags)`, so caller values win) and apply `local.tags` to every resource that supports tags. On Google Cloud the equivalent is `labels`, which must be lowercase.
+
+6. **Hard-code nothing environment-specific.** No account IDs, project IDs, subscription IDs, regions, ARNs, passwords, keys or tokens in the module. Look up the current account or project with a data source (`aws_caller_identity`, `google_client_config`, `azurerm_client_config`), take secrets as `sensitive = true` variables or references to a secret manager, and mark outputs that carry secrets `sensitive = true`.
+
+7. **Tell the user how to check it.** The skill writes files; it does not claim they pass checks it did not run. If `terraform` is on `PATH`, say to run `terraform init -backend=false` and `terraform validate` in the module, and run them if the session allows shell commands. Always end with the commands to run before merging:
+   ```bash
+   terraform fmt -recursive
+   terraform init -backend=false && terraform validate
+   terraform plan   # from the basic example folder, against a sandbox account
+   ```
+   Add `tflint` and `checkov -d .` if the user's team uses them. Recommend running the resulting plan through `terraform-plan-review` before the first apply.
+
+8. **Emit the module in one message**: the stated defaults and assumptions, then each file in its own fenced block headed by its path, then the check commands. Follow the shape of [`examples/s3-log-bucket/`](examples/s3-log-bucket/README.md).
+
+**Non-interactive runs** (subagent, CI, headless): a missing provider version, Terraform version or naming scheme becomes a tagged `[assumption]` listed first. A missing cloud provider or a need too vague to name a resource ("some infrastructure for the app") emits `BLOCKED: need the cloud provider and what the module must create`. Never guess the cloud.
+
+## Useful references in this skill
+
+- [`reference.md`](reference.md): secure defaults per cloud, variable validation patterns, version constraint rules, tagging and labelling, and the secrets checklist
+- [`templates/module-readme.md`](templates/module-readme.md): the README skeleton with inputs and outputs tables
+- [`examples/s3-log-bucket.md`](examples/s3-log-bucket.md): the worked example, the input prompt and the decisions behind the module
+- [`examples/s3-log-bucket/`](examples/s3-log-bucket/README.md): the module itself, with `versions.tf`, `variables.tf`, `main.tf`, `outputs.tf`, a basic usage example and its README
+
+## Quality bar
+
+- **All six pieces exist**: `versions.tf`, `variables.tf`, `main.tf`, `outputs.tf`, a basic usage example, and a README with inputs and outputs tables that match the code.
+- **Provider and Terraform versions are constrained**, with an upper bound on the provider major version.
+- **Every variable has a type and a description**; every variable that can take a bad value has a validation block with a fixable error message.
+- **Defaults are secure**: encryption on, public access off, least-privilege IAM, stateful resources protected from accidental destroy. Insecure options are opt-in variables.
+- **Tags flow from one `tags` variable** merged with module defaults onto every taggable resource.
+- **No hard-coded secrets, account IDs, project IDs, regions or ARNs** in the module.
+- **No provider or backend block** inside the module.
+- **The output does not claim the module was validated** unless the commands were actually run, and it shows their real output when they were.
+
+## When to use this skill
+
+- ✅ "Write a Terraform module for a private S3 bucket / RDS instance / GCS bucket / VNet"
+- ✅ Turning copy-pasted resource blocks from several root configs into one reusable module
+- ✅ Scaffolding a module with sensible secure defaults before the team fills in details
+- ✅ Adding validation, tagging and a README to an existing module that has none
+
+## When NOT to use this skill
+
+- ❌ Reviewing a `terraform plan` before apply: use `terraform-plan-review`
+- ❌ Reviewing someone's Terraform pull request for bugs: use `pre-merge-review`
+- ❌ Modelling the threats to the system the infrastructure supports: use `threat-model`
+- ❌ Estimating what the infrastructure will cost at expected load: use `capacity-cost-model`
+- ❌ Moving existing infrastructure or data from one platform to another: use `migration-plan`
+
+## Anti-patterns to avoid
+
+- ❌ **A provider block inside the module.** It pins the region and credentials for every caller and stops the module being used with provider aliases.
+- ❌ **`type = any` and no validation.** The first sign of a typo is a failed apply half an hour later instead of a plan-time error.
+- ❌ **Unbounded provider versions.** `version = ">= 4.0"` builds today and breaks on the next major release, on someone else's machine.
+- ❌ **Secure options as opt-in.** `encrypted = false` as the default with a variable to turn it on means most callers never do.
+- ❌ **Hard-coded account IDs and ARNs.** The module works in one account and fails or, worse, grants access to the wrong one everywhere else.
+- ❌ **Tags set resource by resource.** Half the resources end up untagged, and cost reports can't attribute them.
+- ❌ **A README that drifts from the code.** An inputs table missing two variables is worse than none, because callers trust it.
+- ❌ **"Validated" without running anything.** Saying the module passes `terraform validate` when no one ran it.

skilldrop_cli/data/packs/infra-as-code/skills/terraform-module/evals/eval_queries.json

@@ -0,0 +1,34 @@
+[
+  {
+    "query": "Write a terraform module for a private S3 bucket with encryption",
+    "should_trigger": true
+  },
+  {
+    "query": "Create Terraform for an RDS Postgres instance that other teams can reuse",
+    "should_trigger": true
+  },
+  {
+    "query": "Turn these copy-pasted resource blocks into a reusable Terraform module with variables and outputs",
+    "should_trigger": true
+  },
+  {
+    "query": "Scaffold infrastructure as code for a GCS bucket with a README and inputs table",
+    "should_trigger": true
+  },
+  {
+    "query": "Review my terraform plan output before I apply it",
+    "should_trigger": false
+  },
+  {
+    "query": "Review this pull request that changes our Terraform files",
+    "should_trigger": false
+  },
+  {
+    "query": "Threat model the payments platform we are deploying to AWS",
+    "should_trigger": false
+  },
+  {
+    "query": "Estimate what this infrastructure will cost per month at 10k requests per second",
+    "should_trigger": false
+  }
+]

skilldrop_cli/data/packs/infra-as-code/skills/terraform-module/evals/evals.json

@@ -0,0 +1,31 @@
+{
+  "skill_name": "terraform-module",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Write a Terraform module for Acme's Postgres database on AWS RDS. The payments team and the orders team will both call it. They need to pick instance class and storage size; everything else should be safe by default.",
+      "assertions": [
+        "Produces versions.tf, variables.tf, main.tf, outputs.tf, a basic usage example and a README with inputs and outputs tables",
+        "versions.tf sets required_version and a provider version constraint with an upper bound on the major version",
+        "Every variable has a type and a description, and inputs such as instance class or storage size have validation blocks with fixable error messages",
+        "Defaults set storage_encrypted = true, publicly_accessible = false, deletion_protection = true and skip_final_snapshot = false",
+        "The master password is not a literal or a variable default; it is a sensitive variable, a managed password, or a secret-manager reference",
+        "A tags variable is merged with module defaults and applied to taggable resources",
+        "The module contains no provider block, no backend block, and no hard-coded account ID, region or ARN",
+        "Does not claim terraform validate or plan was run unless it was actually run"
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "Turn this into a reusable module for Northwind's GCP projects: a GCS bucket for nightly exports, kept 90 days, readable by the analytics service account only.",
+      "assertions": [
+        "Uses labels with lowercase keys rather than AWS-style tags",
+        "Sets public_access_prevention to enforced and uniform_bucket_level_access to true by default",
+        "Grants access with a member-level IAM binding scoped to the named service account variable, not a project-wide or primitive role",
+        "Adds a lifecycle rule deleting objects after a retention variable defaulting to 90",
+        "Takes the project ID as a variable or data source rather than a literal",
+        "Ends with the terraform fmt, validate and plan commands for the user to run"
+      ]
+    }
+  ]
+}

skilldrop_cli/data/packs/infra-as-code/skills/terraform-module/examples/s3-log-bucket/README.md

@@ -0,0 +1,71 @@
+# s3-log-bucket
+
+An S3 bucket for access logs: private, encrypted, versioned, TLS-only, with lifecycle rules that move logs to STANDARD_IA and then expire them. It can receive S3 server access logs from buckets in the same account.
+
+## Usage
+
+```hcl
+module "access_logs" {
+  source = "../.."   # or your registry / git source
+
+  bucket_name    = "acme-prod-access-logs-example"
+  retention_days = 400
+
+  tags = {
+    "environment" = "prod"
+    "owner"       = "platform-team"
+  }
+}
+```
+
+A runnable version is in `examples/basic`.
+
+## What it creates
+
+| Resource | Why |
+|---|---|
+| `aws_s3_bucket.this` | The bucket. `force_destroy` is off by default so `terraform destroy` will not delete logs |
+| `aws_s3_bucket_public_access_block.this` | All four public access settings on |
+| `aws_s3_bucket_ownership_controls.this` | `BucketOwnerEnforced`: ACLs disabled, access by policy only |
+| `aws_s3_bucket_server_side_encryption_configuration.this` | SSE-S3 (AES256) by default, SSE-KMS when `kms_key_arn` is set |
+| `aws_s3_bucket_versioning.this` | Versioning on, so an overwrite or delete is recoverable for 30 days |
+| `aws_s3_bucket_lifecycle_configuration.this` | Transition to STANDARD_IA, expire after `retention_days`, clean up noncurrent versions and incomplete uploads |
+| `aws_s3_bucket_policy.this` | Deny any request not made over TLS; optionally allow S3 server access log delivery from this account |
+
+## Inputs
+
+| Name | Type | Default | Description |
+|---|---|---|---|
+| `bucket_name` | `string` | (required) | Globally unique bucket name, 3 to 63 lowercase characters |
+| `retention_days` | `number` | `365` | Days before log objects expire. Must be greater than `transition_to_ia_days` |
+| `transition_to_ia_days` | `number` | `30` | Days before objects move to STANDARD_IA. At least 30 |
+| `kms_key_arn` | `string` | `null` | Customer-managed KMS key for SSE-KMS. Null means SSE-S3 |
+| `allow_s3_server_access_logs` | `bool` | `true` | Allow the S3 logging service to write server access logs here |
+| `access_log_source_bucket_arns` | `list(string)` | `[]` | Buckets allowed to deliver logs. Empty means any bucket in this account |
+| `force_destroy` | `bool` | `false` | Let `terraform destroy` delete a non-empty bucket |
+| `tags` | `map(string)` | `{}` | Extra tags, merged over the defaults `managed-by = terraform` and `module = s3-log-bucket` |
+
+## Outputs
+
+| Name | Description |
+|---|---|
+| `bucket_name` | Bucket name, to use as a logging target |
+| `bucket_arn` | Bucket ARN, for IAM policies that read the logs |
+| `bucket_regional_domain_name` | Regional domain name of the bucket |
+
+## Notes
+
+- Leave `kms_key_arn` null unless you know every log source supports SSE-KMS on the destination. Elastic Load Balancing access logs, for example, document SSE-S3 as the only supported option. Check the docs for each service that writes here.
+- The account ID in the log delivery policy comes from `data.aws_caller_identity`, so nothing account-specific is hard-coded.
+- This module does not configure a provider. The caller sets the region and credentials.
+
+## Before you apply
+
+```bash
+terraform fmt -recursive
+terraform init
+terraform validate
+terraform plan
+```
+
+Run `tflint` and `checkov -d .` too if your team uses them.

skilldrop_cli/data/packs/infra-as-code/skills/terraform-module/examples/s3-log-bucket/examples/basic/main.tf

@@ -0,0 +1,30 @@
+terraform {
+  required_version = ">= 1.5.0"
+
+  required_providers {
+    aws = {
+      source  = "hashicorp/aws"
+      version = ">= 5.0, < 7.0"
+    }
+  }
+}
+
+provider "aws" {
+  region = "eu-west-1"
+}
+
+module "access_logs" {
+  source = "../.."
+
+  bucket_name    = "acme-prod-access-logs-example"
+  retention_days = 400
+
+  tags = {
+    "environment" = "prod"
+    "owner"       = "platform-team"
+  }
+}
+
+output "log_bucket_name" {
+  value = module.access_logs.bucket_name
+}