agentsclimarketplace

Boundary check

Skill thinkyou0714/claude-lab-skills/lab-thinking-core/skills/boundary-check

THINK YOU LAB thinking-OS skills for Claude Code — reusable judgment/design/automation/communication skill packs (tech-agnostic, MIT)

Install
npx -y skills add thinkyou0714/claude-lab-skills --skill boundary-check

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 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

設計・実装・施策のスコープの境界を確認し、やること・やらないこと・後回しにすることを明確にする。スコープクリープを防ぎ、責任境界を明確にする場面で使う。

SKILL.md

5.7 KB, as published. Nobody here has run it

Purpose

「気づいたらスコープが広がっていた」「どこまでが自分の責任か」が曖昧なまま進むリスクを防ぐ。 スコープの内側・外側・境界を明示し、今何に集中すべきかを確定する。

Use When

  • 設計・実装の開始前にスコープを確定したい場合
  • 「これもやった方がいいか」という追加要求が出てきた場合
  • 複数のシステム・チームにまたがる機能を設計する場合
  • assumption-audit の後にスコープの境界を明確にしたい場合
  • 施工AIへ渡す前に「やること」「やらないこと」を確定したい場合

Inputs

以下を準備すること。不足している場合は推測せず、不足を明示する。

  • 対象: スコープを確認する設計・機能・施策
  • 目的: これを実現する本来の目的
  • 現時点の想定スコープ: 何をやると思っているか（箇条書きで）
  • フェーズ: 現在どのフェーズか（優先度・段階）
  • 関係する他システム: 隣接するシステム・機能・チーム

Output Contract

以下の順で出力すること。順序を変えない。

  1. 論点: このスコープで最も曖昧な境界はどこか
  2. 根拠: その論点をそう判断した理由
  3. 境界マップ: やること / やらないこと / 後回し（後述フォーマット）
  4. 含意: 境界の引き方が示す中長期の意味（何を後回しにするコストか）
  5. 改善案: 境界を引き直すことで品質・コストが改善できる観点
  6. 代替案: 別のスコープの切り方（縮小案・拡大案）
  7. 判断材料: 境界の確定に必要な人間の意思決定事項

境界マップ フォーマット

## スコープ境界マップ

### やること（In Scope）
- （具体的な機能・処理・責任）

### やらないこと（Out of Scope）
- （明示的に除外するもの・理由）

### 後回し（Deferred）
- （将来フェーズで対応するもの・条件）

### 境界が曖昧な箇所（要確認）
- （どちらに入るか確定できていない項目）

Review Lens

  • 目的妥当性: 引いた境界が本来の目的と整合しているか
  • 範囲の過不足: 必要なものを削りすぎていないか。不要なものを含んでいないか
  • 中長期リスク: 「後回し」にしたものが後で大きなコストにならないか
  • LAB全体との整合性: LMS / 自動化 / B2B 展開のフェーズ分けと矛盾しないか
  • 非エンジニア理解可能性: 境界マップが非技術者にも説明できる形か
  • 他LLM移植耐性: 境界の判断基準が Claude 固有の解釈に依存していないか

Instructions

  1. 現時点の想定スコープを読み、各項目を「In / Out / Deferred / 要確認」に分類する
  2. 分類の根拠を各項目に1行添える
  3. 「要確認」は推測で解決しない。人間が決めるべき境界として明示する
  4. 「やらないこと」は「なぜやらないか」の理由を必ず添える
  5. 「後回し」は「どの条件が満たされたら着手するか」を明示する
  6. スコープクリープの兆候（「これもついでに」という追加）を指摘する
  7. 境界確定後は Handoff Notes を使って施工AI へ渡す準備をする

Guardrails

  • スコープを自分で決定しない。「要確認」は人間が判断する
  • 「ついでにやっておく」を提案しない（スコープクリープの原因）
  • 「後回し」にするものは消えるのではなく記録に残す（Deferred として明示）
  • コスト（追加スコープの工数）を省略しない
  • 施工AIへの handoff 前にスコープが曖昧な状態で進めない

LAB Cross-Check

観点状態備考
自動化フロー—自動化スコープの境界が明確か
データ / 認証 / ログ—DB・Auth・ログのスコープが確定しているか
実装 / 運用フロー—実装範囲と運用責任の境界が明確か
非エンジニア理解可能性—境界マップが非技術者に説明できる形か
会員共有 / 再利用耐性—この境界設計が他ケースにも転用できるか
他LLM移植耐性—境界判断が Claude 固有の解釈に依存していないか

状態は OK / 注意 / NG / 対象外 で記入すること。

Handoff Notes

  • 要件: 確定した In Scope の一覧
  • 成功条件: スコープ内の全項目が完了した状態の定義
  • 失敗条件: スコープ外の作業が発生した場合の検知方法
  • 実行範囲: 触ってよいファイル・機能・DB（スコープ内のみ）
  • 影響範囲: スコープ内の変更が波及するシステム・機能
  • ロールバック方針: スコープ内の変更が失敗した場合の戻し方
  • コスト比較: 現在のスコープ vs 縮小案 / 拡大案のコスト差

Further Reading

  • issue-framing — スコープ確認前の論点整理
  • assumption-audit — スコープの前提を洗い出す
  • scope-design skill（lab-strategy-design）— 戦略的なスコープ設計
  • implementation-gate skill（lab-implementation-flow）— 実装前の最終スコープ確認
  • docs/DECISIONS.md — フェーズ分けの過去決定

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.