mirror of https://github.com/affaan-m/everything-claude-code.git synced 2026-02-16 19:33:11 +08:00

Files

Affaan Mustafa bc0520c6c1 fix: broken cross-references, version sync, and enhanced command validator

- Fix /build-and-fix → /build-fix in tdd.md, plan.md (+ cursor, zh-CN)
- Fix non-existent explorer agent → planner in orchestrate.md (+ cursor, zh-CN, zh-TW)
- Fix /python-test → /tdd in python-review.md (+ cursor, zh-CN)
- Sync package.json version from 1.0.0 to 1.4.1 to match plugin.json
- Enhance validate-commands.js with cross-reference checking:
  command refs, agent path refs, skill dir refs, workflow diagrams
- Strip fenced code blocks before scanning to avoid false positives
- Skip hypothetical "Creates:" lines in evolve.md examples
- Add 46 new tests (suggest-compact, session-manager, utils, hooks)

2026-02-12 16:19:04 -08:00

3.4 KiB

Raw Blame History

description

description
重新阐述需求、评估风险并创建分步实施计划。在接触任何代码之前，等待用户确认。

计划命令

此命令调用 planner 代理，在编写任何代码之前创建一个全面的实施计划。

此命令的作用

重新阐述需求 - 明确需要构建什么
识别风险 - 揭示潜在问题和阻碍
创建分步计划 - 将实施分解为多个阶段
等待确认 - 必须获得用户批准才能继续

何时使用

在以下情况下使用 /plan：

开始新功能时
进行重大架构变更时
处理复杂重构时
多个文件/组件将受到影响时
需求不明确或存在歧义时

工作原理

planner 代理将：

分析请求 并用清晰的术语重新阐述需求
分解为多个阶段，每个阶段包含具体、可操作的步骤
识别组件之间的依赖关系
评估风险和潜在阻碍
估算复杂度（高/中/低）
展示计划并等待您明确的确认

使用示例

User: /plan I need to add real-time notifications when markets resolve

Agent (planner):
# Implementation Plan: Real-Time Market Resolution Notifications

## Requirements Restatement
- Send notifications to users when markets they're watching resolve
- Support multiple notification channels (in-app, email, webhook)
- Ensure notifications are delivered reliably
- Include market outcome and user's position result

## Implementation Phases

### Phase 1: Database Schema
- Add notifications table with columns: id, user_id, market_id, type, status, created_at
- Add user_notification_preferences table for channel preferences
- Create indexes on user_id and market_id for performance

### Phase 2: Notification Service
- Create notification service in lib/notifications.ts
- Implement notification queue using BullMQ/Redis
- Add retry logic for failed deliveries
- Create notification templates

### Phase 3: Integration Points
- Hook into market resolution logic (when status changes to "resolved")
- Query all users with positions in market
- Enqueue notifications for each user

### Phase 4: Frontend Components
- Create NotificationBell component in header
- Add NotificationList modal
- Implement real-time updates via Supabase subscriptions
- Add notification preferences page

## Dependencies
- Redis (for queue)
- Email service (SendGrid/Resend)
- Supabase real-time subscriptions

## Risks
- HIGH: Email deliverability (SPF/DKIM required)
- MEDIUM: Performance with 1000+ users per market
- MEDIUM: Notification spam if markets resolve frequently
- LOW: Real-time subscription overhead

## Estimated Complexity: MEDIUM
- Backend: 4-6 hours
- Frontend: 3-4 hours
- Testing: 2-3 hours
- Total: 9-13 hours

**WAITING FOR CONFIRMATION**: Proceed with this plan? (yes/no/modify)

重要说明

关键：planner 代理在您明确用“是”、“继续”或类似的肯定性答复确认计划之前，不会编写任何代码。

如果您希望修改，请回复：

"修改：[您的修改内容]"
"不同方法：[替代方案]"
"跳过阶段 2，先执行阶段 3"

与其他命令的集成

计划之后：

使用 /tdd 以测试驱动开发的方式实施
如果出现构建错误，使用 /build-fix
使用 /code-review 审查已完成的实施

3.4 KiB Raw Blame History Unescape Escape