菜单
work/ 配下の作業ディレクトリ構造を、後続タスクが確実に参照できるよう整備するスキル。 USE FOR: work/ structure, artifacts path, qa/ structure. DO NOT USE FOR: docs/ format (use docs-output-format). WHEN: work/ 配下にファイルを作成したい、作業ディレクトリを整備したい。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
全 Custom Agent が作業開始時に参照する共通プリアンブル。 USE FOR: agent start, common rules, preamble. DO NOT USE FOR: implementation. WHEN: Custom Agent が作業を開始したとき、共通ルールを確認したいとき。
GitHub Actions CI/CD ワークフローの共通仕様。OIDC 認証・workflow_dispatch トリガー・ Copilot push 制約対応・シークレット管理・デプロイ保護の原則を提供する。 USE FOR: GitHub Actions, CI/CD workflow, OIDC authentication. DO NOT USE FOR: application code deployment (use appropriate azure-skills/ deployment skill). WHEN: GitHub Actions ワークフローを作成する、CI/CD パイプラインを設計する。
破壊的操作を事前に検出・阫止する安全ガードの詳細パターンリストと判定フロー。 PHASE: 実行前（コマンド・スクリプト実行前に使用）。 USE FOR: destructive operation detection, rm -rf detection, DROP TABLE detection. DO NOT USE FOR: error recovery after failure (use harness-error-recovery), post-execution verification (use harness-verification-loop). WHEN: コマンドを実行する前の安全確認、破壊的操作の検出。
コード変更後の5段階検証パイプライン（Build/Lint/Test/Security/Diff）の詳細手順。 PHASE: 実行後（コード変更・生成・デプロイを行った**後**に使用）。 USE FOR: build check, lint, test execution. DO NOT USE FOR: error recovery (use harness-error-recovery), pre-execution safety check (use harness-safety-guard). WHEN: コードを変更した後の検証、ビルド確認。
knowledge/ 配下のファイル管理ルールを提供する。業務要件・判定表・連携契約等の ドメイン知識ドキュメントの分類・命名・更新手順を定義する。 USE FOR: knowledge/ file management, D01-D21 classification, domain knowledge organization. DO NOT USE FOR: qa/ file creation (use work-artifacts-layout). WHEN: knowledge/ 配下にファイルを作成・更新する、ドメイン知識を整理する。
初見のリポジトリで最小限の読解により入口・境界・標準コマンドを確定し、 onboarding.md に固定するスキル。"全部読む"を避け、作業に必要な最小限だけ確定する。 USE FOR: repository onboarding, first assignment, entry point discovery. DO NOT USE FOR: full code analysis. WHEN: リポジトリに初めてアサインされた、入口が不明。
| name | work-artifacts-layout |
| description | work/ 配下の作業ディレクトリ構造を、後続タスクが確実に参照できるよう整備するスキル。 USE FOR: work/ structure, artifacts path, qa/ structure. DO NOT USE FOR: docs/ format (use docs-output-format). WHEN: work/ 配下にファイルを作成したい、作業ディレクトリを整備したい。 |
| metadata | {"origin":"user","version":"2.0.0"} |
docs/ 配下の成果物フォーマット管理 — Skill docs-output-format が担当src/ 配下のソースコード構造管理 — リポジトリ慣習または Agent 固有ルールに従うadversarial-review が担当task-questionnaire が担当目的 / 入口（plan / contracts / artifacts）/ 根拠（参照元）/ 現状（完了/未完/次のSub）/ 検証
references/directory-structure-detail.md）work/ および qa/ 配下のファイル作成・更新時は delete→create に必ず従うこと。
work/ 全ファイル / qa/ 全ファイル / knowledge/ 全ファイル / 全 Custom Agent複数ジョブが同時実行される場合、各ジョブは以下の識別子でディレクトリを分離する:
Issue-<N>）で自動分離（変更不要）run-<タイムスタンプ-UUID> + step-<step_id> で分離
work/self-improve/run-20260413T143022-a1b2c3/step-1.1/.self-improve-lock）は run_id ディレクトリ内に配置run_id は SDKConfig.run_id フィールドで管理し、run_workflow() 開始時に1回生成する非 Custom Agent 時: work/Issue-<識別子>/
Custom Agent 時: work/<Custom Agent Name>/Issue-<識別子>/
各ディレクトリの構成ファイル：
README.md・plan.md・subissues.md（分割時のみ）・onboarding.md（初見時のみ）・contracts/・artifacts/
| ファイル | 内容 |
|---|---|
references/directory-structure-detail.md | §4.1 疑似コード全体、§4.3 qa/ の構造・命名規則・適用対象、§4.4 ソースコードパス標準定義テーブル |
全 Agent の成果物に以下 4 要素を含める（PR description 内に統合して記載する）:
## 成果物サマリー
- status: [成功/失敗/部分完了]
- summary: [何を行い何が変わったか（3行以内）]
- next_actions: [後続で必要な作業（あれば Agent 名を推奨付き）]
- artifacts: [生成/変更したファイルの一覧]
§7 との関係: 本テンプレートは §7「目的/変更点/影響範囲/検証結果/既知の制約/次にやるSub」の構造化補完版。PR description 内に統合して記載する。
※ 以下は説明用の架空例です
例1（非 Custom Agent: Issue #42）: work/Issue-42/ に README.md + plan.md + contracts/ + artifacts/
例2（Custom Agent: Arch-DataModeling + Issue #58）: work/Arch-DataModeling/Issue-58/
例3（qa/ 命名）: Custom Agent + Issue #58 → qa/Arch-DataModeling-Issue-58.md
| Skill | 関係 | 説明 |
|---|---|---|
task-dag-planning | 利用元 | plan.md / subissues.md の配置に本Skillのパス規則を使用 |
large-output-chunking | 利用元 | artifacts/ 配下の分割ファイル配置に本Skillの構造を使用 |
docs-output-format | 補完 | docs/ 配下のフォーマットは docs-output-format が担当 |
task-questionnaire | 利用元 | qa/ 配下の質問票ファイル管理に本Skillの§4.3を使用 |