# Apptware Labs — repository self-evaluation A prompt you run yourself, on your own machine, with your own coding agent. **Why this exists.** Apptware Labs licenses production codebases to AI labs. Before anyone signs anything, both sides need to know what an estate actually contains. This prompt produces that picture without you sending us a single line of code. **What it costs.** Nothing. It runs inside whatever coding agent you already pay for — Claude Code, Cursor, Codex, Copilot, Gemini CLI. No account with us, no tool to install from us, no obligation at the end of it. **What leaves your machine.** Only what you decide to send. The prompt is written so the report contains no file paths, no function or class names, no author names, no commit messages, no branch names and no credentials. You read it before anyone else does. --- ## How to use it 1. Open your coding agent at the root of a repository you own. 2. Paste everything below the line. 3. Repeat for each repository, or point it at a folder containing several. 4. Read the report it produces. --- ## The prompt > You are running a repository evaluation for its owner. Work only inside the repository > you are pointed at. Do not push, commit, or modify anything. Read and report. > > ### Hard rules > > These govern the entire run. A report that breaks one is worse than no report. > > - **Never write to the repository.** No commits, no branches, no edited files. If a > measurement step would change the working tree, use a disposable copy or skip the step > and say so. > - **Never open or read credential material.** Skip `.env`, `.env.*`, `*.pem`, `*.key`, > `id_rsa*`, credential files, and anything under a `secrets/` directory. If credential > material reaches you some other way — inside a diff, a log, a file you opened for a > different reason — do not quote it, do not paraphrase it, and do not record where it > was. Say only how many files you skipped on this basis. > - **Keep identifying detail out of the report.** No file paths, no directory names, no > function, class or variable names, no commit hashes or messages, no branch or tag names, > no author names or email addresses, no client or product names. Counts and public > technology names are fine. "A reconciliation routine that handles partial settlement" is > fine. "`src/billing/reconcile.ts`" is not. > - **Never estimate a number you did not measure.** If a step cannot run, write `not > measured` and give the reason in a few words. Do not guess, and do not fill a gap with a > plausible figure. An honest gap is useful; an invented number makes the whole report > worthless. > > ### Phase 1 — Inventory > > Establish the basics from the repository itself, not from its README: > > - Primary language and any secondary languages, by share of code. > - Frameworks and major libraries, read from dependency manifests (`package.json`, > `requirements.txt`, `pyproject.toml`, `pom.xml`, `build.gradle`, `go.mod`, `Gemfile`, > `composer.json`, `*.csproj`, `Cargo.toml`). > - What kind of project it is: web application, API service, mobile app, library, data > pipeline, infrastructure, something else. > - Whether it is a monorepo. > - Whether it looks like real production software or a demo, a tutorial, or scaffolding > output. Say which and why in one sentence. > > ### Phase 2 — Scale > > Count functional source lines, **excluding** anything not authored by the team: > dependency directories (`node_modules`, `vendor`, `.venv`, `__pycache__`), build output > (`dist`, `build`, `.next`, `out`, `target`), lock files, minified bundles, source maps, > generated clients, test fixtures measured in megabytes, and binary assets. > > Use `cloc` if it is available. If not, count by file extension and say which method you > used. Report: > > - Functional source lines, and lines per language. > - Source file count, and test file count, counted separately. > - Any single directory holding more than 20% of the line count — name only its *kind* > ("a directory of generated tool output"), never its path. > > ### Phase 3 — History > > From git, on the default branch unless told otherwise: > > - Total commits, and the date of the first and last. > - Distinct authors. > - **Substantial commits**: commits touching more than 5 files *and* changing more than > 100 lines. Report the count and the share of all commits. > - Whether the history looks incremental or imported. A repository whose history is one or > two bulk commits has lost most of what makes it valuable, and it matters that this is > visible. > - Median lines changed per commit. > > ### Phase 4 — Does it run > > This is the single most load-bearing part of the evaluation, so run it properly, on a > **fresh clone in a temporary directory** so nothing touches the working copy. > > Determine the package manager and the declared runtime first — check `.nvmrc`, > `.node-version`, `engines`, `.python-version`, `requires-python`, the `go` directive, > `rust-toolchain`, `.tool-versions`, `global.json`. Then attempt, in order, recording the > exact outcome of each as `yes`, `no`, or `could not run` with a short reason: > > 1. **Install** — do dependencies resolve and install from clean? > 2. **Build** — does the build command complete? > 3. **Tests discoverable** — can the test runner *list* its tests? > (`pytest --collect-only`, `jest --listTests`, `go test -list .`, `cargo test -- --list`, > `mvn -q test -DskipTests` or equivalent.) Report how many it found. > 4. **Tests pass** — does the suite run green? Report passed, failed, skipped. > 5. **Coverage** — if a coverage tool is already configured, report the figure. Do not > add one. > > Distinguish clearly between *the repository failed* and *I could not run this*. A missing > language runtime on this machine is not the repository's fault, and saying so protects the > repository from being marked down for it. > > ### Phase 5 — Substance > > Read the code and the history and inventory the engineering work the repository contains. > This is a census, not a highlight reel: count everything that clears the bar, and never > pad. An ordinary item listed to reach a round number makes every count less useful. > > Count each of these, and for each one write a one-line description of the *shape* of the > work in words that would be just as true of the same problem in somebody else's codebase: > > | Category | What counts | > | --- | --- | > | `complex_logic` | Non-obvious algorithms, state machines, solvers, schedulers | > | `work_units` | Self-contained pieces of work a competent engineer could be assigned | > | `net_new_capabilities` | Substantial capabilities the codebase is shaped to support but does not have | > | `substantial_features` | Multi-file features the history shows were actually built | > | `defect_repairs` | Real bugs the history shows were diagnosed and fixed | > | `repo_evolutions` | Migrations, splits, interface redesigns the codebase went through | > | `hardening_work` | Validation, authorization, tenancy isolation, failure handling | > | `integration_work` | Third-party systems, protocols, external APIs | > | `performance_work` | Measured optimisation, caching, batching, query work | > > Also count `defect_repairs_with_regression_test`: fixes that shipped with the test > demonstrating them. These are worth more, and they are counted separately for that reason. > > Then compute the weighted total: > > ``` > total = 1.0 × complex_logic > + 1.0 × work_units > + 1.0 × net_new_capabilities > + 0.7 × substantial_features > + 0.7 × defect_repairs > + 0.6 × repo_evolutions > + 0.5 × hardening_work > + 0.5 × integration_work > + 0.5 × performance_work > + 0.4 × defect_repairs_with_regression_test > ``` > > And map it to a depth band: > > ``` > total < 0.5 → 0 total < 14 → 3 > total < 3 → 1 total < 28 → 4 > total < 7 → 2 total < 55 → 5 otherwise → 6 > ``` > > Finally, give a **self-containment** rating from 0 to 4: how much of this codebase could > be understood and worked on without access to systems, data or services that are not in > the repository. 4 means everything needed is present; 0 means it is unusable in isolation. > > ### Phase 6 — The report > > Produce exactly this, as Markdown, and nothing else. One block per repository. > > ``` > APPTWARE LABS — REPOSITORY EVALUATION > Repository label: (whatever the owner wants to call it) > Evaluated: (date) > Measured by: (agent and model used) > > INVENTORY > Primary language … > Other languages … > Frameworks … > Project type … > Monorepo yes / no > Production software yes / no — one sentence of reasoning > > SCALE > Functional source lines … (method: cloc / extension count) > Source files … > Test files … > Test-to-source ratio …% > > HISTORY > Commits … > Span … to … > Distinct authors … > Substantial commits … (…% of all) > Median lines per commit … > History looks incremental / imported in bulk > > RUNNABILITY points > Dependencies install yes/no/could not run > Build completes yes/no/could not run > Tests discoverable yes/no/could not run (… found) > ── Discover sub-score … / 8 > Suite runs and passes yes/no/could not run (…P …F …S) > Coverage reported …% / none configured > ── Observed sub-score … / 14 > ── RUNNABILITY TOTAL … / 22 > > SUBSTANCE > complex_logic … > work_units … > net_new_capabilities … > substantial_features … > defect_repairs … (… shipped with a regression test) > repo_evolutions … > hardening_work … > integration_work … > performance_work … > ── Weighted total … > ── Depth band … / 6 > ── Self-containment … / 4 > > WHAT THIS REPOSITORY IS ABOUT > Three to six themes, each a short phrase, no product or client names. > > THE STRONGEST MATERIAL IN HERE > Up to eight one-line descriptions of the most substantial work, shape only. > > NOT MEASURED > Anything that could not run, and why. Files skipped as credential material: … > ``` > > ### Scoring notes to include at the end of the report > > Reproduce this verbatim so the owner knows what the numbers mean: > > > Runnability carries 22 of the 100 points in Apptware Labs' valuation rubric — 8 for > > whether the project installs, builds and can list its tests, and 14 for whether the > > suite actually runs and passes. Across a 278-repository reference set, the correlation > > with delivered engineering value was strongest for tests being discoverable (+0.156), > > then dependencies installing (+0.141), then the build completing (+0.131). > > > > Commit count feeds a separate multiplier, which is why a repository imported as one > > squashed commit scores poorly however good the code is. > > > > This is a self-assessment. Apptware Labs re-measures independently before making any > > offer, and the figures here do not constitute a valuation. --- ## What raises the number, if you want to improve it first In rough order of value for effort: 1. **Make it install and build from a clean clone.** Commit the lockfile. Remove dependencies on registries an outsider cannot reach. Nothing else scores if this fails. 2. **Make tests discoverable.** Tests the standard runner cannot list score zero even when they exist. This is the strongest single signal in the whole instrument. 3. **Declare the runtime.** A one-line `.nvmrc` or `.python-version` stops the build failing for a reason that is not your code's fault. 4. **Ship a regression test with every bug fix.** It is the only explicit bonus in the weighting, and a handful can move a whole depth band. 5. **Never squash history when moving a repository between hosts.** This one cannot be undone later. --- ## What happens next No access, no code and no obligation at that stage. Nothing is shared before a mutual NDA, you keep ownership of everything under standard terms, and there is no cost to you at any point. *Apptware Labs Pvt Ltd — code acquisition and licensing.*