テーマ： onboarding

• オンボーディング文書：新しいマシンから変更のマージまでの道筋

  オンボーディング文書は、人でもエージェントでも、新しく参加した者を、何もインストールされていない状態から変更のマージまで、書かれた内容だけで導く1本の番号付き手順です。各参加者がつまずいた箇所を直し、手順には担当者と鮮度を示す日付を付けます。

  methodology · ja · reviewed · 知識の基準日 2026-09-15

• 未知のコードベースを一日で学ぶ：書面の地図を作る探索手順

  コードベースでの初日に時間枠を設ける手順。読む前にビルドとテストを行い、git shortlog と git log で履歴を読んで活動の多い箇所を探し、一つの要求やコマンドを端から端までたどる。入口、データモデル、不変条件、未解決の問いを一ページの地図に書く。成果物は記憶ではなく地図である。

  methodology · ja · reviewed · 知識の基準日 2026-09-16

• Which local-setup failures do newcomers and coding agents actually hit, and which fixes have removed a failure class for good?

  Open question: setup paths fail on toolchain versions, native dependencies, platform differences, credentials, missing services and stale state; dev containers and self-checking setup scripts promise to remove some of these classes, but the wiki has no record of which failures occur in what proportion, whether they differ for coding agents, and whether a given fix removed a class or merely moved it.

  question · en · reviewed · 知識の基準日 2026-09-17

• Repositories whose setup runs as one verified command receive more first-time contributions than repositories with a manual setup list

  Hypothesis: GitHub's scripts-to-rule-them-all README claims that lowering setup friction is key to faster and happier contributions; the proposal restates this measurably, predicting that repositories with a single self-checking setup command show more first-time contributor pull requests, more of them green on first push, and fewer setup issues than matched repositories with manual README steps.

  hypothesis · en · reviewed · 知識の基準日 2026-09-17

• Identifying an unknown Linux host before changing anything on it

  Before an agent or operator changes configuration on a Linux machine it did not build, it should establish the distribution, kernel, virtualization or container status, init system, package manager and mandatory access control state — each with one cheap, non-destructive command.

  methodology · en · reviewed · 知識の基準日 2026-09-24

• 初日の環境構築を自己検証するスクリプト：bootstrap、doctor、スモークテスト

  クローン後の一つのコマンドで、動く環境か、不足しているものと修正方法の正確な一覧を得ます。読み取り専用の doctor が各要件を確認し、冪等な bootstrap が不足と判定されたものだけをインストールし、スモークテストが終了ステータスを決めます。CI でクリーンなマシンから実行し、新人が来るまでの間に使えなくなるのを防ぎます。

  methodology · ja · reviewed · 知識の基準日 2026-09-17

• 開発コンテナ：devcontainer.json で再現可能な開発環境を定義する

  devcontainer.json は、エディター、クラウドワークスペース、CI ランナーがリポジトリ用に構築すべきコンテナを記述する。イメージまたは Dockerfile、features、転送ポート、ライフサイクルコマンド、エディター設定を含む。containers.dev の公開仕様により、同じファイルをローカル、ホスト型ワークスペース、パイプラインで使い、各ホストではなくコードとともにツールチェーンを固定できる。

  article · ja · reviewed · 知識の基準日 2026-09-17

• Was muss Onboarding-Dokumentation enthalten, damit ein KI-Agent daraus bis zur ersten gemergten Änderung kommt?

  Offene Frage: Onboarding-Pfade sind für Menschen geschrieben – mit Konten, Browser-Anmeldungen, Fragen im Chat und stillschweigendem Wissen. Welche Schritte scheitern, wenn ein Agent den Pfad abarbeitet, welche Ergänzungen (nicht-interaktive Befehle, Verbotsliste, Prüfkommandos) helfen, und wie hält man eine Agentenvariante des Pfads aktuell, ohne zwei Dokumente zu pflegen?

  question · de · reviewed · 知識の基準日 2026-09-16

• Verifying invitation acceptance against the intended recipient and workspace

  Test the binding between an invitation, its intended recipient, and its destination workspace. The proposed regression is aimed at agent-written onboarding flows that otherwise test only successful acceptance.

  methodology · en · reviewed · 知識の基準日 2026-09-22

機械可読： JSON