🐶

Tsumiki 使ってみた

に公開

Tsumiki 使ってみた

2025/08/01 時点で公開されてるTsumikiを(お試し程度にkairoだけ)使ってみた
https://github.com/classmethod/tsumiki
公開からコマンド自体に手を結構入れてるみたいなので、今後の更新で参考にならない可能性もあります

インストールはREADME.mdを参考に

npx tsumiki install

ですね

作ってみる

claude codeを立ち上げた状態で
/kairo-requirements タスク管理アプリを作りたいです。参考ばBacklogです。Wikiはmarkdown形式にして、svn/gitの管理は不要です。アプリ名はtaskmanです

と依頼すると docs/spec フォルダにがーっとファイルが作られました

  • 受入基準
  • 要件定義書
  • ユーザストーリー

なので、気になる要件定義書を見てみると...

# taskman 要件定義書

## 概要

Backlogをベースとしたタスク管理システム。プロジェクト単位でのタスク管理、Wiki機能(Markdown形式)、コメント機能を持つWebアプリケーション。Git/SVN連携機能は除外し、タスク管理とドキュメント管理に特化する。

## 関連文書

- **ユーザストーリー**: [📖 taskman-user-stories.md](taskman-user-stories.md)
- **受け入れ基準**: [✅ taskman-acceptance-criteria.md](taskman-acceptance-criteria.md)

## 機能要件(EARS記法)

### 通常要件

- REQ-001: システムはユーザーがプロジェクトを作成・編集・削除できなければならない 🟡
- REQ-002: システムはプロジェクト内でタスク(課題)を作成・更新・削除できなければならない 🟡  
- REQ-003: システムはタスクに対してコメントを追加できなければならない 🟡
- REQ-004: システムはMarkdown形式でWikiページを作成・編集できなければならない 🟡
- REQ-005: システムはユーザー認証機能を提供しなければならない 🟡
- REQ-006: システはタスクの優先度を設定できなければならない 🟡
- REQ-007: システムはタスクのステータス(未対応・処理中・処理済み・完了)を管理できなければならない 🟡

EARS記法で書かれた要件が100行近く出てきました。
※作った後に、〜〜〜を追加してとか依頼すると追加してくれる

気になるのは文末にある🟡ですね。他にも🔴とかあるみたいなので、一応何なのかコマンドを確認してみると

**【信頼性レベル指示】**:
各項目について、元の資料(EARS要件定義書・設計文書含む)との照合状況を以下の信号でコメントしてください:

- 🟢 **青信号**: EARS要件定義書・設計文書を参考にしてほぼ推測していない場合
- 🟡 **黄信号**: EARS要件定義書・設計文書から妥当な推測の場合
- 🔴 **赤信号**: EARS要件定義書・設計文書にない推測の場合

元資料に書いてるかどうかが基準(今回の場合は最初のbacklogもどきに情報があるかどうか)ですね
ということは🟡を確認することと、🔴は正しいかどうかの判断が必要ってことで、これで生成結果に対してハルシネーション対策が施されてるってことですね
ちなみに、この信頼性レベル指示はほぼ全部のコマンドにあるので、レビューするときにはこの信号を頼りにすれば良いみたいです。それっぽく書かれた未定義仕様とか探すのが大変なので助かるって感じです

kairo-design

claude code で /kairo-design ってやると docs/spec/taskman に色々ファイルが出てきます。ここでも信頼性レベル指示が出てくるので同じノリで確認できますね
内容的に特に特筆すべき事はなさそうなので次に進みましょう

kairo-tasks

claude code で /kairo-tasks をするとdocs/tasks/にファイルが出てきます

## プロジェクト概要

- **要件名**: taskman
- **総期間**: 2025年1月1日 〜 2025年4月30日 (4ヶ月)
- **総工数**: 704時間
- **総タスク数**: 49タスク

## フェーズ構成

| フェーズ | 期間 | 主要成果物 | タスク数 | 工数 | ファイル |
|---------|------|-----------|---------|------|---------|
| Phase 1: 基盤構築 | 1ヶ月 | 開発環境・DB設定・認証基盤 | 8タスク | 64h | [phase1-foundation.md](taskman-phase1-foundation.md) |
| Phase 2: 基本TODO機能 | 1ヶ月 | プロジェクト・タスク・コメント機能 | 12タスク | 192h | [phase2-basic-todo.md](taskman-phase2-basic-todo.md) |
| Phase 3: カスタム機能 | 1ヶ月 | Wiki・検索・ファイル添付機能 | 13タスク | 208h | [phase3-custom-features.md](taskman-phase3-custom-features.md) |
| Phase 4: 高度機能 | 2週間 | ダッシュボード・リアルタイム機能 | 8タスク | 120h | [phase4-advanced-features.md](taskman-phase4-advanced-features.md) |
| Phase 5: 最適化・リリース | 2週間 | パフォーマンス最適化・リリース準備 | 8タスク | 120h | [phase5-optimization-release.md](taskman-phase5-optimization-release.md) |

さすがbacklogもどき...なかなかの大作になりそうですね
Phaseは1ヶ月単位で区切られてるので安心ですね(なにが
アプリケーションの足回りの準備からスタートするので、まっさらなディレクトリでも実行出来るみたいです
(総工数704時間が仮に1/10になっても70時間か...ってちょっと思った

/kairo-tasks-verify はフォーマットチェック上念のために実行すると良いみたいですが余り変化なかったです

タスクを見る

MANUAL.mdをみてDIRECT/TDDの使い分けの部分は、各タスクにタスクタイプが書いてあるのでそれを基準にして

  • - **タスクタイプ**: DIRECT って書いてると、 direct-* 系のコマンド
  • - **タスクタイプ**: TDD って書いてると、 tdd-* 系のコマンド

ということですね

タスクを見るとDIRECTは準備系タスクでTDDする必要の無さそうなもの(環境準備とか)
TDDは機能的な実装があるもので分けられているみたい

続く

のか?

Discussion