Track and update action item status from natural language updates like 'Seanのメールには返信しておいた' or 'Lu対応予定'. Integrates with daily-comms-ops workflow. Use when managing action items across communication channels.
task-runner
フォルダ型のタスクチケット(1ファイル1タスク、todo/doing/blocked/done フォルダ)を定期的に1件ずつ拾って実行し、結果をチケットに書き戻すスキル。毎回、状況を一目で把握できる看板ボード形式のダッシュボード(tasks/dashboard.html)も更新する。
Coworkのスケジュール実行(1時間ごと等)から呼ばれる想定。
「タスクを1件処理して」「tasksフォルダをチェックして」「タスクランナーを実行」「task-runner」「今日のタスクを進めて」「タスク管理の初期設定」「タスクの状況を見せて」「タスクのダッシュボード」「看板ボード」などと言われたら、明示的にスキル名が出ていなくても必ずこのスキルを使うこと。
含まれるファイル(12)
- SKILL.md14.8 KB
- assets/config.md195 B
- assets/samples/20260101_1_売上CSVの集計.md464 B
- assets/samples/20260101_2_会議アジェンダ作成.md489 B
- assets/samples/20260101_3_取引先へ報告メール送信.md492 B
- assets/samples/sample_data/meeting_notes.md363 B
- assets/samples/sample_data/sales.csv266 B
- assets/task_template.md655 B
- README.md3.9 KB
- scripts/build_dashboard.py31.8 KB
- scripts/tests/__init__.py0 B
- scripts/tests/test_build_dashboard.py5.2 KB
SKILL.md(原文)
インストールする前に、エージェントに与えられる指示の中身を確認できます。
Task Runner
作業フォルダ内の tasks/ を「チケット置き場」として扱い、1回の起動で 最大1件 のタスクを処理する。
定期実行されるため、毎回同じ手順で動き、途中で止まっても次回に安全に再開できることを最優先にする。
フォルダ構成
tasks/
_config.md # 動作モードなどの設定
_template.md # 新規タスクのひな形
log.md # 実行ログ(1起動1行)
dashboard.html # 看板ボード(毎回自動で再生成。手で編集しない)
todo/ # 未着手
doing/ # 実行中(ロック代わり)
blocked/ # 要確認・要承認・失敗
done/YYYY-MM/ # 完了(月別)
output/ # タスクの成果物の既定の置き場
ステータスはフォルダだけで表す。 ファイル内に status 欄は作らない(ずれると正がどちらか分からなくなるため)。
手順
0. 準備
date "+%Y-%m-%d %H:%M"で現在日時を取得する(推測しない)。tasks/が存在しなければ「初期セットアップ」(下記)を行い、その回はそこで終了する。tasks/_config.mdを読み、modeを確認する(dry-run/live。未記載ならdry-runとみなす)。
1. 実行中タスクの確認(二重起動防止)
doing/ にファイルがある場合:
- ファイル内の
開始:が 60分以内 → 前回の実行がまだ動いている可能性があるので、何もせずログにskip: 実行中ありと書いて終了。 - 60分より前 → 前回が途中で止まったとみなす。
## 実行ログに「中断を検知」と追記し、blocked/へ移動する(自動で再実行はしない。途中まで行った操作を二重に実行する危険があるため)。そのうえで手順2へ進む。
2. タスクの選択
todo/のファイルを ファイル名の昇順 で並べる。- ファイル名先頭の
YYYYMMDDが今日以前のものだけを対象にする(未来日付は触らない)。日付がないファイル名は対象に含める。 _で始まるファイルは無視する。- 対象がなければログに
idle: 対象タスクなしと書いて終了。何も起きない回は短く静かに終わること。
3. 着手
- 先頭の1件を
doing/に移動する。 - ファイルの
開始:に現在日時を書く。
4. 計画カードと実行
まず 目的・入力・手順メモ・完了条件 を読み、作業に入る前に ## 計画カード をタスクファイルに書く(書式は下の「計画カード」)。すでにある場合は、内容が古くなっていなければそのまま使う。
計画の確認が必要なタスクは、ここで止める。 次のどちらかに当てはまり、かつタスクに 計画承認: の行がなければ、作業はせずに手順5で blocked/ へ回す。## 結果 の1行目は必ず 計画の確認待ち: 理由 とする(ダッシュボードがこの書き出しで判定する)。
- タスクに
計画確認: 要と書かれている 計画確認:の指定がなく、外部操作: 許可になっている(外部に触れるタスクは既定で確認する)
計画確認: 不要 と書かれていれば、外部操作があっても止めない。
確認が不要、または承認済みなら作業する。
- 計画カードの
進め方に沿って作業する。途中で計画と違うやり方が必要になったら、勝手に変えずに止めてblocked/に回す。 - 成果物は
出力先に指定があればそこへ、なければtasks/output/に置く。 - 外部に影響する操作(メール・チャット送信、ファイル削除・上書き、外部システムへの書き込み、購入・予約など)は、タスクの
外部操作:が許可のときだけ行う。それ以外は下書きや実行内容のまとめまで作って止め、手順5でblocked/(理由: 要承認)に回す。 mode: dry-runのときは、実際の作業はせず計画カードを書くところで止める。## 結果には「dry-run: 計画カードを作成」と1行だけ書く。成果物の作成・外部操作は一切しない。- 情報が足りず判断できない場合は、推測で進めず
blocked/(理由: 情報不足、何が必要か)にする。
5. 完了判定と更新
完了条件 を実際に確認してから判定する(ファイルが本当にあるか、中身が条件を満たすか等を自分で確かめる)。
- 満たした →
## 結果に要約と成果物のパスを書き、完了:に日時を入れ、done/YYYY-MM/へ移動(フォルダがなければ作る)。 - dry-run →
todo/に戻す(本番モードで再実行できるように)。計画は## 計画カードに残っている。 - 計画の確認待ち →
## 結果の1行目を計画の確認待ち: 理由とし、blocked/へ移動。 - 満たせない・要承認・情報不足・エラー →
## 結果に理由と「人が何をすれば再開できるか」を書き、blocked/へ移動。
## 結果 は 毎回まるごと書き直す(前回の内容の下に足さない)。1行目が常に今の状態を表すようにするため(ダッシュボードは1行目で「計画の確認待ち」などを判定する)。経緯は ## 実行ログ に残る。
どの場合も ## 実行ログ に - YYYY-MM-DD HH:MM 状態 / 一言 を1行追記する。
6. ログ
tasks/log.md に1行追記して終了:
- 2026-09-22 10:00 | done | 20260922_1_売上集計.md | output/sales_summary.md を作成
状態は done / blocked / dry-run / idle / skip のいずれか。
7. ダッシュボード更新
ログを書いたあと、どの状態で終わった回でも(idle / skip を含む)ダッシュボードを再生成する:
python3 <このスキルのフォルダ>/scripts/build_dashboard.py tasks
tasks/dashboard.htmlが上書きされる。スクリプトは読み取り専用で、タスクファイルには触れない。- ダッシュボードは Task Runner 自身の記録(log.md と同じ扱い)なので、
dry-runモードでも生成してよい。 - 失敗してもタスク処理の結果には影響させない。ログの末尾に
(dashboard更新失敗: 理由)と添えて終了する。 - 何も起きない回は、利用者への報告に再生成したことを書かない(静かに終わる)。
計画カード
人が「このタスクはどう進むのか」「どこを判断すればいいのか」を10秒で分かるようにするための、決まった書式の計画。ダッシュボードはこれを図解して表示する。タスクファイルの ## 結果 の直前に、次の書式で書く。
## 計画カード
- やること: 何ができあがるかを1文で
- 進め方:
- [読む] 直近3日の受信メールを読む
- [確かめる] 返信が必要なものを選ぶ
- [外部] 下書きを作って Gmail に保存
- [作る] 結果を表にまとめる
- [止まる] 送信は許可されていないので止まる
- 外に触れること:
- [する] Gmail に下書きを保存する
- [しない] 送信・削除はしない
- [保存] output に一覧を保存
- 前提:
- 「直近3日」は実行した時点から数える
- 確認してほしいこと:
- 返信不要とみなす基準はこれでよいか
- 終わりの条件:
- [ ] 対象メールごとにドラフトIDが書かれている
書くときの決まり:
進め方のタグは[読む][作る][確かめる][外部][止まる]の5種類だけ。3〜7ステップ、1ステップ20字程度に収める。外部に触れるステップは必ず[外部]にする外に触れることのタグは[する][しない][保存]の3種類。[しない]も書く。何をしないかが分かると人が安心できる前提には、タスクに書かれておらず AI が自分で決めたことを全部書く。推測を隠さない確認してほしいことは 最大3つ。人が判断すべきことだけを書く。4つ以上になるなら、タスクが大きすぎるので分割を提案してblocked/に回す。確認点がなければ見出しだけ残す終わりの条件は完了条件をチェック欄に分解したもの。完了判定のときに満たした項目を[x]にする- タスクの言葉ではなく、利用者が普段使う言葉で書く
ダッシュボード(看板ボード)
tasks/ の状態を1枚のHTMLにまとめたもの。ブラウザで tasks/dashboard.html を開けば状況が一目で分かる。
- 列:未着手(todo)/実行中(doing)/要確認(blocked)/完了(done・直近14日)
- 上部に件数サマリー(実行対象の件数、停止の疑い、今月の完了数など)と
mode - カード:優先度・日付・件名・目的。blocked は
## 結果の先頭行(止まった理由)を赤字で表示。未来日付の todo は「予定」、開始から60分超の doing は「停止の疑い」、外部操作: 許可は「外部操作あり」、計画の確認待ちは「計画の確認待ち」、確認点があれば「要確認 N」のバッジ - カードをクリックすると右から計画カードが開く。上から順に、止まった理由、やること、あなたに確認してほしいこと、進め方の流れ図(外部に触れるステップは赤枠)、外に触れること、AI が決めた前提、終わりの条件のチェック欄、ファイル情報。計画カードがないタスクは、目的とファイル情報だけを出す
- 検索欄で件名・内容を絞り込める
- 下部に
log.mdの直近8件 - 外部CDNなしの単一HTML。ライト/ダーク両対応
オプション:--done-days 30(完了列の表示日数)、--out パス(出力先の変更)。
python3 が使えない環境では、スクリプトと同じ構成(4列+件数サマリー+直近ログ)のHTMLを直接書いて tasks/dashboard.html に保存する。
初期セットアップ
tasks/ がない場合、または「初期設定して」と頼まれた場合:
- 上記のフォルダをすべて作成する。
- このスキルの
assets/config.mdをtasks/_config.mdに、assets/task_template.mdをtasks/_template.mdにコピーする。 tasks/log.mdを作成する(見出し# 実行ログのみ)。assets/samples/の中身をコピーする:*.mdのタスクはtasks/todo/へ、sample_data/はtasks/sample_data/へ。サンプルタスクのファイル名先頭の日付は 今日の日付に置き換える。- ログに
setup: 初期化完了(dry-runモード)を書き、ダッシュボードを生成する(手順7)。 - 利用者に、作成したものと次の一手(
_config.mdの mode をliveに変える、サンプルで試す、スケジュール実行を登録する、tasks/dashboard.htmlをブラウザで開く)を短く伝える。
人からの依頼への対応
- 「タスクを追加して」→
_template.mdをもとにtodo/へ作成。ファイル名はYYYYMMDD_優先度_短い件名.md(優先度は1が最優先、1〜9の1桁。ファイル名の昇順で処理するため、10は2より先に並ぶ)。作成後にダッシュボードを再生成する。 - 「状況を教えて」→ ダッシュボードを再生成し、各フォルダの件数と、
blocked/の件名・理由を一覧で返す。あわせてtasks/dashboard.htmlの場所を伝える。 - 「ダッシュボードを作って/見せて」「看板ボード」「進捗を見える化して」→ ダッシュボードを再生成し、ファイルを利用者に渡す(表示できる環境ならそのまま表示する)。
- 「blockedを再開して」→ 指示された内容をタスクに反映してから
todo/に戻し、ダッシュボードを再生成する。 - 「このタスクどう進めるの?」「〇〇(件名)の計画を見せて」→ そのタスクに計画カードがなければ書き、ダッシュボードを再生成する。タスクは移動しない。回答では、やること・確認してほしいこと・外に触れることを短く伝え、詳しくはダッシュボードでカードを押すよう案内する。
- 「〇〇(件名) OK」「この計画でいい」→ 件名の一部や優先度の番号からどのタスクか特定する。候補が複数あるときは推測せず、件名を並べて聞き返す。特定できたら、計画の確認待ちのタスクに
- 計画承認: YYYY-MM-DD HH:MMの行を外部操作:の下に足し、todo/に戻して、ダッシュボードを再生成する。確認点への回答があれば、前提ではなく人の指示として手順メモの下に- 追加の指示:として書き足す。
大事な考え方
- 1回1件。まとめて処理しない(失敗時の切り分けと、定期実行の時間内に収めるため)。
- 迷ったら止めて
blocked/に理由を書く。勝手に進めるより、人が1分で判断できる状態で渡す方が価値がある。 - タスクファイルの本文(目的・完了条件など、人が書いた部分)は書き換えない。書き込むのは
開始:完了:## 計画カード## 結果## 実行ログと、人の指示を受けたときの計画承認:追加の指示:だけ。## 結果は毎回置き換え、## 実行ログは追記する。 - 計画カードは人が読むためのもの。きれいにまとめるより、人が判断すべき点と AI の推測を隠さず見せることを優先する。
レビュー
まだレビューはありません。使ってみた感想をお寄せください。
同じリポジトリのスキル
概要と使いどころ
AI活用提案の専門コンサルタントスキル。LLM・AIエージェントの活用事例知識を基に、業界別、部門別、シーン別に最適なAI導入提案を行います。システム化、業務改善、効率化を得意とし、具体的な活用事例、期待効果、導入ステップを含む実践的な提案を提供します。Use when proposing AI/LLM adoption strategies for specific industries, departments, or business scenarios.
Generate AI-powered BPO service proposals for Japanese companies in the US market. Use when creating outsourcing proposals with AI service menus, ROI estimation, implementation roadmaps, and bilingual (JA/EN) proposal documents for 在米日系企業向けAI実装.
日本語の概要は準備中です。原文の説明を表示しています。
AI(LLM)が生成した日本語テキストの「AI臭」を検出・診断し、人間らしい文章にリライトするスキル。 Use when: 「AIっぽい文章を直して」「人間らしくリライトして」「AI臭を消して」「この文章をもっと自然にして」 「テキストのAI感を減らして」「機械っぽさを取りたい」 "make this sound more human", "remove AI tone", "humanize this text", "detect if this is AI-generated". 6つのAI特有パターン(視覚的マーカー、単調なリズム、マニュアル的構成、非コミット姿勢、抽象語の濫用、 定型メタファー)を正規表現ベースで検出し、0-100のAI臭スコアを算出。3つの人間化技法 (バランスを崩す・客観を崩す・論理を崩す)でリライトを実行する。 Note: 検出スクリプトは日本語テキスト専用。英語テキストの場合はClaude自身がreferences/を参照して分析・リライトする。
Generate audit-ready internal control design documents from As-Is business process inventories. Produces control IDs, assertion mappings, procedures, SoD analysis, KPIs, materiality thresholds, and implementation roadmaps. Use when building internal controls for new audit engagements, SOX/J-SOX compliance, or process improvement initiatives.
日本語の概要は準備中です。原文の説明を表示しています。
Review audit-related documents (control design documents, bottleneck analyses, requirements definitions, etc.) for quality, scoring them 0-100 with a severity-rated findings list. Use when reviewing audit documents, checking control design quality, or verifying cross-document consistency. Supports documents governed by US GAAP, IFRS, or J-GAAP.
日本語の概要は準備中です。原文の説明を表示しています。