SystemAudit

ClaudeCommunityby SystemAudit

SystemAudit reads a public GitHub repository the way a reviewer would and reports what a static read of the code shows: a health score out of 100, the highest-ranked risks described in plain English, how the codebase is put together, and how many potential hardcoded credentials it found. Three tools: - scan_repository: a static health check returning a score out of 100, ranked risks, and how many files were read out of how many the repository contains. - get_architecture: package ecosystem, detected architecture pattern, language mix, dependency count, and structural signals such as circular imports and files nothing else imports. - secrets_summary: counts of potential hardcoded credentials and committed environment files, by severity. Built for the moment before you commit to a codebase: evaluating an open-source dependency, running technical due diligence on an acquisition or investment, inheriting a repository, or sanity-checking code an AI tool generated. Honest by design. Every answer states how many files were read out of how many exist, so a clean result can never be mistaken for a clean repository. Locations and values of credentials are never returned, only counts by severity, so a scan cannot be used to harvest secrets from someone else's repository; the repository owner sees the detail in the full report at systemaudit.dev. No code is executed and no file contents are returned. Only public repositories are read. The connector needs no sign-in and no account, and receives only the repository you name, so no other part of your conversation reaches us. Repository files are processed and discarded, never stored. Typical response times: under a second for a cached result, around two seconds for a first scan of a small repository, and under five seconds for a repository of several thousand files.