| name | proposal-storytelling-and-evaluator-journey |
| description | Use when a proposal needs a stronger narrative spine, evaluator journey, case-study story, design rationale, executive argument, or presentation/sign-off flow. |
| metadata | {"portable":true,"compatible_with":["claude-code","codex"]} |
Proposal Storytelling and Evaluator Journey
Acknowledgement: Shared by Peter Bamuhigire, techguypeter.com, +256 784 464178.
Use When
- The proposal is technically correct but flat, fragmented, or hard to remember.
- The executive summary, understanding section, methodology, case studies, or presentation needs a clear narrative.
- The proposal must explain design, software, service, AI, or strategy decisions to different stakeholder groups.
- Evaluators need to see the journey from current state to desired state, not only a list of tasks.
Domain Method
- Define the evaluator's journey: what they believe now, what they worry about, what proof they need, and what decision they must make.
- Build a narrative spine: current situation, complication, decisive question, proposed answer, evidence, implementation path, and measurable outcome.
- Align each major section to the same spine so the cover letter, summary, methodology, experience, work plan, and price tell one story.
- Turn case studies into proof stories: context, stakes, intervention, decision logic, result, and relevance to this bid.
- Explain design decisions through audience-specific rationale: client goal, user need, evidence, trade-off, and approval point.
- Use storyboards or journey examples where they make a method concrete and help evaluators imagine the delivered service.
- For premium or public-facing writing, run the commercial writing gate so the story supports value, proof, risk control, and reader discoverability where relevant.
Quality Standards
- The story must be accurate and evidence-based; do not dramatise beyond the facts.
- Narrative should clarify logic, not add decorative language.
- Every story beat must support evaluator confidence in delivery, value, or risk control.
- Case studies must state role, scope, outcome, and relevance.
Existing Deliverables
- Proposal narrative spine.
- Executive summary and understanding-section improvements.
- Case-study story cards.
- Design-rationale and presentation language.
Do Not Use When
- Do not use this skill when a neighbouring specialist named in the description owns the primary decision; route there first and use this skill only as a supporting layer.
- Do not use it to invent buyer facts, evidence, legal positions, statutory rules, delivery capacity, or current external claims.
Inputs
| Artefact | Source/provider | Required? | Missing-input behaviour |
|---|
| ToR, evaluation criteria, core argument, proof points, section plan, and audience | Buyer, ToR, approved project record, accountable owner, or verified evidence source | Yes | Stop the affected decision, name the missing source, and return only a qualified outline or assumption register. |
Outputs
| Artefact | Consumer | Acceptance condition |
|---|
| evaluator journey and narrative map | Proposal writer and evaluator-review team | Claims trace to supplied evidence; assumptions, owners, exclusions, decisions, and observable acceptance tests are explicit. |
Evidence Produced
| Evidence | Consumer | Acceptance condition |
|---|
| Decision and source trace for the output | Reviewer and release owner | Each load-bearing choice identifies its source, rationale, accountable owner, and any unassessed check. |
Capability Contract
Default to read-only for analysis, critique, discovery, and review. Minimum capability is access to the supplied artefacts and permission to inspect or calculate relevant evidence. Edit only the requested working copy. Do not publish, send, spend, change production systems, certify compliance, make a statutory claim, or approve a commercial concession without explicit authority.
Degraded Mode
If required files, interviews, finance doctrine, search evidence, calculation tools, network access, or specialist review are unavailable, return the narrowest useful qualified result. Mark unavailable checks as not assessed, separate facts from assumptions, and state what is needed to resume. An unassessed gate is never a pass.
Decision Rules
| Choice | Action | Failure/risk avoided |
|---|
| Select narrative spine | Sequence problem, stakes, proof, method, confidence, and decision around evaluator criteria. | A memorable story that obscures compliance. |
| Evidence conflicts or authority is absent | Stop the affected recommendation, record the conflict, and seek the named owner’s decision. | Invented facts or unauthorised commitments. |
| Evidence and approval are complete | Proceed within scope and retain the decision trace. | Irreproducible approval or scope drift. |
Workflow
- Confirm the consumer, decision, neighbouring-skill route, authority, and required inputs; stop if the primary route or accountable owner is unknown.
- Inspect supplied evidence and record facts, assumptions, conflicts, and unavailable checks; stop on a load-bearing contradiction.
- Apply the domain method and decision rules, preserving the repository’s proposal voice and specialist constraints.
- Draft the contracted output with observable acceptance conditions and an evidence trace.
- Review alignment with scope, work plan, team, pricing, risk, and dependent proposal sections; recover by revising the affected choice and rerunning the check.
- Run the critical-analysis and anti-slop gates; block release on unsupported claims, failed safety or finance gates, or an F slop grade.
Quality Standards
- Every load-bearing claim is verified or explicitly qualified, and the output distinguishes fact, assumption, recommendation, and commitment.
- Scope, method, work plan, staffing, pricing, risks, dependencies, and acceptance conditions remain mutually consistent.
- The output preserves domain constraints, names accountable owners, covers failure paths, and blocks unsupported or unauthorised promises.
- British English and the repository’s East African professional tone are used unless the buyer requires another standard.
- The critical-analysis and anti-slop gates pass before release, with no unassessed check represented as passed.
Anti-Patterns
- Inventing a buyer fact or proof point. Fix: cite the supplied source or mark the statement as an assumption requiring confirmation.
- Treating an unavailable check as passed. Fix: mark it not assessed and name the evidence needed to resume.
- Copying a neighbouring skill’s method without routing. Fix: use the specialist for the primary decision and retain only the supporting layer here.
- Writing acceptance as “satisfactory” or “appropriate”. Fix: state an observable measure, evidence record, and decision owner.
- Adding premium or technical claims without delivery capacity. Fix: reconcile the claim with named people, time, budget, dependencies, and authority.
Worked Example
An evaluator scores feasibility before innovation. Open with the operating constraint and proof, then show the phased method; keep every required response easy to locate.
Evaluator proof and expert-positioning controls
Build an evaluator matrix before polishing the narrative: criterion, evaluator question, proposal location, claim, evidence, accountable source/role, acceptance test, risk, and review status. The journey is complete only when an evaluator can find the mandatory response, understand why the method fits, see credible proof, and identify how delivery will be checked.
When the proposal depends on expert-network, advisory, or interview-based credibility, screen the opportunity before using it: purpose and buyer need, subject-matter fit, conflicts, confidentiality, non-public information, client restrictions, compensation/contract terms, and the boundary between informed perspective and professional advice. Use the strongest relevant profile evidence; never imply experience, access, or authority that the source does not support. Record the screening decision and reviewer.
Run a short reviewer loop after each major revision: independent evaluator read, compliance check, evidence check, narrative consistency check, and decision log. Treat feedback as a hypothesis about evaluator confidence; change the proposal only when the evidence or criterion fit improves, then re-run the affected check.
References
