skills/star-response-builder/SKILL.md

---
name: star-response-builder
description: Use when turning the user's experience, achievements, incidents, project examples, or interview notes into STAR-style responses — job applications, public sector/APS selection criteria, two-page pitches, capability statements, cover letters, behavioural interview answers, promotion applications, performance reviews, or resume bullet points.
---

# STAR Response Builder

## Purpose

Use this skill to help the user turn experience, achievements, incidents, project examples, interview notes, or job application material into clear STAR-style responses.

STAR means:

* **Situation**: The context, challenge, or opportunity.
* **Task**: The user's specific responsibility or objective.
* **Action**: What the user personally did.
* **Result**: What changed because of the user's work.

STAR is not just a template. It is a way of presenting credible evidence: context, accountability, action, and impact.

This skill is especially useful for:

* job applications
* public sector selection criteria
* APS/state government pitches
* cover letters
* behavioural interview answers
* promotion applications
* performance reviews
* resumes
* leadership examples
* capability statements
* stakeholder, delivery, conflict, initiative, communication, problem-solving, resilience, and accountability examples

## Core Rule

Always produce a usable draft first.

Do not stop because information is incomplete. Make a reasonable draft using what the user has provided, then briefly identify what details would strengthen it.

## STAR Structure

When given raw information, separate the material into:

### Situation

Set the scene briefly.

Identify:

* where the example occurred
* when it happened
* what was happening
* what problem, risk, pressure, or opportunity existed

Keep this short. The Situation should not become a project briefing.

### Task

Clarify the user's specific responsibility.

Identify:

* what the user was accountable for
* what needed to be delivered, fixed, improved, resolved, or decided
* whether the user led, coordinated, advised, challenged, delivered, or supported the work

The Task should distinguish the user's personal role from the broader team objective.

### Action

Describe what the user personally did.

This is the most important section.

Identify:

* the steps the user took
* the decisions they made
* the stakeholders they engaged
* the analysis, planning, negotiation, escalation, governance, or delivery work they performed
* the judgement they applied
* the methods, frameworks, tools, policies, or processes they used

Use first-person active verbs:

* I led
* I clarified
* I designed
* I rebuilt
* I negotiated
* I coordinated
* I challenged
* I simplified
* I prioritised
* I resolved
* I delivered
* I identified
* I escalated
* I implemented
* I improved
* I reduced
* I prevented
* I drafted
* I presented
* I facilitated
* I reviewed

Avoid weak phrasing unless the user's role was genuinely minor:

* helped with
* was involved in
* worked on
* assisted in
* participated in
* contributed to

Replace weak phrasing with clearer ownership wherever the facts support it.

### Result

Show what changed because of the user's work.

Identify:

* what was delivered
* what improved
* what risk was reduced
* what decision was enabled
* what process was adopted
* what was approved, implemented, reused, or recognised
* what became clearer, faster, safer, more reliable, or more accountable

Use metrics where they are real and defensible.

Good result evidence includes:

* cost savings
* time reductions
* service improvements
* compliance outcomes
* reduced ambiguity
* increased stakeholder confidence
* faster decision-making
* approval by senior stakeholders
* adoption of a process
* repeat use of the work
* formal feedback
* ministerial, executive, board, or panel endorsement

Avoid vague endings such as:

* successful outcome
* positive feedback
* stakeholders were happy
* the project went well
* this was well received

If no metric exists, describe the concrete impact honestly.

## STAR Proportions

For selection criteria, behavioural examples, and public sector responses, use these rough proportions:

* **Situation:** 15%
* **Task:** 10%
* **Action:** 50%
* **Result:** 25%

The Action should do most of the work.

Most weak responses spend too long explaining the background and not enough time showing what the applicant personally did.

For a 250-word response, aim roughly for:

* 35–40 words of Situation
* 20–30 words of Task
* 120–130 words of Action
* 55–65 words of Result

For a 500-word response, scale the same proportions.

Use these proportions as a guide, not a rigid formula.

If the Situation is more than a quarter of the answer, it is probably too long.

## Public Sector and Job Advert Responses

When writing a job advert response, selection criterion, capability statement, cover letter, two-page pitch, or public sector application, do **not** use visible STAR headings unless the user explicitly asks for them.

Do not write:

**Situation:**
**Task:**
**Action:**
**Result:**

Instead, use STAR as the hidden structure underneath the response and weave it into polished prose.

The response should still contain:

* brief context
* clear personal accountability
* specific actions
* concrete result or impact

But it should read like a natural application response, not a template.

### Public Sector Default

For public sector applications:

1. Write in first person.
2. Use "I", not "we", when describing the user's contribution.
3. Keep the context brief.
4. Make the user's responsibility obvious.
5. Spend most of the word count on Action.
6. Show judgement, not just activity.
7. Name decisions, deliverables, risks, processes, stakeholders, governance steps, or outcomes where useful.
8. Finish with a specific and credible result.
9. Avoid inflated or suspiciously precise metrics.
10. Do not expose STAR headings unless requested.

### Public Sector Tone

The tone should be:

* professional
* specific
* credible
* active
* plain English
* evidence-based
* calm and competent

Avoid:

* buzzwords
* overblown claims
* fake metrics
* corporate sludge
* generic capability language
* vague claims about teamwork
* language that makes the user sound passive

Bad:

> I worked with stakeholders to achieve a successful outcome.

Better:

> I convened weekly meetings with operational, technical, and executive stakeholders, clarified the decision points, documented the risks, and prepared a recommended approach for endorsement.

## Individual Selection Criteria

For individual selection criteria responses, use one clear example per criterion unless the user asks for a broader summary.

Default length:

* 250–500 words
* first person
* no visible STAR headings unless requested
* action-heavy
* specific result

Each criterion should show a different capability where possible. Avoid reusing the same example for every criterion unless the user has limited material.

## Two-Page Pitches

For two-page public sector pitches, STAR examples should be woven into body paragraphs.

Do not separate the response into STAR headings.

Use a structure like:

1. Short opening alignment with the role.
2. Two to four evidence-based paragraphs, each using compressed STAR logic.
3. Short closing paragraph reinforcing fit, motivation, and value.

In a pitch, STAR often compresses into CAR:

* **Context**
* **Action**
* **Result**

The pitch should feel like a coherent argument for suitability, not a list of disconnected examples.

## Behavioural Interviews

For behavioural interview answers, visible STAR structure is acceptable if useful, but the spoken answer should still sound natural.

Default structure:

1. Brief context.
2. Clear statement of responsibility.
3. Step-by-step explanation of what the user did.
4. Specific result.
5. Optional reflection or lesson learned.

For interviews, prepare:

### Short Version

45–60 seconds.

### Standard Version

Around 90 seconds.

### Detailed Version

2–3 minutes for senior roles, panels, or complex examples.

The same example can be reused across:

* written application
* pitch paragraph
* interview answer

But it should be calibrated to the format, word limit, and tone.

## STAR Variants

Use the structure that best fits the length and purpose.

### STAR

Situation, Task, Action, Result.

Best for:

* 250–500 word selection criteria
* behavioural interview answers
* detailed written examples

### CAR

Context, Action, Result.

Best for:

* shorter 150–250 word responses
* pitch paragraphs
* cover letters
* cases where Situation and Task naturally merge

### CAO

Context, Action, Outcome.

Best for:

* tight application paragraphs
* softer outcome language
* short statements where "Result" feels too rigid

### STAR-L

Situation, Task, Action, Result, Learning.

Best for:

* senior roles
* leadership examples
* reflective practice questions
* EL2/SES-style responses
* examples where the result was mixed and the learning matters

Use one structure consistently across a single application. Mixing structures can make the response feel disorganised.

## Handling Missing Information

If details are missing, make a cautious draft.

Do not invent:

* agencies
* dates
* dollar figures
* percentages
* senior endorsements
* formal recognition
* project values
* team sizes
* outcomes that were not provided

Use placeholders only when necessary.

Acceptable cautious result language:

* "This improved visibility over…"
* "This reduced ambiguity around…"
* "This gave stakeholders a clearer basis for…"
* "This helped prevent…"
* "This created a repeatable process for…"
* "This supported more consistent decision-making…"
* "This gave the team a clearer view of…"
* "This improved confidence in…"

After the draft, add:

### Useful Details to Add

Include only details that would materially improve the answer, such as:

* specific dates or timeframe
* agency, branch, or team
* role level
* stakeholder groups
* number of people affected
* value, scale, or risk
* measurable improvement
* senior feedback
* adoption or reuse
* final decision or approval

## Default Output Formats

### If the user asks for a STAR breakdown

Use:

**Situation:**
[Brief context.]

**Task:**
[The user's responsibility.]

**Action:**
[What the user specifically did.]

**Result:**
[Outcome and impact.]

Then provide:

### Polished Version

A natural first-person response suitable for use in an interview or application.

### If the user asks for a job application response

Do **not** use STAR headings by default.

Use:

### Draft Response

[Polished first-person prose using STAR internally.]

### Useful Details to Add

[Only if needed.]

### If the user asks for a public sector pitch

Use:

### Draft Pitch

[Integrated prose, no STAR headings.]

### Notes

[Optional short explanation of evidence, gaps, or strengthening opportunities.]

## Quality Checklist

Before finalising, check that the answer:

* has clear context
* identifies the user's personal responsibility
* uses "I" rather than hiding behind "we"
* spends most of the space on Action
* shows judgement and decision-making
* avoids vague claims
* includes a result or impact
* uses real numbers only where defensible
* matches the seniority of the role
* sounds natural and credible
* avoids visible STAR headings for job advert/application responses unless requested

## Example: Visible STAR Breakdown

Use this format only when the user asks for STAR explicitly.

**Situation:**
The organisation was relying on a dashboard that was difficult to interpret and was creating confusion for stakeholders.

**Task:**
I was responsible for improving the reporting so users could understand the key information quickly and make decisions with more confidence.

**Action:**
I reviewed the existing dashboard, identified the areas causing confusion, and worked with stakeholders to clarify what information they actually needed. I simplified the layout, removed unnecessary elements, standardised the metrics, and rebuilt the reporting view around the decisions users needed to make.

**Result:**
The revised dashboard gave stakeholders a clearer and more consistent view of performance. It reduced confusion, improved confidence in the reporting, and created a more usable basis for operational discussion.

## Example: Same Content Woven Into a Job Application Response

Use this format for job adverts, selection criteria, public sector applications, and pitches unless visible STAR headings are requested.

In my role at [organisation], I identified that stakeholders were relying on reporting that was difficult to interpret and was creating confusion around operational priorities. I was responsible for improving the reporting so decision-makers could understand the key information more quickly and use it with greater confidence. I reviewed the existing dashboard, clarified stakeholder requirements, removed unnecessary detail, standardised the metrics, and rebuilt the report around the decisions it needed to support. This improved visibility, reduced ambiguity, and gave stakeholders a clearer basis for operational discussion.

## Final Instruction

Always make the user sound specific, credible, and personally accountable.

For job applications, STAR should usually be invisible scaffolding, not visible headings.