秘書と実務担当の実行境界を分ける

Organization DesignerのYuiは、問題を職能不足ではなく実行主体の曖昧さとして整理した。Executive SecretaryはCEOの意図を整理し、候補となるrole、理由、順序を示し、承認、gate、blocker、進捗、role agentの報告を統合する。一方、設計、実装、レビュー、法務draft、ファイル変更、GitやGitHubの状態変更は、承認済みの割り当てを受けた専門roleが担う構成を提案した。

AGENTS.mdにはExecutive Secretary Execution Boundaryを追加した。Makoが直接行えるrepository確認をlocal read-onlyに限定し、remote Gitの読み取りとGitHub操作をrole agent側へ分けた。既存のStanding RulesとSoftware Delivery Workflowでも、実装やdeliveryを行う主体へ「割り当て済みrole agent」を補い、CEOが委譲を承認したことをMako自身の作業許可として読めないようにした。

## Executive Secretary Execution Boundary

Makoが直接行う:
- CEOの意図整理、routing、承認確認
- gate、blocker、進捗の可視化
- role agent報告の統合
- 軽い非変更調査
- repositoryのlocal read-only状態確認

割り当て済みrole agentへ委譲する:
- ファイル作成、編集、削除と実務成果物作成
- branch作成、commit、mergeなどのGit write操作
- remote Git操作
- GitHub上のPull RequestとIssueの操作

許可するlocal read-only確認は、git status --short、git status --branch --short、git branch --show-current、git diff --stat、git diff --name-only、git log --oneline -n 5などの例で具体化した。作業branch作成、commit、mergeのようなGit write操作と、fetch、pull、push、ls-remoteのようなremote Git操作は、Makoの直接実行範囲から外した。

.agents/skills/software-delivery/SKILL.mdにも同じ境界を追加した。このSkillはsoftware feature、bug、product deliveryの依頼で発動し、事前確認、role flow、GitHub操作、delivery gate、CEOへの報告形を管理する。IssueやPull Requestの文面を作る場合だけ直接参照する.agents/skills/software-delivery/references/github-templates.mdは変更していない。今回変えたのはtemplateではなく、Makoがroutingと報告を担い、割り当て済みrole agentがbranch作成、変更、検証、commit、push、Draft Pull Request作成を担うという処理主体のgateだった。

command ruleの説明では、CLI用のguardrailが割り当て済みrole agentのdelivery操作を対象とし、Makoにはlocal read-only確認だけを残すと説明した。.codex/rules/organization.rulesも冒頭コメントと各commandの説明を同じ主語へ揃えた。既存のcommand判定そのものは変更せず、許可entryをExecutive Secretaryの作業権限として解釈しないための運用境界を明示した。

検証では、4ファイルの差分を読み、git diff --checkとstaged差分の空白error確認を行った。TOMLは変更しておらず、repository内にはrulesやMarkdownを意味的に検査する専用validatorがなかったため、TOML parseとcommand rule evaluatorは実行していない。

この作業では、CEOが問題と許可境界を示し、MakoがOrganization Designerへのrouting、進捗とblockerの整理、返却内容の統合、local read-only確認を担当した。Yuiは境界設計、4ファイルの実装と静的検証を担当した。