Skip to content
Devrecated Solutions

Standalone product

DocPuppet

Release evidence for a running application.

Point DocPuppet at a deployed origin and a spec. It plans the capture, writes stills, optionally records a video tour, writes handbook docs, and returns a verdict on whether the product matches the behavior the developer intended.
Product siteExample handbookAsk about pricing

The problem

Screenshots in a doc are stale the day after they are taken.

Release notes get written from memory, handbooks drift from the product, and nobody can say from the repository alone whether the deployed application does what the ticket asked for. DocPuppet makes that a step in the pipeline instead of a chore.

What a capture produces

Six artifacts from one run.

Stills
Every page in the spec, captured with reduced motion emulated so nothing lands mid-animation.
Video tour
An optional WebM walkthrough plus a clip per catalog page. Clips embed directly on the how-tos.
How-tos
Handbook pages written from the captured run, not from a template someone has to keep current.
What's new
A changelog assembled from commit subjects in your repository. Capture does not invent commit messages.
Verdict
Pass, fail, or uncertain on whether the running product matches the behavior the developer intended.
Machine output
JSON for your own tooling, and exit codes a CI job can branch on without parsing logs.

How it works

Spec in, evidence out.

  1. 01

    Write a spec

    A catalog of pages and steps, plus the origin to visit. Color scheme and dark mode are part of the spec.

  2. 02

    Plan the capture

    Run with --plan-only to review exactly what will be visited and shot before anything is written.

  3. 03

    Capture

    Playwright drives Chromium against the deployed origin and writes stills, clips, and handbook markdown.

  4. 04

    Read the verdict

    Exit 0 passes, 1 is a fail or uncertain, 2 is a usage error. Wire it into the release job as a gate.

doc-puppet capture \
  --origin https://app.example.com \
  --spec ./example/spec.json \
  --site --video --git ../example-app

One command. It runs without an Autodevelop login, without tickets, and without mail.

Two ways to run it

A CLI on your machine, or hosted per tenant.

Command line
Install the CLI, write a spec, and run it locally or in CI. Raw capture output stays on your disk. Handbook markdown and media land in your site tree, so you host the result wherever you already host docs.
Hosted
A multi-tenant service: connect the repository, and a push triggers a job that captures the deployment and publishes that tenant’s handbook. Sign-in, webhook, job runner, and per-tenant storage are part of the product.
See a generated changelogAsk about the hosted plan

Boundaries

What DocPuppet does not do.

The scope is deliberate, and we would rather state it here than in a support thread.

  • It does not send email. Confirmed stakeholder mail stays in Autodevelop.
  • It does not build PDF or slide share packs. Those are an Autodevelop skill, and they can attach a pack DocPuppet produced.
  • It does not write commit messages or release prose from a model. Changelog entries come from your repository.

Relationship to the flagship

One engine, two ways to buy it.

The plan, the pack, and the verdict are implemented once and shared. There is no second engine in the standalone product, so a capture behaves the same either way.

Autodevelop subscribers already have DocPuppet. See what else the subscription includes.

Put evidence in the release, not in a meeting.

Tell us the application and the release process you run today, and we will tell you whether this fits.

Talk to usAll products