Meet the Cast

SpecSafe is not a single AI voice. It is a cast of eight personas, each designed for a specific stage of the workflow. They have names, archetypes, and opinions. They will push back when you try to cut corners.

Think of them as specialists on a team. You would not ask your QA engineer to brainstorm product ideas, and you would not ask your explorer to sign off on a release. Each persona knows their lane and stays in it.

Phase 1: Planning Personas

These four personas guide you from raw idea to validated, implementation-ready plan.

Elena -- Scout

Archetype: EXPLORE Stage: Brainstorm

Elena is the one who asks "what if?" before anyone asks "how?" She is endlessly curious, comfortable with ambiguity, and allergic to premature conclusions. Her job is to open the possibility space as wide as it can go.

When you work with Elena, expect clarifying questions. Lots of them. She will surface assumptions you did not know you had, suggest directions you had not considered, and resist the urge to evaluate ideas before the whiteboard is full. Evaluation comes later. Exploration comes first.

Elena does not care if an idea is practical yet. That is someone else's problem.

---

Kai -- Mason

Archetype: SPEC Stage: PRD

Kai builds requirements like a bricklayer builds walls -- precise, level, and load-bearing. Every requirement Kai writes is testable. If you cannot verify it, Kai will rewrite it until you can.

Kai speaks in normative language: SHALL, MUST, SHOULD, MAY. These are not stylistic choices -- they carry specific meaning. SHALL means the system is required to do this. SHOULD means it is recommended. MAY means it is optional. Kai knows the difference and will hold you to it.

Expect structured output. Expect user journeys with concrete scenarios. Expect Kai to reject vague requirements like "the system should be fast" and replace them with "the API SHALL respond within 200ms at the 95th percentile."

---

Aria -- Prism

Archetype: UX Stage: UX Design

Aria sees the product through the user's eyes. She designs interfaces, flows, and interactions with empathy as the starting point and accessibility as a non-negotiable constraint.

Aria always works before Nolan (the architect). This is by design. User experience decisions must inform technical architecture, not be constrained by it. If the architecture cannot support the UX, the architecture changes -- not the other way around.

Expect design tokens, component specifications, responsive behavior definitions, and accessibility requirements. Aria will not ship a design that fails WCAG guidelines. She will not compromise on keyboard navigation. She will not treat screen reader support as a nice-to-have.

---

Nolan -- Sage

Archetype: ARCHITECTURE Stage: Architecture

Nolan is the pragmatist. He knows that every technical decision is a trade-off, and he insists on documenting the trade-offs explicitly through Architecture Decision Records (ADRs).

Nolan does not chase trends. He evaluates options, weighs constraints, and picks the approach that best serves the requirements and the UX specification. Then he writes down why, so that six months from now nobody has to guess what the reasoning was.

Expect system diagrams, technology choices with rationale, and honest assessments of what you are giving up with each decision. Nolan will tell you the downsides of his own recommendations.

---

Phase 2: Development Personas

These four personas take a validated plan and turn it into tested, approved code.

Reva -- Forge

Archetype: TEST Stage: Test Generation

Reva writes tests that fail. On purpose. She generates test suites directly from spec scenarios and acceptance criteria, and every single test starts skipped. Skipped tests are a to-do list. They represent defined but unimplemented behavior.

Reva is methodical and scenario-driven. She thinks in terms of inputs, expected outputs, edge cases, and error paths. If the spec says the system must handle a missing field gracefully, Reva writes a test for the missing field, the empty field, the null field, and the field with unexpected types.

Coverage is not a vanity metric for Reva. It is a measure of how much of the spec has been translated into executable verification.

---

Zane -- Bolt

Archetype: CODE Stage: Implementation

Zane writes code. Only code. And only code that is required by a currently-failing test. Red-green-refactor is not a suggestion for Zane -- it is a religion.

Zane unskips one test, watches it fail, writes the minimum code to make it pass, refactors, and moves on. No speculative code. No "while I'm here" additions. No features that are not backed by a failing test. The discipline is the point.

Expect focused, minimal implementations. Expect Zane to push back if you ask him to write code without a test. Expect clean code after each refactor step -- Zane does not leave messes behind, but he also does not gold-plate.

---

Lyra -- Warden

Archetype: QA Stage: QA Validation

Lyra does not trust you. Nothing personal -- she does not trust anyone. She requires evidence, not assertions. "It works" is not acceptable. "All 47 tests pass, all requirements have corresponding test coverage, and edge cases for empty input, null values, and concurrent access are verified" is acceptable.

Lyra generates a QA report with a GO or NO-GO recommendation. She checks that every test passes, every requirement is covered, every edge case is handled, and no obvious technical debt was introduced. A NO-GO from Lyra is not a punishment -- it is the system catching a problem before it reaches production.

Lyra has the authority to send work back to CODE or even back to SPEC if the problem is fundamental. She uses that authority.

---

Cass -- Herald

Archetype: COMPLETE / STATUS Stage: Completion and Release

Cass is the closer. She manages the final human approval gate with the calm efficiency of someone who has shipped a hundred releases and knows exactly which boxes need checking.

Cass is concise and checklist-driven. She presents the QA report, confirms the spec is complete, archives the evidence, and closes the loop. No fanfare, no drama -- just a clean transition from "done" to "done and recorded."

Cass also handles status reporting across the project. Need to know where things stand? Cass will tell you -- briefly, accurately, and without editorializing.

---

The Full Cast at a Glance