awesome-requirements-writer 0.1.0

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Mucheng
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/README-zh.md

@@ -0,0 +1,149 @@
+# Awesome Requirements Writer
+
+作为一个具有十多年工作经验的汽车软件工程师和带领工程团队获得ASPICE认证的技术经理，我把多年来参与编写/评审技术产品需求的心得总结出来，写成了这个可复用的 AI agent skill，用于把工程笔记、客户输入、标准条款和测试期望转换为清晰、可测试的技术产品需求。
+
+对于这个skill中提到的一些内容，我曾经写过一篇文章，具体请浏览：https://zhuanlan.zhihu.com/p/338598640
+
+[English](./README.md) | 简体中文
+
+## 聚焦的问题
+
+对于初级工程师而言，撰写的技术需求总会遇到一些常见的问题，例如：
+
+- 口语化工程笔记直接变成了模糊需求；
+- 需求正文混入了原因解释、例子、图示或测试建议；
+- 复合条件里的 `AND` / `OR` 逻辑不清楚；
+- 一个需求 ID 同时覆盖多个行为或多个测试点；
+- 静态数值直接写进需求，没有命名变量和变量表；
+- 输入、输出、状态和验收标准不可测试；
+- 中间级需求不能和上下级作出清晰关联等等。
+
+
+## 解决方案
+
+这个仓库把一个 `SKILL.md` 文件和中英文需求写作模板打包成可给 AI agent 调用的 skill，以解决工程师经验不足的问题。
+
+
+| 原则 | 防止的问题 |
+| --- | --- |
+| **干净直接** | 原因解释或背景信息混进规范性需求正文 |
+| **无歧义** | 主观词、隐藏假设、不明确的布尔逻辑 |
+| **原子化** | 一个 ID 覆盖多个义务或条件 |
+| **正向定义** | 通过否定相反条件来定义需求 |
+| **没有魔法数字** | 硬编码数值缺少静态变量表 |
+| **可直接测试** | 测试团队无法控制输入或观察输出 |
+| **需求和信息分离** | 把需求、说明、上下文、例子和图混在一起 |
+| **可追溯** | 需求缺少来源、测试、设计或验收链接 |
+
+
+
+## 安装
+
+**方法一（推荐）：**
+直接告诉你的agent：安装awesome-requirements-writer。
+
+**方法二：**
+
+前置条件：先安装 Node.js 18 或更新版本。
+
+Linux/macOS 可用 nvm 安装 Node.js LTS：
+
+```bash
+curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.4/install.sh | bash && . "$HOME/.nvm/nvm.sh" && nvm install --lts
+```
+
+检查当前环境：
+
+```bash
+node --version
+```
+
+
+确认node.js已安装后，运行：
+
+```bash
+npx awesome-requirements-writer install
+```
+备注：
+这个包也提供可选安装器 CLI，用于安装特定工具的 adapter。例如，若只想安装到 Codex 专用目录：
+
+```bash
+npx awesome-requirements-writer install codex
+```
+
+查看支持的目标：
+
+```bash
+npx awesome-requirements-writer list
+```
+ß
+## 使用
+
+显式调用 skill：
+
+```text
+Use $awesome-requirements-writer to turn these engineering notes into product requirements:
+...
+```
+
+这个 skill 会跟随用户语言输出。用户用中文输入时，默认输出中文需求，除非明确要求英文。
+
+## 仓库结构
+
+```text
+package.json
+bin/awesome-requirements-writer.js
+SKILL.md
+references/
+  automotive-context.md
+  requirement-patterns-en.md
+  requirement-patterns-zh.md
+adapters/
+  codex/
+  claude/
+  cursor/
+  gemini/
+  opencode/
+  codebuddy/
+  github-copilot/
+  trae/
+```
+
+`SKILL.md` 是核心 agent 指令。`references/` 里的文件只在任务需要详细模板或汽车工程上下文时读取。
+
+## 平台适配
+
+| 目标平台 | Adapter 来源 | 安装目标 |
+| --- | --- | --- |
+| 通用 Agent Skills | `adapters/codex/.agents/skills/awesome-requirements-writer/` | `~/.agents/skills/awesome-requirements-writer/` 或项目 `.agents/skills/awesome-requirements-writer/` |
+| 仅 Codex | `adapters/codex/.agents/skills/awesome-requirements-writer/` | `~/.codex/skills/awesome-requirements-writer/` 或项目 `.codex/skills/awesome-requirements-writer/` |
+| Claude Code | `adapters/claude/.claude/skills/awesome-requirements-writer/` | `.claude/skills/awesome-requirements-writer/` 或 `~/.claude/skills/awesome-requirements-writer/` |
+| Cursor | `adapters/cursor/.cursor/rules/` | `.cursor/rules/`，包含 `references/` |
+| Gemini CLI | `adapters/gemini/` | 合并到 `GEMINI.md`；把 references 复制到 `.gemini/awesome-requirements-writer/` |
+| OpenCode | `adapters/opencode/` | 将 `AGENTS.snippet.md` 合并到 `AGENTS.md`；把 references 复制到 `.opencode/awesome-requirements-writer/` |
+| CodeBuddy | `adapters/codebuddy/.codebuddy/rules/awesome-requirements-writer/` | `.codebuddy/rules/awesome-requirements-writer/`，包含 `RULE.mdc` 和 `references/` |
+| GitHub Copilot | `adapters/github-copilot/.github/` | `.github/`，包含 `copilot-instructions.md`、`instructions/` 和 `instructions/references/` |
+| Trae | `adapters/trae/.trae/` | Trae 项目规则路径，需确认当前版本使用 `.trae/project_rules.md` 还是 `.trae/rules/project_rules.md` |
+
+规则型 adapter 现在也包含 `references/`，但入口文件会明确要求 agent 不要默认加载全部 reference，只在任务需要时读取对应语言模板或汽车工程上下文。对于 `AGENTS.md` 或 `GEMINI.md` 这类固定入口文件，应把提供的 snippet 合并进用户已有文件，而不是覆盖。
+
+CLI 安装器会自动用带标记的文本块完成合并。重复运行安装器会更新同一个标记块，不会反复追加重复内容。
+
+## 如何判断它在起作用
+
+如果输出满足以下特征，说明 skill 正在发挥作用：
+
+- 需求和解释性信息分开。
+- 使用稳定 ID，例如 `SYS-001`、`SWE-001` 或 `HW-001`。
+- 明确触发条件、状态、输入、输出和验收标准。
+- 用命名静态变量替代未解释的数字。
+- 复合条件中的 `AND` / `OR` 逻辑清晰。
+- 对缺失工程值提出开放问题，而不是编造阈值。
+
+## 个性化修改
+
+用户可修改 `SKILL.md` 来调整核心行为，可在## Project-Specific Guidelines 一节中加入自己公司/团队的定制化规则。修改 `references/requirement-patterns-en.md` 和 `references/requirement-patterns-zh.md` 来调整语言相关的示例、模板和术语。
+
+## 许可
+
+MIT

package/README.md

@@ -0,0 +1,145 @@
+# Awesome Requirements Writer
+
+As an automotive software engineer with more than ten years of experience, and as a technical manager who has led engineering teams through ASPICE certification, I summarized what I have learned from years of writing and reviewing technical product requirements into this reusable AI agent skill. It helps turn engineering notes, customer inputs, standards, and test expectations into clear, testable technical product requirements.
+
+Some of the ideas behind this skill are discussed in an article I wrote: https://zhuanlan.zhihu.com/p/338598640
+
+English | [简体中文](./README-zh.md)
+
+## Problems Addressed
+
+Junior engineers often run into recurring problems when writing technical requirements, such as:
+
+- Conversational engineering notes becoming vague requirements;
+- Requirement text mixing normative behavior with rationale, examples, diagrams, or test advice;
+- Compound conditions with unclear `AND` / `OR` logic;
+- One requirement ID covering multiple behaviors or multiple test points;
+- Static values written directly into requirements without named variables or a variable table;
+- Inputs, outputs, states, and acceptance criteria that are not testable;
+- Intermediate-level requirements that cannot be clearly linked to upper-level or lower-level requirements.
+
+## Solution
+
+This repository packages one `SKILL.md` file plus English and Chinese requirement-writing templates as an AI-agent skill to help compensate for gaps in requirement-writing experience.
+
+| Principle | Prevents |
+| --- | --- |
+| **Clean and direct** | Rationale or background information leaking into normative requirement text |
+| **Unambiguous** | Subjective wording, hidden assumptions, unclear Boolean logic |
+| **Atomic** | One ID covering multiple obligations or conditions |
+| **Positively defined** | Requirements defined by negating the opposite condition |
+| **No magic numbers** | Hard-coded values without a static-variable table |
+| **Directly testable** | Inputs or outputs that verification teams cannot control or observe |
+| **Separate requirements from information** | Requirements, explanations, context, examples, and diagrams mixed together |
+| **Traceable** | Requirements without source, test, design, or acceptance links |
+
+## Install
+
+**Method 1 (Recommended):**
+Tell your agent directly: install `awesome-requirements-writer` skill.
+
+**Method 2:**
+
+Prerequisite: install Node.js 18 or newer.
+
+Install Node.js LTS on Linux/macOS with nvm:
+
+```bash
+curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.4/install.sh | bash && . "$HOME/.nvm/nvm.sh" && nvm install --lts
+```
+
+Check your environment:
+
+```bash
+node --version
+```
+
+After confirming Node.js is installed, run:
+
+```bash
+npx awesome-requirements-writer install
+```
+
+Note:
+This package also provides an optional installer CLI for target-specific adapters. For example, if you only want to install to the Codex-specific directory:
+
+```bash
+npx awesome-requirements-writer install codex
+```
+
+List supported targets:
+
+```bash
+npx awesome-requirements-writer list
+```
+
+## Use
+
+Invoke the skill explicitly:
+
+```text
+Use $awesome-requirements-writer to turn these engineering notes into product requirements:
+...
+```
+
+The skill follows the user's language. Chinese input produces Chinese requirements unless English is requested.
+
+## Repository Layout
+
+```text
+package.json
+bin/awesome-requirements-writer.js
+SKILL.md
+references/
+  automotive-context.md
+  requirement-patterns-en.md
+  requirement-patterns-zh.md
+adapters/
+  codex/
+  claude/
+  cursor/
+  gemini/
+  opencode/
+  codebuddy/
+  github-copilot/
+  trae/
+```
+
+`SKILL.md` is the core agent instruction. The files in `references/` are loaded only when the task needs detailed templates or automotive engineering context.
+
+## Adapters
+
+| Target | Adapter source | Install target |
+| --- | --- | --- |
+| Shared Agent Skills | `adapters/codex/.agents/skills/awesome-requirements-writer/` | `~/.agents/skills/awesome-requirements-writer/` or project `.agents/skills/awesome-requirements-writer/` |
+| Codex-only | `adapters/codex/.agents/skills/awesome-requirements-writer/` | `~/.codex/skills/awesome-requirements-writer/` or project `.codex/skills/awesome-requirements-writer/` |
+| Claude Code | `adapters/claude/.claude/skills/awesome-requirements-writer/` | `.claude/skills/awesome-requirements-writer/` or `~/.claude/skills/awesome-requirements-writer/` |
+| Cursor | `adapters/cursor/.cursor/rules/` | `.cursor/rules/`, including `references/` |
+| Gemini CLI | `adapters/gemini/` | Merge into `GEMINI.md`; copy references under `.gemini/awesome-requirements-writer/` |
+| OpenCode | `adapters/opencode/` | Merge `AGENTS.snippet.md` into `AGENTS.md`; copy references under `.opencode/awesome-requirements-writer/` |
+| CodeBuddy | `adapters/codebuddy/.codebuddy/rules/awesome-requirements-writer/` | `.codebuddy/rules/awesome-requirements-writer/`, including `RULE.mdc` and `references/` |
+| GitHub Copilot | `adapters/github-copilot/.github/` | `.github/`, including `copilot-instructions.md`, `instructions/`, and `instructions/references/` |
+| Trae | `adapters/trae/.trae/` | Trae project rules path, confirm whether your version uses `.trae/project_rules.md` or `.trae/rules/project_rules.md` |
+
+Rule-style adapters include bundled `references/`, but their entry files explicitly tell the agent not to load every reference by default. The agent should read only the matching language or automotive-context reference when the task needs it. For fixed entry filenames such as `AGENTS.md` or `GEMINI.md`, merge the provided snippet into the user's existing file instead of overwriting it.
+
+The CLI installer performs this merge automatically by using a marked block. Re-running the installer updates that block instead of appending duplicates.
+
+## How to Know It's Working
+
+The skill is working if the output has:
+
+- Requirements separated from explanatory information.
+- Stable IDs such as `SYS-001`, `SWE-001`, or `HW-001`.
+- Explicit triggers, states, inputs, outputs, and acceptance criteria.
+- Named static variables instead of unexplained numbers.
+- Clear `AND` / `OR` logic for compound conditions.
+- Open questions for missing engineering values instead of invented thresholds.
+
+## Customization
+
+Users can edit `SKILL.md` to adjust the core behavior, and can add company- or team-specific rules under a `## Project-Specific Guidelines` section. Edit `references/requirement-patterns-en.md` and `references/requirement-patterns-zh.md` to adjust language-specific examples, templates, and terminology.
+
+## License
+
+MIT

package/SKILL.md

@@ -0,0 +1,65 @@
+---
+name: awesome-requirements-writer
+description: Use when drafting, rewriting, reviewing, or decomposing technical product requirements for product systems, micro-processors, sensors, actuators, or functions, diagnostics, interfaces, or specifications, engineering change requests. Helps turn engineering know-how, notes, standards, customer notes and test expectations from conversational casual writing into clear, atomic, measurable, traceable，unambiguous requirements with acceptance criteria.
+---
+
+# Awesome Requirements Writer
+ 
+## Overview
+
+Turn engineering intent into requirements that can be designed, reviewed, implemented, verified, and traced. Prefer precise requirements over broad product prose, and flag missing engineering inputs instead of inventing thresholds.
+
+
+## Requirement Principles
+
+A strong requirement is:
+
+- **Clean and direct:** include only necessary normative or definitional content in the requirement statement, no rationale content. 
+- **Unambiguous:** avoid subjective terms, vague modifiers, and implicit Boolean logic; use explicit `AND` / `OR` for compound conditions.
+- **Atomic:** assign one requirement ID to one indivisible obligation, condition, or behavior.
+- **Positively defined:** describe when the system shall perform the required behavior; avoid defining behavior by negating the opposite condition.
+- **No magic numbers:** all static numbers shall be expressed by a static variable name with a table of all static variables with its real engineering value.
+- **Directly testable:** make required inputs controllable and required outputs observable by the intended verification method.
+- **Separate from information:** keep rationale, examples, diagrams, repeated context, and verification notes outside the normative requirement text.
+- **Traceable:** link upward to source, system, safety, customer, regulatory, or design-constraint needs, and sideways or downward to test and design evidence.
+
+
+## Workflow
+
+1. Identify the item under requirement: product system, subsystem, feature, variant, and lifecycle phase.
+2. Extract stakeholder intent, system behavior, constraints, interfaces and validation expectations.
+3. Determine if the content is "information" or "requirement". Information is the content which is rationale, examples, diagrams, repeated else-defined requirements, and verification notes outside the normative requirement text.
+4. Classify requirements by type: functional (direct related to a specific feature or design), non-functional (performance, efficiency, expansion etc).
+5. Draft atomic "shall" statements with a single subject, condition, behavior, measurable target, operating bounds, and verification path.
+6. Add metadata: type(information/requirement), ID , content body and acceptance criteria.
+7. List all functional requirements and related information in one chapter, while all non-functional requirements in another.
+8. In a new chapter make a table of all static variables and its value. If no value is given, type TBD.
+9. Audit the result for ambiguity, hidden design decisions, unverifiable claims, duplicate requirements, conflicting limits, missing fault behavior, and missing open questions.
+
+## Requirement Shape
+
+Use this format unless the user asks for another one:
+
+for information:
+- [Info] `<information body>`   
+
+for requirement:
+- [Req `<ID>`] `<requirement body>` | `<acceptance criteria>`
+
+
+## Output Rules
+
+- Match the user's language. If the user writes in Chinese, draft requirements in Chinese unless they request English.
+- If source notes are incomplete, produce the best draft plus a short "Open Questions" list.
+- If multiple interpretations are plausible, state the assumption used.
+- Generate output as a .md file.
+
+## Project-Specific Guidelines
+User can add their customized project-specific guidelines in this section.
+
+
+## References
+
+- Read `references/requirement-patterns-en.md` when drafting many requirements or converting informal engineering notes in English.
+- Read `references/requirement-patterns-zh.md` when drafting many requirements or converting informal engineering notes in Chinese.
+- Read `references/automotive-context.md` when the work involves automotive engineering.

package/adapters/claude/.claude/skills/awesome-requirements-writer/SKILL.md

@@ -0,0 +1,65 @@
+---
+name: awesome-requirements-writer
+description: Use when drafting, rewriting, reviewing, or decomposing technical product requirements for product systems, micro-processors, sensors, actuators, or functions, diagnostics, interfaces, or specifications, engineering change requests. Helps turn engineering know-how, notes, standards, customer nots and test expectations from conversational casual writing into clear, atomic, measurable, traceable，unambiguous requirements with acceptance criteria.
+---
+
+# Awesome Requirements Writer
+ 
+## Overview
+
+Turn engineering intent into requirements that can be designed, reviewed, implemented, verified, and traced. Prefer precise requirements over broad product prose, and flag missing engineering inputs instead of inventing thresholds.
+
+
+## Requirement Principles
+
+A strong requirement is:
+
+- **Clean and direct:** include only necessary normative or definitional content in the requirement statement, no rationale content. 
+- **Unambiguous:** avoid subjective terms, vague modifiers, and implicit Boolean logic; use explicit `AND` / `OR` for compound conditions.
+- **Atomic:** assign one requirement ID to one indivisible obligation, condition, or behavior.
+- **Positively defined:** describe when the system shall perform the required behavior; avoid defining behavior by negating the opposite condition.
+- **No magic numbers:** all static numbers shall be expressed by a static variable name with a table of all stactic variables with its real engineering value.
+- **Directly testable:** make required inputs controllable and required outputs observable by the intended verification method.
+- **Separate from information:** keep rationale, examples, diagrams, repeated context, and verification notes outside the normative requirement text.
+- **Traceable:** link upward to source, system, safety, customer, regulatory, or design-constraint needs, and sideways or downward to test and design evidence.
+
+
+## Workflow
+
+1. Identify the item under requirement: product system, subsystem, feature, variant, and lifecycle phase.
+2. Extract stakeholder intent, system behavior, constraints, interfaces and validation expectations.
+3. Determine if the content is "information" or "requirement". Information is the content which is rationale, examples, diagrams, repeated else-defined requirements, and verification notes outside the normative requirement text.
+4. Classify requirements by type: functional (direct related to a specific feature or design), non-functional (performance, efficiency, expansion etc).
+5. Draft atomic "shall" statements with a single subject, condition, behavior, measurable target, operating bounds, and verification path.
+6. Add metadata: type(information/requirement), ID , content body and acceptance criteria.
+7. List all functinal requirements and related information in one chapter, while all non-functional requirements in another.
+8. In a new chapter make a table of all static variables and its value. If no value is given, type TBD.
+9. Audit the result for ambiguity, hidden design decisions, unverifiable claims, duplicate requirements, conflicting limits, missing fault behavior, and missing open questions.
+
+## Requirement Shape
+
+Use this format unless the user asks for another one:
+
+for information:
+- [Info] `<information body>`   
+
+for requirement:
+- [Req `<ID>`] `<requirement body>` | `<acceptance criteria>`
+
+
+## Output Rules
+
+- Match the user's language. If the user writes in Chinese, draft requirements in Chinese unless they request English.
+- If source notes are incomplete, produce the best draft plus a short "Open Questions" list.
+- If multiple interpretations are plausible, state the assumption used.
+- Generate output as a .md file.
+
+## Project-Specific Guidelines
+User can add their customized project-spicific guidelines in this section.
+
+
+## References
+
+- Read `references/requirement-patterns-en.md` when drafting many requirements or converting informal engineering notes in English.
+- Read `references/requirement-patterns-zh.md` when drafting many requirements or converting informal engineering notes in Chinese.
+- Read `references/automotive-context.md` when the work involves automotive engineering.

package/adapters/claude/.claude/skills/awesome-requirements-writer/references/automotive-context.md

@@ -0,0 +1,59 @@
+# Automotive Context
+
+Use this reference when requirements touch automotive engineering concerns beyond basic product wording.
+
+## Common Requirement Categories
+
+- Vehicle function behavior
+- ECU or controller behavior
+- Sensor and actuator behavior
+- Signal and network interfaces
+- Diagnostic and service behavior
+- Safety-derived behavior
+- Cybersecurity and access control
+- Calibration and variant behavior
+- Environmental, electrical, EMC, thermal, vibration, and durability constraints
+- Manufacturing, end-of-line, service, and repair constraints
+- Over-the-air update and software lifecycle behavior
+- Regulatory, homologation, emissions, and market-specific constraints
+
+## Safety and Cybersecurity Discipline
+
+Do not infer formal classifications from general knowledge. If safety or cybersecurity is involved, ask for or preserve:
+
+- Item definition and operational design context
+- Hazard or threat source
+- Safety goal, safety requirement, or security goal
+- ASIL, QM, cybersecurity impact, or other classification supplied by responsible experts
+- Safe state, degraded mode, driver warning, fallback, or diagnostic reaction
+- Fault detection time, fault tolerant time interval, debounce, confirmation, and clearing criteria
+- Trace to safety concept, cybersecurity concept, regulation, customer specification, or validation evidence
+
+If the user asks for a safety or regulatory requirement without source material, draft a placeholder requirement and clearly mark the missing source and owner.
+
+## Interfaces
+
+For signal, network, API, or electrical interfaces, capture:
+
+- Sender and receiver
+- Message, signal, pin, connector, topic, or API name
+- Data type, units, range, resolution, accuracy, scaling, default, invalid value, and initialization value
+- Cycle time, latency, timeout, debounce, freshness, and synchronization behavior
+- Behavior on missing, stale, implausible, or conflicting data
+- Ownership of the interface definition and compatibility constraints
+
+## Diagnostics
+
+For diagnostic requirements, capture:
+
+- Fault conditions
+- Enable conditions
+- Suppress conditions
+- Detection threshold and debounce
+- Fault reaction
+- Diagnostic trouble code, status bit, event, or service record
+- Driver or service notification
+- Clearing and healing conditions
+- Freeze-frame, snapshot, log, or service data
+- Verification method and required evidence
+

package/adapters/claude/.claude/skills/awesome-requirements-writer/references/requirement-patterns-en.md

@@ -0,0 +1,121 @@
+# Requirement Patterns
+
+Use these patterns to convert engineering notes into precise automotive requirements.
+
+Write requirements in this form:
+
+- "When `<trigger/condition>`, the `<system/item>` shall `<observable response>` within `<measurable limit>` under `<operating conditions>`."
+- "While `<state>`, the `<system/item>` shall `<maintain/limit/prohibit behavior>`."
+- "If `<fault or invalid input>` is detected, the `<system/item>` shall `<safe/diagnostic/degraded response>`."
+- "Where `<variant/configuration>` is equipped, the `<system/item>` shall `<behavior>`."
+
+## Core Patterns
+
+Functional:
+
+`When <trigger>, the <system> shall <response>.`
+
+Performance:
+
+`When <condition>, the <system> shall <response> within <limit> under <operating range>.`
+
+State behavior:
+
+`While <state>, the <system> shall <maintain/prohibit behavior>.`
+
+Fault behavior:
+
+`If <fault/invalid input/loss of communication> is present, the <system> shall <safe state/degraded mode/diagnostic response>.`
+
+Interface:
+
+`The <sender> shall transmit <signal/message> to <receiver> with <content, range, resolution, timing, timeout, and validity rules>.`
+
+Diagnostic:
+
+`If <fault condition> persists for <debounce criteria>, the <system> shall set <fault status> and <fault mitigation response>`
+
+
+## ID Pattern
+
+Use stable, readable IDs:
+
+- `SYS-001` for system functional behavior
+- `SWE-001` for software behavior
+- `HW-001` for hardware and mechanical requirements
+
+information do not have IDs.
+
+
+Do not renumber existing IDs unless the user asks. New requirements should append to the current sequence.
+
+## Variable and Keywords Pattern
+
+In all information and requirements, 
+- to express local variables/ process variables, use all lower case and italic letters, for example: "*lateral speed*".
+- to express gobal variables/ calibrateable variables, use all uppercase letters and Bold, for example: "**TIMEOUT THRESHOLD**"
+- The logic expressons "and, or, not, xor" shall be marked as "**AND**", "**OR**", "**NOT**", and "**XOR**", respectively.
+- The keywords expresson "true, false,active, inactive, activated, deactivated, suppressed, enabled, disabled, valid, invalid" shall be marked all upper letters as "TRUE", "FALSE", "ACTIVE", "INACTIVE", "ACTIVATED", "DEACTIVATED", "SUPPRESSED", "ENABLED", "DISABLED", "VALID" and "INVALID" respectively.
+- The signal name shall use italic with each first letter in a word in uppercase (unless the word is an acronym), for example: "*ACC Active State*" ,"*Steering Angle*"
+
+## Rewrite Examples
+
+### Example 1 (Clear and direct) 
+Weak:
+
+"The signal *ACC Active State* shall always be set to DEACTIVATED if each of the following conditions are fulfilled:
+
+- Camera Status is invalid， OR
+- Radar Status is invalid. "
+
+Better:
+
+"The signal *ACC Active State* shall be set to DEACTIVATED if the following conditions are fulfilled:
+
+- [Req-SWE-001]*Camera Status* is invalid， **OR**
+- [Req-SWE-002]*Radar Status* is invalid. "
+
+
+### Example 2 （Unambiguous）
+
+Weak:
+
+"The controller shall quickly detect low voltage."
+
+Better:
+
+"[Req-SWE-003]When the supply voltage is below THRESHOLD for DEBUNCE TIME, the controller shall detect an undervoltage condition and report the corresponding diagnostic status."
+
+### Example 3 (Atomic) 
+
+Weak:
+
+"[Req-SWE-004]The current steering torque shall be set to zero if steering torque sensor losts connection or estimated rackposition is invalid."
+
+Better:
+
+"The *current steering torque* shall be set to zero if the following conditions are fulfilled:
+- [Req-SWE-004]Steering torque sensor lost communication fault occurred, **OR**
+- [Req-SWE-005]*estimated rackposition* is INVALID."
+
+
+### Example 4 (Positively defined)
+
+Weak:
+
+"The signal ACC Active State shall not be set to DEACTIVATED if the following conditions are fulfilled:
+
+Camera Status is valid，OR
+Radar Status is valid .
+
+Better:
+
+"The signal *ACC Active State* shall be set to DEACTIVATED if the following conditions are fulfilled:
+
+- [Req-SWE-001]*Camera Status* is invalid， **OR**
+- [Req-SWE-002]*Radar Status* is invalid. "
+
+
+## Handling Missing Data
+
+Use "TBD" as a placeholder in variable table when a required engineering value is missing. Keep placeholders visible in the requirement and repeat them in open questions.