Skip to content
DeepShellDeepShell
Research and decisions · Construction teams

Draft a variation request from the spec

Use selected browser sources to draft a variation request from the spec. DeepShell assists with draft work; you prepare the inputs, verify the evidence, and complete any external action.

Process guideIllustrative — extension test pendingUpdated 2026-09-06

Before you start

Inputs: Approved specification and documented requested change.

Define: the audience, date or version, comparison criteria, and intended destination.

Access: open the sources yourself and select only content you are authorised to send to a model provider. Inaccessible or unselected pages are outside the task.

The process, step by step

  1. 1
    You complete

    Prepare approved specification and documented requested change. Confirm you can share the selected material with a model provider.

  2. 2
    You complete

    Open the relevant pages or attachments, select the sources in the panel, and set the scope. Log in or navigate to any required pages yourself.

  3. 3
    DeepShell assists

    Prepare an editable draft using only the supplied facts. Request: Original requirement, Proposed change, Reason, Unconfirmed impact, Approval needed.

  4. 4
    You complete

    Verify recipient, names, facts, tone, and approval before copying or sending.

  5. 5
    You complete

    Review the final text, then copy it into the intended application. You approve and send or publish it yourself.

Requires another tool: sending, publishing, form submission, CRM updates, purchases, and schedules are outside this extension workflow. Use the destination application yourself.

Your reusable workflow pack

Replace bracketed fields before use. Keep the sources and output together for the next reviewer.

Reusable prompt
Task: Draft a variation request from the spec.
Use only these selected sources: Approved specification and documented requested change.
Audience: [add the intended reader].
Scope: [add dates, criteria, versions, or exclusions].
Return these fields or sections: Original requirement, Proposed change, Reason, Unconfirmed impact, Approval needed.
Cite the source and page or section for factual statements. Mark missing information as "Not stated". Separate facts from assumptions. Do not invent figures, decisions, or events.
Finish with unresolved questions and a review checklist. Do not send, submit, purchase, or update another system.
Output template
Original requirement: [fill from the selected source; otherwise Not stated]
Proposed change: [fill from the selected source; otherwise Not stated]
Reason: [fill from the selected source; otherwise Not stated]
Unconfirmed impact: [fill from the selected source; otherwise Not stated]
Approval needed: [fill from the selected source; otherwise Not stated]

Output structure

Construction & property managementIllustrative workflow
Example output

Original requirement / Proposed change / Reason / Unconfirmed impact / Approval needed

  1. 01Original requirement: [source-grounded original requirement]
  2. 02Proposed change: [source-grounded proposed change]
  3. 03Reason: [source-grounded reason]
  4. 04Unconfirmed impact: [source-grounded unconfirmed impact]
  5. 05Approval needed: [source-grounded approval needed]
Reusable output template. Bracketed fields are placeholders, not observed results. Replace them only with information supported by your selected sources.

Review, then complete the process

  • Verify recipient, names, facts, tone, and approval before copying or sending.
  • Have the appropriate domain professional review the original material and the output before acting on it.
  • Every material claim has a source you can open and inspect.
  • Missing information is explicitly marked; no placeholders remain in the final deliverable.
  • A named person has approved the result before it is shared or used.

Review the final text, then copy it into the intended application. You approve and send or publish it yourself.

Done means: the intended reviewer can trace the result to its sources, all missing details are resolved or explicitly flagged, and any external action has been completed by an authorised person.

If the result is incomplete

Check source selection and access first. Narrow the question, specify the missing field, or supply an authorised source. For long or scanned documents, verify that the relevant text is readable. If evidence is still missing, record the gap rather than accepting an invented answer.

Time, cost, and validation

No measured run time, cost benchmark, or end-to-end extension test is recorded for this guide. Actual cost depends on source length, model, and retries. Use the settled receipt from a real run; do not treat the example as a performance promise.

Practical questions

What should I prepare?

Approved specification and documented requested change. Define the audience, scope, and required fields before you start.

Which steps are automated?

Prepare an editable draft using only the supplied facts. Source selection, review, and any sending, submission, or system update remain your responsibility.

What if the source is incomplete?

Keep missing values marked as Not stated. Add an authorised source or narrow the task; do not ask the model to fill gaps with plausible facts.

Has this workflow been tested in the extension?

This is an illustrative process guide. No end-to-end extension test or measured cost benchmark is recorded for this guide.

Continue the work