A prepared prompt architecture for generating relevant, meaningfully different proposals from résumé-like profiles—with a working example and an initial adversarial evaluation.
Your brief calls for a reusable system that extracts relevant information from different profiles and turns it into varied, high-quality proposals. The important design decision is where that variation comes from.
A candidate might be relevant because they can translate customer research into content, prepare approved work carefully, or help define what a project should learn. Those are different reasons to consider the same person. Changing a greeting, rearranging a skills list, or switching models does not necessarily uncover those differences.
I have already prepared a prompt system for this problem. It adapts evidence and communication principles from my related Marketing Practitioner project into a focused proposal workflow. The complete prompts, handoff contracts, and evaluation records are ready; this page shows the architecture and actual example outputs so you can assess the approach before proceeding.
The input is simple
Each request supplies one candidate profile and one target opportunity. Optional settings control language, format, length, voice, and the number of variants.
The system identifies which experience matters for that opportunity, preserves the strength of the original claims, and develops proposal directions the source can support. It can repeat this process for another profile without carrying accomplishments over from the previous candidate.
The same facts remain true across every version. A supporting role stays a supporting role. An unlisted qualification stays unestablished. A suggested future approach stays a suggestion rather than becoming a past achievement.
Three steps, with a clear job for each
Candidate profile + opportunity + output constraints
↓
PLAN — evidence and proposal directions
↓
WRITE — complete proposal variants
↓
REVIEW — grounding, usefulness, diversity
↓
Accepted proposals or a targeted repair
PLAN chooses the argument. It connects relevant profile excerpts to the opportunity’s requirements, records what each excerpt permits the system to claim, and selects distinct reasons to consider the candidate. Partial or transferable experience can support a proposal without being upgraded into direct expertise.
WRITE realizes those choices. It drafts the proposal set using the selected evidence and arguments. The writer can change expression and structure while preserving responsibility, experience level, qualifications, and the proposed scope of work.
REVIEW checks what the text actually says. It has access to the original profile and opportunity, not just the planner’s summary. It checks whether the claims are supported, whether the proposal answers the brief, and whether the variants express different arguments. Different strategy labels are insufficient if the prose makes the same case.
If the plan is sound but the wording drifts, only the affected draft needs rewriting. If the evidence match or strategy is wrong, the issue returns to planning. Both repair paths are specified in the delivered system; neither was triggered in the initial four-case evaluation below.
This is a prompt workflow with compact structured handoffs. It does not require a custom application to inspect or use the prompts, and it gives an engineer explicit contracts for later integration.
What the prompt controls
Two short excerpts from the prepared shared prompt show the distinction:
A job requirement establishes what is sought, not what the candidate has. An absent profile detail means “not established by this source”; it does not establish that the candidate lacks that experience or qualification.
Different labels, greetings, synonyms, sentence order, rhetorical energy, model identities, or CTA wording alone are expressive differences.
The first prevents a relevant opportunity from becoming invented candidate experience. The second prevents a set of paraphrases from passing as meaningful variation.
A working example: three arguments from one profile
Synthetic demonstration. The candidate, companies, and project details in this example are fictional test inputs. These are actual outputs from the prepared workflow, not a client testimonial or evidence of hiring results.
The candidate, Maya, has documented lifecycle content experience: synthesizing 24 supplied interview transcripts, writing six onboarding emails and three help articles, building approved emails in Customer.io from maintained templates, creating a QA checklist, and coordinating review comments. On a separate project, she documented a test brief and maintained interpretation notes. Strategy approval, rollout, and engineering remained with other owners.
The opportunity asks for research synthesis, five onboarding emails, two help articles, approved Customer.io preparation, review coordination, and an explicit learning question. It also asks for an artifact the candidate could share, with no links or pricing.
The planner selected three directions:
| Direction | Evidence doing the work | Reason to consider the candidate |
|---|---|---|
| Research into coordinated content | Supplied-transcript synthesis, message map, email and help-article writing | Connect existing customer questions to the content the project needs |
| Preparation and review reliability | Template-based builds, QA checklist, approval log, handoff guide | Keep approved content, checks, and review responsibilities connected |
| A clear learning purpose | A separate test brief and interpretation notes | Help define what the refresh should learn while the manager retains decisions |
The outputs below are reproduced unchanged. Their shared experience provides continuity; their main arguments and proposed first steps provide the variation.
Proposal 1 — Start from the customer questions
Your five onboarding emails and two help articles could start from one shared map of customer setup questions, giving each piece a clear purpose.
At Cedarpath, a scheduling software business, I reviewed 24 interview transcripts supplied by our researcher and grouped recurring setup questions into a message map; product marketing approved positioning. I wrote six onboarding emails and three setup help articles. That experience is directly relevant to connecting your existing research with both formats.
For the first stage, I would group recurring questions in your research notes, then propose a five-email outline and two supporting article topics for product marketing and support to review. The outline would also provide a basis for selecting a focused learning question with your lifecycle manager.
I have built approved emails in Customer.io using templates maintained by a lifecycle lead, checked links, merge fields, and mobile previews, and coordinated review comments in an approval log. After confirming your available template setup, I would prepare approved content and carry out those checks, with segmentation and rollout remaining with your lifecycle manager and instrumentation with engineering.
I can share a redacted onboarding sequence on request.
Proposal 2 — Keep preparation and review connected
I could support your refresh by keeping approved copy, Customer.io preparation, review decisions, and QA connected through clear handoffs.
For an onboarding project, I built approved emails in Customer.io using templates maintained by the lifecycle lead. I created a 28-item checklist and used it to check links, merge fields, and mobile previews. I also coordinated comments from product marketing, support, and the lifecycle lead in an approval log, and wrote a handoff guide covering status, owners, QA checks, and unresolved questions.
My contribution also covered the content: I synthesized 24 supplied interview transcripts into a setup-question message map and wrote six onboarding emails and three help articles. That gives me relevant experience across your research, writing, and preparation scope.
I would begin by reviewing your existing research and available content and build materials, then establish a compact approval log for the five emails and two articles. It would identify review owners, open questions—including the intended test learning question—and QA checks. Before preparing approved emails, I would confirm the available Customer.io template setup. Your lifecycle manager would retain segmentation and rollout, with engineering owning instrumentation.
I can share my QA checklist on request.
Proposal 3 — Make the learning question explicit
I would make the refresh’s learning question explicit early, so the five-email sequence and two help articles have a clear question to inform their development.
On a separate trial-recovery project, I wrote two subject-line alternatives and documented an A/B test brief with a primary metric, audience rules, and a decision date. The lifecycle lead selected the final test and owned rollout; I maintained weekly test-status and interpretation notes. That experience is relevant to supporting your lifecycle manager with a concrete proposal for what to learn.
For the first stage, I would review your supplied research and propose a focused content question, connecting it to an email and article outline. I would draft a test brief with a proposed primary metric, audience rules for manager confirmation, and a decision point, while surfacing measurement questions for engineering. Test selection, segmentation, and rollout would remain with your lifecycle manager.
My onboarding experience includes synthesizing 24 supplied transcripts, writing six emails and three help articles, and preparing approved emails in Customer.io using maintained templates. I checked links, merge fields, and mobile previews, and coordinated product marketing, support, and lifecycle review comments in an approval log. I would confirm your template setup before preparing approved content.
I can share a redacted onboarding sequence on request.
What was checked
I froze the prompt system before testing it against four synthetic cases. Separate model calls executed planning, writing, and review. Additional fresh model reviewers then compared the results with the original inputs and prewritten evaluation criteria, followed by a lead review of the evidence.
| Test situation | Observed result |
|---|---|
| Strong direct fit | Three proposals accepted, with different research/content, QA/handoff, and learning arguments |
| Partial or adjacent fit | Three proposals accepted; library documentation remained transferable experience rather than becoming invented healthcare expertise |
| Adversarial overclaim | Three proposals accepted; instructions to invent senior fintech experience and an activation result were excluded, while the legitimate required opening was preserved |
| Five variants requested from a thin profile | One useful proposal returned with an explicit shortfall explanation, rather than forcing five directions |
Across those runs, ten proposals were accepted and nine actual proposal pairs were judged meaningfully distinct. Checks also covered source excerpts, responsibility boundaries, required answers, length limits, and the consistency of the handoffs. No prompt repair was warranted by a verified failure in this evaluation.
These are initial results from one run of each synthetic case on one host model. They do not establish hiring response rates, broad reliability, or performance across providers. The five-variant case tested restraint under count pressure; because it produced one draft, it did not test a reviewer against ten pairs of deliberately duplicated proposals. The complete evaluation record retains those limits.
Where model diversification fits
The default is one writer producing the planned set. The architecture also allows strategies to be assigned to different models, with each receiving the same source material and frozen plan. Their outputs still go through a whole-set review.
That gives different models room to realize an argument in their own way without granting them permission to invent a new candidate history. Another model can also provide a critique perspective. Multi-model routing is specified, but its benefit has not been benchmarked in this evaluation.
The $150 handoff
The prepared scope is a reusable prompt package, with one round of adjustment to the agreed input/output needs:
- Complete production prompts: shared instructions, planner, writer, and reviewer, with explicit inputs and outputs.
- Input and handoff contracts: profile, opportunity, output constraints, evidence, strategies, drafts, and review decisions.
- Execution instructions: call order, optional multi-model assignment, acceptance rules, bounded retries, and targeted repair.
- Evaluation materials: the four synthetic cases, expected boundaries, captured results, and the evaluation report.
- A worked example: the profile-to-plan-to-output chain illustrated here.
The package covers prompt architecture and content generation behavior. Application development, API integration, a user interface, and a multi-provider benchmark would be separate work.
Ready for the next step
The core package is already prepared, so we can use the engagement to confirm fit rather than restart the design. If this approach matches your workflow, we can agree the $150 milestone and I can hand over the complete system once it is funded. A representative profile and opportunity from your workflow would give the included adjustment round a concrete target.