[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-93326":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":9,"language":10,"languages":9,"totalLinesOfCode":9,"stars":11,"forks":12,"watchers":13,"openIssues":14,"contributorsCount":15,"subscribersCount":15,"size":15,"stars1d":15,"stars7d":16,"stars30d":16,"stars90d":15,"forks30d":15,"starsTrendScore":17,"compositeScore":18,"rankGlobal":9,"rankLanguage":9,"license":9,"archived":19,"fork":19,"defaultBranch":20,"hasWiki":21,"hasPages":19,"topics":22,"createdAt":9,"pushedAt":9,"updatedAt":23,"readmeContent":24,"aiSummary":25,"trendingCount":15,"starSnapshotCount":15,"syncStatus":17,"lastSyncTime":26,"discoverSource":27},93326,"inspired-mino-design-skills","my-take-dev\u002Finspired-mino-design-skills","my-take-dev","ミノ駆動氏のWebに掲載されている資料から作成した開発スキル",null,"Shell",295,9,3,1,0,72,2,67.2,false,"main",true,[],"2026-07-22 04:02:08","# mino-drive-inspired-design-skills\n\n本リポジトリは、ミノ駆動氏の公開資料を基に、設計判断の原則をAI Skillとして再構成する非公式プロジェクトです。ミノ駆動氏および所属組織による監修・承認・推奨を受けたものではありません。\n\n目指すのは人物の口調や結論の模倣ではありません。問題、目的、文脈、要件、契約、モデル、品質、公開境界を確認し、根拠のある判断と検証可能な成果物を繰り返し作れるようにすることです。公開資料から直接抽出した原則、反復可能なSkillにするためsuiteが追加したschema・gate・workflow、versioningやvalidator等のrepository policyは区別して記載します。\n\n## 現在の状態\n\n```text\nStatus: Experimental \u002F Preview\nSuite version: 0.9.0\nStructural validation: fail on the native macOS fixture runner; pass on executed Linux and PowerShell-over-WSL layers\nmacOS structural support: implemented; native macOS \u002Fbin\u002Fbash executed \u002F fail (run 29397674053, exit 2)\nTargeted behavioral evidence: not executed\nBehavioral release: not ready\n```\n\nここでいうbehavioral release（行動再現性を確認した安定版判定）は、権限を持つevaluation ownerが`frozen`にしたversioned caseと隔離oracleをfresh contextで繰り返し実行し、代表case・negative case・回帰・required platformのRelease gateを満たした状態です。Experimental \u002F Previewとして配布可能であることと、stable releaseとして承認済みであることを分けます。権限を持つmaintainerが全Evidenceを確認するまでstable releaseとは扱いません。\n\nプロダクト価値（利用者・事業が得る成果）と品質portfolio（優先する品質、制約、意図的に最適化しない品質の組合せ）の最終判断も、AIではなく権限を持つ人間が所有します。\n\nnative macOS Evidenceは、head `e47aaafb74a27cf2cc7d4bc9c64f74d1933f10db`のworkflow run `29397674053`、job `Native macOS \u002Fbin\u002Fbash`（job ID `87294760529`）で取得済みです。環境はmacOS 15.7.7、image `macos-15-arm64` version `20260706.0213.1`、`RUNNER_ARCH=ARM64`でした。`validate-suite.sh`はpassしましたが、fixture runnerは`solver-nested-metadata`のportable rewriteで失敗し、jobはexit `2`でした。\n\nmacOSはBash構造validator、fixture runner、text-format検査を対応範囲に含めます。共用scriptは標準`\u002Fbin\u002Fbash` 3.2で実行できるsubsetへ制限しています。上記failureを修正したheadでnative macOS jobがgreenになるまで、platform parityやreleaseをpassにしません。\n\n## クイックスタート\n\n### Skill routingの適用\n\nこのsuiteは技術非依存の設計原則を扱います。プログラミング言語、framework、tool固有のSkillを併用する場合は、主成果物に最も合うmino Skillを基本workflowとし、必要な技術差分だけを追加します。現在のrouting規則は、maintainerが責任を持って採用・保守しています。\n\nSkill compositionを利用側の`AGENTS.md`へ記載する例:\n\n```md\n# Skill Composition\n\nWhen a request matches multiple Skills:\n\n- Use the Skill that best matches the primary outcome as the basic workflow.\n- Add only relevant language-, framework-, or tool-specific Skills to supplement that workflow.\n- Let the basic Skill control scope, changes, validation, and the final response; specialized Skills provide their domain-specific guidance.\n- Preserve every applicable Skill's exclusions, hard gates, and safety constraints.\n- Follow the user's explicitly named Skills and do not add unrelated Skills.\n```\n\n### 開発工程から選ぶ\n\nこのsuiteには、主に**設計フェーズ**で使うSkillと、設計した内容を**実装・レビューまでつなぐ**Skillが収録されています。最初は次の工程名を目安に選べば十分です。詳細な適用条件と成果物は、後述の「収録しているSkill」で確認できます。\n\n| 主に使う工程・フェーズ | Skill | 開発者が使うタイミング |\n|---|---|---|\n| 設計フェーズ | `mino-problem-framing` | 実装を始める前に、解くべき問題、目的、前提、成功条件を整理するとき |\n| 設計フェーズ | `mino-domain-model-completeness` | 業務に必要な概念、状態、制約、振る舞いに漏れがないか確認するとき |\n| 設計フェーズ | `mino-design-by-contract` | 要件を、正常時・異常時の条件やテスト可能な約束事にするとき |\n| 設計フェーズ | `mino-interface-implementation-separation` | 利用者に見せる操作と、内部の実装方法を分けて設計するとき |\n| アーキテクチャ設計フェーズ | `mino-architecture-quality-strategy` | システム全体の構成、データ管理、移行・復旧を設計するとき |\n| 設計・実装・レビューフェーズ | `mino-reproducible-development` | 中規模以上の変更で、複数の設計観点をまとめて実装・検証まで進めるとき |\n| 通常は直接使わない | `mino-core` | 他のSkillから共通機能として使われるため、開発者が直接選ぶ必要はありません |\n\n新規機能や大きな変更で迷った場合は、まず`mino-problem-framing`で設計の前提を整理します。その後、必要な設計Skillを一つ選び、複数の観点をまとめて実装・レビューまで進める場合だけ`mino-reproducible-development`を使います。設計フェーズのSkillは、実装済みの設計をレビューするときにも使えます。小さなrenameなど、問題や要件が承認済みbaselineとして記録された機械的な変更では、このsuiteを使う必要はありません。\n\n## このSkill suiteが存在する理由\n\nAIに同じ依頼をしても、実装の形は毎回変わり得ます。形が違っても、次の条件を一貫して満たせるようにするのが、このsuiteの役割です。\n\n- 解くべき問題と、採用した手段を混同しない。\n- 自然言語の要件を、モデル、契約、公開操作、テストまで追跡できるようにする。\n- 必要な業務概念、状態、制約、失敗、writer \u002F readerの欠落を見つける。\n- 利用者が知る意味と、内部の技術・手順を分ける。\n- プロダクト価値から品質特性とarchitecture上のtrade-offを判断する。\n- AIの説明ではなく、証拠、コード、契約テスト、品質scenario、独立検証で判定する。\n- 最終的な価値判断、公開契約、不可逆な判断、release可否は人間へ残す。\n\nここでいう再現性は、毎回同じコードを生成することではありません。異なる実装であっても、同じproblem、requirement、contract、model整合性、quality constraint、public boundaryを満たせることです。\n\n## 対応環境\n\nこのSkill suiteは、次の環境を対象にしています。\n\n- **Windows**: Windows PowerShellまたはPowerShell 7を使った構造検証と、Windows固有のpath、filesystem、process差を考慮します。\n- **Linux**: Bash 3.2以降を使った構造検証と、case sensitivity、permission、executable bit、symlink等を考慮します。\n- **macOS**: 標準`\u002Fbin\u002Fbash` 3.2を使うBash構造validatorとfixture runnerを対象とし、BSD userland、native filesystem、locale差を独立Evidenceとして扱います。\n- **WSL**: Linux filesystem \u002F processを操作するときはLinuxとして扱い、Windows processやWindows側filesystemも操作する場合は境界ごとにplatform Evidenceを分けます。\n\n設計上のproblem、業務要件、contract、test oracleはOS間で共有します。path separator、shell、line ending、permission、file lock等の差だけをplatform固有のimplementationまたはenvironment conditionへ分離します。\n\n複数platform対応が要件なら、全required platformの実行結果が揃うまでplatform parityを「検証済み」とは扱いません。利用できないOSは、対応実装の有無とnative runtime Evidenceを分け、必要なrunner、command、未実行理由とともに残します。\n\n## 収録しているSkill\n\n| Skill | 使う場面 | 主な成果物 |\n|---|---|---|\n| [`mino-core`](.agents\u002Fskills\u002Fmino-core\u002FSKILL.md) | 他のSkillが共通の問題定義、証拠、要件追跡、判定規則を必要とするとき。通常は単独で呼びません | Problem Frame、Context Packet、Requirement Catalog、共通decision |\n| [`mino-problem-framing`](.agents\u002Fskills\u002Fmino-problem-framing\u002FSKILL.md) | 技術案先行や曖昧要件を、観測・前提・問題・目的・成功条件へ分けてから設計へ渡すとき | Problem Framing Package |\n| [`mino-domain-model-completeness`](.agents\u002Fskills\u002Fmino-domain-model-completeness\u002FSKILL.md) | ユースケースに必要な概念、状態、制約、失敗、authorityの欠落を監査するとき | Completeness Package |\n| [`mino-design-by-contract`](.agents\u002Fskills\u002Fmino-design-by-contract\u002FSKILL.md) | 自然言語要件を事前条件、事後条件、不変条件、失敗保証、契約テストへ変換するとき | Contract Package |\n| [`mino-interface-implementation-separation`](.agents\u002Fskills\u002Fmino-interface-implementation-separation\u002FSKILL.md) | caller側の分岐や技術漏出を見つけ、目的と契約を中心に境界を設計するとき | Boundary Package |\n| [`mino-architecture-quality-strategy`](.agents\u002Fskills\u002Fmino-architecture-quality-strategy\u002FSKILL.md) | 複数module、data ownership、system-wideな品質trade-off、移行・復旧を設計するとき | Architecture Strategy Package |\n| [`mino-reproducible-development`](.agents\u002Fskills\u002Fmino-reproducible-development\u002FSKILL.md) | 中規模以上の設計・実装・レビュー・再現性検証で、複数の専門成果物と独立検証を統合するとき | Implementation Spec、Verified Change、Review Result、またはReproduction Report |\n\n小さなrenameや、問題・契約・data meaningが承認済みbaselineとして記録された機械変更には、このsuiteを起動する必要はありません。単一の成果物が欲しい場合は、統合Skillではなく対応する専門Skillを使います。\n\n### 資料からruntime Skillへの配置\n\n一つの資料を一つのSkillへ機械的に変換してはいません。主成果物と変更理由が同じ規則をまとめ、異なるものを分離しています。\n\n| `mino-doc`のテーマ | runtime上の配置 | 配置理由 |\n|---|---|---|\n| `01`, `02`, `16`, `17`, `26`: 目的、品質、文脈、前提、具体と抽象 | `mino-core` + 公開入口`mino-problem-framing` | 共通判断順は一箇所に保ち、Problem Frameだけを求める依頼にも暗黙到達させる |\n| `03`〜`05`, `27`: 価値、投資、品質全体最適、target \u002F transition | `mino-architecture-quality-strategy` | system-wide decisionを一つのArchitecture Strategy Packageにする |\n| `05`〜`10`, `22`: 用語、context、概念、不変条件、破壊分析 | `mino-domain-model-completeness` | use case scopeのmodel coverageとgapを主成果物にする |\n| `08`, `09`, `20`: 条件、失敗保証、冪等性、契約test | `mino-design-by-contract` | condition単位の契約とoracleを主成果物にする |\n| `10`〜`13`, `21`: capsule、分岐、命名、抽象、公開境界 | `mino-interface-implementation-separation` + `mino-core`のcode-design reference | consumer operation boundaryと局所code designを接続する |\n| `14`, `15`, `23`: legacy移行、AI支援、統合実装・検証 | `mino-reproducible-development` + change-safety reference | 複数成果物を必要時だけ統合し、modeと変更権限を守る |\n| `18`: 人間の設計学習workshop | 現在のruntime suiteの対象外 | 開発成果物を作るFunctionと混ぜず、独立した学習成果物として将来分離する |\n| `19`, `24`, `25`: Skill modularization、資料監査 | `AGENTS.md`、benchmark、versioned evaluation | 個別開発依頼へ常時発火させず、suiteを育てる保守工程として扱う |\n\n公開資料に明示された主張と、owner schema、canonical status、3-run benchmarkなどSkill化のための操作的解釈は同じ強さの「本人の主張」として扱いません。runtimeでは対象systemのEvidenceで判断し、保守時には`mino-doc`とevaluationの対応を再監査します。\n\n保守時のtraceは「資料テーマ → 判断規則 → 主成果物 → hard gate → case \u002F oracle → evaluation」の順で確認します。0.9.0では、solverへ渡すexact fence payloadを[`cases\u002F0.9.0.md`](.agents\u002Fskills\u002Fmino-core\u002Fevaluations\u002Fcases\u002F0.9.0.md)、runner metadataと期待gateを[`oracles\u002F0.9.0.md`](.agents\u002Fskills\u002Fmino-core\u002Fevaluations\u002Foracles\u002F0.9.0.md)へ分離し、実行済み・未実行を[`Evaluation 0.9.0`](.agents\u002Fskills\u002Fmino-core\u002Fevaluations\u002F0.9.0.md)へ記録します。counted runにはmodel \u002F setting、suite \u002F input \u002F output digest、workspace隔離Evidenceが必要です。資料名だけ、schemaの存在だけ、AIの説明だけでは、判断規則が再現されたEvidenceにしません。\n\n## 使い方\n\n### 発動方法と選択条件\n\nCodexは、起動した作業directoryからrepository rootまでにある`.agents\u002Fskills\u002F`を検出し、利用可能なSkillとして扱います。すべての`SKILL.md`を常時読み込むのではなく、最初は各Skillの`name`、`description`、file pathを使って候補を判断し、使用すると決めたSkillの`SKILL.md`と必要なreferenceだけを読み込みます。\n\nSkillの発動方法は二つあります。\n\n- **暗黙呼び出し**: ユーザーがSkill名を指定しなくても、依頼内容が`SKILL.md`の`description`に記載された適用条件と一致し、`agents\u002Fopenai.yaml`の`allow_implicit_invocation`が`true`なら、CodexがそのSkillを選択できます。これは依頼内容に基づく選択であり、必ず同じSkillが選ばれることを保証するものではありません。\n- **明示呼び出し**: `$mino-problem-framing`のようにSkill名を依頼へ含めます。特定のSkillを必ず使わせたい場合、複数Skillの適用範囲が重なる場合、または`design`、`review`などのmodeも固定したい場合に使います。`allow_implicit_invocation`が`false`でも明示呼び出しは可能です。\n\nこのsuiteの暗黙呼び出し設定は次のとおりです。\n\n| 設定 | 対象Skill | 発動上の扱い |\n|---|---|---|\n| `true` | `mino-problem-framing`、`mino-domain-model-completeness`、`mino-design-by-contract`、`mino-interface-implementation-separation`、`mino-architecture-quality-strategy`、`mino-reproducible-development` | 各Skillの`description`に依頼が一致したとCodexが判断した場合、Skill名の指定なしで選択できる |\n| `false` | `mino-core` | ユーザー依頼から直接は暗黙選択しない。公開入口のFunctionまたはrouterが、共通規則を必要とするときに内部基盤として使う |\n\n暗黙呼び出しでは、次のroutingを基準に必要最小限のSkillだけを選びます。\n\n- Problem FrameまたはContext Packetだけが必要なら、`mino-problem-framing`を使う。\n- model、contract、boundary、architectureのうち単一の専門成果物が必要なら、対応するFunction Skillを使う。\n- 中規模以上の設計・実装・レビューで複数の専門成果物と独立検証を統合する必要があるなら、`mino-reproducible-development`を使う。\n- 問題、公開契約、data meaningが承認済みbaselineとして記録された小規模な機械変更では、このsuiteを発動しない。\n- `mino-core`を単独の専門Skillとして使わず、公開入口のFunctionまたはrouterを選ぶ。\n\n個々のSkillが使われる具体的な場面と非適用範囲は、上の「収録しているSkill」一覧と各`SKILL.md`の`description`が正本です。Codexに選択を任せられますが、使用Skillを再現可能に固定したい依頼では明示呼び出しを使用してください。\n\n### このリポジトリで使う\n\nSkill本体は`.agents\u002Fskills\u002F`に配置されています。このリポジトリを開いたCodexから、依頼内容に応じた暗黙呼び出し、またはSkill名を指定した明示呼び出しができます。\n\nたとえば、次のように依頼します。\n\n```text\n$mino-problem-framing を使って、このRedis導入案を候補手段へ戻し、\n誰の何を改善する問題なのか、前提と成功条件を整理してください。\n```\n\n```text\n$mino-domain-model-completeness を使って、注文確定ユースケースのモデル欠落を監査してください。\n```\n\n```text\n$mino-design-by-contract を使って、この要件を事前条件・事後条件・不変条件・失敗保証・契約テスト仕様へ変換してください。\n```\n\n```text\n$mino-reproducible-development の review mode で、この変更が要件からテストまで追跡できるか監査してください。\n```\n\n### 別のリポジトリまたはユーザー環境で使う\n\n用途に応じて、`.agents\u002Fskills\u002F`直下のSkill directory一式を次の場所へ配置します。\n\n- repository-local（Windows \u002F Linux \u002F macOS共通）: `\u003Ctarget-repository>\u002F.agents\u002Fskills\u002F`\n- user-wide（Windows PowerShell）: `$HOME\\.agents\\skills\\`\n- user-wide（Linux）: `$HOME\u002F.agents\u002Fskills\u002F`\n- user-wide（macOS）: `$HOME\u002F.agents\u002Fskills\u002F`\n\n同名Skillがすでにある場合は上書きせず、先に差分とversionを確認してください。`mino-core`は他のSkillが共有するため、専門Skillだけでなくsuite一式を同じ`skills` rootへ配置するのが基本です。\n\nsuite version、owner、配布対象Skill一覧の正本は[`suite-manifest.txt`](.agents\u002Fskills\u002Fmino-core\u002Fscripts\u002Fsuite-manifest.txt)です。Skill directoryだけを個別に抜き出すのではなく、同じmanifest versionのsuite一式を配置してください。\n\nSkill内の`skills\u002F...`という記述は、実際の保存先名ではなく、インストール済みSkill群の論理的な参照rootです。repository-localとuser-wideのどちらでも動くよう、このpathを`.agents\u002Fskills\u002F...`や絶対pathへ書き換えないでください。\n\n## ディレクトリ構成\n\n```text\n.\n├── AGENTS.md                 # Skill作成・更新を行うagent向けの規則\n├── README.md                 # この利用者向けガイド\n├── .github\u002Fworkflows\u002F\n│   └── validate-suite.yml    # Linux current \u002F Bash 3.2 \u002F native macOS構造検証\n├── mino-doc\u002F                 # 公開資料から整理した調査・設計ノウハウ\n└── .agents\u002Fskills\u002F           # 配布可能なSkill suite\n    ├── mino-core\u002F\n    │   ├── evaluations\u002F\n    │   │   ├── 0.9.0.md             # 現versionのrun結果、未実行事項、残存risk\n    │   │   ├── cases\u002F0.9.0.md       # exact fence bodyとして渡すsolver入力\n    │   │   ├── oracles\u002F0.9.0.md     # runner metadata、input digest、evaluator-only gate\n    │   │   └── fixtures\u002F0.9.0\u002F      # validator parity用のversioned negative fixture\n    │   ├── references\u002Fplatform-compatibility.md\n    │   └── scripts\u002F\n    │       ├── suite-manifest.txt   # version、owner、Skill一覧\n    │       ├── validate-suite.ps1         # Windows\n    │       ├── validate-suite.sh          # Linux \u002F macOS\n    │       ├── validate-utf8.sh           # locale非依存のstrict UTF-8 helper\n    │       ├── test-validator-fixtures.ps1 # Windows validator回帰\n    │       └── test-validator-fixtures.sh  # Linux \u002F macOS validator回帰\n    ├── mino-problem-framing\u002F\n    ├── mino-domain-model-completeness\u002F\n    ├── mino-design-by-contract\u002F\n    ├── mino-interface-implementation-separation\u002F\n    ├── mino-architecture-quality-strategy\u002F\n    └── mino-reproducible-development\u002F\n```\n\n`mino-doc\u002F`はSkillを作るための根拠資料です。完成したSkillは`mino-doc\u002F`を実行時に読まず、インストールされた`skills\u002F` directory内のファイルだけで完結します。この制約により、元リポジトリを伴わずにSkillだけを配布できます。\n\n調査資料の目的、対象範囲、基準日、文書一覧は[`mino-doc\u002FREADME.md`](mino-doc\u002FREADME.md)を参照してください。\n\n## Skillを作成・更新する\n\n1. `mino-doc\u002FREADME.md`と対象テーマの資料を読み、公開資料にある主張と、Skill化のための操作的解釈を区別します。\n2. 既存の`mino-core`と専門Skillを確認し、新しい規則がCore、Function、router、reference、adapter、evaluationのどこに属するか決めます。\n3. 適用条件、非適用条件、必要入力、判断順、成果物、拒否条件、完了条件、target platformへ変換します。\n4. 実行時に必要な内容を対象Skillまたは`mino-core`へ同梱し、内部参照を`skills\u002F\u003Cskill-name>\u002F...`へ統一します。\n5. OS差分を共通contractのplatform adapterとして分離し、各Skillからplatform compatibility referenceをroutingします。\n6. 判断規則の意味を変えた場合は、solver caseとevaluator-only oracleをversioned artifactとして分離し、fresh contextで回帰を確認します。\n7. Windows \u002F Linux \u002F macOSのapplicableな構造validatorと、対象に必要なruntime testを実行し、未実行事項をevaluationへ残します。\n\nSkillを更新するagentが守る詳細規則は[`AGENTS.md`](AGENTS.md)にあります。\n\n## 検証レベルと現在の状態\n\nこのrepositoryでは、Skillの「読み込めること」と「期待する判断を安定して返すこと」を分けて判定します。`behavioral release`は一般規格名ではなく、このsuiteのversion判定に使うrepository内の用語です。\n\n| 検証レベル | 確認すること | 0.9.0の状態 |\n|---|---|---|\n| structural validation | package、front matter、metadata、内部参照、UTF-8 \u002F LF、Linux \u002F macOS BashとPowerShell runtime | Linux Bash 5.3 \u002F 3.2.57とWSL UNC上のPowerShellはpass。native macOSはvalidator pass、fixture runner fail（run `29397674053`、exit `2`）。native Windows checkout \u002F NTFSは未実行 |\n| targeted behavioral evidence | 代表的なforward testで、問題定義、Evidence、過剰抽象化拒否、status分離が働くか | not executed。C1〜C15のprovenance付きfresh runは0件 |\n| behavioral release | versioned case \u002F oracle、最低3 fresh-context run、代表・negative case、過去回帰、required platformの全Release gate | not ready |\n| application runtime correctness | Skillを適用した対象applicationのtest、failure injection、migration rehearsal、実platform動作 | 対象applicationごとに別途検証 |\n\nplatform Evidenceを一つの「cross-platform対応済み」へまとめません。現在の確認状況はruntimeとfilesystemの層ごとに記録します。\n\n| Platform evidence | 0.9.0の状態 |\n|---|---|\n| Linux current Bash validator on WSL Linux filesystem | pass。UTF-8 backend self-testとBash fixture 40 \u002F 40を含む |\n| Linux Bash 3.2 validator | pass。Docker Official Image `bash:3.2.57`のLinux rootfsでvalidatorとBash fixture 40 \u002F 40を実行。native macOS Evidenceではない |\n| Windows PowerShell 5.1 validator over the same WSL UNC artifact | pass。PowerShell fixture 37 \u002F 37。PowerShell compatibilityの確認であり、native NTFS Evidenceではない |\n| Native Windows checkout \u002F NTFS validator and fixture runner | not executed |\n| Native macOS `\u002Fbin\u002Fbash` validator and fixture runner | executed \u002F fail。run `29397674053`、job `87294760529`、macOS 15.7.7、image `macos-15-arm64` `20260706.0213.1`、ARM64。validatorはpass、fixture runnerは`solver-nested-metadata`でexit `2` |\n| Application runtime with the same requirement \u002F contract \u002F oracle on required platforms | not executed |\n\n構造validatorのpassだけでbehavioral releaseや対象applicationの正しさを宣言しません。一部caseのpassはその範囲のEvidenceですが、全体の代用にはしません。0.9.0の実行結果、未実行事項、残存riskは[`Evaluation 0.9.0`](.agents\u002Fskills\u002Fmino-core\u002Fevaluations\u002F0.9.0.md)、全release条件は[`Reproducibility benchmark`](.agents\u002Fskills\u002Fmino-core\u002Freferences\u002Fbenchmark.md#release-gate)を参照してください。\n\n### Windowsで構造を検証する\n\nWindows PowerShellでは、repository rootから次を実行します。\n\n```powershell\npowershell.exe -NoProfile -ExecutionPolicy Bypass -File .agents\\skills\\mino-core\\scripts\\validate-suite.ps1 -SkillsRoot .agents\\skills\n```\n\nPowerShell 7を利用する場合は次を実行します。\n\n```powershell\npwsh -NoProfile -ExecutionPolicy Bypass -File .agents\u002Fskills\u002Fmino-core\u002Fscripts\u002Fvalidate-suite.ps1 -SkillsRoot .agents\u002Fskills\n```\n\n### Linuxで構造を検証する\n\nrepository rootから次を実行します。実行権限の有無に依存しないよう、Bashを明示します。shared `.sh` contractの最小runtimeはBash 3.2です。\n\n```bash\nbash .agents\u002Fskills\u002Fmino-core\u002Fscripts\u002Fvalidate-suite.sh --skills-root .agents\u002Fskills\n```\n\n### macOSで構造を検証する\n\nrepository rootから標準`\u002Fbin\u002Fbash`を明示して実行します。Homebrew等の別BashをPATHから選び直しません。\n\n```bash\n\u002Fbin\u002Fbash .agents\u002Fskills\u002Fmino-core\u002Fscripts\u002Fvalidate-suite.sh --skills-root .agents\u002Fskills\n\u002Fbin\u002Fbash .agents\u002Fskills\u002Fmino-core\u002Fscripts\u002Ftest-validator-fixtures.sh --skills-root .agents\u002Fskills\n```\n\nmacOSで必要な外部commandは、標準環境にある`awk`、`od`、`mktemp`、`find`、`grep`、`sed`、`sort`、`tail`、`tr`、`wc`です。strict UTF-8判定は同梱helperでbyte列を検査し、`iconv`実装名やUTF-8 locale名へ依存しません。\n\nCIは[`.github\u002Fworkflows\u002Fvalidate-suite.yml`](.github\u002Fworkflows\u002Fvalidate-suite.yml)で、Linux current Bash、Docker Official ImageのBash 3.2.57、native macOSの標準`\u002Fbin\u002Fbash`を別jobとして定義しています。validatorとfixture runnerも別named stepで実行します。run `29397674053`のnative macOS failureをpassへ読み替えず、修正後headのgreen rerunを新しいEvidenceとして記録します。\n\nvalidatorは、主に次を確認します。詳細検査とtext-format検査はmanifest記載Skillに限定し、同じrootへインストールされた無関係なSkillは無視します。一方、manifestにない`mino-*` Skillはsuiteの登録漏れとして報告します。\n\n- manifestに記録したversion、owner、Skill一覧と、実際のSkill directoryが一致すること。\n- manifestのscalarが一意、versionがleading zeroなしの3-part SemVer、Skill名が一意かつSkillsRoot直下であること。\n- manifest versionに対応するsolver case、evaluator oracle、evaluation recordのheadingとbenchmark参照が一致し、solver caseのtop-level fieldがallowlist内であること。\n- suiteを構成するSkillと必須section・fileが揃っていること。\n- required headingと100行超referenceの`## Contents`が末尾空白なしの完全一致であること。\n- front matterがexact delimiterと`name` \u002F `description`一意性を満たし、directory名と一致すること。\n- agent metadataが所定の階層とfieldだけを持ち、default prompt内のSkill名、implicit invocation policyが整合すること。\n- 内部pathが`skills\u002F`をrootとし、bare filename、absolute path、親参照、SkillsRoot外参照がないこと。\n- `$\u003Cskill-name>`によるSkill間参照が解決できること。\n- 全Skillがplatform compatibility referenceをroutingしていること。\n- Windows用PowerShell validatorとLinux \u002F macOS共用Bash validator、strict UTF-8 helperが同梱されていること。\n- Skill directoryが配布に不要なREADMEへ依存していないこと。\n- suite内のtext fileがUTF-8（BOMなし）、LF、final newlineありであること。\n\nvalidator自体を変更した場合は、通常の構造検証に加えて次の共通fixtureを実行します。\n\n```powershell\npowershell.exe -NoProfile -ExecutionPolicy Bypass -File .agents\\skills\\mino-core\\scripts\\test-validator-fixtures.ps1 -SkillsRoot .agents\\skills\n```\n\n```bash\nbash .agents\u002Fskills\u002Fmino-core\u002Fscripts\u002Ftest-validator-fixtures.sh --skills-root .agents\u002Fskills\n```\n\n構造validatorの合格は、対象アプリケーションがrequired platformで正しく動作する証明ではありません。application runtime対応を完了とするには、同じrequirementとcontract testを各required platformで実行します。\n\n## 大切にしていること\n\n- **人物模倣ではなく判断規則**: 誰かの口調ではなく、入力、根拠、判断、成果物、検証可能性を保存します。\n- **必要なSkillだけを使う**: すべての観点を毎回適用せず、依頼とriskに合う最小のFunctionを選びます。\n- **事実と推論を分ける**: 確認済み事実、解釈、仮定、unknown、矛盾を隠しません。\n- **人間の判断を残す**: product value、業務上の正しさ、公開契約、不可逆なtrade-off、release可否は自動決定しません。\n- **持ち運べること**: 完成Skillは`skills\u002F`の外を参照せず、repository-localとuser-wideの両方で利用できます。\n- **OS差を閉じ込めること**: Windows \u002F Linux \u002F macOSで同じcontractを保ち、path、shell、filesystem、processの差だけをimplementationへ隔離します。\n\nこのsuiteは設計判断を支援する道具であり、対象domainの専門家や、変更を承認する人の責任を代替するものではありません。\n","这是一个基于日本开发者ミノ駆動（Mino Drive）公开设计资料构建的、面向软件工程设计决策的可复用技能集（AI Skill Suite）。项目将设计原则结构化为可验证、可组合的Shell脚本化工作流，涵盖问题建模、契约式设计、领域模型完整性检查、接口与实现分离等核心能力，并内置schema校验、gate控制、版本管理与跨平台验证机制。适用于需要在系统设计阶段提升判断一致性、保障设计可验证性与可追溯性的中大型软件开发团队，尤其适合强调设计质量、架构治理与工程规范落地的技术组织。当前处于实验性预发布阶段，支持Linux\u002FWSL及PowerShell环境，macOS原生Bash兼容性仍在完善中。","2026-07-16 02:30:07","CREATED_QUERY"]