Design a frontend persona

Personas are the most underused feature in CodeCourier. A generic agent will write working code; a well-designed persona will write code that looks like your team wrote it. In this guide you build a Frontend Specialist persona from scratch - model, tools, skills, house style, and guardrails - that ships React + TypeScript work you would happily merge.

1. Start from the right base

Open the persona library and clone the Senior Engineer template. Do not start from blank; the template comes with sensible defaults for model choice, thinking budget, and tool permissions. You will override the parts that matter and inherit the rest.

Rename your clone to Frontend Specialist v1. The version suffix matters - personas are first-class, versioned objects. Future-you will run sessions that reference Frontend Specialist v3 while v1 still exists and can be replayed.

2. Define the house style

The persona's system prompt is where house style lives. Be specific. Be opinionated. The model will not guess what you want.

You ship React + TypeScript components for a design system named Atlas.

Rules:
- Functional components only. No class components.
- Co-locate component, test, and story files: Foo.tsx, Foo.test.tsx, Foo.stories.tsx.
- Props interfaces exported, named `<ComponentName>Props`.
- No prop-spreading onto DOM nodes - be explicit.
- Tailwind for styling. No inline styles except for dynamic values.
- Every interactive component takes a `data-testid` prop.

When unsure, ask. Do not invent house-style decisions.

3. Bind the right tools

A persona is only as good as its tools. For frontend work, restrict the toolset rather than expanding it. The agent should be able to:

• Read any file in the repo.
• Write files inside src/components/ and src/stories/.
• Run pnpm test, pnpm lint, and pnpm typecheck.
• Run pnpm build:storybook to verify stories compile.

Do not give it shell access. Do not give it write access to your CI config. Do not give it package-install permissions - adding a dependency is a human decision.

4. Attach the right skills

Skills are reusable knowledge bundles. Attach react-patterns, tailwind-conventions, and component-testing-rtlfrom the skill library. Skip the generic frontend-design skill - it overlaps with your house style and will pull the agent toward a less-opinionated default.

More skills is not better. Skills compete for the agent's attention. Three sharp skills beat ten vague ones.

5. Add a guardrail check

Personas can attach a Judge - a second model that grades every diff before the PR opens. For a frontend persona, the Judge should be terse and opinionated: does the diff violate house style? Does it touch files outside the component scope? Are tests present?

judge_prompt: |
  Reject the diff if any of:
  - Components missing a co-located test file.
  - Tailwind classes mixed with inline styles for non-dynamic values.
  - Interactive elements missing data-testid.
  - Files modified outside src/components/ or src/stories/.

  Approve otherwise.

6. Test against a real ticket

Open an Issue Session with the new persona against a real ticket from your backlog - something like "add a Tooltip component with arrow positioning". Compare the diff to what you would have written. Iterate on the system prompt and Judge until the gap is closed.

7. Promote and document

When the persona consistently ships PRs you would merge without comment, promote it from v1-draft to v1. Write a one-paragraph internal note describing when to use it and when to reach for a different persona. Personas without documentation get used wrong, then blamed.

Next: layer this persona into a Sprint Chain via the multi-step workflow guide, or read the operations handbook before letting it loose on the full backlog.