Update to Vanta

{
  "description": "Show failing Vanta compliance tests, prioritized by what can be fixed from this repository",
  "included_files": [],
  "name": "list-tests",
  "skill_md_contents": "---\nname: list-tests\ndescription: Show failing Vanta compliance tests, prioritized by what can be fixed from this repository\n---\n\nShow the user their failing Vanta tests, ranked by what the plugin can help with.\n\n## Steps\n\n1. **Fetch failing tests.** Call `tests` to get all tests with status `NEEDS_ATTENTION`.\n2. **Categorize and rank tests.** Group the failing tests into tiers:\n   **Ready to fix** — Tests where:\n    - 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.\n    - Present these first. These are one-command fixes with `/vanta:fix-test <testId>`.\n   **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.\n   **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.\n3. **Present the results.** For each tier, show a table with columns:\n    - Test name\n    - Test ID\n    - Number of failing entities\n    - Integration (e.g., AWS, GitHub, Azure)\n    - How long the test has been failing (from `latestFlipDate`)\n    - For \"Ready to fix\" tests, show: `Run /vanta:fix-test <testId> to generate a PR`\n4. **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.\"\n5. **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.\n\n## Edge cases\n- **No failing tests:** \"All tests are passing. Nice work.\" Do not show an empty table.\n- **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:\"\n- **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.\"\n- **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.\"\n- **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]?\"\n"
}