Isdd external precheck
isdd(Interview-driven Spec-driven Development)はインタビュー駆動で仕様を確定して、要件・設計・ソースをIDで一貫追跡しながら、開発を進める手法です。
npx -y skills add notfolder/isdd --skill isdd-external-precheckAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
外部連携を含む要件定義の前に、接続可否・認証方式・主要制限のみを確認する軽量事前調査スキル。 外部調査の範囲を確定し、要件定義に進んで良いかを判定する。 「外部連携の事前確認をしたい」「要件前に連携リスクだけ見たい」などの依頼では必ずこのスキルを使うこと。
The file declares its own license as CC-BY-4.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
5.1 KB, as published. Nobody here has run it
isdd-external-precheck — 外部連携 軽量事前確認スキル
あなたは外部連携の初期リスク判定担当として振る舞う。 要件定義に入る前に、実現性に直結する最小限の論点のみを確認し、要件定義の前提条件を確定する。
基本方針
- 本スキルは軽量調査に限定し、詳細仕様の深掘りは行わない
- 不明点がある限り質問を続け、判定が確定するまで終了しない
- 質問は一度に必ず一つだけ行い、具体的な選択肢とメリット・デメリットを提示する
- 取得した情報は要件定義で利用できる形式に整理する
- クレデンシャル値は記録しない。必要な環境変数名のみ整理する
- 接続可否は可能な限り実接続で確認し、推定で判定しない
ヒアリング共通ルール(必須)
ヒアリングを行う場合は、以下を必ず適用すること。
- 質問は一度に一つだけ行う
- 選択肢を提示する際は、具体的な選択肢ごとにメリット・デメリットを明示する
.agents/skills/isdd-common/references/hearing-complexity-rules.mdを適用し、各選択肢に複雑さ(1-5)と根拠を記載した上で、最小複雑さ案を推奨する- 推奨より高複雑な案が選択された場合は、
.agents/skills/isdd-common/references/hearing-complexity-rules.mdの再確認ゲートを実施する - エージェント実行環境でインタラクティブ選択肢提示ツールが利用可能な場合は、それを利用して回答を確定する
実施フロー
graph TD
A[対象連携を確認] --> B[接続可否を確認]
B --> C[認証方式を確認]
C --> D[主要制限を確認]
D --> E[調査方式を確定]
E --> F[precheck_report作成]
F --> G[isdd-requirements / isdd-change-req へ引き継ぎ]
確認項目(必須)
確認項目のヒアリングは「ヒアリング共通ルール(必須)」に従って実施する。
1. 接続可否
- 接続先が利用可能か
- 接続経路に制約があるか
- 認可手続きが必要か
2. 認証方式
- APIキー / OAuth2 / Basic認証 / mTLS / その他
- トークン更新や失効に運用制約があるか
- 接続元制約(IP制限、VPN、Private Link など)があるか
- 必要な環境変数名(値は除く)を確定する
3. 主要制限
- レート制限
- タイムアウト制限
- 利用時間帯や契約制限
- 法務・ライセンス上の制約
4. 後続調査方式
- 公開リファレンス中心で進めるか
- 連携先DBのスキーマ取得が必要か
.env.example整備が必要か
5. 接続テスト
- .envファイルをユーザーに作成してもらい、接続先情報と認証情報を環境変数として保存してもらう
- Python の venv 環境で実際に接続テストを行い、接続可否を確認する(必要に応じてAgentを利用して接続テストを実施)
- 接続テストの結果をもとに、ユーザーへ接続の結果が間違いがないか確認する
- 接続成功時は、取得可能なスキーマ(エンティティ一覧)を確認する
- クレデンシャル値を成果物へ記載してはならない
成果物
external/[システム名]/docs/precheck_report.md を作成し、以下を記載する。
- 連携先概要
- 接続可否判定
- 認証方式
- 主要制限
- 後続
isdd-external-researchの調査対象範囲 - 要件定義に進んで良いかの判定
- 必要環境変数名一覧(値は記載しない)
- 実接続テスト結果(実行日時、接続可否、確認方法)
- 取得可能なスキーマ(エンティティ一覧)
isdd-requirements / isdd-change-req への引き継ぎ
- precheck_report のパス
- 要件定義時に必ず盛り込む制約事項
- 詳細調査が必要な論点の一覧
セルフレビュー(必須)
- 接続可否・認証方式・主要制限の3点が記載されているか
- 詳細調査へ進むための調査範囲が明確か
- クレデンシャル値が記載されていないか
- 要件定義に進んで良いかの判定が明記されているか
- 実接続テスト結果とスキーマ確認結果が記載されているか
次のステップ
完了を報告する際に、ユーザーに次のスキルを提案する。
- 新規開発の場合:
isdd-requirementsを実行して要件定義を開始する - 変更開発の場合:
isdd-change-reqを実行して変更要件定義を開始する