plans-management

Plans Management Skill

A skill for task management and marker operation in Plans.md.

---

Trigger phrase

This skill is triggered by the following phrases:

• "Add a task"
• "Update Plans.md"
• "Mark as complete"
• "Change the task status"
• "add a task"
• "update plans"
• "mark as complete"

---

Overview

This skill assists with editing and updating Plans.md. It adds tasks, changes statuses, and archives them in a consistent format.

---

Structure of Plans.md

# Plans.md - タスク管理

> **最終更新**: YYYY-MM-DD HH:MM
> **更新者**: Claude Code / PM（Cursor/PM Claude）

---

## 🔴 進行中のタスク

- [ ] タスク名 `cc:WIP`
  - 詳細説明
  - 関連ファイル: `path/to/file.ts`

---

## 🟡 未着手のタスク

- [ ] タスク名 `cc:TODO`
- [ ] タスク名 `pm:依頼中`（互換: cursor:依頼中）

---

## 🟢 完了タスク

- [x] タスク名 `pm:確認済` (YYYY-MM-DD)

---

## 📦 アーカイブ

<!-- 古い完了タスクはここに移動 -->

---

Marker operation rules

Status change rules

Change	Actor	Condition
pm:依頼中(Compatibility: cursor:requesting) → cc:WIP	Claude Code	When starting a task
cc:TODO → cc:WIP	Claude Code	When starting a task
cc:WIP → cc:完了	Claude Code	When work is complete
cc:完了 → pm:確認済(Compatibility: cursor:confirmed)	PM	When review is complete
* → blocked	Either	When a block occurs

Marker format

# 正しい例
- [ ] タスク名 `cc:WIP`
- [x] タスク名 `cc:完了` (2024-01-15)

# 間違った例
- [ ] タスク名 cc:WIP      # バッククォートなし
- [ ] タスク名 `cc: WIP`   # スペースあり

---

Task operations

Adding a task

## 追加前
## 🟡 未着手のタスク

- [ ] 既存タスク `cc:TODO`

## 追加後
## 🟡 未着手のタスク

- [ ] 既存タスク `cc:TODO`
- [ ] 新規タスク `cc:TODO`
  - 詳細説明（あれば）

Changing a task's status

## 変更前
- [ ] タスク名 `cc:TODO`

## 変更後
- [ ] タスク名 `cc:WIP`

Completing a task

## 変更前
- [ ] タスク名 `cc:WIP`

## 変更後
- [x] タスク名 `cc:完了` (2024-01-15)

Task archiving

Tasks that have been complete for 7 days or more are moved to the archive section:

## 📦 アーカイブ

### 2024年1月
- [x] タスク1 `pm:確認済` (2024-01-10)
- [x] タスク2 `pm:確認済` (2024-01-08)

---

Auto-formatting rules

When updating Plans.md, adhere to the following:

1. Always include the last update: Update the date and time in the header
2. Maintain section order: In progress → Not started → Complete → Archive
3. Leave empty sections: Do not delete section headers even if there are no tasks
4. Unify indentation: 2 spaces or 4 spaces

---

Useful patterns

Subtasks

- [ ] 親タスク `cc:WIP`
  - [x] サブタスク1
  - [ ] サブタスク2
  - [ ] サブタスク3

Recording the block reason

- [ ] タスク名 `blocked`
  - ブロック理由: API キーの発行待ち
  - 担当: @username
  - 期限: 2024-01-20

Expressing priority

- [ ] 🔥 緊急タスク `pm:依頼中`（互換: cursor:依頼中）
- [ ] ⭐ 重要タスク `cc:TODO`
- [ ] タスク `cc:TODO`

---

Related commands

• /sync-status - Output the current status summary
• /handoff-to-cursor - Automatically update Plans.md when reporting completion

---

Notes

• Plans.md is the single source: Do not scatter task information across other files
• Update frequently: Always update at the start and end of work
• Synchronization with Cursor: If a long time has passed, /sync-status check with

---

Extended notation (optional)

For large-scale projects, the following notation can be used withOptions:

Task ID / dependencies / parallelizable

- [ ] T001: 認証機能 `cc:TODO`
- [ ] T002: ユーザーAPI `cc:TODO` depends:T001
- [ ] T003: 商品API `cc:TODO` [P]
- [ ] T004: 注文API `cc:TODO` depends:T001,T003

Notation	Meaning	Purpose
T001:	Task ID	Used for reference/dependency specification
depends:ID	Dependent task	depends:T001,T002(comma-separated)
[P]	Parallelizable	/work Execute simultaneously with other tasks at runtime

Example of dependency analysis

T001 (認証) ─────────────┐
                         ↓
T003 (商品API) [P] ─────> T004 (注文API)
                         ↑
T002 (ユーザーAPI) ─────┘

Backward compatibility: Works fine in the conventional format even without ID/depends/[P].