Employee handoff design · review before skill build

One clear route from prospect URL to signed contract.

This page defines what the future employee package must feel like on a separate Codex computer. It is the operating model and acceptance target. The skills, ZIP, and employee test have not been built yet.

DESIGN SPEC · NOT YET IMPLEMENTED

The end result

The employee can operate the whole sales path without the original chats.

They receive one versioned local ZIP and a matching standalone Markdown attachment in Matt’s message. Codex places the files in the correct skill folders, checks access, and guides the employee through a test run. The employee starts from one prospect URL, prepares a call, sends a case-specific offer, and prepares an editable contract. Sending, signing, and binding commercial decisions remain visible states.

Operating rule: the package must answer “What do I run now?”, “What file proves it?”, and “What do I do when a value is missing?” without requiring Matt to reconstruct the system.

Authority

Equal partner

The employee is an equal business partner with full commercial decision authority. They can choose new-deal terms and record them. Agreed client obligations remain authoritative. A template default never overrides their decision.

User requirementDefaults are guidance

Codex recovers missing facts first, then asks the operating partner only for an essential unresolved decision. It does not send routine decisions back to Matt or invent client facts.

The route the employee sees

Four stages, one run manifest

1 · PrepareURL → source packet → reviewed HTML index

›

2 · ImproveTwo Gemini homepages → Luna QA → repair

›

3 · OfferCall facts → exact offer → Missive draft/send

›

4 · ContractAccepted terms → HTML review → DocuSeal

BuiltLocal files exist and pass structural checks.

ReviewedComment-host URL is editable and read back.

Drafted / published / sentThese are separate provider states, each read back.

Accepted / signed / paidNever inferred from a draft, URL, or submission alone.

Build order

Design first, then prove, then package

NowReview this HTML operating model.

›

EvidenceAudit ten joined historical journeys.

›

DesignWrite companion skills and templates.

›

ProveRun the slice and fresh-computer test.

›

DeliverExport the ZIP, Markdown, and receipts.

Communication templates depend on the ten-case audit. Gemini integration and evidence collection can run in parallel after this design review. Packaging is verified from the final combined result.

What is evidenced today

Keep the verified base

The current sales-prep defines the HTML asset pipeline. Matt considers those assets sufficient. Reuse them as the base instead of redesigning the preparation report.
Recent Missive offers show recurring patterns: a personal recap, exact scope and price, optional Ads, payment terms, delivery conditions, and a short signing handoff.
Seven DocuSeal documents were inspected and show several real clause profiles. This is useful evidence, but it is not yet ten complete prep → call → proposal → email → contract journeys.
The review host provides stable commentable URLs. Website outputs still need the Luna section screenshot, fix, and fresh QA loop.

Evidence

What this project requires

Build around the employee

Leave sales-prep, offer-in-email, and contract-html-to-docuseal untouched.
Use a local ZIP plus a standalone Markdown handoff. GitHub is not an employee prerequisite.
Use rakamazablak.hu as the first controlled end-to-end fixture.
Use different Gemini templates: the first call receives untitled folder/new_template.html; the second receives reusable-template-kit/template-v2.html.
Before final communication templates, inspect ten joined historical journeys and label examples as examples.

Explicit requirement

The ZIP the employee receives

A package that explains itself

Top level

clientsflow-sales-operator/
  START-HERE.md
  SETUP-CHECKLIST.md
  ACCESS-MAP.template.md
  RUNBOOK.md
  CHANGELOG.md
  checksums.sha256
  skills/
    <employee-skill>/
      SKILL.md
      templates/
      examples/
      references/
  test-fixtures/
  receipts/

What belongs in each area

START-HERE: the first command, expected output, and recovery path.
SETUP-CHECKLIST: where Codex copies each folder, how to verify discovery, and how to roll back a mistaken copy.
skills: only the employee-facing companions and required dependencies. Protected originals are preserved separately.
templates, inside their skill folders: reusable offer and contract files. Each SKILL.md says exactly when to load a template, which fields to fill, and how to validate the result.
examples, inside their skill folders: anonymized historical examples with source locators kept in a private evidence ledger. Never copy their price or signer automatically.
test-fixtures: rakamazablak.hu packet, expected file map, and an internal recipient only.
receipts: checksums, model requests, QA reports, review URLs, and provider readbacks.

Portability test: the employee must be able to move this ZIP with Codex, not with a hand-written Mac path. The package includes a machine-neutral destination map, SHA-256 manifest, copy verification, and rollback instructions. Any machine-specific path is either resolved during setup or marked as a deliberate access dependency.

First five minutes · proposed operator experience

Give Codex the Markdown and the ZIP

The standalone START-HERE.md is the canonical handoff, adapted from handoff-to-dani: objective, read-first files, authority, destination map, validation, evidence, and recovery. It must work before installation. The HTML is its explanation.

First prompt to Codex

Read START-HERE.md and inspect the matching ZIP.
Set this sales package up on this computer.
Verify the package version and checksums.
Preserve existing skills and install the named companions.
Check dependencies and authorized service access.
Then run the internal rakamazablak.hu rehearsal.
Report ready stages and the exact action for any gap.

What happens without Matt managing it

Codex detects the employee’s operating system and home folder, then uses the documented supported installation route.
Codex validates the archive, resolves dependencies, copies actual files rather than broken symlinks, and verifies skill discovery.
The employee completes their own logins or access grants when needed. Credentials and Matt’s browser sessions are excluded from the ZIP.
A setup receipt names the installed version, available services, affected gaps, and first usable action.

Build and test on a clean local installation first. The employee’s actual computer is a separate acceptance step. A simulated clean install must not be labelled as that real-device test.

Stage 1 · the concrete homepage test

rakamazablak.hu proves the vertical slice

Employee invokes the new preparation facade with the prospect URL.
Existing sales-prep assets are located in the lead folder. The run manifest records their paths and hashes.
Both independent Gemini 3.1 API calls receive the same four shared inputs: image catalog JSON, scraped copy JSON, main-keywords Markdown, and the unchanged prompt from handoffs/sales-prep-gemini-homepage-prompt.md.
Gemini call A receives /Users/agency/Desktop/untitled folder/new_template.html as its fifth input.
Gemini call B receives /Users/agency/Desktop/reusable-template-kit/template-v2.html as its fifth input. The two template inputs are intentionally different. Package both template files and the fixed prompt as portable, checksum-verified resources. These are original source locations on Matt’s computer, not paths the employee must recreate.
Each call saves the original monolithic HTML before any repair. No paid generation is repeated after an interruption.
Both variants are staged. Luna inventories every visible section and meaningful desktop/mobile state, repairs concrete failures, and runs fresh QA against the repaired pages.
Comment-html-review-host publishes both final pages. Verify desktop/mobile behavior on the actual final hosted URLs. The index links the source assets, originals, repaired files, QA reports, and two review URLs.
Save the source JSONs, keyword Markdown, HTML assets, and index.html under ~/Desktop/LEADS/rakamazablak.hu/. Resolve the employee’s real Desktop path at setup. Apply the review layer to every delivered HTML.
Add the parameterized ClientsFlow ROI calculator to the index. Preserve budget, cpc, conversion, close, revenue, margin, fee. Show assumptions separately from measured values. Required starting calculator scenario.
Import all final preparation HTML, both homepage variants, and the index into one new Figma file. Record frame IDs and verify visible content. Prove this after the core homepage path, but retain it as a required full-package result.

Stop condition: a page that is generated but has not passed fresh visual QA is a draft. A review URL is not proof that the page was sent to a client.

Stage 2 · after the call

Offer operation

Recover the exact transcript, call facts, current correspondence, and selected prep evidence.
Fill a deal record: scope, page count, exact price and tax basis, payment split, deadline or delivery trigger, expiry or bonus, optional Ads, next-call date/time, exclusions, and accepted state.
Select the appropriate new offer template. Examples guide tone and structure, never terms.
Prepare the complete message and validate every exact commercial field against the deal record. Draft mode stays unsent. An explicit send invocation includes its recipient, channel, and purpose and proceeds to a verified send without a redundant approval step.
Use the authorized Missive route. Read back the message state and preserve a receipt.

Exact terms requiredMissing terms become exceptions

Stage 3 · accepted offer

Contract operation

Select the clause profile that matches the accepted deal. Do not combine the most generous terms from different historical contracts.
Generate one standalone HTML contract with client facts and accepted terms filled in.
Apply comment-html-review-host. The employee edits the hosted HTML and identifies the final revision.
Use a new employee finalization companion after the edited HTML is ready. It may reuse the protected contract-html-to-docuseal implementation, but must enforce the complete signing-URL and Missive-draft handoff without changing the original skill.
Verify the PDF, recipients, fields, submission, signing URL, and unsent Missive draft. Return the client signing URL in chat.

Review before finalizationDraft does not mean sent

The ten-journey evidence audit

Templates come after the evidence, not before it

The new employee pack should contain a small communication library only after an agent checks ten complete journeys. Begin with the latest sent proposals and their matching contracts, then widen the date range until ten complete cases are verified. A proposal contained in its sent email counts as one artifact serving two roles, not a missing extra document. Each row must join the same client and deal revision across these five source roles:

Prepsource assets and audit

Calltranscript and agreed facts

Proposaldraft or working document

Emailactual outgoing Missive

Contractactual DocuSeal document

Audit output	What it answers	Acceptance
Term ledger	Which facts actually survived from call to contract?	Every price, scope, payment, schedule, correction, warranty, signer and optional service has a source pointer.
Template rules	What repeats, and what must remain case-specific?	Rules separate tone and structure from commercial commitments.
Examples	What does a good offer, email, and contract look like?	Examples are anonymized or clearly labelled. No example value is silently reused.
Exception list	Where did the path break or change?	Conflicts are reconciled against later accepted terms. Unresolved essentials go to the operating partner. Incomplete cases are listed and do not count toward ten.

Expected library: a call-facts record, website proposal/offer, website plus optional Ads offer, short follow-up/signing email, and HTML website/recurring-service contract families where the evidence supports them. Each carries a selection rule, required fields, a worked example, and validation. Every resulting rule points back to evidence or a current explicit requirement.

Evidence limit today: the prior review inspected seven DocuSeal documents and a targeted Missive corpus. That supports the pattern inventory, not the completion of this ten-journey audit.

Employee test before rollout

Fresh computer, no memory of the project

Copies the ZIP with Codex and confirms every skill is discoverable.
Runs the rakamazablak.hu fixture, finds the final index, and opens both generated review links.
Explains original HTML, repaired HTML, review URL, and staging URL.
Runs the required Luna desktop/mobile check and resumes after a deliberate interruption without paying for duplicate Gemini calls.
Creates an offer draft from exact test facts without importing a historical price.
Edits one contract review, then completes a separate controlled internal DocuSeal rehearsal. Verifies the signing URL in chat and in an unsent Missive draft. No client send or real signature is required for this test.
Finds a template and worked example, records a partner-selected term, and catches a conflicting historical price without inventing a replacement.
Verifies calculator parameters and Figma frame coverage, and records provider access gaps stage by stage.

What Matt reviews

Three checkpoints

This operating model.
The LLL verification board before launch.
The final ZIP, Markdown, and employee rehearsal receipt.

Matt reviews outcomes and material exceptions. The partner owns setup and commercial decisions. Retire competing entry points only after replacements pass and a dependency scan and recoverable archive exist. Preserve the three protected skills and shared dependencies.

Next step recommendation

Use this page to shape the build, then run one bounded LLL goal.

Use this operating model as the input to LLL Prepare. One executor owns the package and its acceptance evidence. After launch, it can run the ten-journey evidence audit and Gemini integration in parallel, then integrate the communication templates, test installation and recovery, and export the ZIP. The new skills are created only after this explanation exists. The employee’s real-machine rehearsal is the final onboarding proof.

Recommended sequence: LLL Prepare from this page → one review of the board → Launch → one review of the tested ZIP and rehearsal receipt. Comments on this page can feed the same board, without another questionnaire.

Not started here: no production skill was modified, archived, or executed. No offer was sent and no contract was created.