増え続ける運用を、 Skill化する"型"でさばく

by mori

Embed

Start on current slide

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

作成を補助するSkillを作った現状と課題を踏まえて、Skillを作るときの前処理を担うSkillを用意しました。 Skill 構成 ops-skill-builder/ ├── SKILL.md ├── references/ │ ├── hearing.md │ └── acceptance.md └── impact-log.md 作るときの流れ要件のヒアリング項目受け入れチェック実績の記録守ってほしいことが増えたら、references に足していく © 2026 Classmethod, Inc. 6

Slide 7

Slide 7 text

を作るときの流れ Skill 重複の確認と要件のヒアリングを先に済ませ、Skill本体の生成は skill-creator に任せます。できたものは受け入れ確認を通してから登録します。重複を確認既存Skillの拡張で済まないか判断する © 2026 Classmethod, Inc. 要件をヒアリング正本・判断基準・承認の要否を聞くへ skill-creator Skill本体はここで生成する受け入れ確認チェックリストを通す実績を記録 Before/After を1行残す 7

Slide 8

Slide 8 text

課題ごとの現在地先ほどの課題に対して何をしたかと、今どこまでできているかを並べます。課題したこと今の状態似た処理が複数のSkillにある要件不足で手戻りする作る前に既存Skillを確認するヒアリングで固めてから渡す 1本作るのに時間がかかる生成は skill-creator に任せるスクリプトを直接書いている受け入れチェックに入れた既存Skillの拡張を提案する動きを確認最低限必要な要件が、質問として出てくる要件整理やレビューの時間が削られ、時短になった実際にスクリプトが別ファイルに切り出されることを確認 © 2026 Classmethod, Inc. 8

Slide 9

Slide 9 text

振り返り効果を感じた点と、まだ改善が必要な点を分けて整理しました。効果があった点改善が必要な点作る前にヒアリングが入るので、何を書くか迷いにくい書いていないことは確認リストで返るので、抜けたまま進まない動かして確かめる過程でバグや想定外の挙動に気づけた暗黙知はヒアリングでしか引き出せないため、ヒアリング項目自体のブラッシュアップが必要生成したドラフトは一度で完成せず、試走とレビューが要るチームで使った実績がなく、作る人による差が減るかは未検証 © 2026 Classmethod, Inc. 9