Star Stories

STAR Stories

When to use

• User says "STARify", "STARify my resume", "STARify [project name]", "build STAR stories"
• User wants to convert career-doc project entries into structured behavioral-interview ammo
• User pastes a project description and wants it formatted in STAR
• Before a hiring-manager or behavioral round, when the user needs ready-to-deliver project narratives

For mock interviews or curating which stories to lead with for a specific role, use interview-prep. STARify produces the raw material; interview-prep selects and rehearses it.

After STARifying a project (or batch of projects), suggest the user run /interview-prep in audit mode to refresh the competency index, or in cheat-sheet mode if there's an upcoming round the new stories should feed.

Inputs

$PERSONAL is the personal-docs sibling directory defined in CLAUDE.md. Resolve it once at the start of the session.

Source documents (read all that exist):

• $PERSONAL/career/impact-doc.md — primary source. Has roles, projects, scope, metrics.
• $PERSONAL/career/brag-doc.md — wins and recognition. Cross-check metrics; brag doc often has sharper numbers.
• $PERSONAL/career/rish-career.md — narrative framing. Use to recover the why and the struggle behind a project, which often gets compressed out of impact-doc bullets.

Or: user-pasted project text. If the user pastes a single project description, skip the file reads and STARify the paste directly.

Modes

Mode 1: STARify the full portfolio

Triggered by: "STARify my resume", "build STAR stories for everything", "go through all my projects".

1. Read the three source docs.
2. Extract a deduped list of distinct projects. A "project" is a named piece of work with a beginning, a personal contribution, and an outcome (e.g., "Agentic Dev Team", "Bill's Design System MCP", "OPEX Notebook"). Not roles. Not skills. Not multi-year team initiatives that aren't yours.
3. Present the list to the user before writing. Confirm the slug for each, ask which to skip, ask whether to merge any.
4. For each confirmed project, write $PERSONAL/career/star/<slug>.md using the template below.

Mode 2: STARify a single project

Triggered by: "STARify [project name]", or user pastes one project's worth of detail.

1. Skip the list-and-confirm step.
2. Pull whatever context exists about that project across the source docs (or just use the pasted text).
3. Write $PERSONAL/career/star/<slug>.md.

Mode 3: Update / refine an existing STAR file

Triggered by: "tighten the Agentic Dev Team story", "add a conflict angle to OPEX", "the metric is wrong in trinity-mcp.md".

1. Read the existing file.
2. Apply the requested edit.
3. Preserve other angles in the file unless the user says to drop them.

File format

One file per project. Each file contains:

1. Frontmatter with project metadata.
2. Context block (2-3 sentences, role-agnostic background a reader needs).
3. Multiple STAR angles, each tagged with the competencies it lands.

---
slug: agentic-dev-team
project: Agentic Dev Team
company: Bill
years: 2025-2026
scope: 10-agent SDLC pipeline, adopted across multiple teams
primary_competencies: [leadership, ambiguity, technical-depth, leverage]
---

# Agentic Dev Team

## Context
(2-3 sentences. What was the system, what team, what was the state of the world when you started. Reader should be able to evaluate the rest without back-and-forth.)

---

## Angle 1: Leadership / influence without authority
**Best for:** "Tell me about a time you drove a change without formal authority."

- **Situation:** ...
- **Task:** ...
- **Action:** ...
- **Result:** ...

## Angle 2: Ambiguity
**Best for:** "Describe a time you had to define the problem before solving it."

- **Situation:** ...
- **Task:** ...
- **Action:** ...
- **Result:** ...

## Angle 3: Technical depth / architecture
**Best for:** "Walk me through a technically complex system you designed."

- **Situation:** ...
- **Task:** ...
- **Action:** ...
- **Result:** ...

(Add more angles as the project supports them. A strong project supports 3-5 angles. Don't pad.)

---

## Quick-fire facts (for follow-ups)
- One-line scope:
- Key metrics:
- Who else was involved:
- What I'd do differently:
- Why this matters now:

Workflow rules

• Write in first person, past tense. "I built", not "we built" unless the action genuinely was a we. Surface the user's specific contribution.
• Action should be decision-driven, not task-driven. "I chose multi-agent over a single God-Agent because X" beats "I implemented an orchestrator class." Interviews reward judgment, not labor.
• Result must be quantified. Pull numbers from impact-doc / brag-doc. If a project's result is unquantified in the source files, flag it: **RESULT-NEEDS-METRIC:** ... and ask the user inline.
• Don't invent. If a detail isn't in the source material, write [VERIFY] and ask. Never fabricate scope, names, or numbers.
• Cross-reference, don't duplicate. If the OPEX story shares a competency with Agentic Dev Team, both files keep the angle but each frames it through its own project.
• Push back on weak angles. If a project doesn't actually support a "conflict" angle, don't force one. Note it: ## Angle X: Conflict — N/A for this project, see [other-project].md instead.
• Slug rules: lowercase, kebab-case, short. Match how the project is referenced in impact-doc when possible.

Output discipline

• Files: $PERSONAL/career/star/<slug>.md. Create the directory if missing.
• If a file already exists, prompt: Overwrite (replace entirely), Merge (add new angles, preserve existing), or Cancel (print to terminal only).
• After writing, summarize: which files were created/updated, which angles are weakest and would benefit from a verification pass, and any [VERIFY] or RESULT-NEEDS-METRIC flags the user needs to resolve.

Anti-patterns

• Don't write a STAR file for a role (e.g., "Senior Engineer at Bill"). STARify projects, not job titles.
• Don't pad an angle if the project doesn't earn it. Three sharp angles beats five wishy-washy ones.
• Don't lead the Action with the technology choice. Lead with the decision/judgment, then explain what enabled it.
• Don't write a Result without a number unless the source material genuinely lacks one (then flag, don't fabricate).
• Never use em or en dashes (— –) in the output. Use commas, periods, colons, or parentheses.
• Don't bury the metric at the end of a long paragraph. Result section should land the number in the first sentence.