ライフスタイル
依頼、ルール、引き継ぎのテンプレート
依頼、規則、引き継ぎの雛形を選び、必要項目と入力場所を確認して使います。
読了目安 15 分 · 操作 20 分

Codex 学習目次に戻るCodex 学習ガイド:全記事の目次導入と最初のタスクから MD の指示、高度な連携まで、60 レッスン・十単元を予定しています。習熟度、環境、目的、コマンドで次の記事を探せます。未公開の記事には状態を表示します。記事全文を読む
目標と準備
この段落の教材・資料: 依頼の書き方目的が伝わる依頼の書き方よい依頼は成果、背景、制約、完了条件を明確にします。「ページを改善」だけでは速度、見た目、操作性のどれか分かりません。まず観察できる動作へ言い換えます。記事全文を読む · MarkdownMarkdown と MD ファイル入門Markdown は見出し、一覧、リンク、コードを純粋なテキストで表す形式です。README.md は説明、AGENTS.md は代理の作業規則、SKILL.md は再利用する技能を扱います。すべての MD が自動的に指示として読まれるわけではありません。記事全文を読む
手順1:用途を分けて雛形を保存
実習ディレクトリ内に templates を作り、下記ファイルをエディターで追加します。Windows は .md.txt になっていないか確認、macOS は標準テキスト、Linux は UTF-8 で保存します。全 OS とも実習ルートを基準に同じ名前を使います。このフォルダーは自動読込みされず、追加導入、別サイトへのログイン、グローバル設定は不要です。
templates/
task.md
bug.md
review.md
handoff.md
rules.example.md
connection-check.md
| 作業 | 雛形 | 代用できないもの |
|---|---|---|
| 小機能の実装 | task.md | ファイルと検証 |
| 再現可能な修正 | bug.md | 元エラーと再現 |
| 変更の審査 | review.md | テストと判断 |
| 長作業の引継ぎ | handoff.md | 最新 Git 状態 |
| 規則の下書き | rules.example.md | 適切な AGENTS.md |
| 外部機能の確認 | connection-check.md | 実ツール応答 |
手順2:検証可能な依頼へ変える
# Task
Goal: Verify the active-task filter and repair it only if the acceptance case fails.
Context: Use the complete reference copy in this practice folder.
Inspect first: index.html, app.js, core.mjs, style.css and core.test.mjs.
Scope: Only files needed for the filter and its focused tests.
Behavior: All shows every task; Active shows tasks whose completed value is false.
Preserve: Existing task IDs, titles, ordering and stored data format.
Acceptance: With three tasks (two complete), Active shows exactly one.
Boundary: An empty list shows a useful empty state and does not throw.
Validation: Run node --test core.test.mjs and verify the browser behavior; report actual results.
If the existing behavior passes, report that evidence without unnecessary edits.
Delivery: Explain changed behavior, tests actually run and remaining limitations.
この記入例は Small Steps 用です。expected コピーに5つのコードファイルがあるか確認します。説明は expected 内ではなくダウンロードの根にある README.md にあります。他のプロジェクトでは各 README で検証命令を照合します。可能性の相談は Plan モードPlan モードで実装前に計画するPlan モードは範囲や方法を決める段階に向いています。成果は実装計画であり、完成したコードではありません。入力、出力、制約、検証方法が含まれるかを確認します。記事全文を読むで手順と未決事項を成果にし、実装なら編集範囲を明示します。
「サイトを整理して」をこの形式に直します。画面、維持する動作、検証データ、公開の有無まで分かれば使えます。ファイル名が未知なら一覧表示を担当する箇所の特定を依頼し、架空のパスを書きません。説明文は自分の言語に変えても、識別子、パス、条件は保持します。
手順3:不具合報告に証拠を残す
# Bug report
Environment: <OS, browser/runtime and version>
Practice folder or branch: <actual location>
Starting state: <fixture or steps to create it>
Reproduction:
1. <first action>
2. <next action>
Expected: <observable result>
Actual: <observed result>
Error: <exact message, with secrets removed>
Frequency: <always / intermittent / unknown>
Already tried: <one change and its result, or none>
Fix scope: <allowed behavior and files>
Verification: Reproduce first, fix, rerun the original case and a boundary case.
山括弧は記入欄であり、ターミナルの構文ではありません。不具合の練習不具合修正の一連の流れ不具合修正は再現する症状から始め、根拠で原因を絞って検証します。入力、操作、期待、実際を伝えます。記事全文を読むなら「broken のコピーで Read と Build を追加し、Read だけ完了にすると、Completed に Build が出る」と書きます。Actual は自分の観測だけとし、未実施なら NOT RUN にして例を実測扱いしません。未確定のデータベース故障を原因に書かず、エラー表示がなければ none observed と動作・手順を記録します。
修正後に元手順と空データ・同名の境界を再実行します。失敗と未実行を分け、通るはずを結果にしません。実行できない場合は制限と再実行命令を渡し、Verification 欄を完了扱いにしません。通過数を予記しないことで、古い証拠の流用を防ぎます。
手順4:審査と引継ぎを分ける
# Review request
Compare: <base branch or exact before-state> -> <current change>
Purpose: <user-visible behavior>
Read first: <requirements and relevant files>
Review for: correctness, regressions and missing meaningful tests.
For each finding: give the trigger, impact, file/location and suggested correction.
Evidence: <commands actually run, exit codes and relevant output>
Unknowns: <tests or environments not checked>
Report no findings if none are supported; do not invent issues to fill a quota.
Do not modify files in this review task unless I request a fix.
# Handoff
Goal:
Working directory and branch:
Current commit:
Existing uncommitted changes and owners:
Completed work with evidence:
Pending work:
Decisions and constraints:
Files to inspect next:
Last command and result:
Known limitations:
Next smallest action:
Before continuing: verify the current files and Git state against this record.
審査の比較元は現在の Git で解決できる必要があります。存在しなければ Git と差分Git・ブランチ・差分・復元Git は履歴、ブランチは変更のまとまり、diff は差分を扱います。会話の再開ではファイルは復元されません。記事全文を読むを確認し main を仮定しません。引継ぎは現在地と状態を毎回更新します。以前の会話のコミット報告だけで現在のディレクトリを未変更と判断せず、未コミット分と担当を残します。
引継ぎ文書は共有可能な場所ならプロジェクト内に保存できます。顧客情報、資格情報、会話全文は通常不要で、パス、問題要約、検証結果を残します。保存だけで新タスクが読んだとは限らないため、開始時に読取りを依頼し次の行動を照合します。文脈と引継ぎコンテキストと作業の引き継ぎ長い作業には判断と証拠を残します。README は使い方、設計書は理由、引き継ぎは進捗、AGENTS.md は継続する規則に分けます。記事全文を読むも参照します。
手順5:規則と外部ツールの雛形
# Practice project rules
Read index.html, app.js, core.mjs and core.test.mjs before changing this practice app.
Preserve task IDs and the existing data format.
Keep changes within the requested behavior.
Run node --test core.test.mjs and report actual results.
Do not commit credentials or private practice data.
If required files are missing, report the missing paths before making assumptions.
rules.example.md は確認前の下書きなので AGENTS.md としていません。適合を確認後、既存条件を読み保全して AGENTS.mdAGENTS.md でプロジェクトのルールを設定AGENTS.md は作業開始前にプロジェクトの指示を渡すファイルです。全体設定とルートから現在の作業場所までの規則が連なります。同じ階層では AGENTS.override.md が優先されます。読み込まれた内容を検証することが大切です。記事全文を読む の適切な階層へ統合します。一回限りなら要求文に入れます。範囲が安定した反復作業を SKILL.mdSkills と SKILL.mdSkill は繰り返す手順と資料をまとめます。最小構成はフォルダーと SKILL.md で、先頭に name と description、本文に操作と出力を書きます。導入しただけで使用済みとは判断しません。記事全文を読む にし、一時的な依頼まで全て導入しません。
# Connection check
Surface / host / version:
Plugin or MCP server name and source:
Configured:
Authenticated (if required):
Tool available in a new task:
Read-only target (fictional or public):
Expected marker or source:
Actual tool call and result:
Original data unchanged:
Disconnect or disable action, if performed:
Retest after change:
Never include tokens, passwords or one-time login URLs in this report.
設定、認証、能力、実呼出しを別記します。不要な認証は not required、未確認は not checked とします。設定ファイルだけで接続成功とせず true を予記しません。PluginsPlugins と外部サービスPlugin は Skills や MCP を配布できます。導入、アカウント接続、ツール成功は別段階です。記事全文を読む や MCPMCP の設定と接続確認MCP は外部ツールと接続します。STDIO はローカル命令、HTTP は URL を使います。設定保存だけでなく起動、認証、応答を確認します。記事全文を読む は今回の入口とホストを記録し、他機の同名設定を同一視しません。
矛盾するテンプレートを1つの依頼へ直す
誤った依頼「expected を読み取り専用で審査し、ついでに修正してコミット。npm test で3件通過と報告」を考えます。読み取りと変更が矛盾し、package.json のない教材へ不適切なコマンドを指定し、未実施の結果も決めています。今回は読み取り専用の確認を選び、次の完全な依頼を練習ルートの adapted-task.md に保存します。元の6つのテンプレートは保持します。
# Read-only practice check
Goal: Verify the existing Active-filter behavior in this expected copy.
Confirm the absolute working directory and the five expected source files first.
Read core.mjs and core.test.mjs; explain the filter condition and test coverage.
Run node --test core.test.mjs and report the actual exit code, passes and failures.
Do not edit, stage, commit, push or deploy anything in this task.
Browser behavior: NOT RUN unless actually checked; core tests do not prove it.
If required files are missing, report the paths and stop before guessing commands.
Delivery: observed evidence, unverified behavior and the next smallest step.
クリーンな expected の参考結果は3件通過・0件失敗ですが、今回の出力を記録し、ソースは変更しません。broken を開いたなら2件通過・1件失敗と開始状態の違いを報告し、パスを直すか別の修正タスクを作ります。テンプレートに expected とあるだけで失敗を無視しません。これは公式の依頼方法にある目標、背景、境界、使える成果を教材へ適用した例です。
間違い・復元・小実習
未記入の山括弧は送信前に < を検索し、記入または不要欄削除で直します。旧命令の流用は README と現在地の確認で防ぎます。読取り審査とついでの編集など競合する要求は一目的に絞ります。同名の既存雛形は別コピーや Git 差分で保護し、復元も自分が変更した雛形に限定します。
実習では観測済みの不具合を bug.md、次の一歩を handoff.md に書き、元の作業を知らない人に渡します。場所、再現、未確認が分かれば合格です。ホストやデータを推測させるならその欄だけを足し、全テンプレートを長くしません。未記入の元テンプレートを保持し、作業ごとに別コピーを保存して、前回結果を次回の既定値にしません。
オリジナル教材であるこれらのファイルに実行権限はなく、アカウントも変えません。六つの読める雛形、記入済み報告と引継ぎ、特定した曖昧さ一件が検証成果です。モデルの特定表現は要求しません。次は MCP 設定MCP の設定と接続確認MCP は外部ツールと接続します。STDIO はローカル命令、HTTP は URL を使います。設定保存だけでなく起動、認証、応答を確認します。記事全文を読むで接続雛形を実際の読取り試験に使います。
Codex 学習目次に戻るCodex 学習ガイド:全記事の目次導入と最初のタスクから MD の指示、高度な連携まで、60 レッスン・十単元を予定しています。習熟度、環境、目的、コマンドで次の記事を探せます。未公開の記事には状態を表示します。記事全文を読む
詳しい説明を読む
Three numbered stages: identify the starting point, perform the exercise, and verify the result. Original illustration, not a product screenshot.
同じテーマの記事
ライフスタイル
Codex 学習ガイド:全記事の目次
導入と最初のタスクから MD の指示、高度な連携まで、60 レッスン・十単元を予定しています。習熟度、環境、目的、コマンドで次の記事を探せます。未公開の記事には状態を表示します。
ライフスタイル
Worktree とタスクの分離
Worktree は一つの Git リポジトリに別ブランチの作業場所を作ります。ファイルは分かれても DB、ポート、外部サービスは共有される場合があります。
ライフスタイル
実践:小さな Web サイトを作る
brief.md から Small Steps のタスクサイトを計画・制作し、追加、完了、削除、絞り込み、ローカル保存を実装します。HTML、CSS、データ関数、画面イベント、テストを分け、Node とブラウザーで検証して再起動・復元の手順を残します。
ライフスタイル
使用量と効率:やり直しを減らす
条件、モデル設定、時間、成果を記録し、不要な再試行と過剰な文脈を減らします。
この記事を引用している記事
最新の旅の情報・ガイド

ガイド東京
東京ではどのエリアに泊まる?新宿・上野・東京駅・渋谷・浅草・池袋・銀座の七エリア比較。空港アクセス、宿泊税、荷物配送も解説
東京ではどのエリアに泊まる?新宿、上野、東京駅、渋谷、浅草、池袋、銀座の七エリアを同じ基準で比較。成田・羽田空港からのアクセス、利用できる路線、周辺にあるもの、街の雰囲気、向いている人を、比較表と山手線の概略図とともに紹介します。2026年9月に確認した東京都の宿泊税(2027年4月から3%)と、空港宅急便で荷物を送る際のルールも解説します。
- 予算
- ホテル

ガイド東京
東京の交通パスの選び方:Suica/Welcome Suica、Tokyo Subway Ticket、JR Passは買うべき?
初めての東京では、まず一人一枚ICカードで都度払い(Welcome Suicaはデポジット不要、有効期間28日)。一日に地下鉄へ4回以上乗るならTokyo Subway Ticketの72時間券2,000円を追加し、関西へ行かず東京だけならJR Passは必ず割高です。TOURIST PASMO、iPhoneのSuica、東京メトロ一日乗車券で乗れる路線・乗れない路線を決定チャートで比較。価格は2026年9月に確認。
- 交通
- 予算

ガイド東京
東京ディズニーランド・シー攻略:チケット料金、ファンタジースプリングス、ディズニー・プレミアアクセス(DPA)とスタンバイパスの使い方、初めてならどちらを選ぶ?
東京ディズニーの一日パスポートは変動価格制で、2026 年 9 月は平日の多くが 9,900 円、週末が 10,900 円。公式サイトでは毎日 14:00 に二か月後の同日分を発売します。無料のプライオリティパスは公式サイトのサービス一覧に載っておらず、待ち時間を短縮できるのは有料のディズニー・プレミアアクセス(一人一回 1,000~3,500 円)のみ。運営時間、25 周年イベント、スタンバイパス、エントリー受付、ファンタジースプリングスの利用方法、初回にランドとシーのどちらを選ぶかも解説。2026 年 9 月に公式サイトで確認しました。
- モデルコース
- 家族向け