메뉴
面向 React + TypeScript 项目的代码坏味道审查 Skill。当用户提到 code review、clean code、技术债、可维护性、重构建议、组件太复杂、组件拆分过细、Hook 混乱、类型设计问题、PR 审查，或 @rabjs/react 领域模式与状态传递问题时，必须优先使用本 Skill。发现可执行问题时，必须使用 `gh` CLI 创建 GitHub issue。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
先查验代码再创建 GitHub Issue。只要用户提出“先确认是不是问题再提 issue”“根据代码排查并建单”“把用户反馈转成 issue”这类请求，就必须启用本技能：先验证问题是否成立，证据不足时主动追问用户补充，再用 gh CLI 按模板创建 issue。
用于按优先级串行修复 GitHub issue 的技能。只要用户提到“修 issue / 批量修 bug / 从 P0 开始处理 / 逐个修复问题 / 自动修复 issue 队列”等，都应启用。必须先复用 `gh.issue` 技能获取 issue，上游按 P0->P1->P2->P3->P4 排序，每次只处理一个 issue，并且每个 issue 都用子 Agent 修复；默认自动连续处理，只有遇到功能语义或产品策略需要产品经理确认时才暂停并向用户确认。每个成功修复的 issue 都必须由子 Agent 完成 commit（commit 信息关联 issue）并自动评论“已修复”后关闭。
Practical Anki v11 schema and import/export compatibility guide for Echoe. Use this skill whenever the user mentions Anki, .apkg/.anki2, notes/cards/revlog tables, notetype/deck JSON blobs, or fields like flds/sfld/csum/guid/usn/due. Even if the request sounds generic (for example "flashcard import" or "Anki sync issue"), consult this skill first before implementing or reviewing code.
审查需求文档（PRD/需求说明/业务规则）是否足够清晰、无歧义并可用于生成技术方案。Whenever user asks "帮我看需求是否清楚"、"这个需求能不能直接出技术方案"、"找出模糊定义/规则歧义/功能不清晰"，都应主动使用本技能，即使用户只提供需求片段或会议纪要。
Generate a Product Requirements Document (PRD) for a new feature. Use when planning a feature, starting a new project, or when asked to create a PRD. Triggers on: create a prd, write prd for, plan this feature, requirements for, spec out.
读取 Echoe 的 ADR 知识库（`arch.adr/references`）作为架构 Source of Truth，用于技术方案设计、PRD 对齐、架构评审与 Guardrails 检查。只要用户提到“按 ADR 出方案/按 ADR 对齐 PRD/查架构约束/避免架构漂移”，都应立即启用。`。
| name | code-review |
| description | 面向 React + TypeScript 项目的代码坏味道审查 Skill。当用户提到 code review、clean code、技术债、可维护性、重构建议、组件太复杂、组件拆分过细、Hook 混乱、类型设计问题、PR 审查，或 @rabjs/react 领域模式与状态传递问题时，必须优先使用本 Skill。发现可执行问题时，必须使用 `gh` CLI 创建 GitHub issue。 |
本 Skill 专门用于"已实现代码"的坏味道审查，聚焦 React + TypeScript 场景。目标不是挑语法细节，而是发现会持续放大维护成本、引发缺陷、降低团队协作效率的问题。
当用户出现以下意图时，直接触发：
Code Review / PR Reviewclean code、坏味道、技术债、可维护性useService 获取领域状态any 绕过useEffect 应只处理副作用，依赖明确、清理完整、避免竞态先定位高风险问题：
any、断言滥用）useService 直连）view 装饰器缺失导致响应性失效useService 获取的状态被改为 props 透传useEffect 职责过多（请求、转换、埋点、状态回写混杂）useEffect 依赖项缺失/过量，出现 stale closure 或重复触发any、as unknown as、非空断言 ! 过度使用if/else 或三元表达式可读性差key 不稳定导致列表状态错乱| 级别 | 描述 |
|---|---|
P1 | 严重问题：会引发运行时错误或数据不一致 |
P2 | 中等问题：影响可维护性，增加回归风险 |
P3 | 轻微问题：代码风格、可读性改进 |
P4 | 观察项：低风险优化建议 |
仅返回：当前代码未发现阻塞问题
# React + TypeScript 代码坏味道审查
## Findings
### [P1] useEffect 职责混杂且依赖不完整
- **位置**: `src/features/order/OrderList.tsx` / `useEffect(loadOrders)`
- **坏味道**: 副作用与状态派生耦合，依赖缺失导致 closure 过期
- **风险**: 数据刷新不一致，线上行为难复现
- **证据**: effect 内同时做请求、过滤、埋点，并遗漏 `filters` 依赖
- **建议**:
1. 请求逻辑抽到 `useOrdersQuery` 自定义 Hook
2. 过滤逻辑改为 `useMemo` 派生值
3. effect 仅保留"触发请求"职责并补齐依赖
### [P2] Props 通过布尔开关表达多态
- **位置**: `src/components/PaymentPanel.tsx` / `PaymentPanelProps`
- **坏味道**: `isEdit`, `isReadonly`, `isPreview` 等并存，存在非法组合
- **风险**: 新需求叠加后分支爆炸，回归概率高
- **建议**: 用判别联合类型替代布尔组合
## Open Questions
- 当前是否允许将请求逻辑从组件迁移到 hooks 层？
## Refactor Plan
1. 先修 P1 且低改动项（依赖补齐、清理副作用）
2. 再处理类型建模（判别联合、API 响应类型）
3. 最后处理结构优化（组件拆分、共享逻辑抽离）
## Overall Assessment
- 主要问题集中在副作用边界和类型建模，属于可渐进治理的技术债
当存在至少一个可执行的 P1/P2 finding 时，必须创建 GitHub issue。
gh --version
gh auth status
gh repo view --json nameWithOwner,viewerPermission
[code-review][<P1|P2|P3|P4>][<category>] <short summary>
category 示例：component、state、hook、type、performance
## Background
Why this review item matters in business/technical terms.
## Current behavior
What the code currently does.
## Problem
Why this is incorrect/risky.
## Scope and impact
Who/what is affected.
## Reproduction or evidence
- File paths
- Key logic snippets/conditions
## Expected behavior
What correct behavior should be.
## Suggested fix
Concrete implementation direction.
## Acceptance criteria
- [ ] Criterion 1
- [ ] Criterion 2
优先添加：
code-reviewtech-debtP1 / P2 / P3 / P4（必须与 finding severity 一致）- Repo: `owner/repo`
- Findings reviewed: P1: 1, P2: 2, P3: 0, P4: 0
- Issues created:
- `#123` [code-review][P1][hook] useEffect 依赖缺失 - https://github.com/owner/repo/issues/123
- Next step: 一个明确可执行的实现建议
[P1][Hook Side Effect] `useEffect` 同时处理请求和派生状态，且依赖不完整。
- Impact: 可能导致请求数据与 UI 过滤条件不同步
- Suggestion: 将请求迁移到自定义 Hook，派生过滤使用 `useMemo`
- Why: 这能让副作用边界更清晰，减少闭包陷阱并提升可测试性
// ❌ Bad
const [fullName, setFullName] = useState("");
useEffect(() => {
setFullName(`${user.firstName} ${user.lastName}`);
}, [user]);
// ✅ Good
const fullName = `${user.firstName} ${user.lastName}`;
// 或使用 useMemo 如果计算成本高
// ❌ Bad
const data = resp as any;
return data.list.map(item => item.id);
// ✅ Good
interface ApiResponse {
list: Array<{ id: string }>;
}
const data = resp as ApiResponse;
return data.list.map(item => item.id);
// ❌ Bad
<Dialog isCreate={false} isEdit={true} isReadonly={false} />
// ✅ Good
<Dialog mode="create" | "edit" | "readonly" />
// ❌ Bad - 维护路径过长
<Section>
<SectionBody>
<FieldRow>
<FieldLabel>姓名</FieldLabel>
<FieldValue>{user.name}</FieldValue>
</FieldRow>
</SectionBody>
</Section>
// ✅ Good - 语义化组件
<Field label="姓名" value={user.name} />