external-cannbot-ops-pypto-intent-understand

PyPTO Operator Requirement Intent Understanding

Convert the user's natural language description intostructured, completePyPTO operator development requirement document (SPEC.md).

Core Principles

Strictly follow the core principles below to ensure accurate and complete requirement understanding

Principle 1: Based on facts, no guessing

✅ Clearly mark information sources and confidence levels (✓ High / ⚠ Medium / ❓ Low)
✅ When uncertain, proactively ask rather than infer on your own
❌ Do not guess formulas, specifications, or parameter meanings out of thin air

Principle 2: Clear feature priorities

✅ Mark priorities (P0/P1/P2/P3) for all features (including optional parameters)
✅ P0 and P1 features must be implemented in the first version
✅ Clearly mark which features are not yet supported and why

Principle 3: In-depth analysis of optional parameters

✅ Analyze optional parameters from four dimensions: code location, computation logic, implementation complexity, and dependencies
✅ Clearly identify constraints and mutually exclusive relationships among parameters
❌ Do not omit analysis of commonly used optional parameters

Principle 4: Information completeness

✅ Required information (operator name, formula, input/output specifications, dynamic axes) must not be missing
✅ Complex operators must provide an algorithm description
✅ It is recommended to provide typical configurations to facilitate subsequent golden generation and design solutions

Principle 5: Confirm at least once

✅ Unless the user strongly requests no confirmation, confirm at least once
✅ At most 2 confirmations, overall confirmation rather than item-by-item confirmation

Principle 6: Default values must be explicitly disclosed

✅ Fields that allow default values must be shown during the confirmation step
✅ Default values may only fill in non-blocking information, and must not silently replace key requirements
❌ Do not inject default values without the user's awareness

Core Workflow

阶段 1: 快速解析 → 阶段 2: 可视化确认 → 阶段 3: 可选补充 → 输出文件

When the user's first input already contains all required information (operator name, formula/algorithm, input/output specifications), Stage 1 and Stage 2 can be merged into one step: directly show the data flow diagram + specification confirmation checklist, and generate the file after the user confirms. There is no need to mechanically go through every stage.

Stage 1: Quick Parsing

Receive user input

The user can describe operator requirements in any way. Immediately perform input classification after receiving it.

Input Classification

First determine which of the following 4 categories the input belongs to:

Standard reference category
- Applicable: common operators, framework API references, operators whose standard definitions can be found
- Identification features: the user directly gives the operator name, or explicitly says "refer to PyTorch/NumPy/TensorFlow/JAX's ..."
External material category
- Applicable: paper/document links, code snippet references
- Identification features: input contains URLs, paper links, document snippets, function definitions, import statements, or obvious code syntax
Custom description category
- Applicable to: custom operators, those without standard definitions, and operators for which trusted external references cannot be located
- Identifying characteristics: the name is clearly custom, or a search cannot locate a trusted definition
Direct specification category
- Applicable to: the user's first input already contains key information such as the operator name, formula/algorithm, and input/output specifications
- Identifying characteristics: can proceed directly to specification confirmation without relying on external references

Complexity determination and key characteristic identification

After completing input classification, determine whether it is a complex operator and identify key characteristics.

Criteria for determining complex operators：

Involves multiple steps, blocking, loops, online updates, state maintenance, or a combination of multiple sub-operators
After marking, append the following requirements:
- An algorithm description or material from which an algorithm description can be recovered must be provided
- The decomposed computation graph must be shown
- The confirmation strength must be increased to ensure there is no ambiguity in understanding the workflow

Key characteristic identification(Required for complex operators): Complex operators usually contain key characteristics that can be configured independently, and these characteristics significantly affect implementation complexity and performance. They must be proactively identified and broken down for the user to confirm.

List of common key characteristics：

Characteristic category	Typical characteristic	Applicable operator type	Scope of impact
Numerical stability	safe_softmax, logsumexp, numerical_stable	Softmax/normalization/exponential operations	Computation precision, overflow handling
Blocking strategy	tiling_strategy, block_size	Large-scale matrices/attention/convolution	Memory layout, loop structure
Mask mechanism	causal_mask, padding_mask, custom_mask, sliding_window	Attention/sequence processing	Data flow, memory access, boundary handling
Online algorithm	online_softmax, online_reduction, streaming_update	Reduction/Softmax	Computation order, intermediate state
Quantization support	int8_quant, fp8_quant, blockwise_quant, dequantize	Quantized operators	Data type, scaling factor
Fusion mode	bias_add, residual_add, activation_fused	General	Operator boundaries, intermediate result reuse
Dynamic Shape	variable_length, ragged_tensor, dynamic_axis	Sequence processing/variable-length input	Memory allocation, loop unrolling
Parallel strategy	split_k, split_n, parallel_reduction	Matrix multiplication/Reduction	Degree of parallelism, synchronization overhead
Memory optimization	in_place, workspace_reuse, page_attention	General	Memory usage, data dependency, memory optimization
Boundary handling	padding_mode, boundary_condition, edge_handling	Convolution/pooling/interpolation	Boundary precision, computation logic
Precision control	mixed_precision, accumulator_dtype, rounding_mode	General	Computation precision, numerical range
Randomness	deterministic, seed_control, dropout_rate	Dropout/random sampling	Reproducibility, random number generation
Sparsity	sparse_pattern, masked_compute, structured_sparsity	Sparse operators	Data layout, computation skipping

Characteristic identification process：

Extract characteristics already mentioned from the user's description
Identify implicit characteristics from reference materials (papers/documentation/code)
Generate a characteristic list, annotating confidence and source
During the confirmation step, have the user confirm or modify them one by one

Detailed handling of various inputs

Category 1: Standard reference type (usually ✓ high confidence)

Prioritize recovering standard definitions from existing knowledge or trusted references.

Known common operators include:

Category	Operator list
Activation functions	relu, gelu, silu, swish, mish, sigmoid, tanh, softmax, hardswish, hardsigmoid
Mathematical operations	sin, cos, sinh, cosh, tanh, exp, log, log2, log10, sqrt, rsqrt, pow, abs, sign
Normalization	layer_norm, rms_norm, batch_norm, instance_norm, group_norm
Attention	scaled_dot_product_attention, multi_head_attention
Matrix operations	matmul, addmm, bmm, linear, einsum
Reduction	sum, mean, max, min, amax, amin, argmax, argmin, prod
Element-wise	add, sub, mul, div, maximum, minimum, clamp

Handling method：

Obtain formulas and standard specifications from own knowledge base or trusted references
Mark as ✓ high confidence, display and suggest confirmation
If it is a multi-step/complex operator (such as Flash Attention, Scan), append an algorithm description requirement

Interaction example：

用户: 开发一个 GELU 算子

助手: 我知道 GELU 算子：

      GELU(x) = x * Φ(x)
            ≈ x * 0.5 * (1 + tanh(√(2/π) * (x + 0.044715*x³)))

      标准规格：
      - 输入: x [...], float32
      - 输出: y [...], float32 (shape与输入相同)

      ✓ 算子名称: gelu
      ✓ 公式: GELU(x) = x * Φ(x)
      ⚠ 有两个版本：
         1. 精确版 (使用erf)
         2. 近似版 (使用tanh)
      ❓ 你需要哪个版本？

Category 2: External material type (usually ⚠ medium confidence)

Identifying features: The input contains a URL, paper link, document excerpt, code snippet, or function definition.

Handling method：

If it is a paper/document link, use WebFetch to obtain the content and extract specification information
If it is a code snippet, analyze the code structure and extract inputs, outputs, and computation logic
Uniformly mark as ⚠ medium confidence
Musthave the user confirm whether the extracted result is correct

Fallback strategy(when WebFetch is unavailable):

Generate specification information based on standard definitions in the AI's own knowledge base
Confidence is lowered to ⚠ medium (source: AI knowledge base inference, not the original material)
In SPEC.md, annotate "⚠ Original material unavailable, generated based on standard reference, manual confirmation recommended"
Explain the reason for the fallback to the user and show the basis for the inference

Interaction example：

用户: 参考 PyTorch 的 F.scaled_dot_product_attention

助手: 我提取到以下规格信息：

      公式: Attention(Q,K,V) = softmax(QK^T/√d) @ V

      标准规格：
      - Q: [batch, num_heads, seq_len, head_dim]
      - K: [batch, num_heads, seq_len, head_dim]
      - V: [batch, num_heads, seq_len, head_dim]
      - Output: [batch, num_heads, seq_len, head_dim]

      可选参数：
      - attn_mask: 注意力掩码
      - dropout_p: dropout 概率
      - is_causal: 是否因果注意力
      - scale: 缩放因子（默认 1/√d）

      ❓ 你需要支持哪些可选参数？
      ❓ 输入的dtype是什么？(float32/bfloat16)

Category 3: Custom description type (usually ❓ requires a complete description)

Identifying features: The name is obviously custom (such as my_op, custom_fusion), no trusted standard definition can be located, or the user explicitly says it is custom.

Handling method：

Clearly inform the user that this is a custom operator
Guide the user to provide the required information (mathematical formula, input/output specifications)
Provide multiple input methods: formula description, pseudocode, NumPy/PyTorch code, flowchart description

助手: 我没有找到 "my_fusion_op" 的标准定义，这似乎是一个自定义算子。

      请提供以下信息：

      必须提供：
      1. 数学公式（例如: y = f(x) = ... 或用文字描述计算逻辑）
      2. 输入输出规格（输入: x [shape] dtype / 输出: y [shape] dtype）

      你可以用以下任一方式提供：
      - 公式描述: "y = relu(x) * sigmoid(gate), x和gate都是[b,s,d]的float32"
      - 伪代码: h1 = relu(x); h2 = sigmoid(gate); y = h1 * h2
      - NumPy/PyTorch 代码: def my_op(x, gate): return torch.relu(x) * torch.sigmoid(gate)

Category 4: Direct specification type (information completeness determines confidence)

Identifying features: The user's first input already contains key information such as the operator name, formula/algorithm, and input/output specifications.

Handling method：

Directly organize the existing information and generate a structured specification draft
If the information is complete and consistent, proceed directly to visual confirmation
If there are gaps in the information, ask only about the missing items and do not repeatedly ask about existing information

Confidence marking conventions

Mark	Confidence	Information source	Handling method
✓	High	Own knowledge base/framework knowledge	Display and suggest confirmation
⚠	Medium	WebSearch/WebFetch/code analysis	Musthave the user confirm
❓	Low	Inference/guess	Actively ask the user

Phase 2: Visual Confirmation

This isthe most critical step, ensuring that understanding aligns with user intent.

Display Content

Display in the following order:

0. Key Feature Breakdown (for complex operators only)

For complex operators, before displaying the data flow diagram,you mustfirst display the list of identified key features:

🔍 识别到的关键特性:

| 特性 | 是否需要 | 置信度 | 来源 | 实现说明 | 优先级 |
|------|----------|--------|----------|--------|
| causal_mask | ✓ 需要 | ✓ 高 | 用户描述 | 需要上三角 mask 逻辑 | P0 |
| online_softmax | ✓ 需要 | ⚠ 中 | 论文推断 | 需要分块 + 数值稳定更新 | P0 |
| multi_query_attention | ✗ 不需要 | ❓ 低 | 默认假设 | - | - |
| paged_attention | ? 待确认 | ❓ 低 | 网络搜索 | 需要KV cache管理 | P1 |
| dropout | ? 待确认 | ❓ 低 | 框架默认 | 需要随机数生成 | P2 |

❓ 请确认以上特性是否符合你的需求：
  - 需要调整哪些特性的"是否需要"状态？
  - 是否有遗漏的特性？

Feature Confirmation Interaction：

Use AskUserQuestion to let the user confirm the feature list
Provide options: Confirm all / Modify features / Add new features / I'm not sure, explain it to me
If the user is unsure, provide a brief description of each feature and typical usage scenarios

1. ASCII Data Flow Diagram

Select an appropriate data flow diagram template based on the operator type:

Simple Element-wise Operator(single input, shape unchanged):

    输入 x                      输出 y
┌────────────────┐         ┌────────────────┐
│  [b, s, n, d]  │ ──────▶ │  [b, s, n, d]  │
│   float32      │  sinh   │   float32      │
└────────────────┘         └────────────────┘

公式: y = sinh(x) = (e^x - e^(-x)) / 2
动态轴: b, s

Multi-input Matmul-type Operator：

    输入 a           输入 b           输入 c (可选)
┌──────────┐    ┌──────────┐    ┌──────────┐
│  [m, k]  │    │  [n, k]  │    │  [m, n]  │
└────┬─────┘    └────┬─────┘    └────┬─────┘
     │               │               │
     │    ┌──────────┘               │
     ▼    ▼                          │
  ┌────────────┐                     │
  │  a @ b^T   │                     │
  └─────┬──────┘                     │
        │                            │
        ▼                            ▼
     ┌──────────────────────────────────┐
     │              +                   │
     └───────────────┬──────────────────┘
                   ▼
             ┌──────────┐
             │ 输出 y   │
             │  [m, n]  │
             └──────────┘

Other Operators: Refer to the above templates and draw according to the actual data flow. For composite operators, show the decomposition and merging relationships of sub-operators.

2. Specification Confirmation Checklist

For simple operators (formulas are sufficient to describe):

✅ 必须信息:
  [✓] 算子名称: {operator_name}
  [✓] 数学公式: {formula}
  [✓] 输入: {input_name}[{shape}] {dtype}, 动态轴: {dynamic_axes}
  [✓] 输出: {output_name}[{shape}] {dtype}, 动态轴: {dynamic_axes}

⚙️ 自动推断（使用默认值，可修改）:
  • 支持数据类型: float32 (atol=0.001, rtol=0.001)
  • 性能目标: 无特殊要求
  • 边界处理: 正常计算

For complex operators (formulas cannot fully express the computation flow), add an algorithm section and a key features section:

✅ 必须信息:
  [✓] 算子名称: {operator_name}
  [✓] 数学公式: {formula}
  [✓] 关键特性:
      ┌─────────────────────┬────────┬──────────────────────────┐
      │ 特性                │ 状态   │ 实现说明                 │
      ├─────────────────────┼────────┼──────────────────────────┤
      │ causal_mask         │ ✓ 需要 │ 上三角 mask 逻辑         │
      │ online_softmax      │ ✓ 需要 │ 分块 + 数值稳定更新      │
      │ paged_attention     │ ✗ 不需 │ -                        │
      │ dropout             │ ✗ 不需 │ -                        │
      └─────────────────────┴────────┴──────────────────────────┘
  [✓] 算法描述:
      Algorithm: {algorithm_name}
      ────────────────────────────
      {带编号的伪代码步骤}
  [✓] 输入: ...
  [✓] 输出: ...

When an algorithm description is needed: When the computation involves procedural logic such as tiling, loops, online updates, state maintenance, etc., formulas can only describe the mathematical semantics but cannot describe the implementation strategy. In this case, an algorithm description is needed to explain "how it is computed". Typical examples: the tiled computation + Online Softmax of Flash Attention, and the recurrence process of Scan-type operators.

Algorithm Description Format: Use numbered pseudocode steps to clearly show the loop structure, tiling strategy, state updates, and other processes. Example:

Algorithm: Flash Attention (Forward)
────────────────────────────────────
输入: Q, K, V ∈ R^{N×d}, 分块大小 Br, Bc
输出: O ∈ R^{N×d}

1. 将 Q 分为 Tr = ⌈N/Br⌉ 块, K/V 分为 Tc = ⌈N/Bc⌉ 块
2. 初始化 O = 0, l = 0, m = -∞
3. for j = 1 to Tc:                          // 外层循环: K/V 块
     3.1 从 HBM 加载 K_j, V_j 到 SRAM
     3.2 for i = 1 to Tr:                    // 内层循环: Q 块
           3.2.1 从 HBM 加载 Q_i, O_i, l_i, m_i 到 SRAM
           3.2.2 S_ij = Q_i @ K_j^T  ∈ R^{Br×Bc}
           3.2.3 m̃_ij = rowmax(S_ij)
           3.2.4 P̃_ij = exp(S_ij - m̃_ij)
           3.2.5 l̃_ij = rowsum(P̃_ij)
           3.2.6 m_new = max(m_i, m̃_ij)
           3.2.7 l_new = exp(m_i - m_new) * l_i + exp(m̃_ij - m_new) * l̃_ij
           3.2.8 O_i ← diag(l_new)^{-1} * (diag(l_i) * exp(m_i - m_new) * O_i
                        + exp(m̃_ij - m_new) * P̃_ij @ V_j)
           3.2.9 写回 O_i, l_new, m_new 到 HBM
4. return O

3. Operation Options

Use the AskUserQuestion tool to provide the user with the following choices:

Modify an item — Modify any of the above information
Add more details — Proceed to Phase 3
Everything is correct, continue — Skip Phase 3 and generate the file directly

Confirmation Strategy

High confidence (✓): Display but do not force confirmation; the user can continue directly
Medium confidence (⚠)：mustconfirm once
Number of confirmations: At most 2 times (category confirmation (only for medium confidence) + final confirmation)
Confirmation method: Overall confirmation, not item-by-item confirmation
Multi-step/complex operators: Decomposed display, overall confirmation

Phase 3: Optional Supplements

If the user chooses "Add more details", use AskUserQuestion to display the following optional configuration items:

Dynamic axis range — The value range of dynamic axes (default: unrestricted)
Performance goals — Whether there are special performance metric requirements (default: no special requirements)
Boundary condition handling — How zero values/extreme values/NaN/Inf are handled (default: normal computation)
Reference implementation — PyTorch/NumPy reference implementation link or code

Application Scenarios and Typical Configurations — Target model, usage location, typical configuration table (strongly recommended)

Typical configurations are used for subsequent golden verification and design solution generation, using a 7-column format:

Configuration Name	Type	Priority	Parameters	Input Shape	Output Shape	Description
Performance_P0	Performance	P0	{key parameters}	{each input shape}	{output shape}	Core performance scenario
Function_P0	Function	P0	{key parameters}	{each input shape}	{output shape}	Core function verification

Guided Process: If the user chooses to provide application scenarios, proactively ask whether they will provide typical configurations. If the user does not provide typical configurations, recommend default configurations based on the dynamic axis ranges for confirmation.

The user may fill in only the items they care about, and the rest will use default values.

Output File Generation

After user confirmation, generate the SPEC.md file:

SPEC.md Template

The template file is located at: templates/spec-template.md

When using it, replace the following placeholders:

{operator_name} — Operator name
{category} — Operator category (element-wise / reduction / matmul / attention / custom)
{formula} — Mathematical formula
{description} — Functional description
front matter structured fields:
- {axes_list} / {axes_ranges} / {shape_constraints}
- {performance_target}
- {atol} / {rtol}
- Convention:axes_list Must be a YAML-parsable list (for example ['N'] or ['N','M']）
{feature_name}, {need_or_not}, {confidence}, {impl_note}, {priority} — Key features table rows (required for complex operators)
{algorithm_name} / {带编号的伪代码步骤} — Algorithm description (optional, required for complex operators)
{ASCII数据流图} — Data flow diagram
{name}, {shape}, {dtype}, {dynamic_axes}, {description} — Input/output specifications
{atol}, {rtol} — Precision requirements
{axes_list}, {axes_meanings}, {axes_ranges} — Dynamic axis description
{zero_handling}, {inf_handling}, {nan_handling} — Boundary condition handling
{performance_target} — Performance targets
{reference_impl}, {paper}, {similar_ops} — Reference information
{model}, {layer} — Application scenarios
{config_name}, {type}, {priority}, {params}, {input_shapes}, {output_shapes}, {config_desc} — Typical configuration table rows
{timestamp} — Generation time

File Conflict Handling

If under the target path SPEC.md already exists,mustask the user via AskUserQuestion :

⚠ 文件已存在:
  - SPEC.md 路径

请选择:
  1. 覆盖 — 用新生成的内容替换已有文件
  2. 取消 — 不生成文件，保留现有内容

Field Definitions and Default Values

Required fields (no default values, must be provided by the user)

Field	Type	Description
Operator name	string	Unique identifier, starts with a lowercase letter, may contain only lowercase letters, digits, and underscores
Mathematical formula	string	Core computation logic, required for all operators

Conditionally required fields (must be provided in specific scenarios)

Field	Type	When required
Algorithm description	string	When the formula cannot fully express the computation flow (involving procedural logic such as blocking, loops, online updates, state maintenance, etc.)

The formula describes "what to compute", and the algorithm describes "how to compute it". Most operators that require an algorithm also have a formula. Simple operators (such as y = sinh(x)) only need a formula; complex operators (such as Flash Attention) have both.

Recommended fields (with default values)

Field	Default value	Description
Input shape	Construct a typical value	Input tensor shape
Input dtype	float32	Input data type
Output shape	Derived from the input	Output tensor shape
Output dtype	Same as the input	Output data type
Dynamic axes	batch、seq	Supports dynamic shape
Performance target	2 times the first-run accuracy-success performance	Performance optimization guidance
Accuracy requirement	atol=0.001, rtol=0.001	Default accuracy standard

Optional fields (with reasonable default values, can be skipped entirely)

Field	Default value	Purpose
Optional parameters	Automatically derived	Functional completeness
Dynamic axis ranges	[1, INT32_MAX]	Performance optimization
Boundary condition handling	Normal computation (zero/inf/nan are all normal)	Special value handling
Reference implementation	None	Framework/paper/code reference
Application scenarios	Recommended to provide typical configurations (7-column table)	Model/layer/typical configuration table, for subsequent golden generation and design solutions

Default value disclosure rules

When the following information is not provided and default values are allowed to be used, it must be clearly displayed during the confirmation step and must not be filled in silently:

dtype default value
atol / rtol default values
Dynamic axis range default values
Performance target default value

Display format suggestion:

⚙️ 将使用以下默认值（如不修改，将直接写入 SPEC.md）：
- dtype: float32
- atol/rtol: 0.001 / 0.001
- 动态轴范围: [1, INT32_MAX]
- 性能目标: 首跑精度成功性能的 2 倍

⚠️ Default value persistence requirement: All default values displayed during the confirmation step must be written into the corresponding fields of the generated SPEC.md (such as default_params frontmatter fields, accuracy requirement section, etc.), and must not be only displayed without being persisted.

In-depth analysis of optional parameters

When an operator involves optional parameters (such as in framework API reference scenarios), an in-depth analysis must be performed from the following four dimensions:

Dimension	Description	Example
Code location	At which stage of the computation flow the parameter is used	Input preprocessing/core computation/output post-processing
Computation logic	How the parameter affects the computation	Conditional branching/numerical scaling/data selection
Implementation complexity	Whether PyPTO supports it	Low (directly supported)/Medium (requires special handling)/High (not supported)
Dependency relationships	Whether it depends on other parameters	Independent/dependent on parameter X/mutually exclusive with parameter Y

Analysis method：

Locate the code position: Search for the parameter name in the reference implementation and find where it is used
Understand the computation logic: Analyze how the parameter affects the computation flow
Assess implementation complexity: Determine whether the PyPTO API supports it and how difficult it is to implement
Determine dependency relationships: Analyze constraints and mutual exclusivity relationships between parameters

Feature priority system

Determine implementation priority based on the importance of the feature:

Priority	Definition	Description
P0 (must have)	Core feature	Cannot work without it; required in all scenarios
P1 (important)	Common feature	Affects most usage scenarios,must be implemented in the first version
P2 (optional)	Special-scenario feature	Decide whether to implement based on requirements
P3 (deferred)	Not supported or too costly	Not supported by PyPTO or too costly to implement; not implemented for now

Important principles：

P0 and P1 features must be implemented in the first version
Only P2/P3 features can be deferred
Mark the priority of each feature in the specification confirmation checklist

Example：

✅ 必须信息:
  [✓] 算子名称: scaled_dot_product_attention
  [✓] 数学公式: Attention(Q,K,V) = softmax(QK^T/√d) @ V
  [✓] 输入: Q, K, V [b, h, s, d] float32 (P0)
  [✓] 可选参数:
      - attn_mask: 注意力掩码 (P2)
      - dropout_p: dropout 概率 (P3)
      - is_causal: 因果注意力 (P1)
      - scale: 缩放因子 (P1)

Requirements understanding checklist

The completeness of the current requirements information has been assessed (high / medium / low)
The usage of default values has been explicitly shown
The operator name has been confirmed and complies with the naming convention (see "Field definitions" § Operator name)
The mathematical formula has been confirmed and clearly describes the core computation logic
For complex operators, key characteristics have been identified and confirmed with the user (see "Complexity determination and key characteristic identification")
For complex operators, an algorithm description has been provided (see "Stage 2" § When an algorithm description is needed)
All key characteristics have been marked with implementation status (✓ needed / ✗ not needed / ? to be confirmed) and priority
All information has been marked with confidence level (✓ high / ⚠ medium / ❓ low)
Input/output shapes, dtypes, and dynamic axes have been clarified
Optional parameters have been listed and marked with priority (P0-P3); P0/P1 have completed the four-dimensional analysis
P0 and P1 features have no omissions (see "Feature priority system")
Precision requirements, boundary conditions, and dynamic axis ranges have been clarified or default values have been used
Performance goals, reference implementation, application scenarios, and typical configuration have been asked about
Medium-confidence information has been confirmed once, and the number of confirmations has not exceeded 2

About this skill

Core Principles

Principle 1: Based on facts, no guessing

Principle 2: Clear feature priorities

Principle 3: In-depth analysis of optional parameters

Principle 4: Information completeness

Principle 5: Confirm at least once

Principle 6: Default values must be explicitly disclosed

Core Workflow

Stage 1: Quick Parsing

Receive user input

Input Classification

Complexity determination and key characteristic identification

Detailed handling of various inputs

Category 1: Standard reference type (usually ✓ high confidence)

Category 2: External material type (usually ⚠ medium confidence)

Category 3: Custom description type (usually ❓ requires a complete description)

Category 4: Direct specification type (information completeness determines confidence)

Confidence marking conventions

Phase 2: Visual Confirmation

Display Content

0. Key Feature Breakdown (for complex operators only)

1. ASCII Data Flow Diagram

2. Specification Confirmation Checklist

3. Operation Options

Confirmation Strategy

Phase 3: Optional Supplements

Output File Generation

SPEC.md Template

File Conflict Handling

Field Definitions and Default Values

Required fields (no default values, must be provided by the user)

Conditionally required fields (must be provided in specific scenarios)

Recommended fields (with default values)

Optional fields (with reasonable default values, can be skipped entirely)

Default value disclosure rules

In-depth analysis of optional parameters

Feature priority system

Requirements understanding checklist