Facets Modules Validation

IMPORTANT: This skill does TWO things: (1) validates modules against all rules in

rules.md

by reading and analyzing the module files directly, and (2) runs

raptor create iac-module --dry-run

for each module. Both checks must pass.

Validate changed Facets modules against the project's

rules.md

validation ruleset.

---

Step 1: Determine which modules to validate

Identify the set of modules to validate, in priority order:

1. If the user passed a module path as argument → use that path directly
2. If on a PR branch (not

   main

   ) → run

   git diff origin/main --name-only

   to get all changed files vs main, then extract unique module directories
3. Otherwise → run

   git diff --name-only

   (unstaged) and

   git diff --cached --name-only

   (staged) to get locally changed files, then extract unique module directories

Extracting module paths: A module directory is any directory that contains a

facets.yaml

file. For each changed file, walk up its path to find the nearest

facets.yaml

. The module path is that directory (e.g.,

modules/datastore/postgres/aws-rds/1.0/

).

Deduplicate the list. If no modules are found, inform the user and stop.

Print the list of modules that will be validated before proceeding.

---

Step 2: Read rules.md and module files

1. Read

   rules.md

   from the repo root — this contains all validation rules
2. For each module, read:

   • facets.yaml

   • All

     .tf

     files in that module directory (

     variables.tf

     ,

     main.tf

     ,

     outputs.tf

     ,

     locals.tf

     ,

     versions.tf

     , etc.)
   • The relevant output type schemas from

     outputs/

     based on the output types declared in

     facets.yaml

     outputs section (e.g., if output type is

     @facets/eks

     , check

     outputs/eks/outputs.yaml

     ; if

     @outputs/postgres

     , check

     outputs/postgres/outputs.yaml

     )

---

Step 3: Validate each module against applicable rules

For each module, check every rule from

rules.md

(RULE-001 through the last defined rule). Use the rule's category and description to determine if it applies to the module being validated:

• Skip rules whose category doesn't apply (e.g., skip "output schema" rules if the module has no output type schemas in

  outputs/

  )
• Check all applicable rules and record PASS/FAIL/SKIP with a brief finding

The rules in

rules.md

contain all the detail needed — category, description, and good/bad examples. Do NOT hardcode rule numbers or descriptions here; always read

rules.md

at validation time to pick up any newly added rules.

---

Step 4: Run raptor dry-run validation

For each detected module, run:

export FACETS_PROFILE=1155708878 && raptor create iac-module -f <module-path> --dry-run

• If the raptor dry-run fails due to security scan, retry with

  --skip-security-scan

  but report the security findings to the user in a table
• If the raptor dry-run fails for other reasons (provider issues, schema errors, etc.), report the error
• Record each module's raptor result (PASS / FAIL + error details) for the final report

---

Step 5: Report results

Per-module report

For each validated module, output a report in this format:

## modules/datastore/postgres/aws-rds/1.0

| Rule | Status | Finding |
|------|--------|---------|
| RULE-001 | PASS | — |
| RULE-002 | PASS | — |
| RULE-003 | SKIP | No sample values to check |
| RULE-004 | FAIL | var.inputs uses `type = any` instead of explicit object type |
| RULE-005 | PASS | — |
| ... | ... | ... |
| RULE-024 | SKIP | No cloud resources with names |
| Raptor dry-run | PASS/FAIL | Result or error details |

X passed, Y failed, Z skipped.

Status values:

• PASS — Rule checked and satisfied
• FAIL — Rule checked and violation found (include specific finding)
• SKIP — Rule not applicable to this module (include brief reason)

Summary (if multiple modules)

After all per-module reports, output a summary:

## Summary

| Module | Passed | Failed | Skipped |
|--------|--------|--------|---------|
| modules/datastore/postgres/aws-rds/1.0 | 18 | 2 | 4 |
| modules/service/aws/1.0 | 20 | 0 | 4 |
| **Total** | **38** | **2** | **8** |

If all modules pass, add a confirmation message. If any fail, list the critical failures that should be fixed before commit.

---

Step 6: Recommend new rules (if applicable)

During validation, if you encounter any of the following that are NOT covered by existing rules in

rules.md

:

• A new anti-pattern seen across multiple modules
• A validation gap (something raptor catches but rules.md doesn't cover)
• A convention that modules follow inconsistently

Propose a new rule to the user in the standard format:

• Rule number: next available (RULE-025, RULE-026, etc.)
• Category, description, bad example, good example
• Do NOT modify rules.md automatically — present the proposal and wait for approval