job-stories

job-stories スキルの概要

job-stories スキルは、あいまいなプロダクトアイデアを JTBD 形式の job story に落とし込むのに役立ちます。形式は「When [状況], I want to [動機], so I can [成果].」です。バックログ項目をより明確にしたいとき、要件整理を前に進めたいとき、あるいはソリューション設計の前にユーザーの文脈を共有できる形でまとめたいときに特に有効です。

このスキルが最も向いている場面

すでに機能領域は分かっているものの、その背後にあるユーザー課題をより鋭くしたいときに job-stories スキルを使います。プロダクトマネージャー、デザイナー、アナリスト、そしてデザインリンクや機能プロンプト、関係者のメモをもとに要件を書き起こす AI エージェントと相性が良いスキルです。

一般的なプロンプトと何が違うのか

このスキルの主な価値は、構造があることです。状況と動機から始め、そこに観測可能な成果に紐づく受け入れ条件を乗せるようモデルを促します。そのため、チームが文脈、意図、テスト可能な結果を重視するなら、雑に「ユーザーストーリーを書いて」と頼むより job-stories のほうが実用的です。

どんなときに適しているか

job-stories for Requirements Planning、ディスカバリー前のバックログ整理、機能コンセプトをユーザー中心のストーリーへ変換する用途に強く適しています。逆に、受け入れ条件のない短いアイデア一覧だけ欲しい場合や、チームがまったく別の要件フォーマットを使っている場合には、あまり向きません。

job-stories スキルの使い方

正しくインストールして起動する

job-stories install では、ディレクトリの通常のスキルローダーを使います: npx skills add phuryn/pm-skills --skill job-stories。そのうえで、モデルがユーザー状況、プロダクト領域、望ましい成果を推測できるだけの入力を与えて呼び出してください。機能名だけでは情報が足りないことが多いです。

入力の形を整える

このスキルは、プロダクト、機能、ユーザー文脈、そして必要ならデザイン参照を含めると最もよく機能します。よい起点のプロンプトは次のようなものです: 「[product] の [feature] 機能について、次のユーザー状況を使って job stories を作成してください: [context]。デザインリンク [design] を参照し、役割ではなく成果に焦点を当ててください。」
これは「checkout の job stories を書いて」よりずっと良い入力です。

先に読むべきファイル

まず SKILL.md を開いてください。ワークフロー、ストーリーテンプレート、必須引数がまとまっています。ローカルコピーに隣接ドキュメントがあるなら、次に README.md、AGENTS.md、metadata.json を読み、加えて rules/、resources/、references/、scripts/ フォルダも確認してください。この repo では SKILL.md が主な正本なので、追加で見る範囲はあまり多くありません。

出力を良くするワークフローのコツ

このスキルは 2 回に分けて使うと効果的です。まず生の job stories を出し、次に実際の制約に照らして磨きます。最初の出力があいまいなら、具体的な状況、意思決定ポイント、デザインリンクを足してください。ストーリーが役割ベースに寄りすぎるなら、ペルソナではなくトリガーと望ましい前進を中心に書き直すよう依頼します。

job-stories スキル FAQ

job-stories は Requirements Planning に向いているか

はい。job-stories は、機能起点のチケットではなく、ユーザー中心のバックログ項目にしたいときの requirements planning に向けて設計されています。スコープを、デザインやエンジニアリングと議論しやすい状況・動機・成果へ変換するのに役立ちます。

うまく使うのにデザインファイルは必要か

必須ではありませんが、job-stories スキルは用意したほうが強くなります。Figma や Miro のリンクがあると、モデルは仮定を勝手に作るのではなく、受け入れ条件を見える振る舞いに結びつけやすくなります。

通常のユーザーストーリーとどう違うのか

一般的なプロンプトでは、役割ベースのテンプレートや浅い受け入れ条件が出やすくなります。job-stories スキルが優れているのは、システムが何をするべきかだけでなく、なぜユーザーが行動するのか、どんな成果が必要なのかが判断の中心にあるときです。

初心者でも使いやすいか

はい。機能を平易な言葉で説明できるなら問題ありません。主な制約は入力品質です。初心者ほど、広い機能テーマを入れるより、1〜2 個の実在するユーザー状況を入れたほうが良い結果になります。

job-stories スキルを改善するには

機能名だけでなく、状況を厚く書く

品質を最も上げるのは、具体的な文脈です。「notifications」だけでなく、「旅行中に支払いリマインダーを見逃したとき」のような状況を与えると、job-stories スキルは意味のある状況・動機・成果の流れを作りやすくなります。

制約と成功シグナルを足す

アクセシビリティ、タイミング、端末制限、承認フローが重要なら、最初から書いてください。成功の見え方、観測可能であるべき点、どんな場合に失敗とみなすかが明確だと、受け入れ条件は強くなります。

失敗パターンから修正を依頼する

初稿が一般的すぎるなら、役割の言及を減らして状況の詳細を増やすよう頼みます。解決策寄りすぎるなら、実装用語を避けた job stories にしてほしいと伝えます。広すぎるなら、機能を 1 回に 1 つのユーザー目標へ絞ってください。

最初の出力は計画用ドラフトとして扱う

1 回目の結果は、完成版ではなく探索用の下書きとして見てください。job-stories の最良の使い方は、ロードマップ、デザイン、エンジニアリング制約に合うまで反復し、Requirements Planning や実装に役立たない要素を削っていくことです。