reprompter-oneshot

RePrompter — Build (One-Shot)

Mode skill of the reprompter plugin. Entry/routing: ../reprompter/SKILL.md. "Split across a team" hands the finished brief to ../reprompter-team/SKILL.md (Repromptverse). Content below is verbatim from root SKILL.md lines 1285-1311; the template is references/oneshot-template.md.

Required reading: ../reprompter/references/advanced-features.md. The always-on rules in ../reprompter/SKILL.md → "Core shared rules" (context check, uncertainty permission) apply to every build brief.

Intent: Build (One-Shot)

For "one-shot this", "one-shot a X", "tek promptla", "tek seferde", "vibe a game", "build me a whole app/game/site" — the user wants the whole thing built, not a prompt they will hand to themselves. Two execution shapes: one prompt (default, below) or split across a team — if the user asks for a team (or says yes when the ask clearly spans 2+ independent domains), hand the finished brief to Repromptverse: the done-list becomes the team's success criteria, the harsh checker becomes the Phase-4 evaluator, and each work area becomes an agent scope. See references/oneshot-template.md "Split across a team".

Full template, interview, bracket-filling rules, and worked example: references/oneshot-template.md. Read it when this intent triggers.

The shape in brief — three prose paragraphs, no XML. This describes default mode; maximal mode replaces paragraph 3's checklist with the unreachable reference as its only bar and has no done-list at all:

1. What good looks like — a real named reference (never "AAA"/"polished", which let the model pick its own generous bar), one phrase of what quality means here, two seed work areas, then "anything you could think of" so the model enumerates the rest itself.
2. Who does the work — get one end-to-end slice running first, then expand; work areas in parallel where they don't touch, one helper per area, integrating as you go. A separate helper checks each piece and is told to be a harsh critic, not an encouraging one, and it writes and calibrates its own checks. Never let a builder grade its own work - self-graded work always passes. On a runtime with no helper mechanism, swap both helper sentences for an explicit hostile self-review pass and say it is weaker; never leave a prompt demanding a separate checker where none can exist.
3. When it is done (default mode) — a 5-12 item done-list, each item checkable by looking at the built thing, each closable as "not possible in {stack}, because X" only when genuinely impossible, or recorded unverified when a named measurement condition cannot be reproduced. The checker confirms items on the real running artifact, never on the builder's summary, and a final smoothing pass reconciles the separately built pieces before stopping. Plus the stack, which is the only technical instruction and shapes the result more than it looks like it will.