Skip to content This library is free, offered as dana. If it helps your work, donate here →
penguin tree ai
← back to libraryDonate here

This is one of 3,622 free prompts in the penguin tree ai library. Sign up once and the whole library opens, with new prompts by email.

open the library →

Retail trading feature brief

Produces a concise, build-ready feature brief for a retail trading capability — covering problem framing, user stories, functional requirements, edge cases, regulatory and risk flags, data dependencies, and acceptance…

download .md

Purpose

Generate a tight, engineering-ready feature brief for a retail trading capability that a product team can hand to design and engineering without a second drafting pass. Solves the recurring problem of trading features stalling in ambiguity — unclear buying-power math, unhandled market states, and missing regulatory flags that surface late in the build.

When to Use

Invoke this skill when the user asks to:

  • Write a feature brief or PRD for a trading capability (options chain, charting, order ticket, margin tools)
  • Spec a buying power, margin, or settlement display for a brokerage app
  • Document requirements for a new watchlist, quote, or portfolio feature
  • Turn a rough feature idea into user stories and acceptance criteria for engineering handoff
  • Define edge cases and market-state behavior for a trading UI before a sprint
  • Capture regulatory and risk requirements for a new investing feature

Inputs Required

Before starting, collect:

  • Feature: The trading capability to spec (e.g., options chain, candlestick chart, buying power widget, margin call flow)
  • Platform context: Web / iOS / Android / all; self-directed brokerage, robo, or hybrid
  • Target user: Novice retail, active trader, options trader, or margin user
  • Account types in scope: Cash / margin / IRA / options-approval levels
  • Market data source: Real-time, delayed 15-min, or provider name if known
  • Regulatory jurisdiction: US (FINRA/SEC), and whether PDT, Reg T, or options suitability rules apply
  • Integration surface: Existing systems it touches (order management, clearing, quote feed, funding)

If account types or jurisdiction are missing, default to US self-directed brokerage with cash and margin accounts and note the assumption. Assume real-time data unless stated otherwise.

Instructions

Step 1: Problem Statement & Objective

Open with a 2–3 sentence problem statement: who the user is, what they currently can't do or do painfully, and the outcome the feature delivers. Pair it with one measurable objective (e.g., "reduce order-entry errors on multi-leg options," "surface accurate buying power before order submission"). Avoid restating the feature name as the problem — name the underlying job.

Step 2: User Stories

Write 4–6 user stories in the format "As a [specific trader type], I want to [action] so that [outcome]." Cover the primary happy path plus at least one story for a constrained user (e.g., cash-account user hitting a settlement rule, options user below the required approval level). Each story must map to a real trading decision, not a UI interaction for its own sake.

Step 3: Functional Requirements

List numbered functional requirements grouped under:

  • Display & data: What values render, at what precision, refresh cadence, and source (real-time vs. delayed)
  • Interactions: Inputs the user can take, defaults, and any confirmations
  • Calculations: Any math must be stated explicitly — buying power, margin requirement, options P/L, cost basis. Show the formula or reference the governing rule (e.g., Reg T 50% initial margin).
  • States: Loading, empty, error, halted-security, pre/post-market, and disabled states

Step 4: Edge Cases & Market States

Enumerate the trading-specific conditions that break naive implementations:

  • Market closed, pre-market, after-hours, and holiday sessions
  • Halted or restricted securities; hard-to-borrow or non-marginable names
  • Zero or negative buying power; unsettled funds; PDT flag triggered
  • Options expiration day, assignment/exercise, and pin risk near strike
  • Stale or missing quote data and reconnection behavior For each, state the expected behavior — what the user sees and what actions are blocked or warned.

Step 5: Regulatory & Risk Flags

Call out compliance requirements the build must satisfy:

  • Suitability and approval gating (options levels, margin agreement, PDT acknowledgment)
  • Required disclosures and risk warnings, and where they must appear
  • Real-time vs. delayed data labeling obligations
  • Any recordkeeping, audit-trail, or best-execution touchpoints Flag anything requiring legal/compliance sign-off explicitly.

Step 6: Data Dependencies & Integrations

List upstream and downstream systems: quote feed, order management, clearing/settlement, funding/balance service, and any third-party market data. Note latency expectations and what happens on dependency failure.

Step 7: Acceptance Criteria

Write acceptance criteria in Given/When/Then format — one set per user story minimum, plus criteria covering the top 3 edge cases. Each must be testable by QA without interpretation (specific values, states, and expected outputs).

Output Format

  • Structure: Single structured brief with labeled sections in the order below
  • Length: 700–1,000 words
  • Format: Structured document — prose for problem statement, numbered/bulleted lists for requirements and criteria
  • Sections: Problem Statement & Objective → User Stories → Functional Requirements → Edge Cases & Market States → Regulatory & Risk Flags → Data Dependencies & Integrations → Acceptance Criteria
  • Tone: Senior fintech PM — precise, decision-forcing, no hedging; assumes a technical reader

Quality Checklist

Before delivering output, verify:

  • [ ] 4–6 user stories, at least one covering a constrained or restricted user
  • [ ] Every calculation states its formula or references the governing rule (Reg T, PDT, etc.)
  • [ ] At least 5 distinct market-state or edge-case conditions are covered with expected behavior
  • [ ] Regulatory section names specific approval, disclosure, or data-labeling requirements — not "ensure compliance"
  • [ ] Acceptance criteria are in Given/When/Then and testable without interpretation
  • [ ] No unresolved bracket placeholders; assumptions are stated where inputs were missing

Notes

  • The most common failure in trading briefs is under-specifying buying power and margin math — make those formulas explicit even when they feel obvious.
  • Market-state handling (halts, pre/post-market, expiration) is where trading features diverge most from generic fintech UI; never skip Step 4.
  • When the feature touches options or margin, treat the regulatory flags as gating, not decoration — the build likely needs a compliance review before shipping.
  • If the user only has a rough idea, ask one clarifying question: "What decision is the user trying to make in the moment they use this?"

How to use this skill

This file is a Claude Code skill in Anthropic's standard format — markdown with YAML frontmatter at the top.

Installing in Claude Code:

  • ~/.claude/skills/<folder-name>/SKILL.md — auto-loads in every session anywhere on your machine (recommended for skills you'll use across multiple projects)
  • <your-project>/.claude/skills/<folder-name>/SKILL.md — auto-loads only when working in that project (recommended for project-specific skills)

Restart Claude Code or open a new session to register.

Using in Claude.ai, ChatGPT, Gemini, or other AI tools:

  1. Drag this file into a new chat, or copy and paste its contents
  2. Send your task or request as your next message — the AI will apply the skill where it fits

For Claude Code skill details: https://docs.anthropic.com/en/docs/claude-code/skills