Generate Prompt Request
Overview
Turn the current working session into a compact "prompt request" one-pager for a pull request:
a single User: block that folds together every ask and every decision made during the session,
followed by a single Assistant: block summarizing what was actually built or done. It is a
one-pager a reviewer can read at a glance, not a turn-by-turn transcript.
When to use
- The user asks to "generate a prompt request", recap the session for a PR, or capture what was requested.
- Automatically while opening a pull request or writing a PR description. Generate this and include
it in the PR body so reviewers see the asks and decisions behind the change. A repo's AGENTS.md or
CLAUDE.md can wire this in with one line, for example: "When opening a PR, invoke the
generate-prompt-request skill and include its output in the PR body."
Output format
Render the result INLINE in the reply. Do not write a file. Produce exactly this shape:
# <Session topic> — Prompt Request
**User:**
> <one consolidated request: all the asks first, then "Decisions made along the way: ..."
> folding in every choice the user made or approved>
**Assistant:**
> <a short summary of what was actually built or done, plus status>
How to build it
- Re-read the whole current session, from the first user message to now.
- Collect every distinct ask or requirement, and every decision the user made or approved,
including ones that emerged mid-session (a stack choice, a "keep it simple" constraint, a
dropped feature).
- Write ONE
User: block: a single natural request that compresses all of it. Lead with what
they wanted, then end with "Decisions made along the way: ..." listing the resolved choices inline.
- Write ONE
Assistant: block: a tight summary of what was delivered (what got built, its key
properties, and status). Two to four sentences.
- Title: derive it from the session's main deliverable (for example "White-Label Template — Prompt Request").
Rules
- Current session only. Never invent an ask, decision, or outcome that did not happen in this
session. If something is uncertain, leave it out.
- Compress hard. One short paragraph per block. No multi-turn transcript, no separate Summary or
Gotchas sections.
- Use bold
User: / Assistant: labels with the content in a blockquote.
- No em dashes or en dashes in the prose. Use periods, commas, or rephrase.
- When invoked during PR generation, output only the block so it can be pasted straight into the PR body.
Example
A real one-pager from a session that designed a white-label template app:
# White-Label Template — Prompt Request
**User:**
> I want a white-label, open-source GitHub template built on our existing B2B Agents API
> (`/v1`), a bare-bones version of our B2C dashboard that people fork and rebrand. It needs
> workspaces per user (members + shareable invite links) and the basics the API supports:
> instance lifecycle (create / list / start / stop / restart / update / resize / delete),
> budget + usage, and opening each agent's own UIs (dashboard / terminal / files) via signed
> URLs. No Stripe. Decisions made along the way: one server-side `sk_live_` key with logical
> app-level workspaces (there is no API to mint per-tenant Agent37 keys, so tenancy is enforced
> in our own layer); no in-app chat, just open the agent's real UIs in a new tab; stack is
> Next.js + Supabase (magic-link auth, Postgres, RLS); and keep it simple, no Docker (setup
> provisions a hosted Supabase project for you).
**Assistant:**
> Built it as a standalone Next.js 15 repo wrapping `/v1`: Supabase magic-link auth, logical
> workspaces with admin/viewer roles and invite links, the full instance lifecycle plus
> budget/usage, signed-url "open" actions, and a template list, backed by a Supabase `instances`
> mirror refreshed from `/v1`. Isolation is RLS plus server-side role checks, the `sk_live_` key
> stays server-side, branding is env-only, and there is no Stripe. Setup provisions a hosted
> Supabase project via an access token (no Docker); typecheck and build pass. Not pushed, the
> adopter creates the GitHub repo.
1---2name: generate-prompt-request3description: This skill should be used to generate a "prompt request" one-pager that summarizes the current session for a pull request. It produces one consolidated User block folding together every ask and decision from the session, plus one Assistant block summarizing what was built. Use it when the user asks to "generate a prompt request", recap or summarize the session for a PR, or capture what was requested. Also use it automatically when opening a pull request or writing a PR description, so the PR body includes the asks and decisions behind the change. Works on the current session only and outputs inline markdown ready to paste into a PR.4---5
6# Generate Prompt Request
7
8## Overview
9
10Turn the current working session into a compact "prompt request" one-pager for a pull request:
11a single `User:` block that folds together every ask and every decision made during the session,
12followed by a single `Assistant:` block summarizing what was actually built or done. It is a
13one-pager a reviewer can read at a glance, not a turn-by-turn transcript.
14
15## When to use
16
17- The user asks to "generate a prompt request", recap the session for a PR, or capture what was requested.
18- Automatically while opening a pull request or writing a PR description. Generate this and include
19 it in the PR body so reviewers see the asks and decisions behind the change. A repo's AGENTS.md or
20 CLAUDE.md can wire this in with one line, for example: "When opening a PR, invoke the
21 generate-prompt-request skill and include its output in the PR body."
22
23## Output format
24
25Render the result INLINE in the reply. Do not write a file. Produce exactly this shape:
26
27```
28# <Session topic> — Prompt Request
29
30**User:**
31> <one consolidated request: all the asks first, then "Decisions made along the way: ..."
32> folding in every choice the user made or approved>
33
34**Assistant:**
35> <a short summary of what was actually built or done, plus status>
36```
37
38## How to build it
39
401. Re-read the whole current session, from the first user message to now.
412. Collect every distinct ask or requirement, and every decision the user made or approved,
42 including ones that emerged mid-session (a stack choice, a "keep it simple" constraint, a
43 dropped feature).
443. Write ONE `User:` block: a single natural request that compresses all of it. Lead with what
45 they wanted, then end with "Decisions made along the way: ..." listing the resolved choices inline.
464. Write ONE `Assistant:` block: a tight summary of what was delivered (what got built, its key
47 properties, and status). Two to four sentences.
485. Title: derive it from the session's main deliverable (for example "White-Label Template — Prompt Request").
49
50## Rules
51
52- Current session only. Never invent an ask, decision, or outcome that did not happen in this
53 session. If something is uncertain, leave it out.
54- Compress hard. One short paragraph per block. No multi-turn transcript, no separate Summary or
55 Gotchas sections.
56- Use bold `User:` / `Assistant:` labels with the content in a blockquote.
57- No em dashes or en dashes in the prose. Use periods, commas, or rephrase.
58- When invoked during PR generation, output only the block so it can be pasted straight into the PR body.
59
60## Example
61
62A real one-pager from a session that designed a white-label template app:
63
64```
65# White-Label Template — Prompt Request
66
67**User:**
68> I want a white-label, open-source GitHub template built on our existing B2B Agents API
69> (`/v1`), a bare-bones version of our B2C dashboard that people fork and rebrand. It needs
70> workspaces per user (members + shareable invite links) and the basics the API supports:
71> instance lifecycle (create / list / start / stop / restart / update / resize / delete),
72> budget + usage, and opening each agent's own UIs (dashboard / terminal / files) via signed
73> URLs. No Stripe. Decisions made along the way: one server-side `sk_live_` key with logical
74> app-level workspaces (there is no API to mint per-tenant Agent37 keys, so tenancy is enforced
75> in our own layer); no in-app chat, just open the agent's real UIs in a new tab; stack is
76> Next.js + Supabase (magic-link auth, Postgres, RLS); and keep it simple, no Docker (setup
77> provisions a hosted Supabase project for you).
78
79**Assistant:**
80> Built it as a standalone Next.js 15 repo wrapping `/v1`: Supabase magic-link auth, logical
81> workspaces with admin/viewer roles and invite links, the full instance lifecycle plus
82> budget/usage, signed-url "open" actions, and a template list, backed by a Supabase `instances`
83> mirror refreshed from `/v1`. Isolation is RLS plus server-side role checks, the `sk_live_` key
84> stays server-side, branding is env-only, and there is no Stripe. Setup provisions a hosted
85> Supabase project via an access token (no Docker); typecheck and build pass. Not pushed, the
86> adopter creates the GitHub repo.
87```
gabrielmoreira