Adopting R.I.S.C.E.A.R.

R.I.S.C.E.A.R. is a ten-field specification for describing roles. FCC uses it to describe AI agent roles. The same structure, with minor adaptation, is useful for describing contributor roles, module ownership, subteam responsibilities, and workflow steps in any open-source project.

This page shows you how.

The ten fields, re-read for OSS maintainers

Field	AI original	OSS adaptation
Role	What the agent does	What the contributor/module does
Input	What it consumes	What a ticket or PR looks like when it lands
Style	How it communicates	Communication conventions (where, how, tone)
Constraints	What it must not do	Boundaries / out-of-scope behaviours
Expected Output	Shape of output	PR shape / artifact shape
Archetype	Pattern family	Pattern family (Triager, Reviewer, Shepherd)
Responsibilities	Duties during a run	Duties during a release cycle
Role Skills	Skill tags	Skill tags (for matchmaking)
Role Collaborators	Other roles it talks to	Other contributors/modules it interacts with
Role Adoption Checklist	Pre-use verification	Pre-onboarding verification

A worked example: a "Bug Triager" role

id: bug-triager
category: contributor
role: >
  Responsible for reviewing incoming bug reports, classifying them,
  reproducing when possible, and either closing them or routing
  them to the right module owner.

input: >
  A GitHub issue with the "bug" label, opened within the last 72 hours.

style: >
  Polite, structured. Always acknowledges the reporter. Uses issue
  templates. Labels issues precisely.

constraints:
  - Never close an issue without either reproducing or requesting specific missing info.
  - Never label an issue "wontfix" without a linked ADR or maintainer consensus.
  - Must respond within 72 hours or hand off explicitly.

expected_output: >
  An issue with complete labels, a reproduction block, and either
  a routed assignee or a closure comment.

archetype: Triager

responsibilities:
  - Review the issue queue daily (M-F).
  - Request minimal-reproducible-example when needed.
  - Route to module owners using the CODEOWNERS file.
  - Escalate to maintainers if ambiguous.
  - Keep triage-metrics-spreadsheet current.

role_skills:
  - Reproducibility discipline
  - Friendly communication
  - Familiarity with issue templates
  - Knowledge of module ownership

role_collaborators:
  - module-owner-X
  - release-manager
  - newcomer-shepherd

role_adoption_checklist:
  - Read CONTRIBUTING.md and CODEOWNERS.
  - Shadow an experienced triager for 2 weeks.
  - Complete onboarding issue.
  - Be added to triage rotation by a maintainer.

That YAML file lives at ROLES/bug-triager.yaml in a hypothetical project. A new triager reads it on day one and knows exactly what is expected.

Why the format works for OSS

• Explicit constraints. Most OSS projects have implicit conventions ("don't close stale issues without asking"). Writing them as constraints makes them teachable.
• Explicit collaborators. Surfaces hidden dependencies between roles and modules.
• Explicit onboarding checklist. Reduces maintainer burden when new contributors arrive.
• Machine-readable. CI can check that every active role still has an owner; every closed issue was triaged by someone holding the bug-triager role.

Where to put the files

Two conventions work:

• Top-level ROLES/ directory. One YAML per role.
• Inline with modules. src/mymodule/ROLE.yaml. Natural if your roles are module-centric.

FCC uses the inline-with-modules pattern for personas; do whichever matches your mental model.

Minimum schema

If you want a JSONSchema to validate against, start with this trimmed version (FCC's full schema is at src/fcc/data/schemas/persona.json and is overkill for most OSS adoption):

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "required": ["id", "role", "constraints", "responsibilities"],
  "properties": {
    "id": {"type": "string", "pattern": "^[a-z0-9-]+$"},
    "role": {"type": "string"},
    "input": {"type": "string"},
    "style": {"type": "string"},
    "constraints": {"type": "array", "items": {"type": "string"}},
    "expected_output": {"type": "string"},
    "archetype": {"type": "string"},
    "responsibilities": {"type": "array", "items": {"type": "string"}},
    "role_skills": {"type": "array", "items": {"type": "string"}},
    "role_collaborators": {"type": "array", "items": {"type": "string"}},
    "role_adoption_checklist": {"type": "array", "items": {"type": "string"}}
  }
}

Four required fields is enough to get value. Add more as discipline builds.

Sample roles to bootstrap

Good starter roles for most OSS projects:

• bug-triager
• pr-reviewer
• release-manager
• docs-gardener
• newcomer-shepherd
• security-responder

Each should fit on one page of YAML. If a role's YAML sprawls over multiple pages, the role is probably two roles.

Anti-patterns

• Writing roles that describe an employee contract. These are not HR documents. Keep them operational.
• Making constraints aspirational. "Always be kind" is not a constraint. "Never merge a PR without approving-review from code-owners" is.
• Listing every file as a collaborator. Collaborators are roles, not files. If your role talks to ten collaborators, something is wrong.
• Skipping the adoption checklist. It is the newest-contributor experience. Treat it as critical.

Evolving the roles

Roles should be living documents. FCC revises personas every 2-3 releases; a similar cadence for OSS is roughly once a quarter.

Suggested review triggers:

• A new-contributor survey flags onboarding confusion → update the role_adoption_checklist.
• A repeating issue about out-of-scope PRs → tighten a constraints entry.
• A role collapses (becomes defunct) → archive the YAML with a note, don't delete.

The "review my role YAML" PR

Once you have 2-3 role YAMLs drafted, open a PR titled "RFC: role specifications." Tag frequent contributors and ask:

1. Is the role accurate to how you see this work done?
2. Is there an implicit constraint missing?
3. Is the checklist actually sufficient for a newcomer?

You will get better-than-expected feedback. Revise, then merge.

Where next

With roles drafted, tighten documentation via Docs-as-Code Patterns, formalize their use in the Contributor Ceremony, or think about versioning via Release Cadence Lessons.