@pilotspace/add 1.17.0 → 2.1.0

package/tooling/templates/personas/_template.md.tmpl

@@ -1,82 +0,0 @@
----
-name: <persona name — e.g. Frontend Engineer, UX Researcher>
-vibe: <one-line essence — what this persona keeps true>
-flow: <RECOMMENDED — which of the three apply-surfaces this persona is loaded at (see
- docs/18-personas.md "Apply — three surfaces"): design (the UDD requirements lens) | build
- (the domain-identity overlay on SOUL.md) | advisor (subagent/streams delegation, incl. the
- verify refute-read) — comma-separate if more than one, e.g. `build, advisor`>
-source: <OPTIONAL — the teacher file(s) this was distilled from, e.g. `.add/personas-teacher/engineering/engineering-software-architect.md` (provenance; omit if hand-authored)>
----
-<!-- A PERSONA is a project-fit requirements persona, distilled from the vendored teacher
-     library (`.add/personas-teacher/`) to the parts ADD can act on. The AI authors one file
-     per persona this project needs (frontend, backend, reviewer, …) from PROJECT.md +
-     the teacher; the engine only seeds + validates this schema (presence-based). This
-     `_template.md` is the schema reference — copy it to `<slug>.md` and fill it.
-
-     REQUIRED (engine-checked): `name` + `vibe` frontmatter and the Identity / Critical Rules /
-     Default Requirement / Success Metrics sections.
-     RECOMMENDED (not engine-checked, but expected on every persona for consistency): `flow:`
-     frontmatter and the `## Abilities` section — a persona with no stated flow or abilities is
-     hard for the design/build/advisor surfaces to actually pick up and use.
-     OPTIONAL (recommended for a faithful distillation): `source:` frontmatter, and the
-     `## Anti-patterns` + `## Playbook` sections. The engine never requires the optional
-     parts; absence is conformant.
-
-     DISTILLATION DISCIPLINE (how to fill this faithfully — learned from the teacher corpus):
-     1. SCOPE = stance, not voice. A persona is a domain STANCE (what to enforce, what to
-        suspect, what "good" measures). TONE/voice belongs to SOUL.md — never duplicate it here.
-     2. KEEP the teacher's own rules. Carry 1–2 of the teacher's signature Critical Rules
-        VERBATIM-in-spirit before adding project-specific ones — distil, don't replace.
-     3. TAG provenance honestly. In `## Playbook`, mark each item teacher-derived vs
-        ADD-native. Never credit home-grown project scaffolding to the teacher.
-     4. METRICS are rules, not snapshots. Prefer an invariant ("suite matches the last
-        green run") over a volatile literal ("2491/0") that rots as the project grows.
-     5. NAME the flow. State which apply-surface(s) actually load this persona — a persona
-        that fits none of design/build/advisor is dead weight nobody will ever pick up.
-     6. ABILITIES are checkable skills, not aspirations. Anchor each to a real file, tool, or
-        command this project already has — the same anchoring discipline as Critical Rules
-        and Success Metrics, applied to "what this persona can concretely do." -->
-
-## Identity
-<who this persona is — role, domain depth, and the EARNED perspective it brings (what it has
- seen succeed/fail that shapes its judgement). One short paragraph.>
-
-## Abilities
-<concrete, checkable things this persona can actually DO — a capability list, distinct from
- Critical Rules (always-enforced constraints) and Playbook (optional step-by-step scaffolding).
- State each as something the agent can perform right now, anchored to a real file/tool/command
- where possible — not an aspiration.>
-- <ORIENT first (convention): lead with the 1–3 commands the agent RUNS on load before acting —
-  e.g. `add.py status` · the domain's suite · the diff to judge — acting beats re-deriving>
-- <a concrete capability — e.g. "can diff two response fixtures byte-for-byte to prove passthrough">
-- <another concrete capability>
-
-## Critical Rules
-<non-negotiables this persona ALWAYS enforces. Lead with 1–2 carried from the teacher (its
- signature stance), then add project-specific ones.>
-- <a teacher-sourced rule (the persona's signature non-negotiable)>
-- <a project-specific rule this project needs>
-
-<!-- OPTIONAL — the asymmetric instinct: what this persona DEFAULTS TO SUSPECTING. Distinct
-     from Critical Rules (always-do) — these are "treat X as guilty until proven innocent". -->
-## Anti-patterns
-- <a smell this persona refuses to wave through, with its default reaction — e.g.
-  "'0 issues found' on a first pass → look harder", "an abstraction with no second caller → cut it">
-- <another anti-pattern + the default response>
-
-## Default Requirement
-<the one requirement this persona includes by default in every deliverable
- (e.g. "WCAG AA accessibility in all designs", "tests-first for every change")>
-
-## Success Metrics
-<MEASURABLE outcomes that prove this persona's work is right. State each as an INVARIANT
- (a rule that stays true as the project grows), not a today-snapshot that will rot.>
-- <a measurable outcome — e.g. "4.5:1 contrast", "p95 < 100ms", "full suite green vs last logged run">
-- <another measurable metric>
-
-<!-- OPTIONAL — delete if the persona needs no executable scaffolding. -->
-## Playbook
-<the highest-value EXECUTABLE know-how — a checklist, a template, or a step sequence the
- build can actually follow (e.g. an ADR skeleton, a STRIDE pass, a red→green loop). Tag each
- item `(teacher)` or `(ADD)` so provenance is honest. Keep it to what gets used at the work
- moment; link the full teacher file for depth: see the `source:` path above.>