Back to Details

brainstorm-prompt-optimizer

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Brainstorm Prompt Optimizer

头脑风暴提示词优化器

Transform a raw idea into an optimized prompt ready for the brainstorming workflow (
/specs.brainstorm
).
This skill prepares ideas so that when passed to 
/specs.brainstorm
, they produce better functional specifications following EARS syntax, proper acceptance criteria taxonomy, and complete Non-Goals/Negative Requirements sections.
将原始想法转换为适用于头脑风暴工作流（
/specs.brainstorm
）的优化提示词。
该技能可对想法进行预处理，使其在传入
/specs.brainstorm
后，能生成更优质的功能规格说明，遵循EARS语法、规范的验收标准分类，并完善非目标/负面需求章节。

When to Use

适用场景

  • User wants to optimize an idea before running 
    /specs.brainstorm
  • User says "prepare this idea for brainstorming", "enhance for brainstorm"
  • User provides a simple idea and wants it structured for better brainstorming results
  • User asks "make this ready for brainstorm"
  • User says "imposta per brainstorm", "prepara idea per brainstorm"
  • 用户希望在运行
    /specs.brainstorm
    前优化想法
  • 用户说出“prepare this idea for brainstorming”、“enhance for brainstorm”
  • 用户提供一个简单想法，希望将其结构化以获得更好的头脑风暴结果
  • 用户询问“make this ready for brainstorm”
  • 用户说出“imposta per brainstorm”、“prepara idea per brainstorm”

Do Not Use When

不适用场景

  • User wants code or performance optimization (use appropriate skills)
  • User wants general prompt engineering (use prompt-engineering skill)
  • User wants analysis of an existing prompt
  • User is asking to execute a task directly
  • User wants to fix a bug or modify existing behavior → route to 
    specs.change-spec
  • 用户需要代码或性能优化（使用对应技能）
  • 用户需要通用提示词工程（使用prompt-engineering技能）
  • 用户需要分析现有提示词
  • 用户要求直接执行任务
  • 用户需要修复bug或修改现有行为 → 转至
    specs.change-spec

How It Works

工作原理

Output ONLY the optimized prompt — no analysis, no reports, no recommendations.
The workflow transforms a raw idea into a structured prompt that will produce better functional specifications when used with 
/specs.brainstorm
.
仅输出优化后的提示词 — 不包含分析、报告或建议。
该工作流将原始想法转换为结构化提示词，在与
/specs.brainstorm
配合使用时能生成更优质的功能规格说明。

Workflow

工作流程

Phase 1: Detect Project Context

阶段1：检测项目上下文

Check for project files to understand the environment:
  • CLAUDE.md
    → project conventions
  • docs/specs/architecture.md
    → existing architecture constraints
  • docs/specs/ontology.md
    → existing domain terms
Tech stack detection:
  • package.json
    → Node.js/TypeScript/React
  • pom.xml
    / 
    build.gradle
    → Java/Spring Boot
  • requirements.txt
    / 
    pyproject.toml
    → Python
检查项目文件以了解环境：
  • CLAUDE.md
    → 项目约定
  • docs/specs/architecture.md
    → 现有架构约束
  • docs/specs/ontology.md
    → 现有领域术语
技术栈检测：
  • package.json
    → Node.js/TypeScript/React
  • pom.xml
    / 
    build.gradle
    → Java/Spring Boot
  • requirements.txt
    / 
    pyproject.toml
    → Python

Phase 2: Analyze the Idea

阶段2：分析想法

Parse the raw idea to identify:
  1. Core action: What needs to be built/created (e.g., "add authentication", "create search")
  2. Target domain: What part of the system is affected
  3. Implicit scope: What's naturally included vs. excluded
  4. User perspective: Who benefits from this feature
  5. Business value: Why this feature matters
解析原始想法以确定：
  1. 核心动作：需要构建/创建什么（例如：“添加认证”、“创建搜索功能”）
  2. 目标领域：系统的哪个部分会受到影响
  3. 隐含范围：自然包含与排除的内容
  4. 用户视角：谁将从该功能中受益
  5. 业务价值：该功能的重要性

Phase 3: Identify Scope Size

阶段3：确定范围规模

Estimate complexity to help 
/specs.brainstorm
:
  • Small: Single user story, 1-3 entities, simple flow → 3-8 tasks
  • Medium: 2-4 user stories, 4-8 entities → 8-15 tasks
  • Large: 5+ user stories, 9+ entities → may need split (warn user)
估算复杂度以辅助
/specs.brainstorm
：
  • 小型：单个用户故事，1-3个实体，简单流程 → 3-8个任务
  • 中型：2-4个用户故事，4-8个实体 → 8-15个任务
  • 大型：5个以上用户故事，9个以上实体 → 可能需要拆分（提醒用户）

Phase 4: Structure the Optimized Prompt

阶段4：构建优化后的提示词

Build a structured prompt with these components (aligned with 
/specs.brainstorm
template):
undefined
构建包含以下组件的结构化提示词（与
/specs.brainstorm
模板对齐）：
undefined

[Core Action] — [Target Domain]

[核心动作] — [目标领域]

Problem Statement

问题陈述

[What problem does this solve? Who has it?]
[该功能解决什么问题？谁面临这个问题？]

Core Feature

核心功能

[What should the system do? Focus on behavior, not implementation]
[系统应该做什么？聚焦行为，而非实现方式]

Target Users

目标用户

[Who will use this? What's their goal?]
[谁会使用该功能？他们的目标是什么？]

User Flows

用户流程

  1. [Primary flow from user perspective]
  2. [Alternative flows if applicable]
  1. [用户视角的主流程]
  2. [适用的备选流程]

Data Requirements

数据需求

  • [What data the feature needs to work with]
  • [Any data relationships]
  • [功能运行所需的数据]
  • [任何数据关系]

Success Criteria

成功标准

  • [IMP] [Testable criterion that requires code/implementation]
  • [SEF] [Side-effect criterion - automatic consequence]
  • [EXT] [External verification criterion]
  • [IMP] [需要代码/实现的可测试标准]
  • [SEF] [副作用标准 - 自动产生的结果]
  • [EXT] [外部验证标准]

Non-Goals

非目标

  • Feature X: [Brief explanation why excluded]
  • Feature Y: [Brief explanation why excluded]
  • 功能X：[简要说明排除原因]
  • 功能Y：[简要说明排除原因]

Negative Requirements

负面需求

  • REQ-NR001: The system SHALL NOT [security/data integrity constraint]
  • REQ-NR001：系统不得[安全/数据完整性约束]

[NEEDS CLARIFICATION] (max 3)

[需要澄清]（最多3项）

  • [Specific question that significantly impacts scope]
undefined
  • [对范围有重大影响的具体问题]
undefined

Phase 5: Output the Optimized Prompt

阶段5：输出优化后的提示词

Present the complete optimized prompt in a fenced code block with the label 
optimized-prompt
:
markdown
```optimized-prompt
[Full optimized prompt content]

---
将完整的优化提示词放在带有
optimized-prompt
标签的代码块中展示：
markdown
```optimized-prompt
[完整的优化提示词内容]

---

EARS Syntax Reference

EARS语法参考

Use EARS (Easy Approach to Requirements Syntax) for requirements:
FormPatternExample
Event-driven
WHEN <event> THEN the system SHALL <action>
WHEN the user clicks "Submit" THEN the system SHALL validate the form data
State-driven
WHEN <system state> THEN the system SHALL <action>
WHEN the session expires THEN the system SHALL clear user data
Generic
The system SHALL <action>
The system SHALL encrypt all stored passwords with bcrypt
Feature
IF <feature> THEN the system SHALL <action>
IF multi-factor auth is enabled THEN the system SHALL require second factor
Negative
IF <unwanted condition> THEN the system SHALL NOT <action>
IF SQL input detected THEN the system SHALL reject with 400
Mandatory keywords: SHALL, WILL, MAY Forbidden words: "robust", "intuitive", "fast", "scalable", "efficient", "user-friendly"
使用EARS（Easy Approach to Requirements Syntax，需求语法简易方法）编写需求：
形式模式示例
事件驱动型
WHEN <事件> THEN the system SHALL <动作>
WHEN the user clicks "Submit" THEN the system SHALL validate the form data
状态驱动型
WHEN <系统状态> THEN the system SHALL <动作>
WHEN the session expires THEN the system SHALL clear user data
通用型
The system SHALL <动作>
The system SHALL encrypt all stored passwords with bcrypt
功能型
IF <功能> THEN the system SHALL <动作>
IF multi-factor auth is enabled THEN the system SHALL require second factor
负面型
IF <不希望的条件> THEN the system SHALL NOT <动作>
IF SQL input detected THEN the system SHALL reject with 400
必填关键词：SHALL、WILL、MAY 禁用词汇："robust"、"intuitive"、"fast"、"scalable"、"efficient"、"user-friendly"

Acceptance Criteria Taxonomy

验收标准分类

Every success criterion MUST be tagged:
TagMeaningGenerates Tasks?
[IMP]
Requires new code, configuration, or explicit behaviorYES
[SEF]
Natural automatic consequence of an 
[IMP]
criterion		NO (verify in e2e)
[EXT]
Verified by external tools or user observationNO (e2e checkpoint)
60% Rule: At least 60% of criteria should be 
[IMP]
.
每个成功标准必须标记：
标签含义是否生成任务？
[IMP]
需要新代码、配置或明确行为是
[SEF]
[IMP]
标准自然产生的自动结果		否（在端到端测试中验证）
[EXT]
通过外部工具或用户观察验证否（端到端检查点）
60%规则：至少60%的标准应为
[IMP]
。

Prompt Templates by Category

按类别划分的提示词模板

Authentication & User Management

认证与用户管理

optimized
undefined
optimized
undefined

Add [Feature] — User Management

Add [Feature] — User Management

Problem Statement

Problem Statement

[Describe the problem users face without this feature]
[Describe the problem users face without this feature]

Core Feature

Core Feature

The system SHALL [describe what the feature does, focus on behavior]
The system SHALL [describe what the feature does, focus on behavior]

Target Users

Target Users

  • Primary: [main user type]
  • Secondary: [other affected users]
  • Primary: [main user type]
  • Secondary: [other affected users]

User Flows

User Flows

  1. Primary Flow: [Step by step from user perspective]
  2. Alternative Flow: [If applicable]
  1. Primary Flow: [Step by step from user perspective]
  2. Alternative Flow: [If applicable]

Data Requirements

Data Requirements

  • User entity: [fields]
  • [Other entities involved]
  • User entity: [fields]
  • [Other entities involved]

Success Criteria

Success Criteria

  • [IMP] [Criterion 1 — testable outcome requiring code]
  • [IMP] [Criterion 2]
  • [SEF] [Criterion 3 — automatic consequence]
  • [EXT] [Criterion 4 — verified externally]
  • [IMP] [Criterion 1 — testable outcome requiring code]
  • [IMP] [Criterion 2]
  • [SEF] [Criterion 3 — automatic consequence]
  • [EXT] [Criterion 4 — verified externally]

Non-Goals

Non-Goals

  • Social Login: No OAuth providers (Google, GitHub, etc.)
  • Password Reset: Not included in this specification
  • Two-Factor Auth: Not included in this specification
  • Social Login: No OAuth providers (Google, GitHub, etc.)
  • Password Reset: Not included in this specification
  • Two-Factor Auth: Not included in this specification

Negative Requirements

Negative Requirements

  • REQ-NR001: The system SHALL NOT store passwords in plain text; it SHALL use bcrypt with cost factor ≥12
  • REQ-NR002: The system SHALL NOT expose user existence through login error messages
undefined
  • REQ-NR001: The system SHALL NOT store passwords in plain text; it SHALL use bcrypt with cost factor ≥12
  • REQ-NR002: The system SHALL NOT expose user existence through login error messages
undefined

API & Backend Features

API与后端功能

optimized
undefined
optimized
undefined

[Feature Name] — API Layer

[Feature Name] — API Layer

Problem Statement

Problem Statement

[What integration need or capability gap exists]
[What integration need or capability gap exists]

Core Feature

Core Feature

The system SHALL provide [describe the API behavior]
The system SHALL provide [describe the API behavior]

Target Users

Target Users

  • Primary: [API consumers]
  • Secondary: [administrators]
  • Primary: [API consumers]
  • Secondary: [administrators]

User Flows

User Flows

  1. Happy Path: [Request → Validation → Response]
  2. Error Path: [Invalid input → Error response]
  1. Happy Path: [Request → Validation → Response]
  2. Error Path: [Invalid input → Error response]

API Contract

API Contract

  • Endpoint: [path and method]
  • Input: [what the API receives]
  • Output: [what the API returns]
  • Error cases: [failure modes with codes]
  • Endpoint: [path and method]
  • Input: [what the API receives]
  • Output: [what the API returns]
  • Error cases: [failure modes with codes]

Data Model

Data Model

  • [Entities involved]
  • [Relationships]
  • [Entities involved]
  • [Relationships]

Success Criteria

Success Criteria

  • [IMP] [Criterion 1]
  • [IMP] [Criterion 2]
  • [SEF] [Criterion 3]
  • [IMP] [Criterion 1]
  • [IMP] [Criterion 2]
  • [SEF] [Criterion 3]

Non-Goals

Non-Goals

  • GraphQL: REST only
  • Async Processing: Synchronous only
  • Caching: Not included
  • GraphQL: REST only
  • Async Processing: Synchronous only
  • Caching: Not included

Negative Requirements

Negative Requirements

  • REQ-NR001: IF user input is used in SQL query THEN the system SHALL NOT concatenate directly
  • REQ-NR002: The system SHALL NOT expose internal error details to clients
undefined
  • REQ-NR001: IF user input is used in SQL query THEN the system SHALL NOT concatenate directly
  • REQ-NR002: The system SHALL NOT expose internal error details to clients
undefined

UI & Frontend Features

UI与前端功能

optimized
undefined
optimized
undefined

[Feature Name] — User Interface

[Feature Name] — User Interface

Problem Statement

Problem Statement

[What user experience gap exists]
[What user experience gap exists]

Core Feature

Core Feature

The user SHALL be able to [describe user action and system response]
The user SHALL be able to [describe user action and system response]

Target Users

Target Users

  • Primary: [end users]
  • Secondary: [admin users if applicable]
  • Primary: [end users]
  • Secondary: [admin users if applicable]

User Flows

User Flows

  1. Entry: [How user accesses this feature]
  2. Interaction: [Primary user action]
  3. Outcome: [Result user sees]
  4. Error: [Error handling for invalid input]
  1. Entry: [How user accesses this feature]
  2. Interaction: [Primary user action]
  3. Outcome: [Result user sees]
  4. Error: [Error handling for invalid input]

UI Requirements

UI Requirements

  • Layout: [description]
  • Components: [key UI elements]
  • Feedback: [success/error/loading states]
  • Layout: [description]
  • Components: [key UI elements]
  • Feedback: [success/error/loading states]

Responsive Behavior

Responsive Behavior

  • Desktop: [behavior]
  • Mobile: [behavior]
  • Desktop: [behavior]
  • Mobile: [behavior]

Success Criteria

Success Criteria

  • [IMP] [Criterion 1 — visible behavior]
  • [IMP] [Criterion 2]
  • [IMP] [Criterion 3]
  • [SEF] [Criterion 4 — automatic]
  • [IMP] [Criterion 1 — visible behavior]
  • [IMP] [Criterion 2]
  • [IMP] [Criterion 3]
  • [SEF] [Criterion 4 — automatic]

Non-Goals

Non-Goals

  • Real-time Updates: No WebSocket or SSE
  • Offline Mode: Not included
  • Accessibility Features: [specific exclusions]
  • Real-time Updates: No WebSocket or SSE
  • Offline Mode: Not included
  • Accessibility Features: [specific exclusions]

Negative Requirements

Negative Requirements

  • REQ-NR001: The system SHALL NOT display raw error messages to users
  • REQ-NR002: The system SHALL NOT allow XSS through user input fields
undefined
  • REQ-NR001: The system SHALL NOT display raw error messages to users
  • REQ-NR002: The system SHALL NOT allow XSS through user input fields
undefined

Data & Processing Features

数据与处理功能

optimized
undefined
optimized
undefined

[Feature Name] — Data Processing

[Feature Name] — Data Processing

Problem Statement

Problem Statement

[What data challenge exists]
[What data challenge exists]

Core Feature

Core Feature

The system SHALL [describe data transformation/processing behavior]
The system SHALL [describe data transformation/processing behavior]

Target Users

Target Users

  • Primary: [who benefits]
  • Secondary: [who monitors]
  • Primary: [who benefits]
  • Secondary: [who monitors]

User Flows

User Flows

  1. Data Input: [Source and format]
  2. Processing: [Transformation steps]
  3. Output: [Result destination and format]
  1. Data Input: [Source and format]
  2. Processing: [Transformation steps]
  3. Output: [Result destination and format]

Data Quality

Data Quality

  • Validation: [rules]
  • Error handling: [for bad data]
  • Validation: [rules]
  • Error handling: [for bad data]

Performance Constraints

Performance Constraints

  • Volume: [expected data size]
  • Latency: [expected processing time]
  • Volume: [expected data size]
  • Latency: [expected processing time]

Success Criteria

Success Criteria

  • [IMP] [Criterion 1]
  • [IMP] [Criterion 2]
  • [EXT] [Criterion 3 — external verification]
  • [IMP] [Criterion 1]
  • [IMP] [Criterion 2]
  • [EXT] [Criterion 3 — external verification]

Non-Goals

Non-Goals

  • Real-time Processing: Batch only
  • Data Export: Not included
  • Backup/Restore: Not included
  • Real-time Processing: Batch only
  • Data Export: Not included
  • Backup/Restore: Not included

Negative Requirements

Negative Requirements

  • REQ-NR001: The system SHALL NOT lose data on processing failure
  • REQ-NR002: The system SHALL NOT process unbounded data without pagination

---
  • REQ-NR001: The system SHALL NOT lose data on processing failure
  • REQ-NR002: The system SHALL NOT process unbounded data without pagination

---

Examples

示例

Example 1: Simple Idea → Optimized

示例1：简单想法 → 优化后

Input:
Add user authentication
Output:
optimized
undefined
输入：
Add user authentication
输出：
optimized
undefined

Add User Authentication — Authentication Layer

Add User Authentication — Authentication Layer

Problem Statement

Problem Statement

Users cannot securely access the system. They need a way to prove their identity and access their personalized content.
Users cannot securely access the system. They need a way to prove their identity and access their personalized content.

Core Feature

Core Feature

The system SHALL provide email/password authentication that allows users to:
  • Register with a valid email address and secure password
  • Log in with registered credentials
  • Maintain an authenticated session across requests
  • Log out to terminate their session
The system SHALL provide email/password authentication that allows users to:
  • Register with a valid email address and secure password
  • Log in with registered credentials
  • Maintain an authenticated session across requests
  • Log out to terminate their session

Target Users

Target Users

  • Primary: End users who need to access personalized features
  • Secondary: Administrators who manage user accounts
  • Primary: End users who need to access personalized features
  • Secondary: Administrators who manage user accounts

User Flows

User Flows

  1. Registration: User enters email → receives confirmation → sets password → account created
  2. Login: User enters credentials → validated → session established → redirected to dashboard
  3. Logout: User clicks logout → session terminated → redirected to login page
  1. Registration: User enters email → receives confirmation → sets password → account created
  2. Login: User enters credentials → validated → session established → redirected to dashboard
  3. Logout: User clicks logout → session terminated → redirected to login page

Data Requirements

Data Requirements

  • User entity: email, hashed_password, created_at, updated_at
  • Session entity: user_id, token, expiration
  • User entity: email, hashed_password, created_at, updated_at
  • Session entity: user_id, token, expiration

Success Criteria

Success Criteria

  • [IMP] Users can register with email/password
  • [IMP] Users can log in with valid credentials
  • [IMP] Invalid credentials show generic error message
  • [IMP] Users can log out
  • [IMP] Session persists across page navigation
  • [IMP] Expired sessions require re-login
  • [IMP] Users can register with email/password
  • [IMP] Users can log in with valid credentials
  • [IMP] Invalid credentials show generic error message
  • [IMP] Users can log out
  • [IMP] Session persists across page navigation
  • [IMP] Expired sessions require re-login

Non-Goals

Non-Goals

  • Social Login: No OAuth providers (Google, GitHub, etc.)
  • Password Reset: Not included in this specification
  • Two-Factor Authentication: Not included in this specification
  • Social Login: No OAuth providers (Google, GitHub, etc.)
  • Password Reset: Not included in this specification
  • Two-Factor Authentication: Not included in this specification

Negative Requirements

Negative Requirements

  • REQ-NR001: The system SHALL NOT store passwords in plain text; it SHALL use bcrypt with cost factor ≥12
  • REQ-NR002: The system SHALL NOT expose user existence through login error messages; it SHALL use generic "invalid credentials" for both cases
  • REQ-NR003: The system SHALL NOT allow weak passwords (minimum 8 characters, mixed case, number)
undefined
  • REQ-NR001: The system SHALL NOT store passwords in plain text; it SHALL use bcrypt with cost factor ≥12
  • REQ-NR002: The system SHALL NOT expose user existence through login error messages; it SHALL use generic "invalid credentials" for both cases
  • REQ-NR003: The system SHALL NOT allow weak passwords (minimum 8 characters, mixed case, number)
undefined

Example 2: Vague Idea → Structured

示例2：模糊想法 → 结构化

Input:
Better search for products
Output:
optimized
undefined
输入：
Better search for products
输出：
optimized
undefined

Improve Product Search — Product Discovery

Improve Product Search — Product Discovery

Problem Statement

Problem Statement

Users cannot find products they are looking for using the current search. Results are not relevant, don't match user intent, and sorting is not useful.
Users cannot find products they are looking for using the current search. Results are not relevant, don't match user intent, and sorting is not useful.

Core Feature

Core Feature

The system SHALL provide enhanced product search that allows users to:
  • Search products by name, description, and category
  • Receive results ranked by relevance to search terms
  • Filter results by category, price range, and availability
  • Sort results by relevance, price, or newest
The system SHALL provide enhanced product search that allows users to:
  • Search products by name, description, and category
  • Receive results ranked by relevance to search terms
  • Filter results by category, price range, and availability
  • Sort results by relevance, price, or newest

Target Users

Target Users

  • Primary: Shoppers looking for specific products
  • Secondary: Browsers exploring product catalog
  • Primary: Shoppers looking for specific products
  • Secondary: Browsers exploring product catalog

User Flows

User Flows

  1. Direct Search: User enters search terms → results displayed → user selects product
  2. Filtered Search: User enters terms → applies filters → refined results → user selects product
  3. Empty Results: User enters terms → no results → suggestion displayed
  1. Direct Search: User enters search terms → results displayed → user selects product
  2. Filtered Search: User enters terms → applies filters → refined results → user selects product
  3. Empty Results: User enters terms → no results → suggestion displayed

Search Behavior

Search Behavior

  • Minimum 2 characters to trigger search
  • Partial word matching for product names
  • Search across: product name, description, category name, tags
  • Results limited to 50 per page with pagination
  • Minimum 2 characters to trigger search
  • Partial word matching for product names
  • Search across: product name, description, category name, tags
  • Results limited to 50 per page with pagination

Filtering Options

Filtering Options

  • Category: single or multiple selection
  • Price range: min/max with validation
  • Availability: in-stock only toggle
  • Category: single or multiple selection
  • Price range: min/max with validation
  • Availability: in-stock only toggle

Sorting Options

Sorting Options

  • Relevance (default): based on search term match score
  • Price: low-to-high or high-to-low
  • Newest: by creation date descending
  • Relevance (default): based on search term match score
  • Price: low-to-high or high-to-low
  • Newest: by creation date descending

Success Criteria

Success Criteria

  • [IMP] Search returns products matching the query terms
  • [IMP] Search supports partial word matching
  • [IMP] Category filter limits results to selected category
  • [IMP] Price range filter shows products within min/max bounds
  • [IMP] Results can be sorted by relevance, price, or date
  • [IMP] Pagination allows navigation through large result sets
  • [IMP] Empty search shows appropriate message with suggestions
  • [IMP] Search returns products matching the query terms
  • [IMP] Search supports partial word matching
  • [IMP] Category filter limits results to selected category
  • [IMP] Price range filter shows products within min/max bounds
  • [IMP] Results can be sorted by relevance, price, or date
  • [IMP] Pagination allows navigation through large result sets
  • [IMP] Empty search shows appropriate message with suggestions

Non-Goals

Non-Goals

  • Autocomplete: Not included in this specification
  • Search Analytics: Not included in this specification
  • Personalized Results: Results are the same for all users
  • Image Search: Not included in this specification
  • Autocomplete: Not included in this specification
  • Search Analytics: Not included in this specification
  • Personalized Results: Results are the same for all users
  • Image Search: Not included in this specification

Negative Requirements

Negative Requirements

  • REQ-NR001: The system SHALL NOT expose product inventory details in search results unless explicitly needed
  • REQ-NR002: The system SHALL NOT allow SQL injection through search terms; it SHALL sanitize all input
  • REQ-NR003: The system SHALL NOT return results beyond configured pagination limits per request
undefined
  • REQ-NR001: The system SHALL NOT expose product inventory details in search results unless explicitly needed
  • REQ-NR002: The system SHALL NOT allow SQL injection through search terms; it SHALL sanitize all input
  • REQ-NR003: The system SHALL NOT return results beyond configured pagination limits per request
undefined

Example 3: Technical Idea → Functional

示例3：技术想法 → 功能化

Input:
Implement Redis caching for API responses
Output:
optimized
undefined
输入：
Implement Redis caching for API responses
输出：
optimized
undefined

Implement API Response Caching — Performance Optimization

Implement API Response Caching — Performance Optimization

Problem Statement

Problem Statement

The API is slow for frequently requested data. Repeated requests for the same resources consume unnecessary server resources and increase response times for users.
The API is slow for frequently requested data. Repeated requests for the same resources consume unnecessary server resources and increase response times for users.

Core Feature

Core Feature

The system SHALL cache frequently accessed API responses to reduce response times and server load:
  • Cache GET requests for defined intervals
  • Return cached responses when data hasn't changed
  • Invalidate cache when underlying data changes
  • Provide cache statistics for monitoring
The system SHALL cache frequently accessed API responses to reduce response times and server load:
  • Cache GET requests for defined intervals
  • Return cached responses when data hasn't changed
  • Invalidate cache when underlying data changes
  • Provide cache statistics for monitoring

Target Users

Target Users

  • Primary: API consumers (frontend applications, mobile apps)
  • Secondary: System administrators monitoring performance
  • Primary: API consumers (frontend applications, mobile apps)
  • Secondary: System administrators monitoring performance

Cache Behavior

Cache Behavior

  • Cache key based on request URL and parameters
  • Default TTL: 5 minutes (configurable per endpoint)
  • Cache stores: response body, status code, headers
  • Cache miss: fetch from source, store, return
  • Cache key based on request URL and parameters
  • Default TTL: 5 minutes (configurable per endpoint)
  • Cache stores: response body, status code, headers
  • Cache miss: fetch from source, store, return

Invalidation Rules

Invalidation Rules

  • Cache invalidated when source data is modified via POST/PUT/PATCH/DELETE
  • Manual invalidation available via admin endpoint
  • Bulk invalidation by cache key pattern
  • Cache invalidated when source data is modified via POST/PUT/PATCH/DELETE
  • Manual invalidation available via admin endpoint
  • Bulk invalidation by cache key pattern

Success Criteria

Success Criteria

  • [IMP] Cached requests return within 50ms
  • [IMP] Cache hit rate visible in metrics
  • [IMP] Manual cache invalidation works
  • [IMP] Automatic invalidation on data changes
  • [IMP] Cache can be disabled per request via header
  • [SEF] Cache reduces database load for repeated requests
  • [EXT] Response time improvement measurable via APM
  • [IMP] Cached requests return within 50ms
  • [IMP] Cache hit rate visible in metrics
  • [IMP] Manual cache invalidation works
  • [IMP] Automatic invalidation on data changes
  • [IMP] Cache can be disabled per request via header
  • [SEF] Cache reduces database load for repeated requests
  • [EXT] Response time improvement measurable via APM

Non-Goals

Non-Goals

  • Distributed Cache: Single Redis instance only
  • Cache Warming: Not included
  • Cache Partitioning: Not included
  • Multi-Tenant Isolation: Not included in this specification
  • Distributed Cache: Single Redis instance only
  • Cache Warming: Not included
  • Cache Partitioning: Not included
  • Multi-Tenant Isolation: Not included in this specification

Negative Requirements

Negative Requirements

  • REQ-NR001: The system SHALL NOT cache responses containing user-specific data
  • REQ-NR002: The system SHALL NOT serve stale cache beyond configured TTL
  • REQ-NR003: The system SHALL NOT expose cache internals in API responses
  • REQ-NR004: IF cache connection fails THEN the system SHALL fall back to direct database access without error

---
  • REQ-NR001: The system SHALL NOT cache responses containing user-specific data
  • REQ-NR002: The system SHALL NOT serve stale cache beyond configured TTL
  • REQ-NR003: The system SHALL NOT expose cache internals in API responses
  • REQ-NR004: IF cache connection fails THEN the system SHALL fall back to direct database access without error

---

Integration with Brainstorming

与头脑风暴的集成

The optimized prompt should be used directly with 
/specs.brainstorm
:
bash
undefined
优化后的提示词应直接与
/specs.brainstorm
配合使用：
bash
undefined

Copy the optimized prompt and use it with brainstorm

Copy the optimized prompt and use it with brainstorm

/specs.brainstorm [paste optimized prompt here]
undefined
/specs.brainstorm [paste optimized prompt here]
undefined

Workflow

工作流

Raw Idea → brainstorm-prompt-optimizer → Optimized Prompt → /specs.brainstorm → Functional Spec → /specs.spec-to-tasks → Tasks
Raw Idea → brainstorm-prompt-optimizer → Optimized Prompt → /specs.brainstorm → Functional Spec → /specs.spec-to-tasks → Tasks

Constraints

约束条件

  • Output ONLY the optimized prompt — no analysis, no recommendations
  • If the input is a bug fix or modification request, do NOT optimize → route to 
    specs.change-spec
  • If the input is too vague to optimize meaningfully, ask ONE clarifying question
  • Keep the output focused on WHAT (behavior), not HOW (implementation)
  • Include explicit Non-Goals section (minimum 3 items) to prevent scope creep
  • Include Negative Requirements (minimum 2 items) for security/integrity constraints
  • Use EARS syntax (SHALL/WILL/MAY) for requirements
  • Tag every acceptance criterion with 
    [IMP]
    , 
    [SEF]
    , or 
    [EXT]
  • Maximum 3 
    [NEEDS CLARIFICATION]
    markers
  • 仅输出优化后的提示词 — 不包含分析、报告或建议
  • 如果输入是bug修复或修改请求，请勿优化 → 转至
    specs.change-spec
  • 如果输入过于模糊无法进行有意义的优化，提出一个澄清问题
  • 输出聚焦于“做什么”（行为），而非“怎么做”（实现方式）
  • 包含明确的非目标章节（至少3项）以防止范围蔓延
  • 包含负面需求（至少2项）用于安全/完整性约束
  • 使用EARS语法（SHALL/WILL/MAY）编写需求
  • 为每个验收标准标记
    [IMP]
    、
    [SEF]
    或
    [EXT]
  • 最多3个
    [NEEDS CLARIFICATION]
    标记

Related Commands & Skills

相关命令与技能

ComponentWhen to Use
/specs.brainstorm
After optimization, run brainstorm to create specification
/specs.spec-to-tasks
Convert specification to executable tasks
specs-change-spec
For bug fixes or delta changes (not new features)
specs-brainstorm
Reference for functional specification template
组件适用场景
/specs.brainstorm
优化完成后，运行头脑风暴以生成规格说明
/specs.spec-to-tasks
将规格说明转换为可执行任务
specs-change-spec
用于bug修复或增量变更（非新功能）
specs-brainstorm
功能规格说明模板参考