Codetruss

CodeTruss

Use the installed codetruss CLI as the source of truth. Do not reimplement scope classification, analyzers, verdict rules, signing, or hook behavior in the agent.

Preserve the trust boundary

• Work inside the developer's Git repository and inspect existing policy before proposing changes.
• Run codetruss --version first. This skill targets v0.2.35 or newer. If the CLI is missing or older, explain the prerequisite, then obtain explicit consent before downloading or installing software, including an upgrade.
• Offer only the official install paths from https://codetruss.com/cli. Let the developer inspect a downloaded installer instead of piping it when they prefer an inspect-first flow.
• Do not run --llm, codetruss auth login, or codetruss sync unless the developer explicitly requests that networked action. Never search for or print provider keys.
• Do not broaden allow, remove deny, add --no-verify, or edit a receipt to manufacture a green verdict. Fix the change or ask the developer to approve a genuine policy change.
• For codetruss run and codetruss review, treat exit 0 as PASS, exit 1 as REVIEW_REQUIRED, exit 2 as FAILED, and exit 3 as a usage or environment failure. Exits 1 and 2 still produce receipts; other commands may use nonzero exits differently, so read their output.
• A receipt also names what did not run, and that boundary moved in v0.2.35. A local run now executes the shared SAST engine over the JavaScript, TypeScript and TSX in the repository, covering SQL injection, mass assignment, un-awaited database writes, swallowed errors, coercion-prone ==, and N+1 queries in loops. The rest of the rule pack (command injection, code injection, path traversal, SSRF, open redirect, XSS, insecure deserialization), every non-JavaScript language, and the hosted symbol graph stay hosted-only. Read the receipt's own "What did not run" section instead of asserting either way from memory. Report a PASS as the deterministic passes finding nothing new, never as evidence that the change is secure.
• Local security findings are REVIEW_REQUIRED at most. They never fail a verdict on their own, so do not report one as a blocking failure.
• Describe a valid signature as post-generation integrity evidence. Do not call it trusted execution, proof of authorship, or automatic compliance evidence.

Set up a repository

1. Confirm the repository root and require a reasonably clean baseline when attribution matters.
2. Inspect tracked paths, task context, existing .codetruss.yml, package scripts, and the repository's normal lint, typecheck, test, or build commands.
3. Propose the smallest useful allow globs, appropriate deny globs, the exact verification commands CodeTruss is expected to detect, and one hook target. Keep secrets, generated output, production infrastructure, and unrelated migrations denied when appropriate. Show which tracked paths each glob matches, and flag empty or overly broad matches. Do not default to **/*.
4. Ask the developer to confirm the exact boundary, hook target, verification command list, and whether to trust that list for automatic execution.
5. After confirmation, use codetruss setup as the single guided setup path, with the approved repeated --allow and --deny values and one --hooks claude|codex|pre-commit|all value. Prefer its interactive trust prompt so the commands it actually prints can be compared with the approved list before answering trust. Use --yes only after every choice is explicit and the inspected repository state is unchanged. Include --trust-verify only after the developer approves the exact detected list, so fingerprint trust is completed. Do not replace guided initial setup with ad hoc config editing or separate hook installation.
6. Read the setup output and verify the expected policy, hook health, and local-only privacy reminder. When commands were detected, require their full verification fingerprint and trusted result, then run codetruss verify-policy status and require exit 0 with the same fingerprint and command list. Otherwise confirm that setup reports no detected commands. If setup pauses before trust, show the exact commands and fingerprint, obtain approval, then rerun the same setup path with --trust-verify.
7. Remind Codex users to open /hooks and approve the exact repository hook definition when setup reports that one-time host trust step.

The CLI's hook installer is idempotent and preserves supported existing hook configuration. An existing .codetruss.yml remains authoritative: if setup reports a policy mismatch, stop instead of overwriting or weakening it, and treat any policy change as a separate developer decision. If the developer approves the exact policy diff, make only that reviewed edit and rerun setup without conflicting policy flags. A setup hook target installs or checks that target; it does not remove other existing hooks. Never uninstall another hook without an explicit removal request. Do not replace the installer with plugin-bundled hook logic.