Technical Due Diligence skill for Codex

Diligence is done well when every rating rests on evidence the reader can check (a command output, a file, an interview answer), red flags come with a cost and time to fix, and the report answers the deal question: can this system and team deliver the plan the buyer or investor is paying for?

Legal and financial conclusions (IP ownership, licence compliance, contract terms) need a lawyer or accountant. Flag them; do not rule on them.

Ground rules

• Confirm scope and access in writing: which repos, environments, documents and people, and any NDA or clean-team restrictions. Ask the user before starting if unclear.
• Read-only. Do not push, open issues, rotate credentials, or run anything against production. Clone into an isolated directory.
• Keep target code inside the agreed environment. Do not upload it to third-party services; prefer scanners that run fully offline, and ask before any tool that needs network or sends data out.
• Secrets found in the code are reported by location and type only, never copied into the report.

Workflow

- [ ] 1. Understand the deal thesis and the questions it raises
- [ ] 2. Request documents and access; build the system map
- [ ] 3. Automated scans: size, history, dependencies, licences, secrets
- [ ] 4. Manual review of the critical paths
- [ ] 5. Team and process interviews
- [ ] 6. Infrastructure, cost and operations review
- [ ] 7. Rate each area; estimate remediation
- [ ] 8. Write the report; review findings with the user

1. Thesis

Diligence answers specific questions. “Can this product handle 10x customers after we bundle it?” leads to scalability work. “Can we integrate it with our stack in a year?” leads to architecture and team questions. Write the 3-6 questions first and tie every section of the report back to them.

2. Document request (typical)

Architecture diagrams, infrastructure inventory and cloud bills (12 months), incident and postmortem history, security assessments and pen-test reports, SOC 2 / ISO reports, SBOM or dependency list, open-source policy, on-call and release process, roadmap, org chart with tenure, contractor agreements (for counsel).

3. Automated scans

Run on a local clone. Install tools only with approval; many need network to install.

scc --no-cocomo .                               # size by language (or: cloc .)
git log --since="12 months ago" --pretty=format:'%ad' --date=short | cut -c1-7 | sort | uniq -c
git shortlog -sne --since="12 months ago" | head -20     # who does the work
git log --since="12 months ago" --name-only --pretty=format: | sort | uniq -c | sort -rn | head -30   # hotspots
osv-scanner scan source -r .                    # known vulnerabilities (OSV, v2 syntax)
syft dir:. -o spdx-json > sbom.json             # SBOM
gitleaks git --redact .                         # secrets in history
grep -rIl --exclude-dir={node_modules,vendor,.git} -E 'GNU (Affero )?General Public License|SSPL|Business Source License' .

Key-person risk from history: for each top-level module, what share of commits in the last year came from one person? Over ~80% from one person in a core module is a risk, especially if that person is leaving or a contractor.

4. Manual review

Prioritise the code paths the thesis depends on: authentication, billing, data model and migrations, the core domain workflow, integrations. For each:

Area	Look for
Architecture	Clear boundaries vs a tangled monolith; data ownership; coupling to a vendor or legacy platform
Scalability	Database as single bottleneck, N+1 patterns, synchronous chains, missing queues and caching, load test evidence
Code health	Test coverage on critical paths (not overall %), complexity hotspots, dead code, framework end-of-life versions
Delivery	CI on every change, deploy frequency, rollback ability, environments, feature flags
Security	Authz checks, input handling, secrets management, dependency patching cadence, past incidents
Data	Backups tested, PII inventory, retention, regulatory scope (GDPR, HIPAA, PCI)
Licensing	Copyleft components in distributed products, missing attributions, unclear provenance code

5. Interviews

Ask the CTO and 2-3 engineers the same questions separately; differences are findings.

• Walk me through the last serious incident. What changed afterwards?
• What would break first at 10x load? How do you know?
• What part of the code do people avoid touching? Why?
• How long from merged PR to production? How often do deploys fail?
• What would you rewrite with six months and no feature work?

6. Infrastructure and cost

From cloud bills and IaC: cost per customer or per transaction, trend over 12 months, largest line items, reserved vs on-demand, single-region or single-account risks, and whether infrastructure is reproducible from code. Compare hosting cost to revenue if the user provides financials.

7. Rating

Rating	Meaning
Green	Meets the thesis; normal maintenance
Amber	Gaps that need planned investment; fixable within the deal timeline
Red	Blocks the thesis, needs significant cost or time, or carries legal/security exposure; consider price adjustment or conditions

Each amber and red item gets: evidence, impact on the thesis, remediation, rough effort (person-weeks) and owner type (buyer, seller pre-close, counsel).

Gotchas

• Overall test coverage hides untested billing code. Measure coverage on critical paths.
• Commit counts reward small commits; use them for patterns, not performance judgments about individuals. Do not put named individual productivity rankings in the report.
• Code that looks clean can still run on an end-of-life runtime or framework; check versions against vendor support dates.
• Demo environments are curated. Ask for production metrics and incident logs.
• A great codebase with one engineer who knows it is a red flag, not a green one.
• AGPL or SSPL components in a hosted product can create obligations; route to counsel.
• Seller-provided reports (pen tests, SOC 2) have scope limits; read the scope section.

Verification

• Every rating cites evidence (file path, command output, document, interview).
• Each thesis question has an explicit answer.
• Remediation estimates add up to a total the user can compare with the deal value.
• Findings were shared with the user before any are discussed with the target company.

Report template

# Technical due diligence: <target> (<date>)
**Scope:** repos, environments, documents, interviews | **Limits:** what we could not access

## Executive summary
Overall: Amber. <3-5 sentences answering the thesis questions>
Top risks: 1. ... 2. ... 3. ...
Estimated remediation: <n> person-months before/after close

## Scorecard
| Area | Rating | Key evidence | Remediation (effort) |
|---|---|---|---|
| Architecture & scalability | Amber | Single Postgres primary at 70% CPU peak | Read replicas + queue for exports (6 pw) |
| Security | Red | 14 critical CVEs unpatched > 90 days; no SSO enforcement | Patch + policy (4 pw) |
| Licensing | Flag for counsel | AGPL component in hosted product | Legal review |

## Detailed findings
## Team and key-person risk
## Infrastructure and cost
## Items for legal / financial review
## Appendix: commands run, documents reviewed, interviews held