# Truto Integration Config Auditor

> Audit Truto integration JSON or stored integration configs for syntax, schema validity, provider-doc alignment, auth, pagination, resource methods, docs-table behavior, capabilities, and Truto repo conventions. Use when validating or reviewing an integration config.

- Skill: `yuvraj3335/truto-integration-config-auditor` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add yuvraj3335/truto-integration-config-auditor`
- Raw SKILL.md: https://api.skillmd.com/api/skills/yuvraj3335/truto-integration-config-auditor/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: yuvraj3335 (https://skillmd.com/u/yuvraj3335)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/yuvraj3335/truto-integration-config-auditor

---


# Truto Integration Config Auditor

## Mission

Prove whether an integration config is valid, documented, and aligned with provider behavior. Prefer CLI schema validation and dry-run build comparison over manual opinions.

## Inputs

Accept a local config file, stored integration slug/ID, provider docs URL/path, profile, resource allow-list, suspected failing method, or customer issue.

## Validation Ladder

Local file:

```bash
jq . "$CONFIG_FILE" >/dev/null
truto integrations validate --file "$CONFIG_FILE" -p "$PROFILE" -o json --no-color
```

Stored integration:

```bash
truto integrations list --name "$INTEGRATION" -p "$PROFILE" -o json --no-color
truto integrations get "$INTEGRATION_ID" -p "$PROFILE" -o json --no-color
truto integrations validate "$INTEGRATION_ID" -p "$PROFILE" -o json --no-color
truto integrations tools "$INTEGRATION_ID_OR_NAME" -p "$PROFILE" -o json --no-color
truto capabilities "$INTEGRATION" --target integration -p "$PROFILE" -o json --no-color
```

Provider-doc comparison:

```bash
truto integrations build "$DOC_SOURCE" "$INTEGRATION" --dry-run --strict --plan-out --report-out -p "$PROFILE"
```

Add `--resources "$RESOURCES"` for focused review. Use `--source-tier` only after evidence that auto discovery chose the wrong docs.

## Audit Focus

- Config passes schema validation before deeper review.
- Auth type, auth placement, token refresh, base URL, and sandbox/prod host match docs.
- Resources and method names match provider concepts without accidental `misc` or verb-as-resource grouping.
- Paths, HTTP verbs, path params, query/body schemas, and required fields match docs.
- Pagination config matches examples and does not invent paths that are absent in sample responses.
- Rate limits, retry behavior, webhooks, verification, and error envelopes match docs where available.
- Descriptions, `query_schema`, and `body_schema` belong in documentation rows. Inline descriptions are not runtime truth.
- Capabilities and tools expose what customers and AI surfaces expect.
- No secrets or customer-specific credentials live in config JSON.

## Repo-Specific Rule

When reviewing CLI build code or docs behavior, read `.cursor/rules/cli-doc-table-descriptions.mdc`. The runtime capabilities path reads from the documentation table, not inline method descriptions.

## Output

Lead with blockers. Then list provider-doc mismatches, runtime risks, docs/capability gaps, and low-risk improvements. Include commands run, artifacts produced, and a safe apply or refresh plan.

