Imported from mtaiseeei/yasashii-secretary (plugins/secretary/skills/projects/SKILL.md). Install upstream with npx skills add mtaiseeei/yasashii-secretary --skill projects. Copyright stays with the author.

継続する仕事を整理する（projects）

plugin root（必須）

このSKILL.mdの実ファイル絶対pathを SECRETARY_SKILL_FILE に入れ、最初に1回だけ解決する。 空・相対path・未解決placeholderならcommandへ渡さず停止し、cwdやhost固有の環境変数から推測しない。

SECRETARY_SKILL_FILE="<このSKILL.mdの実ファイル絶対path>"
case "$SECRETARY_SKILL_FILE" in /*/skills/*/SKILL.md) ;; *) exit 2 ;; esac
SECRETARY_PLUGIN_ROOT="$(node "$(dirname "$SECRETARY_SKILL_FILE")/../../scripts/resolve-plugin-root.mjs" --skill-file "$SECRETARY_SKILL_FILE")" || exit 2

以後の共通file参照は ${SECRETARY_PLUGIN_ROOT} を使う。

${SECRETARY_PLUGIN_ROOT}/rules/plain-language.md と、存在する場合は secretary/memory/preferences.md を先に読む。通常報告は独自に包装せず、最終出力形は同rule入口から解決される 「最終応答serializer」だけを正本とする。

1. 候補と作成を分ける

候補検出はLLMによる判断であり、完全自動ではない。次のシグナルを会話から数える。

• 同じ成果に向けた次の行動が2つ以上ある。
• 今日だけで完了せず、別の日・別セッションへ続く。
• 締切、待ち状態、関係者がいる。
• 判断や成果物が今後も増える。
• 別の会話で同じ案件が繰り返し登場する。

少なくとも2つがあり、そのうち1つが「複数行動」または「複数セッション」のときだけ候補にする。 単発成果物、同じ会話で完了する作業、一つだけのTODOには提案しない。 判定の確認には、副作用のない次のコマンドを使える。

node ${SECRETARY_PLUGIN_ROOT}/scripts/project-tools.mjs candidate-check --multiple-actions --multiple-sessions

同じ案件名が分かっている場合は、通常の候補提案より先に既存PJを照合する。 通常照合はopenとlegacy-openだけを対象にし、closedの存在確認はしない。利用者がclosed、完了、終了、 過去案件を明示した場合だけ --closed を付けて照合し、再開確認へ進む。

node ${SECRETARY_PLUGIN_ROOT}/scripts/project-tools.mjs candidate-check <secretary> <project> \
  --multiple-actions --repeated-topic

結果の route が existing-project なら新規作成せず既存PJへ続ける。reopen なら新規候補として 提案せず、「このプロジェクトを再開しますか？」と確認する。該当PJがなく create-project の場合だけ、 新規プロジェクトとしてまとめるかを確認する。この照合もファイルを変更しない。

候補になったら理由を1〜2点に絞り、構造化質問で次を確認する。

この内容は今後も続きそうです。プロジェクトとしてまとめますか？

選択肢は「まとめる／今回はまとめない」。候補の提案だけではprojectファイル、journal、 commit、remoteを変更しない。candidate-checkもファイルを変更しない。

2. 一般プロジェクトはライト運用から始める

営業、マーケティング、新規事業、採用、研修、契約準備等は、作成操作と必要項目が現在の依頼で明示されたときだけ同じprivate workspaceの secretary/projects/open/<project>/PROJECT.md を正本にする。新規PJは一般PJ、ライトPJ、 別repo参照PJを含め必ずopenへ作り、closedへの直接新規作成は拒否する。作成前に、プロジェクト名、概要、ゴール、 成功の測り方、現在の状況、次の入口、要確認事項を短く確認する。

node ${SECRETARY_PLUGIN_ROOT}/scripts/project-tools.mjs create-light <secretary> <project> \
  --overview "<誰のために何をするか>" --goal "<終了条件>" --success "<成功の測り方>" \
  --current "<現在の状況>" --next "<次の入口>" --questions "<要確認事項>" --confirm

--confirmは作成操作、対象、必要項目が現在の依頼で明示されている場合に付け、同じturnで1回だけ実行する。不足があれば副作用0で1問だけ聞く。コマンドは安全な名前、 既存同名PJ、空入力、資格情報、境界外path、symlinkを検査し、空テンプレや部分生成を残さない。

進行中一覧は project-tools.mjs list <secretary>、closedを明示的に含む一覧は list <secretary> --include-closed、再開時の状態確認は show <secretary> <project> --closed を使う。 --allだけではclosedを読まない。既存 secretary/projects/<project> はlegacy-openとしてread-onlyで扱う。

3. 状態・判断・事実・タスクを混ぜない

• 状態、待ち、次の入口は PROJECT.md。
• 確認済みのPJ固有判断は、ライトのDecisionsまたはフルの DECISIONS.md。
• 恒久的な事実は、ライトのメモまたはフルの MEMORY.md。
• 実行タスクは secretary/inbox/todo.md または接続済みサービス。PJ内に生きた TODO.md を作らない。
• PJ固有の本文を一般 memory/decisions/ や memory/topics/ へ複製しない。
• 一般memoryへの明示保存を内部分類の確認へ戻さない。ただしPJ固有であることが明示済みの判断はこのPJ正本へ1回だけ保存し、 一般memoryへ重複させない。秘書からPJメモ保存を提案する場合だけ内容を示して確認する。

判断は原文を示して確認した後だけ、現在状況と次の入口も同じ操作で更新する。

node ${SECRETARY_PLUGIN_ROOT}/scripts/project-tools.mjs add-decision <secretary> <project> \
  --decision "<確認済み判断>" --current "<判断後の現在状況>" --next "<次の入口>" --confirm

未確定事項はDecisionsへ入れず、PROJECT.mdの要確認事項として扱う。恒久事実の追加も確認後だけ行う。

node ${SECRETARY_PLUGIN_ROOT}/scripts/project-tools.mjs add-note <secretary> <project> --note "<確認済み事実>" --confirm

PJの実行項目は既存TODO正本へPJ参照つきで追加する。

node ${SECRETARY_PLUGIN_ROOT}/scripts/project-tools.mjs add-todo <secretary> <project> \
  --todo "<実行項目>" --source "<サービス名＋リンク/ID＋日付>" [--due YYYY-MM-DD]

4. 作業文書・確定版・旧版

• 単発成果物は従来どおり secretary/docs/YYYY/MM/。
• PJの作業文書はPJ直下: save-work。
• 確定成果物は outputs/: save-output。
• 旧版・backup・superseded文書は archive/: archive-file ... --confirm。

save-work / save-output は本文を標準入力から受ける。最新版を判断できない場合は移動せず、 対象を示して確認する。フル運用ではファイル変更と同じ操作でAGENTS.mdの索引も更新される。

5. ライトからフルへ整理する

次のいずれかに達したときだけ、その場で昇格を提案する。件数は目安であり、LLMが安全に取得済みの 実内容から、件数が少なくても昇格理由を判断してよい。

1. Decisionsが10件を超えた。
2. メモが10件を超えた、または状態以外の情報でPROJECT.mdが読みにくい（例: 判断・事実・作業の情報が混在して追いにくい）。
3. PJ固有のガードレール、確認フロー、読む順序が必要になった。
4. PJ直下の作業ファイルが10件を超えた。

promotion-statusは任意のread-only診断であり、昇格提案の必須前段ではない。対象PJのcanonical root、symlink境界、 open / general / activeの状態を安全に確認できている場合、LLMはPROJECT.md、Decisions、メモ、作業fileの実内容から、 「状態以外の情報で読みにくい」「PJ固有のガードレールが必要」といった具体的な理由を短く示してよい。 件数が少ないことだけを理由に提案を抑えない。対象の安全な読み取りが拒否された場合は停止し、直接Readで迂回しない。 提案では「フル運用へ整理する／今はライトのまま」を確認し、拒否時・確認前は何も変更しない。

node ${SECRETARY_PLUGIN_ROOT}/scripts/project-tools.mjs promotion-status <secretary> <project>
# 実内容に応じて必要なflagだけを付ける（常に両方を付けるわけではない）
node ${SECRETARY_PLUGIN_ROOT}/scripts/project-tools.mjs promote-full <secretary> <project> [--hard-to-read] [--guardrail-needed] --confirm

承認後だけ、LLMが示した理由に対応する--hard-to-read／--guardrail-neededと--confirmを既存のpromote-fullへ渡す。 このpromote-full --confirmが昇格の唯一の書込み経路であり、PROJECT.md等を直接分割しない。 既存promote-fullが内部で行うpath / symlink / secret検査、5ファイルの役割分離、索引更新、atomic rollbackを保ち、実行結果の成功・失敗を正直に伝える。 承認後だけ AGENTS.md（指示・Start here・索引）、PROJECT.md（状態）、DECISIONS.md（判断）、 MEMORY.md（事実）、CLAUDE.md（AGENTS.mdへのポインタ）へ分ける。INDEX.mdは作らない。

6. 完了と再開

対象、完了日、達成した結果、残件が現在の依頼で明示されていれば、同じturnで完了処理を1回実行する。 不足がある場合だけ「完了扱いにする／まだ進行中」または不足項目を1問で確認する。

node ${SECRETARY_PLUGIN_ROOT}/scripts/project-tools.mjs complete <secretary> <project> \
  --result "<達成した結果>" --remaining "<未完・保留・引継ぎ。なければ、なし>" --confirm

完了はPROJECTのstatus／完了記録、journal、projects/openからprojects/closedへの移動を 一つの原子的操作として行う。通常の一覧、検索、timeline、daily／weekly、候補提案はclosedを読まない。 closed、完了、終了、過去案件の明示指定時だけ --closed／--include-closed を使う。

完了済みPJに新しい作業が出ても自動再開しない。再開操作、対象、理由、次の入口が現在の依頼で明示されていれば、 reopen ... --reason "<再開理由>" --next "<次の入口>" --confirm を同じturnで1回使う。不足があれば1問だけ確認し、closedからopenへ戻す。 過去の完了記録は消さない。

Project Clarityとの協働

ClarityはProjectの作成・完了・再開・canonicalRepoを所有しない。これらは上記のprojects操作を正本のまま使う。 Clarityを追加するときは、まずgeneric resolverのread-only previewを返し、利用者が対象を確認した後だけapplyする。

node ${SECRETARY_PLUGIN_ROOT}/scripts/clarity-secretary.mjs init <secretary> <project> --json
node ${SECRETARY_PLUGIN_ROOT}/scripts/clarity-secretary.mjs init <secretary> <project> --apply --json

PROJECT.md本文へClarity Itemを埋め込まず、project-tools.mjs showではmode、Attention、link health、詳細pointerだけを短く添える。 通常はopenだけを参照し、legacyは読み取り専用、closedは利用者が明示した場合だけstatus ... --closedで参照する。 完了・再開ではProject folder全体が既存の原子的操作で移動するため、Clarity IDとEvent履歴を再作成・複製しない。 別repo開発PJのcanonicalRepoはcreate-dev-pointerが作るPROJECT.mdの「正本repo」をprojects正本として扱う。 Clarityはread-onlyのlink候補として参照するだけで、相手Repoへのwrite、fetch、pull、push、branch／remote変更を行わない。

Project固有Decisionは次のadapterから既存add-decision seamへ一度だけ委譲する。Decision本文を一般memoryやClarity Eventへ複製しない。

node ${SECRETARY_PLUGIN_ROOT}/scripts/clarity-secretary.mjs decide <secretary> <project> \
  --decision "<確認済み判断>" --current "<現在状況>" --next "<次の入口>" --json

Clarity Itemを作っただけではTODOを作らない。「これをタスク化して」と明示された場合だけtask-route ... --explicitで既存task seamへの委譲先を確認し、既存の確認境界に従う。public共通coreはdownstream固有のtask実装を持たず、fixed handoffだけを返す。

7. 開発プロジェクトはbuildを維持する

「作って」「開発したい」「アプリ／ツールにして」は一般PJへ吸収せず、 ${SECRETARY_PLUGIN_ROOT}/skills/build/SKILL.md を段階ロードする。

別repoを正本にする場合は、repoの作成、接続、公開範囲を先に確認する。了承後だけworkspace側へ AGENTS.mdと概要スナップショットのPROJECT.mdを作る。

node ${SECRETARY_PLUGIN_ROOT}/scripts/project-tools.mjs create-dev-pointer <secretary> <project> \
  --repo "<正本repo>" --entry "<最初に読むファイル>" --overview "<概要>" \
  --current "<現在状態の短いスナップショット>" --visibility private --confirm

このコマンドはrepoやremoteを作成・変更しない。workspace側に実装仕様、判断ログ、Sprint状態、コード、 成果物を複製しない。実作業は正本repoで行い、Harnessの入口は edition.json のhost別設定に従う。 Yasashii版ではClaude Codeが harness@yasashii-harness の /harness、Codexも harness@yasashii-harness の $using-harness または $harness-loop を使う。

成功時だけ残す記録

定義済みproject操作は、成功した事実だけをjournalへ1回記録する。候補、確認前、拒否、失敗は記録しない。 project-toolsはcommit・push・remote変更を行わない。節目commitは既存規約に従い、pushは現在の会話で その操作への明示指示がある場合だけ行う。 プロジェクト文書には、確認済みの要点だけを残す。会話全文や逐語ログ、資格情報、外部サービス本文は保存しない。