FACTUAL ACTIVITY RECORD · 実際の作業をもとにした活動記録
Narrative Directorと共有コンテンツ制作基盤を加える
構成と執筆を担う専任role、9種のtemplate、design前のNarrative gateを一つの運用へまとめる
目的
Wirohのコーポレートサイトをつくるにあたり、brandやstoryの構造を考える仕事と、記事、script、site copy、CTA、資料文面を書く仕事を、異なる担当へ分断せず一貫して扱う役割が必要だった。既存の組織には、requirements、design、technical design、implementation、legal、reviewの担当はあったが、Narrativeの構造と執筆成果物を継続して所有する専任roleがなかった。
同時に、物語としての表現が実際のdecisionやproductの事実を上書きしないよう、confirmed fact、approved claim、creative hypothesis、dramatization、placeholder、private inputを分け、designへ進む前に同じversionのNarrativeを確認できる共有制作基盤を整えることを目指した。
実装
.codex/agents/narrative-director.tomlに、Narrative Director + Writerを単一の専任roleとして追加した。brand / story architecture、message hierarchy、continuity、記事・script・site copy・CTAの執筆、deck storylineを一体で所有する一方、brand truthとorganization governance、product facts、visual design、technical design、implementation、法務判断、独立reviewは既存の担当へ残した。domain leadのchildではなく、中央のlifecycle ownerから直接起動される同階層specialistとして責務を定義した。
.agents/skills/narrative-development/SKILL.mdには、Brand Bible、Story World、AI社員character、series / season / episode、記事、script、site copy、CTA、deck storylineを扱うときの共通workflowを定義した。開始前にlinked Task、Narrativeのsource of truth、対象template、review checklistを確認し、truth owner、product facts、legal judgmentを別の入力として扱う。必要な入力や公開境界が揃わない場合は、推測で書き始めず不足を返す構成にした。
- Audience、desired outcome、channel、public boundary、source factsを先に定義する。
- Why、Belief、What、Current chapter、Promiseからmessage hierarchyを組み立てる。
- confirmed fact、approved claim、creative hypothesis、dramatization、placeholder、private / prohibited inputを区別する。
- 全roleが再利用できるcontent briefとmessage mapを先に作り、承認済みbriefから個別の文章へ展開する。
- truthfulness、continuity、audience fit、i18n、public boundaryを確認し、明示的な確認を得るまではcompleteと扱わない。
organization-level Narrative source of truthをorganization-levelのNarrative正本の入口とし、ownership、artifact status、変更の流れを定義した。その配下にはBrand Bible、Story World、AI Employee Profile、Series Bible、Season Outline、Episode Brief、Corporate Site Narrative、Shared Content Brief、Deck Outlineの9 templateと、truth / boundary、Narrative / message、shared input / deliveryを確認するchecklistを用意した。templateは完成済みのNarrativeではなく、後続artifactを同じ情報構造で作るための雛形として追加した。
Narrative出力に依存するdesignでは、専任roleがversioned artifactを作成し、同じversionへの明示的な確認を受け、brand truthとgovernanceの整合およびCEO confirmationを揃えたうえで、gate通過を記録してからdesign担当を開始する順序にした。確認後に内容が変わった場合は、変更versionを再確認するまでgateを通過したままにしない。この順序をAGENTS.md、.agents/skills/software-delivery/SKILL.md、operating model、handoff examplesへ同期した。
最初の横断確認では、旧ownershipとdesign開始条件が新しいrole契約と矛盾している点と、Narrative gateが運用文書とdelivery Skillのgate一覧へ同期されていない点がblockerとして見つかった。ownershipと開始条件を単一の有効な順序へ整理し、欠けていたgateを同期した後、同じ観点で再確認して矛盾が解消されていることを確かめた。
検証では、project設定と8つのagent定義をTOMLとしてparseし、role idの一意性、thread数とdepthの整合、Skill frontmatter、UI metadata用YAML、routing・hierarchy・source-of-truthの参照、古いrole数や開始条件の残存、差分の空白errorを確認した。公式のquick validatorは実行環境にYAML packageがなく起動できなかったため、YAMLとfrontmatterの構文は標準の別parserで確認した。
一次Commitの差分へ行単位で照合した、.agents/skills/narrative-development/SKILL.mdのcutoff時点の抜粋を示す。
## Before Writing
1. `AGENTS.md` とlinked Task Issueを確認する。Taskがなければsubstantive artifactを開始しない
2. approved narrative source を読む
3. 対象に合うthe matching narrative template and review checklistを使う
4. Yuiが所有するbrand truth、Ryomaが所有するproduct facts / value / roadmap、Yasuが所有するlegal judgmentを入力として分離する
5. fact、approved claim、creative hypothesis、dramatization、placeholder、private / prohibited inputを分類する
6. 自分がdomain leadのchildではなく、Makoが直接起動するspecialistであることを確認する。structured handoffにscope、inputs、dependencies、acceptance、expected outputs、開始・合流・停止条件、返却先がなければ不足を返す図を描画しています…
確認したこと
確認結果
Narrativeの構造と執筆を分割しない専任role、Narrative Development Skill、organization-levelのsource-of-truth、9種のtemplate、review checklistが共有制作基盤へ揃った。
Narrative artifactとdesignの間には、同じversionの確認、brand truth / governance整合、CEO confirmation、gate記録を求める開始条件が入り、内容変更時には再確認する順序が運用規則、delivery Skill、人向け文書で一致した。
初回確認で見つかったownership / start conditionとgate同期の2つのblockerは修正され、再確認では重大度付きの不整合が残っていなかった。TOML、YAML、frontmatter、role inventory、routing、stale reference、差分の検査も成功した。
公式quick validator自体はYAML package不足のため実行しておらず、構文は別parserで代替確認した。また、この時点で完成していたのは制作基盤であり、実際のBrand BibleやStory WorldなどのNarrative artifact、後続design、implementationはまだ作成・完了していなかった。
完了とした根拠
専任roleの責務と境界、Skillの発動条件とworkflow、source-of-truth、template、review checklist、design前のNarrative gateが一つの運用として反映され、初回の矛盾を修正した最終構成が静的検証と横断確認を通過したことをもって、共有コンテンツ制作基盤の追加を完了とした。