القائمة
Assess technical feasibility for a feature. Scans codebase, checks dependencies, researches libraries, and writes a structured report under .ai/tech-research/.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Run a single demo E2E test file, diagnose failures, dispatch fixes to agents, and re-run until pass.
Execute phased task plans by dispatching work to specialized sub-agents for backend, frontend, miniapp, Flutter, or demo phases.
Validate task plan executability and consistency with a 100-point score and P0/P1/P2 fix list.
Convert technical design documents into executable phased task plans with ordered work breakdown.
Evaluate technical design documents for implementability, completeness, and consistency with a quantitative 100-point score.
Initialize a full-stack project skeleton with Rust backend (Axum + SeaORM + Redis) and React frontend (TypeScript + TanStack + Tailwind).
| name | t-tech-research |
| description | Assess technical feasibility for a feature. Scans codebase, checks dependencies, researches libraries, and writes a structured report under .ai/tech-research/. |
| allowed-tools | ["AskUserQuestion","Read","Glob","Grep","Task","Write","Bash","WebSearch","mcp__context7__resolve-library-id","mcp__context7__query-docs"] |
运行时边界统一参考：${CLAUDE_PLUGIN_ROOT}/protocols/runtime-boundaries.md
需求来源边界统一参考：${CLAUDE_PLUGIN_ROOT}/protocols/requirement-source-contract.md
基于 Decision Brief、用户需求和现有代码库，评估技术可行性、依赖缺口、代码影响范围和关键风险，生成报告供后续 /t-prd 或纯技术方案 /t-design 参考。
会影响技术路线、依赖选择、范围边界、兼容性、成本/风险结论、PRD 建议或后续 /t-design 输入的问题，必须通过 AskUserQuestion 解决；不得只写成 P0/P1 风险、显式假设或"需要更多信息"后继续收敛。
输出文件：
.ai/tech-research/<file-name>.md（file-name 取自 $ARGUMENTS 第一个空格前的部分）如果未传 feature 名称，立即终止并提示：
请提供 feature 名称。例如：/t-tech-research user-management
输入：
.ai/decision/<file-name>.md（可选但推荐，来自 /t-decision）docs/prd/00-index.md、docs/user-stories/00-index.md、.ai/user-stories/**/*.md、.ai/design/**/*.md输出报告必须包含：
$ARGUMENTS 可包含两部分：<file-name> [补充描述]
rag-otel-metrics）.., /, \.ai/tech-research/<file-name>.md 已存在，先询问是否覆盖.ai/decision/<file-name>.md，必须承接其中 Verdict、Scope Direction、D0/D1 决策和 Handoff；不得用技术预研改写产品立项结论Needs Clarification、Park 或 Reject，除非用户明确要求技术探索，否则应停止并提示先回到 /t-decisionCargo.toml、package.json 和 lock 文件（如存在）如果当前对话中已有足够需求背景，不要重复提问。
仅在需求目标、约束、技术偏好或排除项不足以支撑可行性判断时，使用 AskUserQuestion 补问最少问题：
如果缺失或冲突会影响技术路线、依赖选择、兼容性、影响范围、风险等级、是否进入 PRD 或是否可直接进入 /t-design，必须等待用户回答；回答前不得写入报告或给出收敛结论。
只有非阻塞缺口才可在写报告前转为 §6.2 显式假设。报告中不得留下"待确认"/"需确认"/"待定"/"TBD"等未决项。
按需读取以下文件，跳过不存在的文件：
.ai/decision/<file-name>.mdbackend/Cargo.tomlfrontend/package.jsonCargo.lockpackage-lock.jsondocs/prd/00-index.mddocs/user-stories/00-index.md.ai/user-stories/**/*.md.ai/design/**/*.md扫描真实代码目录，重点关注：
backend/api/backend/core/backend/sdk/frontend/src/如果代码分析较复杂，可委托探索任务，要求返回相关实现位置、可复用点、影响模块和理由。
对比需求与现状，明确：
仅当本地分析表明需要新依赖或需要补充库级事实时执行。
对每个候选库调研：
如果不需要新依赖，在报告中写明"现有依赖栈可满足需求"并说明理由。
把本地分析、依赖调研和人类讨论收敛为一个最终技术路线。
收敛规则：
AskUserQuestion 提问；回答前不得把结论写成"需要更多信息"并继续交付输出文件级和架构级影响：
使用 template.md 的结构生成 .ai/tech-research/<file-name>.md。
如果某章节不适用，保留章节并标记"不适用"及原因，不要直接删除。
完成后说明：
/t-prd <file-name>；不涉及业务逻辑变动的纯技术方案可进入 /t-design <file-name>生成前自检：
AskUserQuestion 解决，非阻塞缺口是否已转为显式假设/t-design/t-design 和 /t-task 的职责/t-tech-research <file-name> 示例Reject / Park 且用户未要求继续探索：终止并提示先回到 /t-decisionAskUserQuestion 补齐，回答前不写报告；若不影响，只在报告中写入显式假设