| name | starr-achievements |
| description | Complete guide to creating STARR achievement stories with measurable results. Use when gathering work achievements, building accomplishment stories, or preparing for behavioral interviews. Helps extract metrics, structure narratives, and create evidence-based achievement files. |
STARR Achievements
Core Concepts
What is a STARR Achievement?
A structured story that demonstrates your skills through measurable results:
- Situation — Background, context, timeline
- Task — What needed to be done, the goal
- Action — Specific steps YOU took (focus on YOUR contribution)
- Result — Measurable outcome with NUMBERS
- Reflection — What you learned, what you'd do differently
Key Principles
FACTS ONLY — Never invent or assume. If something is missing → ask the user
Anti-fabrication examples:
- User says "I analyzed student questions" → ❌ do NOT write "identified top 10 friction points" (they never said "10")
- User says "I mapped processes" → ❌ do NOT write "conducted structured interviews in 3 phases" (they never said "3 phases")
- User says "we had metrics" → ❌ do NOT write "tracked 15 KPIs including..." (they never said "15")
- ✅ Use the user's exact words. If you need specificity → ASK: "Did you track specific metrics? How many friction points?"
Reflection MUST come from the user — ALWAYS:
- ❌ NEVER generate Reflection yourself, even if the story is short or a side project
- ❌ NEVER infer what the user learned, felt, or would change — these are personal insights only they can provide
- ❌ NEVER write generic filler like "I learned a lot" or "this broadened my perspective"
- ✅ ALWAYS ask the user all 4 Reflection questions (learned, differently, shaped, advice) BEFORE writing the file
- ✅ This applies to ALL story types: employment, project, short gigs, volunteer work — no exceptions
- ✅ If the user skips a question → leave it out rather than making something up
NO SKILLS IN ACHIEVEMENT FILES — Skills analysis happens per-target-role in skills_mapping.md, not in the achievement itself. Achievements are role-agnostic evidence sources.
EVERY CLAIM NEEDS A NUMBER — Before/after metrics, percentages, time saved, revenue impact, team size affected, budget managed.
Data Extraction Process
1. Context Gathering (ask questions)
- What was the situation?
- What were the stakes/constraints?
- Who were the stakeholders?
2. STARR Structure (guide through each section)
For SITUATION:
- What team/company situation?
- What were the stakes or constraints?
- Timeline: When did this happen?
For TASK:
- What was the goal?
- What problem needed solving?
- What was your responsibility?
For ACTION:
- What specifically did YOU do? (not "we")
- Step 1, 2, 3...
- What tools/methods did you use?
- Who did you work with?
For RESULT:
- What was the measurable outcome? (numbers!)
- Before: What was the situation before?
- After: What changed?
- Probe for metrics: "Can you quantify that?"
For REFLECTION:
- What did you learn about yourself?
- What would you do differently?
- How did this shape you professionally?
- What advice would you give someone else?
3. Number Mining (ask follow-up questions)
Always ask for:
- Before/after metrics
- Percentages improved
- Time saved
- Revenue impact
- Team size affected
- Budget managed
Be persistent about metrics — don't accept "it improved" without a number.
Writing Quality Examples
Good vs Bad ACTIONS
❌ "I improved the process"
✅ "I mapped current workflow in Miro, identified 3 bottlenecks using JTBD framework, eliminated 2 approval steps, and automated status updates in Jira"
Why: Specific tools, specific steps, specific numbers. This is where the work shows.
Good vs Bad RESULTS
❌ "The process was faster"
✅ "Reduced cycle time from 2 weeks to 3 days (85% improvement), enabling team to handle 3× more requests"
Why: Before/after numbers + business context of what the improvement enabled.
Good vs Bad REFLECTIONS
❌ "I learned a lot"
✅ "I learned that technical solutions alone don't fix process problems — you need to address human behavior and incentives. Next time I'd involve stakeholders earlier in design."
Why: Specific insight + actionable "what I'd change" = shows growth mindset.
What Makes a Strong Action Section
- Detailed steps with tools/methods mentioned
- YOUR actions ("I did X"), not team actions ("we did X")
- Specific: names of tools, frameworks, approaches
- Sequential: step 1, 2, 3
What Makes a Strong Result Section
- Before/after numbers
- Percentage or multiplier improvements
- Business context (what the number means)
- Who benefited and how
Achievement File Structure
Story Types
Every story has a **Type:** field that determines how it's used across the system:
employment (default) — Work at a company as an employee or long-term contractor. Gets a company profile. Appears in CV Experience section. Numbered chronologically with company-first grouping.project — Side project, consulting gig, personal project, volunteer work. No company profile. In CV: may appear in optional Projects section or Summary, never in Experience. Numbered after all employment stories.
How to determine type:
- If the user was employed/contracted by a company →
employment
- If it's a one-off project, personal initiative, or freelance →
project
- When in doubt → ask the user
Impact on workflows:
- Company profiles are built from
employment stories only
- CV Experience section uses
employment stories only
- Skills mapping analyzes ALL stories (both types) for coverage
- Projects don't participate in company-first chronological renumbering
REQUIRED Sections (User Provides)
- STARR narrative — Situation, Task, Action, Result, Reflection
- Quantified results — All metrics with numbers
REQUIRED Sections (Auto-Generated)
- YAML frontmatter — title, company, role, dates, tags, metrics
- TOOLS & TECH STACK — Extracted from Action section
- INTERVIEW USES — Ready-made answers to common interview questions
NOT ALLOWED in Achievement Files
Any section that links achievement to specific roles:
- ❌ Skills breakdown or analysis (per-role deep analysis)
- ❌ "Maps to Requirements" (job-specific mapping)
- ❌ "Best For Roles" (role recommendations)
- ❌ Any role-specific or job-specific categorization
Principle: Achievement files are role-agnostic evidence sources. Skills analysis happens when analyzing specific target roles.
See Story Template for the full template structure.
Working with Pre-Written Achievements
Quality Assessment Checklist
Before importing user-written stories:
Import Strategy
1. Assess quality first
- If high-quality → preserve content
- If missing sections → add REQUIRED sections only
- If has disallowed sections → remove them
2. Apply minimal adaptations
- Add missing REQUIRED sections (YAML, Tools, Interview Uses)
- Remove any role-specific sections (see NOT ALLOWED above)
- Update file naming to match convention
- Link to related company file:
**See also:** [[company_X]]
- Update index files
3. Preserve user's content
- DO NOT rewrite STARR narrative to match "template"
- DO NOT change their voice or structure
- Keep all valid content
Quality principle: High-quality existing content > template compliance. Structure rules ensure consistency without destroying valuable content.
Tags vs Skills
Tags (YAML frontmatter)
- Purpose: Navigation and categorization
- Examples: [data, product, launch, team, process]
- Level: Basic categories
- Used for: Finding achievements, filtering
Skills (in target_roles/[role]/skills_mapping.md)
- Purpose: Deep analysis for specific job applications
- Examples: "Data Analysis" with evidence from achievement
- Level: Role-specific, detailed
- Used for: Matching achievements to job requirements
Key distinction: Tags live in achievement YAML (basic organization). Skills analysis happens per-target-role where we deeply analyze how the achievement demonstrates required skills.
Naming Conventions
- Achievement files:
story_[descriptive_slug].md (lowercase)
- Use underscores, not hyphens
- Be descriptive:
story_data_framework_launch.md not story_1.md
Quality Checklist
Before finalizing any achievement:
Cross-Reference Check
When creating or updating an achievement, verify against existing stories:
