sf-technical-debt-audit

Audits Salesforce orgs and source trees for technical debt and produces a ranked remediation register.

2|Updated Sep 12, 2026
One-click install
npx skills add https://github.com/grzmol/vibe-force --skill sf-technical-debt-audit-grzmol
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: sf-technical-debt-audit
Source: https://github.com/grzmol/vibe-force/tree/main/skills/sf-technical-debt-audit
Command: npx skills add https://github.com/grzmol/vibe-force --skill sf-technical-debt-audit-grzmol

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Taking over an unfamiliar Salesforce org or planning a hardening sprint is guesswork without a measured picture of version drift, test gaps, automation sprawl, hardcoded values, dead code, and delivery debt. This Skill runs a read-only audit across source and a connected org, then ranks findings by impact and effort into an actionable debt register. ## Core Features & Use Cases - Six debt categories with measurable signals: API version drift, test and coverage debt, trigger and automation sprawl, structural debt (hardcoded ids, profiles), dead weight against the 6 MB Apex limit, and delivery debt from org-only changes. - Ranked debt register: Findings are scored on impact and effort, assigned an owner and a remediation skill, and written to .vibeforce/reports/ so successive audits can diff progress. - Read-only and production-safe: All queries and previews are non-mutating, with explicit guidance on what an audit cannot see and which checks to skip against production. - Use Case: You inherit an org where every small change takes days. Run the audit to discover two triggers on Account, an active Process Builder beside Flows, 14 classes with no tests, and org coverage below the gate - then hand the top five ranked items to owners with remediation skills attached. ## Quick Start Ask the assistant to run a technical debt audit of the Salesforce project against the vf-int org and produce a ranked debt register.

Frequently Asked Questions about sf-technical-debt-audit

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I audit technical debt in a Salesforce org?

Run read-only checks against source and the org: grep apiVersion spread, count triggers per object, query FlowDefinitionView for active Workflow Rules and Process Builders, and run sf project retrieve preview for org-only changes. Rank findings by impact and effort into a debt register.

How to find Apex classes with no test coverage in Salesforce?

Use the vf-check pairing command to list classes and LWC bundles without tests, and vf-check apex against a target org for per-class coverage. Also grep for SeeAllData=true and assertion-free test methods, since coverage without assertions is not a safety net.

Is it safe to run a technical debt audit against a production Salesforce org?

Yes, when limited to read-only operations: queries, org limits, and deploy or retrieve previews are legitimate against production. Do not run test-executing checks like vf-check apex in production, and never force mutating checks through with VF_ALLOW_PROD.

What is the difference between a technical debt audit and a code review in Salesforce?

A debt audit measures org-wide signals like version drift, automation sprawl, and dead code across the whole source tree and org. Reviewing the diff of a specific change belongs to static analysis tooling such as Code Analyzer and a quality gate, not an audit.

Why does my Salesforce org have slow and risky deployments?

Common causes are components changed only in the org (found via sf project retrieve preview), multiple triggers per object, active Workflow Rules or Process Builders beside Flows, and Apex volume approaching the 6 MB org limit. An audit quantifies each and ranks the fixes.

What can a Salesforce metadata audit not detect?

It cannot see Setup-only configuration with no metadata representation, report and list view field references, managed package internals, runtime behavior under load, or data quality issues. These blind spots should be stated explicitly in every audit report.