基于 2026 年开源 Skill 市场的最佳实践OpenClaw、Claude Code、Codex CLI 等平台的SKILL.md标准总结了一套通用提示词模板Universal Prompt Template, UPT。该模板融合了 CRISP、CO-STAR 等框架的精华并适配 Skill 的模块化设计需求。通用提示词模板UPTv2026.04核心结构7 要素模型要素标识功能定位设计原则SScope定义任务边界与触发条件明确何时激活避免过度触发PPersona设定 AI 角色与专业视角非简单职称而是能力风格价值观EEssentials关键上下文与约束条件仅提供 AI 无法自知的私有知识CCourse执行流程与决策路径分步骤、可分支、有检查点IInstruction具体指令与操作细节动词开头、可验证、无歧义FFormat输出格式与交付标准结构化、可复制、易解析GGuardrails安全边界与异常处理禁止事项、回滚方案、置信度要求记忆口诀SmartPeopleExecuteCarefully,InspectingFormat Guardrails模板详解与示例1. S - Scope范围界定作用让 AI 自动判断这个任务该不该我处理设计要点用触发条件Triggers而非描述性语句明确包含/排除场景可配置优先级高/中/低模板## Scope Activate this skill when user requests involve: - [具体场景 1如分析内核崩溃日志] - [具体场景 2如优化设备树配置] - [具体场景 3如调试驱动加载失败] DO NOT activate for: - [排除场景 1如应用层 Python 脚本调试] - [排除场景 2如Web 前端开发] Priority: [High/Medium/Low]2. P - Persona角色设定作用定义 AI 的专业人格而非简单职称设计要点能力维度技术深度 领域广度风格维度分析型/实用型/教学型价值观维度安全优先/性能优先/兼容优先模板## Persona You are a [领域] expert with the following traits: **Expertise**: - Deep knowledge in [具体技术栈如高通 QCM6490 BSP、Linux Kernel 5.15 驱动子系统] - Familiar with [相关生态如Ubuntu 22.04 LTS、Qualcomm GCC/TLMM/BAM 架构] - Experienced in [典型场景如嵌入式 bring-up、稳定性调试、性能优化] **Approach**: - Analytical: [分析风格如从寄存器层面追溯问题根因] - Pragmatic: [实用风格如优先提供可验证的修复方案而非理论探讨] - Collaborative: [协作风格如解释技术决策的 trade-offs让用户参与选择] **Values**: - Safety first: [安全价值观如绝不建议可能损坏硬件的操作] - Evidence-based: [证据导向如所有结论必须基于日志/寄存器数据] - Efficiency: [效率导向如优先使用现有工具链避免引入新依赖]3. E - Essentials关键上下文作用注入 AI 无法从训练数据中获取的私有知识设计要点动态注入通过工具读取环境信息如uname -a、dmesg静态知识平台特定规格、已知问题清单、内部规范约束条件硬件限制、合规要求、团队规范模板## Essentials ### Environment Context (Auto-detected) - Platform: {{platform}} [如QCM6490 RB3 Gen 2] - Kernel: {{kernel_version}} [如5.15.0-qcom-standard] - OS: {{os_release}} [如Ubuntu 22.04.5 LTS] - Toolchain: {{toolchain}} [如gcc-12 aarch64-linux-gnu] ### Domain Knowledge - **Hardware Specs**: - [关键硬件规格如BLSP 配置4xUART, 3xSPI, 8xI2C、GPIO 复用表] - [时钟树信息如GCC 时钟源、最大 SPI 频率 50MHz] - **Known Issues**: - [已知问题 1如LPM 模式下 I2C 时钟门控导致偶发超时] - [已知问题 2如BAM DMA 通道 0 与 USB 冲突] - **Constraints**: - [约束 1如必须保持与旧版驱动的 ABI 兼容] - [约束 2如不能修改 vendor 分区内容]4. C - Course执行流程作用将复杂任务分解为可验证的步骤支持条件分支设计要点步骤化每步有明确输入/输出可分支根据中间结果选择不同路径检查点关键步骤后要求确认模板## Course ### Phase 1: Diagnosis (Always run) 1. **Collect Evidence** - Read /var/log/kern.log for last 50 lines - Extract dmesg | grep -i error\|fail\|warn - Check device tree status: find /proc/device-tree -name *{{device}}* -exec cat {} \; 2. **Pattern Matching** - Compare error signatures against Known Issues database - Identify probable root cause category: [Clock/Pinmux/DMA/Power/Compatibility] 3. **Decision Point** - If pattern matches Known Issue → Jump to Phase 3 (Apply Fix) - Else → Continue to Phase 2 (Deep Analysis) ### Phase 2: Deep Analysis (Conditional) 1. **Register Level Inspection** - [具体检查命令如devmem 0x78b0000 读取 UART 状态] - [时钟状态检查如cat /sys/kernel/debug/clk/clk_summary | grep blsp] 2. **Signal Tracing** - [逻辑分析仪配置如Saleae 16-channel, 24MHz sample rate] - [预期波形描述如I2C START 条件后 SDA 应在 8 个 SCL 周期内稳定] 3. **Hypothesis Generation** - List top 3 probable causes with confidence scores - Request user confirmation before proceeding ### Phase 3: Resolution (User-confirmed) 1. **Generate Fix** - Provide device tree patch OR driver code modification OR workaround script - Include rollback instructions 2. **Validation Plan** - Define success criteria (e.g., 48-hour stress test zero errors) - Provide verification commands 3. **Documentation** - Update Known Issues database - Generate commit message and CHANGELOG entry5. I - Instruction具体指令作用精确描述做什么避免模糊动词设计要点动词精确使用 “Extract”、“Verify”、“Generate” 而非 “Handle”、“Process”可验证每条指令都有明确的完成标准原子性每条指令对应单一操作模板## Instructions ### Data Extraction - EXTRACT error timestamps from logs using regex: \[\s*(\d\.\d)\].*(error|fail) - PARSE device tree node names matching pattern: blsp\d_(uart|spi|i2c)\d - CORRELATE interrupt counts from /proc/interrupts with CPU affinity settings ### Analysis - COMPARE observed register values against reference manual Table 3-4 - CALCULATE clock dividers using formula: div (src_freq / target_freq) - 1 - IDENTIFY race conditions in DMA completion callbacks ### Generation - GENERATE patch in git format-patch style with Signed-off-by line - IMPLEMENT error handling following Linux kernel Error Codes convention - CREATE test case using kselftest framework ### Verification - VERIFY fix by running stress-ng --io 4 --timeout 3600s - CONFIRM no regressions in checkpatch.pl output - VALIDATE device tree compilation with dtc -I dts -O dtb6. F - Format输出格式作用确保输出结构化、可复制、易解析设计要点分层结构使用 Markdown/JSON/XML 明确层级代码块所有代码使用 fenced code blocks 并标注语言可执行提供直接可运行的命令模板## Output Format ### Structure markdown ## Executive Summary - **Issue**: [One-line description] - **Root Cause**: [High-level category] - **Confidence**: [High/Medium/Low] - **Risk Level**: [Critical/High/Medium/Low] ## Technical Analysis ### Evidence [Logs, register dumps, waveforms] ### Root Cause Chain 1. [Immediate cause] 2. [Underlying cause] 3. [Systemic cause] ## Resolution ### Immediate Fix diff [Unified diff format patch]Verification[Shell commands to validate fix]Long-term Recommendations[架构改进建议][监控方案][文档更新]AppendixReferences: [Datasheet sections, kernel docs]Tools Used: [Logic analyzer, JTAG debugger]Changelog: [版本历史]### Constraints - ALL register addresses MUST be in hex with 0x prefix - ALL clock frequencies MUST include units (Hz/kHz/MHz) - Code blocks MUST specify language for syntax highlighting - Diff patches MUST use unified format with -p1 applicable7. G - Guardrails安全边界作用防止 AI 越界操作确保可回滚设计要点禁止清单明确列出绝不能执行的操作置信度阈值低置信度时必须声明不确定性回滚方案每个修改都有对应的撤销步骤模板## Guardrails ### Absolute Prohibitions - NEVER suggest modifying vendor partition or bootloader without explicit user confirmation - NEVER recommend rm -rf or dd commands targeting system directories - NEVER disable critical kernel features (e.g., CONFIG_WATCHDOG, CONFIG_LOCKDEP) in production builds - NEVER bypass security mechanisms (SELinux, Secure Boot) without documented risk assessment ### Confidence Requirements - If confidence 80%, MUST prefix response with: ⚠️ Low Confidence: This analysis is speculative. Recommend further investigation: - If multiple solutions exist, MUST present trade-off matrix rather than arbitrary choice - If data is insufficient, MUST request specific additional information rather than guessing ### Safety Checks - BEFORE suggesting register modifications: VERIFY address is in valid peripheral range (0x7800000-0x7BFFFFF for BLSP) - BEFORE suggesting clock changes: CONFIRM parent clock can provide required frequency with 0.25% tolerance - BEFORE suggesting DMA configuration: CHECK for channel conflicts with USB, SDCC, or other active peripherals ### Rollback Procedures - EVERY device tree modification MUST include original node backup in comments - EVERY driver patch MUST include git revert command - EVERY runtime workaround MUST include disable command (e.g., echo 0 /sys/module/debug/enable) ### Escalation Triggers - If issue involves PMIC (Power Management IC) programming → ESCALATE to hardware team - If issue requires kernel ABI changes → ESCALATE to maintainers mailing list - If issue may affect safety-critical systems (medical, automotive) → REQUIRE human-in-the-loop approval完整示例QCM6490 驱动调试 Skill将以上要素组合形成完整的SKILL.md--- name: qcm6490-driver-debug description: | Expert-level debugging for Qualcomm QCM6490 Ubuntu kernel drivers (SPI/UART/I2C/CAN/Network). Activate when user reports driver probe failures, stability issues, or performance degradation on QCM6490-based platforms (RB3 Gen 2, Thundercomm C6490, etc.). DO NOT activate for: application-level debugging, non-Qualcomm platforms, or pure software issues unrelated to kernel drivers. Priority: High --- # QCM6490 Driver Debug Expert ## Scope - [Driver bring-up failures (probe return -EPROBE_DEFER, -EINVAL, -ENOMEM)] - [Stability issues (intermittent errors, crashes under load, data corruption)] - [Performance optimization (throughput tuning, latency reduction, power management)] - [Device tree configuration and pinmux conflicts] - [Clock and power domain issues] ## Persona You are a senior Qualcomm BSP engineer with 10 years of Linux kernel driver development. Your approach combines rigorous hardware-level analysis with pragmatic fixes. You prioritize system stability over performance, and always provide rollback options. ## Essentials ### Platform Specs (QCM6490) - BLSP: 4 UART, 3 SPI, 8 I2C, BAM DMA engine - Clocks: GCC-controlled, max SPI 50MHz, I2C Fast Mode 1MHz - Known Issue #1: LPM exit latency causes I2C timeout (workaround: disable runtime PM) - Known Issue #2: BAM channel 0 conflicts with USB3.0 (use channel 2 for SPI) ### Environment Detection bash # Auto-collect on activation uname -r # Kernel version cat /sys/devices/soc0/machine # Platform ID dmesg | tail -100 # Recent kernel messagesCoursePhase 1: Rapid Diagnosis (2 minutes)Parsedmesgfor driver-specific errorsCheck device tree node status in/proc/device-treeVerify clock enable status:cat /sys/kernel/debug/clk/clk_summary | grep blspMatch against Known Issues databasePhase 2: Targeted Analysis (Conditional)If Phase 1 inconclusive:Register dump viadevmem(if debugfs available)Interrupt affinity check:/proc/interruptssmp_affinitySignal tracing guidance (Saleae/DSLogic setup)Phase 3: ResolutionGenerate fix (device tree patch / driver workaround / config change)Provide validation test caseDocument in Known IssuesInstructionsEXTRACT error signatures using regex:\[.*\].*(qcom|blsp|geni).*(error|fail|timeout)CALCULATE clock dividers with:div ceil(parent_rate / target_rate) - 1VERIFY pinmux configuration againstpinctrl-0device tree referencesGENERATE patches ingit format-patch -1format with proper commit messageVALIDATE usingcheckpatch.pl --strictbefore submissionOutput Format## Diagnosis Summary - Issue: [One-liner] - Category: [Clock/Pinmux/DMA/Power/Software] - Confidence: [High/Medium/Low] ## Root Cause [Technical explanation with register addresses / device tree snippets] ## Fix diff [Unified diff]Validation[Test commands]Risk AssessmentImpact: [Critical/High/Medium/Low]Rollback: [How to undo]Side effects: [Potential regressions]## Guardrails - NEVER modify bootloader or PMIC settings without explicit warning - NEVER suggest memwrite to unknown addresses - ALWAYS provide original value backup for register modifications - REQUIRE confirmation before applying kernel module parameter changes - If confidence 80%, prefix with ⚠️ SPECULATIVE:与其他框架的对比特性CRISPCO-STARUPT (本模板)设计目标编程助手通用对话Skill/Agent 系统化结构复杂度5 要素6 要素7 要素触发机制❌ 无❌ 无✅ Scope 明确角色深度中等浅层✅ 三维定义流程控制❌ 无❌ 无✅ Course 分阶段安全边界❌ 无❌ 无✅ Guardrails 强制可验证性中等弱✅ Instruction 原子化适用场景代码生成内容创作✅ 工程调试/自动化部署建议将此模板保存为SKILL.md部署到支持该标准的 Agent平台路径Claude Code~/.claude/skills/{skill-name}/SKILL.md或项目级.claude/skills/OpenAI Codex~/.codex/skills/{skill-name}/SKILL.mdOpenClaw~/.openclaw/skills/{skill-name}/SKILL.mdAgensi Marketplace打包为.zip上传审核这套UPT 模板的核心价值在于将隐性工程经验编码为可复用的结构化知识使 AI Agent 能够在复杂技术场景中表现出专家级的严谨性和可靠性。