Story Bank Builder
REQUIRED BACKGROUND: Use career-state-protocol. Use project-deep-dive when a source project is too thin to support a story.
Goal
Build a compact portfolio of distinctive, evidence-backed stories that covers the candidate's real interview needs. Optimize for coverage and defensibility, not a fixed story count.
Inputs
Read the Career Profile, P### dossiers, confirmed and bounded C### claims, existing S### stories, target models when available, and prior interview use or feedback. Do not invent missing project detail in the story layer.
Workflow
- Build a coverage matrix from the supplied
T### model. Without a target, use broad career signals such as ownership, ambiguity, product or technical judgment, evaluation, collaboration, conflict, failure, customer or user insight, measurable impact, and learning.
- Inventory candidate events that contain a real tension, decision, action, result, or changed operating method.
- Score each event for relevance, evidence, ownership, distinctiveness, follow-up safety, and overlap with other stories.
- Select the smallest portfolio that provides strong coverage and useful backups.
- For thin but promising events, create a
G### item and route to project-deep-dive before drafting.
- Draft each story from linked claims, then test skeptical follow-ups.
- Ask the user to confirm any new framing that changes emphasis, causality, or personal attribution.
- Update story strength, follow-up risks, use count, and interview feedback after reuse.
Read references/coverage-and-selection.md before selecting stories and references/story-contract.md before writing them.
Story construction
Prefer a decision narrative over mechanical STAR labels in spoken output:
- context and stakes;
- exact responsibility;
- hard tension or decision;
- specific actions and mechanisms;
- evidence-supported result and attribution;
- learning that changed later behavior.
Prepare a 30-second version for retrieval, a 90-second version for normal answers, and deep-dive bullets for follow-up. All versions must use the same claims and boundaries.
Portfolio rules
- One strong story may answer several questions, but do not pretend reuse creates broader evidence.
- Track follow-up risks and use count to prevent repetitive interviews.
- Preserve honest adjacent bridges where a perfect story does not exist.
- A failure story needs a real miss and changed method, not a disguised success.
- A conflict story needs a real disagreement and resolution mechanism, not "we communicated."
- Target-specific mappings belong under
T###; the base story remains target-neutral.
1---2name: story-bank-builder3description: Use when mining, building, auditing, prioritizing, or updating a candidate's reusable interview stories from confirmed career experiences and project dossiers.4---56# Story Bank Builder78**REQUIRED BACKGROUND:** Use `career-state-protocol`. Use `project-deep-dive` when a source project is too thin to support a story.910## Goal1112Build a compact portfolio of distinctive, evidence-backed stories that covers the candidate's real interview needs. Optimize for coverage and defensibility, not a fixed story count.1314## Inputs1516Read the Career Profile, `P###` dossiers, confirmed and bounded `C###` claims, existing `S###` stories, target models when available, and prior interview use or feedback. Do not invent missing project detail in the story layer.1718## Workflow19201. Build a coverage matrix from the supplied `T###` model. Without a target, use broad career signals such as ownership, ambiguity, product or technical judgment, evaluation, collaboration, conflict, failure, customer or user insight, measurable impact, and learning.212. Inventory candidate events that contain a real tension, decision, action, result, or changed operating method.223. Score each event for relevance, evidence, ownership, distinctiveness, follow-up safety, and overlap with other stories.234. Select the smallest portfolio that provides strong coverage and useful backups.245. For thin but promising events, create a `G###` item and route to `project-deep-dive` before drafting.256. Draft each story from linked claims, then test skeptical follow-ups.267. Ask the user to confirm any new framing that changes emphasis, causality, or personal attribution.278. Update story strength, follow-up risks, use count, and interview feedback after reuse.2829Read `references/coverage-and-selection.md` before selecting stories and `references/story-contract.md` before writing them.3031## Story construction3233Prefer a decision narrative over mechanical STAR labels in spoken output:3435- context and stakes;36- exact responsibility;37- hard tension or decision;38- specific actions and mechanisms;39- evidence-supported result and attribution;40- learning that changed later behavior.4142Prepare a 30-second version for retrieval, a 90-second version for normal answers, and deep-dive bullets for follow-up. All versions must use the same claims and boundaries.4344## Portfolio rules4546- One strong story may answer several questions, but do not pretend reuse creates broader evidence.47- Track follow-up risks and use count to prevent repetitive interviews.48- Preserve honest adjacent bridges where a perfect story does not exist.49- A failure story needs a real miss and changed method, not a disguised success.50- A conflict story needs a real disagreement and resolution mechanism, not "we communicated."51- Target-specific mappings belong under `T###`; the base story remains target-neutral.
ZhanlinCui