Recover an interrupted AI document job before starting another one
Retrieve the existing result before retrying, then separate replay evidence, source checks, and present spending.
Where it came from: October 21 verification replayed the same pre-existing completed synthetic Dokyumi request twice and read the same saved extraction. It did not establish a fresh extraction or new debit.
Package status: Draft package; structurally checked; not verified in Claude.
You give it
- Existing job/request identity
- Source document identity
- Schema/settings
- Authorized status and result tools
You get back
- Recovered result or unresolved state
- Source and schema match
- Replay and debit evidence receipt
- Next action
The invoice upload appears to hang. The page refreshes. The result is gone, so the obvious next move is to upload the file again.
The service may already have finished the first job. A failed screen and a failed operation are different events. Repeating the upload can leave you with two results, two charges, or two downstream entries for the same invoice.
The recover-document-job skill gives Claude a procedure for finding the existing result and reporting what happened before anyone starts another operation.
The saved request is the starting point
In an October Dokyumi verification, two calls replayed the same pre-existing completed synthetic invoice request. Both returned the same extraction identity. Reading the saved extraction confirmed that it was already complete.
That record demonstrated recovery of a saved result. It did not demonstrate a fresh extraction, a new charge, or general extraction accuracy. That distinction is the useful part of the workflow. A response can carry the original processing time and credits used without describing work performed by the recovery call.
The reusable skill preserves that distinction. It starts with the existing job, the source document, the intended schema, and the last known state. Claude uses whatever authorized status and retrieval tools the service actually provides. The skill itself does not add a connection to an extraction service.
Match the document before trusting the result
Consider an illustrative case: an accounts-payable operator submits invoice.pdf and loses the browser connection. The saved job reports complete, but another upload has the same filename.
A filename is too weak to settle the identity. The operator needs the service's attachment identity, a source hash, or another reliable match. Claude should also compare the schema and processing settings. A result for a different invoice or an earlier schema can be perfectly valid and still be the wrong result.
Once identity is established, the skill separates the possible states. A completed job needs retrieval. A running job needs observation through the documented status mechanism. A failed job needs the service's retry rules. An inaccessible job remains unknown. None of those states is improved by pretending a timeout settled the question.
A replay needs its own evidence
A job ID, a provider's historical request ID, and a client idempotency key are separate objects. An idempotency key is the identity a service may use to recognize a repeated operation. Its behavior depends on the service, including how long it is retained and which request fields must stay the same.
The skill tells Claude to check those rules before replaying anything. If a call only retrieves an existing result, the recovery can continue within the authorized task. If it may begin new processing or spend credits, the authorization must cover that action. Changing the source or schema may create a new operation even when the filename stays the same.
The receipt should make the distinction readable: existing result recovered; source identity matched; schema matched; important fields checked against the invoice; saved replay confirmed; current charge evidence unavailable. If a live ledger establishes whether money moved, record that separately from historical credits metadata.
Recovery ends with a usable handoff
An illustrative request is:
Use recover-document-job to inspect this interrupted invoice request. Retrieve the existing result if it is complete. Match the source and schema, check the required fields, and tell me whether the evidence shows a replay or new processing. Do not start another extraction.
Claude should return either the recovered artifact and its checks or a specific unresolved condition. An extraction that passes schema validation still needs review against the source. Recovery also does not approve the invoice or enter it into the accounting system.
Start with one interrupted job whose source and original identity are available. The useful first outcome is modest: the right result, tied to the right request, with a clear account of what remains to be checked.
Use recover-document-job to inspect this interrupted invoice request. Retrieve the saved result, match source and schema, and distinguish replay evidence from new processing. Do not start another extraction.
/plugin marketplace add johnarndt/john-lab /plugin install john-lab@john-labDownload recover-document-job.zipView on GitHub
View SKILL.md
--- name: recover-document-job description: Recover an interrupted document-processing job from saved state and distinguish a replay from new processing, duplicate work, or an unresolved outcome. --- # Recover a document job Use this when a document extraction or conversion appears interrupted and a prior request may already exist. Do not restart a job merely because its client timed out. ## Establish the identity Collect the service, existing job or request identifier, source identity, intended schema or conversion settings, and the last observed status. Use a source hash or service-held attachment identity when available; a filename alone may be ambiguous. Keep secrets and source-document contents out of operational logs. Separate a job ID, historical provider request ID, and client idempotency key. They serve different purposes. Use the service's documented key and replay behavior; do not manufacture a replacement key or infer retry safety from a successful HTTP response. ## Inspect before retrying Prefer status and result reads through available authorized tools. Classify the existing request as completed, running, failed, absent, or unknown. If completed, retrieve its saved result. If running, follow the documented status mechanism. If absent or failed, determine whether an authorized retry can reuse the original identity. A missing read permission or unavailable status endpoint leaves the outcome unknown. Replaying an existing completed request is appropriate only when the service documents it as retrieval without a new operation. If replay may start new processing, consume credits, or duplicate a write, require authorization for that action unless already granted. A new source, schema, or processing configuration is a new request unless the service explicitly supports updating the existing one. ## Verify the recovered result Match source identity and schema/settings to the intended job. Record returned extraction/job identity and replay markers. Check required fields and validation warnings, and compare material extracted values to the original source when accessible. A valid schema or confidence score alone does not establish correctness. If the source is unavailable, say the result was recovered but source review is pending. Treat saved credits, model names, processing duration, and historical request IDs as metadata about the prior execution. To establish a new debit or fresh provider work, use current transaction or execution evidence. Without it, classify new spending as unknown; never infer a new charge from a saved credits-used field. ## Return a recovery receipt Include the existing job identity, observed status, identity match, recovered artifact location, validation/source-review findings, whether the response is a saved replay or fresh execution, and the evidence for any debit classification. Record unknowns next to their consequences. Give the next safe action for unresolved cases. Stop when the saved result is recovered and checked, or when an access/identity/side-effect uncertainty prevents a safe continuation. Do not loop through retries with new keys. Recovery does not authorize emailing, posting, purchasing, or approving the extracted data.