Prompt Examples

When you inherit code or add a feature, writing good tests is often the slowest part. This prompt maps behaviors and edge cases first, chooses a sensible test strategy, then emits an idiomatic suite for your framework (Jest/Mocha/Vitest).

It’s ideal for jump-starting coverage on legacy modules, turning bug reports into tests, or scaffolding a suite you’ll refine by hand. Parameters let you dial scope (basic vs full), format (code vs markdown), and verbosity.

Prompt

Parameters:

• {{TEST_FRAMEWORK}}: jest | mocha | vitest

• {{COVERAGE_LEVEL}}: basic | full

• {{OUTPUT_FORMAT}}: code | markdown

• {{WORD_LIMIT}}: 250

You are a senior backend engineer specializing in automated testing and code quality.
Generate a {{TEST_FRAMEWORK}} unit test suite for the code below. Aim for {{COVERAGE_LEVEL}} coverage.

Quality examples to imitate:
Good example:

describe('add', () => { it('adds positives', () => { /* ... / }); it('handles negatives', () => { / ... */ }); });

Bad example:

test('test', () => { expect(true).toBe(true); });

Before drafting, think step-by-step:

• Enumerate inputs/outputs, branches, boundary and error cases.

• Identify mocking/stubbing needs and fixtures.

Propose two test strategies (basic vs comprehensive), briefly evaluate coverage/clarity,
choose the better one, then proceed.

Process tracking:

• Derive a concise 3–7 item checklist from your plan and keep it visible; mark items complete as you go.

Output strictly as {{OUTPUT_FORMAT}}; if "code", provide only valid {{TEST_FRAMEWORK}} tests.
Limit narrative to {{WORD_LIMIT}} words if present.

Consistent stories make components easy to discover, demo, and reuse. This prompt analyzes a component’s props and critical states, proposes an organization (state-focused vs prop-variation), and outputs valid stories with controls and brief docs.

Use it to standardize story quality across a design system, ensure “empty/error/loading” paths are documented, or seed stories for new components with minimal hand-editing.

Prompt

Parameters:

• {{COMPONENT_NAME}}

• {{OUTPUT_FORMAT}}: code | markdown

• {{WORD_LIMIT}}: 200

You are a senior frontend engineer documenting UI components for reuse.
Generate Storybook stories for {{COMPONENT_NAME}} including default, critical states
(loading, empty, error), and a small set of controls (args/argTypes).

Quality examples to imitate:
Good example (CSF with args/controls, descriptive names): ...
Bad example (single trivial story): ...

Before drafting, think step-by-step:

• Identify primary props and critical state permutations.

• Decide sensible default args and control types.

• Note any accessibility or interaction considerations.

Propose two outline options (state-focused vs prop-variation-focused), evaluate clarity
for consumers, choose the better one, then proceed.

Process tracking:

• Derive a 3–7 item checklist (states covered, controls defined, a11y note, docs block).

• Keep it visible; mark items complete as you go.

Output strictly as {{OUTPUT_FORMAT}}. If "code", return a valid .stories.tsx using CSF.
Limit narrative to {{WORD_LIMIT}} words.
{{COMPONENT_SOURCE}}

Busy teams need clear, prioritized reviews, not vague nitpicks. This prompt summarizes scope, identifies risk (security/perf/correctness), checks tests/docs, and produces must-fix vs should-fix feedback aligned to your repo guidelines.

It’s perfect for triaging large PRs, leveling up review consistency, and creating actionable review notes you can paste back into the PR. Parameters control the severity threshold and output format (markdown/json).

Prompt

Parameters:

• {{REPO_GUIDELINES_URL}}

• {{SEVERITY_THRESHOLD}}: high | medium | low

• {{OUTPUT_FORMAT}}: markdown | json

• {{WORD_LIMIT}}: 300

You are a senior reviewer enforcing our engineering standards.
Review this PR for correctness, security, performance, readability, and test impact,
aligned with {{REPO_GUIDELINES_URL}}. Produce prioritized, actionable feedback.

Quality examples to imitate:
Good review (specific, actionable, prioritized, cites guidelines): ...
Bad review (vague, nitpicky, no priorities): ...

Before drafting, think step-by-step:

• Summarize change scope and impacted areas.

• Identify top risks and missing tests.

• Map issues to guidelines and suggest concrete fixes.

Propose two review structures (risk-first vs file-by-file), evaluate which is clearer
for authors, choose one, and proceed.

Process tracking:

• Derive a 3–7 item checklist (scope summary, risks, guideline mapping, tests, action items).

• Keep it visible; mark items complete as you go.

Output strictly as {{OUTPUT_FORMAT}}. If "json", include:
summary, risks[], suggestions[], must_fix[] (≥ {{SEVERITY_THRESHOLD}}).
Limit to {{WORD_LIMIT}} words.

Docs drift when formats vary by author. This prompt lets you pick a doc type (how-to/reference/concept) and audience (beginner/intermediate/advanced), then generates a structured draft with tasks/sections, examples, troubleshooting, and links.

It’s useful for bootstrapping new pages, converting internal notes into public-facing guides, or enforcing a house style at scale. Switch the output to JSON when you need machine-readable docs for pipelines or site builds.

Prompt

Parameters:

• {{DOC_TYPE}}: "how-to" | "reference" | "concept"

• {{TARGET_AUDIENCE}}: "beginner" | "intermediate" | "advanced"

• {{OUTPUT_FORMAT}}: markdown | json

• {{WORD_LIMIT}}: 600

You are a technical writer producing a {{DOC_TYPE}} doc for {{TARGET_AUDIENCE}} developers.
Create a clear, consistent guide based on the material below, with examples and cross-links.

Quality examples to imitate:
Good doc (accurate, structured, example-led, scannable): ...
Bad doc (vague, no examples, wall of text): ...

Before drafting, think step-by-step:

• Extract the core tasks/concepts and prerequisites.

• Identify 1–2 canonical examples and a minimal “happy path.”

• Decide a logical flow and what to defer to references.

Propose two outline options (task-first vs concept-first), evaluate for {{TARGET_AUDIENCE}},
choose the better one, then proceed.

Process tracking:

• Derive a 3–7 item checklist (prereqs, steps/sections, examples, troubleshooting, links).

• Keep it visible; mark items complete as you go.

Output strictly as {{OUTPUT_FORMAT}}. If "json", return a single object with keys:
title, audience, prerequisites[], steps[]|sections[], examples[], troubleshooting[], links[].
Respect {{WORD_LIMIT}}.