Redential CLI

@redential/cli reads your local git history and turns it into a metadata-only proof: volume, span, cadence, languages, technical categories, signed commits, ownership share. Never the code itself.

npx redential scan

That's it. No login, no config, nothing installed globally. scan makes zero network calls: on a real terminal it prints a human-readable summary, or pipe it (or pass --json) for the exact JSON it would ever upload. Either way, nothing is sent: you review it before anything else happens. redential is a bare-name alias of the canonical package, @redential/cli.

Your best work is probably under an NDA

The years you spent building payments infrastructure, hardening auth, or carrying on-call can't go in a portfolio, because none of it can leave your employer's repo. Redential's GitHub App proves work from a repo you can connect. The CLI is for the repos you can't: it reads what happened locally and produces a bundle that proves the shape of your activity without ever exposing the code.

Install

No install needed for a first look. npx runs the latest published version directly:

npx redential scan
npx redential login
npx redential submit
npx redential logout

redential is a bare-name alias package: a minimal launcher with a floating dependency on the canonical package, @redential/cli. npx redential scan and npx @redential/cli scan run the exact same published code either way.

Prefer a persistent install:

npm install -g redential
redential scan

Requires Node.js 20 or later. Every release is published from GitHub Actions on a tagged commit with npm provenance (npm publish --provenance), never from anyone's laptop. Verify any installed version was built from the published source with npm audit signatures.

Quick start

Full flag reference, exit codes, and real output examples (including the terminal summary): Commands.

Private label: a nickname only you ever see

Every redential submitnow sends a private label: a short nickname for the repo ("Acme Corp backend", "ClientCo Q3 contract"), typed once and mandatory. It exists so you can tell "Acme Corp repo #1" from "Acme Corp repo #2" on your own dashboard, not to identify you to anyone else: it is visible to you, the account owner, only, never shown on your public profile or to anyone else.

The label travels alongside the bundle, never inside it: submit sends it as a second HTTP request, only after the bundle upload itself has already succeeded, so it is never a bundle field and causes no schema change. It passes the exact same secret-scan the bundle payload itself is checked against. A secret typed into the label blocks the whole submit, nothing uploads, not even the bundle.

Private label for this repo (only you will ever see it): 

Pass it up front with --label <text> to skip the prompt, or when running non-interactively (a script, CI): it is required in that case, checked before any network call at all. If the label request fails after the bundle already uploaded successfully, submit never retries it and never re-uploads the bundle. It prints a warning and still exits 0, since the bundle itself is safely stored. That same recovery path, setting or editing the label later from the dashboard, is the general way to change it after the fact: it is never written to any local file on your machine.

Structural detection & explain

Ordinary skill detection matches a single line of a diff against a signature: a package import, a config file, an API-call shape. Structural detection goes one step further for a closed set of payment integration shapes: it follows connected relations in your own code, such as a webhook handler that verifies a provider's signature, feeding a database write, guarded by an idempotency check, and infers the skill from that shape, entirely on your machine, with zero network calls and no LLM.

Since schema 1.2.0, a detected skill can carry two optional fields: evidence ("import" or "structural") and confidence ("direct" or "inferred", only alongside evidence: "structural"). "import"is reserved for a future change and isn't emitted in 1.2.0: an absent evidence field already means an ordinary import-tier match. "direct" means the connected shape sits in one function or file; "inferred"means it was found across files, within a bounded search. A pattern that's present but not fully connected classifies internally as ambiguous and is never emitted in any bundle, under any field: there is no bundle representation of "maybe". See Trust & privacy for the full field contract.

redential explain <skill>is a local-only diagnostic for this: it prints why a structural pattern was (or wasn't) detected in the current HEAD snapshot, the classification, matched anchors, how they connect, and whether it's attributed to your own commits, all without ever writing a file or touching the network. Today it can only explain the six structural patterns the CLI ships (Stripe, PayPal, Mercado Pago, Lemon Squeezy, and Paddle webhook flows, plus IAP/RevenueCat purchase flows); every other, ordinary import-tier slug isn't covered by explain yet. Full usage and an illustrative walkthrough: Commands.

FAQ