Vanta

View saved version →

---
name: fix-test
description: Fix a failing Vanta compliance test by generating code changes and opening a pull request
argument-hint: test ID or Vanta test URL
---

Fix the failing Vanta test specified in $ARGUMENTS.

## Steps

1. **Parse the test ID.** If `$ARGUMENTS` is a URL (e.g., `https://app.vanta.com/c/<slug>/tests/<testId>`), extract the test ID from the path. If it's a plain string, use it directly as the test ID.
2. **Get remediation context.** Call `getAgentRemediationPrompt` with the test ID and follow instructions. 
3. **Follow the returned prompt.** The `getAgentRemediationPrompt` response contains a system prompt and user message with test-specific remediation intelligence. Follow these instructions to scan the local repository and generate the fix.

## Edge cases

- **Test ID not found:** Call `tests` to fetch the failing tests list, fuzzy-match against the provided ID, and present the closest matches. "I couldn't find a test called `[id]`. Did you mean one of these?" Never dead-end.
- **Test is already passing:** "This test is currently passing. No remediation needed." Then show the failing tests list so the user can pick something else.
- **Malformed or non-test URL:** "I couldn't parse a test ID from that URL." Then show the failing tests list.
- **Ambiguous description (no ID):** If `$ARGUMENTS` doesn't match a test ID, call `tests` and filter by keyword. If one match, proceed. If multiple, show candidates with entity counts and ask which one. If none, show the full failing tests list.
- **No IaC files in directory:** "I have the fix for this test, but I don't see any IaC files in this directory." Offer options: open Claude Code in the right repo, generate new Terraform files, or provide CLI commands.
- **IaC files found but no matching resources:** "I found Terraform files, but none manage the failing resources." Offer: import + fix, fix in a different repo, or CLI commands.

View saved version →

---
name: list-tests
description: Show failing Vanta compliance tests, prioritized by what can be fixed from this repository
---

Show the user their failing Vanta tests, ranked by what the plugin can help with.

## Steps

1. **Fetch failing tests.** Call `tests` to get all tests with status `NEEDS_ATTENTION`.
2. **Categorize and rank tests.** Group the failing tests into tiers:
   **Ready to fix** — Tests where:
    - The test's integration matches resources likely managed in this repo. Detect this by checking for deployment code: look for provider declarations (`provider "aws"` in `.tf` files for AWS, `provider "google"` for GCP, `provider "azurerm"` for Azure) **and** resource type prefixes (`aws_`, `google_`, `azurerm_`) in `.tf` files; or `AWSTemplateFormatVersion` in CloudFormation templates; or `cdk.json` for CDK projects. Use both signals — provider blocks are often absent in child modules or Terragrunt configs.
    - Present these first. These are one-command fixes with `/vanta:fix-test <testId>`.
   **Fixable with guidance** — Tests that are code-remediable but may not match this repo (different cloud provider, different integration). The user can still get remediation code, but may need to apply it elsewhere.
   **Manual steps needed** — Tests that require configuration changes in external tools, Vanta settings, or manual processes. The plugin can provide guidance but not generate code.
3. **Present the results.** For each tier, show a table with columns:
    - Test name
    - Test ID
    - Number of failing entities
    - Integration (e.g., AWS, GitHub, Azure)
    - How long the test has been failing (from `latestFlipDate`)
    - For "Ready to fix" tests, show: `Run /vanta:fix-test <testId> to generate a PR`
4. **Highlight co-failure clusters.** If multiple failing tests map to the same resource type or integration, note this. For example: "5 IAM tests are failing — fixing the password policy may resolve all of them at once."
5. **Keep it scannable.** Use a table or bulleted list. Do not dump raw API responses. The user needs to quickly see what to fix first.

## Edge cases
- **No failing tests:** "All tests are passing. Nice work." Do not show an empty table.
- **User asks to filter (e.g., "show AWS tests"):** Filter by integration name. If no failures match the filter, say so and show the full list: "No failing AWS tests found. Here's what is failing across other integrations:"
- **User asks to filter by framework (e.g., "SOC 2 gaps"):** Filter by framework. "You have [N] failing tests mapped to SOC 2. Here are the ones I can help fix from this repo."
- **User asks "what should I fix first?":** Rank by impact: IaC-fixable in this repo first, then highest entity count, then longest time failing. Highlight co-failure clusters as "biggest bang for the buck."
- **Very large number of failing tests:** Group by integration and summarize counts rather than listing every test. Show the top 5-10 highest-impact items with a note: "[N] more tests failing. Want to see the full list or focus on [integration]?"