R.I.S.C.E.A.R. Exercise

A structured hands-on exercise. You will author three personas of increasing sophistication, get each to pass the validator, and reflect on what each field is for.

The ten fields, in one table

Letter	Field	One-line function
R	Role	What this persona is, in one sentence.
I	Input	What it consumes.
S	Style	How it communicates.
C	Constraints	What it must not do.
E	Expected Output	Shape of what it produces.
A	Archetype	Pattern family (see archetype atlas).
R	Responsibilities	Actionable duties during a run.
S	Role Skills	Human-readable skill tags.
C	Role Collaborators	Who it talks to.
A	Role Adoption Checklist	Pre-use verification steps.

Memorize the order. It is not alphabetical; it is the order of a design conversation.

Exercise 1: A trivial persona

Goal: make the validator happy with a minimum viable persona.

id: echo-persona
category: core
risk_category: minimal
riscear:
  role: "Echoes input verbatim."
  input: "Any string."
  style: "Identity function."
  constraints:
    - "Must not modify input."
  expected_output: "Input string, unchanged."
  archetype: "Echo"
  responsibilities:
    - "Preserve input bytes."
  role_skills: ["identity"]
  role_collaborators: []
  role_adoption_checklist:
    - "Verify no transformation applied."

Run fcc personas validate echo_persona.yaml. If it passes, you have the template right.

Reflection question: can you think of a situation in which an echo persona would be useful in a real deployment?

Exercise 2: A domain persona

Goal: author a persona in a domain you care about.

Pick a domain (recipe planning, study scheduling, sports analytics — whatever). Author a persona that performs one well-defined task in that domain. Constraints are where most students over- or under-specify; aim for 3-5 constraints, each of which could produce a failure mode if removed.

Example (study scheduling):

id: deadline-aware-scheduler
category: core
risk_category: minimal
riscear:
  role: "Produces a weekly study schedule from a list of assignments and deadlines."
  input: "CSV with columns: course, assignment, due_date, est_hours."
  style: "Compact weekly table; one row per day."
  constraints:
    - "Never schedule more than 8 study-hours per day."
    - "Reserve at least one full rest-day per week."
    - "Prioritize by (due_date - today) / est_hours."
  expected_output: "Markdown table with day, assignment, hours."
  archetype: "Planner"
  responsibilities:
    - "Flag unachievable schedules before returning."
  role_skills: ["temporal reasoning", "prioritization"]
  role_collaborators: []
  role_adoption_checklist:
    - "Verify CSV columns before scheduling."

Reflection questions:

• Which constraint would, if removed, produce the most dangerous failure?
• Which responsibility is testable in an automated test?

Exercise 3: A persona with a collaborator

Goal: design two personas that cooperate.

The classic Finder + Creator pair. Author both, connect them with matching collaborator lists, and run a scenario that invokes them together.

# finder.yaml
id: study-finder
category: core
risk_category: minimal
riscear:
  role: "Retrieves relevant course material for a study question."
  input: "A study question and a course-material index."
  style: "Citation-heavy, terse."
  constraints:
    - "Only cite materials in the provided index."
  expected_output: "List of (citation, excerpt) pairs."
  archetype: "Knowledge Finder"
  responsibilities:
    - "Return <= 5 results, sorted by relevance."
  role_skills: ["retrieval", "ranking"]
  role_collaborators: ["study-creator"]
  role_adoption_checklist:
    - "Verify index is current."

# creator.yaml
id: study-creator
category: core
risk_category: minimal
riscear:
  role: "Drafts a study-question answer from finder results."
  input: "A question and a list of (citation, excerpt) pairs."
  style: "Essay form, 200-400 words."
  constraints:
    - "Every non-trivial claim must have a citation."
  expected_output: "Markdown essay with inline citations."
  archetype: "Synthesizer"
  responsibilities:
    - "Identify unsupported claims and flag them."
  role_skills: ["synthesis", "citation-weaving"]
  role_collaborators: ["study-finder"]
  role_adoption_checklist:
    - "Verify that at least 2 citations are included."

Create a scenario that uses both. Run it with --trace and inspect how they exchange messages.

Reflection questions:

• At what point in the trace does the Creator begin work? (Hint: look at the message-ordering.)
• What happens if you remove the Creator's citation constraint?

Common authoring mistakes

• Role contains a verb phrase that's too broad. "Helps with everything" is useless. "Summarizes course readings into 5-bullet outlines" is useful.
• Constraints are vague. "Be accurate" is not a constraint; it's a hope. "Never invent citations" is a constraint.
• Responsibilities restate the role. They should be active duties during the run, not a paraphrase of the role.
• Empty collaborator list when collaborators exist. If another persona reads your output, list it.
• Ten-field fatigue. Newcomers often make the last three fields perfunctory. Do not. role_adoption_checklist is what prevents the persona from being misused.

Check your understanding

Take someone else's persona (your classmate's, or one from data/personas/). Remove one field. Hand it to another person and ask them to guess which field you removed. If they can reconstruct it accurately, the persona was well-specified and the field you removed was doing real work.

Where next

Return to the main track at Assignment Patterns, or apply your persona-authoring skill in the Persona Role-Play activity.