logvalet-decisions

name

logvalet:decisions

description

Extract and summarize decision logs from a Backlog issue's timeline: who decided what, when, and why — by analyzing comments and status change history. TRIGGER when: user says "意思決定", "decision log", "決定履歴", "なぜこうなったか", "経緯を教えて", "決定の背景", "decision history", "どうして変更された", "意思決定ログ", "何が決まった", "承認経緯", "設計の経緯", "why was this decided", "変更の理由", "この課題の歴史", "議論の経緯", "ステータス変更の理由", "誰が決めたか", "合意形成の過程", "過去の決定を振り返りたい", "この仕様になった理由". DO NOT TRIGGER when: user wants current issue status (use context) or wants to analyze project-wide activity patterns (use intelligence). Complements: Use after /logvalet:context to dive deeper into the decision history.

logvalet-decisions

lv issue timeline を材料に、LLM がコメント・更新履歴から意思決定を抽出・要約する。

For full logvalet CLI documentation, see the logvalet skill.

---

When to use this skill

Use logvalet-decisions when you need to:

• understand why a certain approach was chosen
• trace the history of key decisions in an issue or project
• identify who was involved in key decisions and when
• summarize decision points for stakeholders or retrospectives
• explain the rationale behind current issue state

---

Workflow

Step 1: Identify issue key or project

If the user provides a Backlog issue key (e.g., PROJ-123) or project key, extract and use it directly.

If no key is provided, ask for it.

Step 2: Fetch timeline data

For a single issue:

lv issue timeline ISSUE_KEY -f json

For a richer view, optionally include more activity:

lv issue timeline ISSUE_KEY --max-comments 0 --max-activity-pages 10 -f json

To narrow to a specific period:

lv issue timeline ISSUE_KEY --since YYYY-MM-DD --until YYYY-MM-DD -f json

The timeline returns a chronological sequence of:

• comments (author, timestamp, content)
• update events (field changed, old value → new value, actor, timestamp)

Step 3: Identify decision signals

Scan the timeline for content that indicates decisions were made:

Comment-based signals:

• Explicit decision phrases: "決定しました", "〜にします", "承認", "合意", "decided to", "agreed to", "resolved to"
• Rationale phrases: "なぜなら", "理由は", "because", "the reason is"
• Alternatives discussion: "〜か〜か", "option A vs B", "検討した結果"
• Status transitions with explanation

Update-based signals:

• Priority changes (especially escalation)
• Assignee changes with significant workload implication
• Category or milestone changes
• Due date extensions with context

Step 4: Extract and structure decisions

For each identified decision, extract:

• When: timestamp of the decision event
• Who: actor(s) involved (comment author or update actor)
• What: what was decided (concise summary)
• Why: rationale if mentioned
• Context: linked alternative options or prior discussion

Step 5: Present decision log

Present the decision log in chronological order:

## 意思決定ログ — ISSUE_KEY

> タイムライン期間: FROM〜TO / 意思決定数: N件

---

### 1. [YYYY-MM-DD] <決定内容の1行サマリー>

- **判断者:** UserName
- **決定:** <具体的な決定内容>
- **理由:** <根拠・背景（記載がある場合）>
- **証拠:** <元のコメント or 更新イベント（要約）>

---

### 2. [YYYY-MM-DD] <決定内容の1行サマリー>

...

---

**サマリー:**
- 主要な意思決定: N件
- 主な判断者: UserA, UserB
- 重要な転換点: <あれば記載>

---

Notes

• issue timeline が材料の唯一の権威ソース — 追加の issue get / comment list 呼び出しは不要
• 明確な根拠が記載されていない決定は「根拠: 記録なし」と明示する
• コメントが多い場合は最初に --since で期間を絞ることを検討する
• --no-include-updates フラグでコメントのみに絞ることもできる

---

Anti-patterns

• Do not invent rationale that is not in the timeline — if rationale is missing, say so
• Do not skip the issue identification step — always confirm the key
• Do not confuse routine status updates with actual decisions — focus on changes that involved judgment or discussion
• Do not summarize all comments; focus only on those containing decision signals