Personas - who repository-standards is built for

The standard's own roster, dogfooding standard/docs/personas.md and ADR-006: every epic, skill, and doc in this repo must name which of these it serves. Source-only (a consuming repo writes its own product's roster).

The roster

Standard-bearer Staszek (primary)

• Who / context. Senior dev / architect responsible for more than one repo (own products + client work). Lives in the terminal with a coding agent; time split across projects, so every repo must be self-describing when he returns to it.
• Jobs to be done. "When I inherit or revisit a messy repo, I want to point an agent at a reference and have it walk the repo there, so quality does not depend on my memory." "When the standard improves, I want each repo to update by delta and prove compliance, so upkeep is a command, not a project."
• Goals. Drift as a number, per repo; one way of working everywhere; transitions that are guided, resumable, and safe on brownfields.
• Pains / frictions. Big-bang alignments that stall; standards that are prose, not checks; tooling that assumes greenfield; paid trackers on hobby projects.
• Decisions they influence. ADR-005 (manifest), ADR-008/009 (zones, skill classes), ADR-010 (lifecycle + tracker), the project's naming.
• Success signals. A repo he has not touched in months passes self-verify after one update-to-latest run; a new client repo reaches drift 0 in planned waves.
• Anti-goals. An IDE lock-in, a SaaS dependency, or a ceremony layer (Scrum-for-AI).

Spec-first PO Paula

• Who / context. Product owner without a compiler; thinks in users, behavior, and priorities. Works through chat/specs; the repo is readable to her only if the standard makes it so.
• Jobs to be done. "When I write a story, I want to be asked exactly the questions that make it buildable - and be allowed to defer the technical ones explicitly - so refinement happens once, not in review ping-pong." "When I read a decision, I want it explained plainly with examples, so I can gate it honestly."
• Goals. See at a glance what is in-refinement vs ready-to-develop; trust that acceptance criteria survive into tests.
• Pains / frictions. Specs that go to build half-baked; jargon walls; her deferrals getting lost; tools that require her to run commands she does not know exist.
• Decisions they influence. ADR-006 (personas gate), the clarify gate (ADR-010), the plain-language explainers, backlog/status conventions.
• Success signals. Zero specs reaching a developer with open clarifications; Paula answers or defers every clarify question without leaving the flow.
• Anti-goals. Writing YAML, choosing libraries, or learning git internals.

Buildable-truth Dev Darek

• Who / context. Senior developer pairing with agents daily. Wants contracts, not vibes; changes code fastest when the spec, records, and guards say what is settled.
• Jobs to be done. "When I pick up a ready-to-develop spec, I want every contract verbatim, so the agent and I can build and verify without archaeology." "When a change ripples, I want the guard to tell me which specs/ADRs it touches, so nothing rots."
• Goals. Same-PR spec+code coupling that stays green; decisions recorded once, re-litigated never.
• Pains / frictions. Descriptive specs that cannot be rebuilt from; scaffolding debris from shipped features; docs that lie about the current system.
• Decisions they influence. ADR-002/003 (specs by capability, buildable), the spec-first loop and its gates, the coupling guard, stack picks in the registered stack repos (stacks.json).
• Success signals. A capability rebuilt from its spec alone passes its tests; the coupling guard blocks a drifting PR before review does.
• Anti-goals. Process for its own sake; being the human linter.

Owner Olek

• Who / context. Founder / company owner / head of a business unit - the person the repos ultimately belong to. Not hands-on technical (or long past it); hires the Staszeks and Paulas of this roster. Reads dashboards and outcomes, not diffs.
• Jobs to be done. "When I fund a team, I want their repos held to a standard that people better than me have already vetted, so I do not have to personally verify work I cannot read." "When a key developer leaves or an auditor asks questions, I want the repo to explain itself, so the company's knowledge is an asset I own, not a memory that walked out."
• Goals. Maintainable, transferable repositories; quality he can point at (a green self-verify, a pinned standard version) instead of quality he must take on faith; onboarding a new dev or agency without a month of tribal handover.
• Pains / frictions. Vendor lock-in to one contractor's private conventions; "trust me, it's clean" as the only quality signal; discovering at the worst moment that the docs lied; paying enterprise prices for process a five-person company cannot carry.
• Decisions they influence. ADR-011 (the scale profile is his shape of the product; core keeps his solo projects cheap), naming and discovery (his trust story only works if the standard will be publicly credible and community-reviewed - it is neither yet, and that gap is the work, not the claim), the going-public bar (nothing in the repo the community should not see).
• Success signals. He can ask any repo "are you compliant, and to which version?" and get a number; an external audit or handover starts from the repo itself; his teams' PRs cite the standard instead of debating taste.
• Anti-goals. Reading specs or records himself; choosing technologies; any dashboard that needs him to understand git.

Position note: the role is Owner - deliberately not "project manager" (a PM runs delivery from inside; Olek sits above it and buys assurance) and not "sponsor" (too corporate for a persona who may simply own the whole company). If a team has a PM persona, it is a variant of Spec-first PO Paula, not of Olek.

Coding agent

• Who / context. Claude Code / Cursor / any agent reading AGENTS.md first. No memory between sessions - the repo IS its context.
• Jobs to be done. "When I enter a repo, I want one entry point and honest indexes, so I load the right context without crawling." "When the user talks features, I want rules that tell me to start the loop unprompted, so process does not depend on the user knowing skill names."
• Goals. Deterministic navigation (taxonomy, indexes); mechanical gates it can obey (clarify gate, coupling guard, self-verify).
• Pains / frictions. Stale docs, dead scaffolding, rules living in someone's head or personal config (ADR-012 exists against exactly this).
• Decisions they influence. AGENTS.md-as-entry, honest folder indexes, living docs (R4), the enforcement stack.
• Success signals. An agent fresh in the repo executes the loop correctly with no human prompting beyond the feature description.
• Anti-goals. Being trusted to "remember" anything not written down.

Read this page's markdown, or its source on GitHub.