前回までのあらすじ

自作PCを作ろう！
まずメモリを作ったよ！
ISAを作ったよ！
アセンブリ言語を作ったよ！
CPUを作ったよ！
任意のプログラムを実行できるようになったよ！
キーボード入力を受け付けられるようになったよ！(ただし独力ではない)
複数桁+複数桁の足し算が行えるようになったよ！
CALL命令とRET命令を実装して，関数呼び出しが可能になったよ！
自作CPU上で動作する自作プログラミング言語をコンパイルするコンパイラを作ったよ！
上記コンパイラで，プログラミング言語から機械語への一気通貫が可能になったよ！

今回の目標

前回の記事で説明した通り，プロジェクトの数が増えてきたのでちゃんとgit管理するようにします．

ここから本題

ghを導入しよう

gitコマンドはインストール済みでしたが，ghはありませんでした．という事で導入しました．

@rem コマンドインストール
winget install --id GitHub.cli
@rem 認証設定
git auth login
@rem 認証情報確認
git auth stath

組織を作ろう

今回，コンパイラやアセンブラなど複数のリポジトリを作ります．
そのため，それらをひとまとめにする組織を作成することにしました．
それにあたって，このプロジェクト全体の名前と，プログラミング言語などその中で使用する各プロジェクトの名前も決定しました．

このプロジェクト全体，つまりPCの名前: Pynthesis (ピンセシス．Pynqと，「組み上げる」みたいな意味のギリシャ語を組み合わせた造語)
CPUやメモリ，ROMなどハードウェアをひっくるめた名前: Qurge (クージ．Pynqと，ギリシャ語で「自分の技術を使用して材料から物を作り上げる職人を意味するDemiurgeを組み合わせた造語)
アセンブリ言語の名前: Pyntaxis (ピンタクシス．Pynqと，順序だてて並べるという意味のギリシャ語を組み合わせた造語)
プログラミング言語の名前: Pynesis (ピネシス．Pynqと，「まだないものを生み出す行為」みたいな意味のギリシャ語を組み合わせた造語)

余談ですが，名前の変更に合わせて拡張子も変更になります．

アセンブリ言語: .asm → .pt　※PyTorchのモデルファイルの拡張子と被ってますが，気にしない気にしない
プログラミング言語: .c → .pn

てなわけでまずは，名前pynthesisで組織を作ります．
これはAPIが対応していないので，ローカルからコマンドで実行とはいきません．
Webブラウザ上で操作します．詳しいやり方はググってください(無責任)．

ところが，僕はなんかこれが上手く行かなかったのでGitHubに問い合わせ．
その間にリポジトリを作って，あとで組織に移動させることにしました．

リポジトリを作ろう

コミットのためお馴染みのあのコマンドを打ちます．

git init
git add -A
git commit -m "コメント"

あとはリポジトリを作るだけ．

gh repo create (リポジトリ名) --private --source=. --remote=origin --push

リポジトリを組織に移動させよう

なかなか対応してもらえないので飛ばしますね．

issueを作ろう

こんな感じで作るみたいです

gh issue create --title "タイトル" --body "本文"

issueに対応しよう

以下のコマンドを使用してissueの情報を取得します．

@rem issue一覧を取得する
gh issue list --repo "リポジトリ名" --state all
@rem issue詳細を取得する
gh issue view (issueの番号) --repo "リポジトリ名"

issueに対応したブランチを切ります．

@rem ブランチを切り，そのブランチに切り替える
git checkout -b "ブランチ名"

実際の修正を行います．

コミットとプッシュを行います．

@rem addする
git add "変更ファイル"
@rem コミットする
@rem コミットメッセージに`Closes "ユーザー名/リポジトリ名/#issueの番号"`を記載することで，このコミットを含むブランチがマージされたらissueが自動で閉じる
git commit -m "コメント"
@rem プッシュする
git push -u origin "ブランチ名"

プルリクエストを作成します．

@rem プルリクエストを作成．この本文にも`Closes "ユーザー名/リポジトリ名/#issueの番号"`を書いていい
@rem 一つのissueに対して複数のPRが対応する場合，issueのcloseを担当させたいPR以外では`Related to "ユーザー名/リポジトリ名/#issueの番号"`を記載
gh pr create --title "タイトル" --body "本文"

プルリクエストをマージします．
これはコマンドでも行えますが，差分を目で見て最終確認するという意味でもブラウザで行った方がいいと思います．

ローカルブランチを削除します．
マージ時点でリモートブランチは自動削除することができますが，もう不要になったローカルブランチが残っているので削除しておきます．

@rem 別のブランチに移動しておく
git checkout "ブランチ名"
@rem 不要になったローカルブランチ削除
git branch -d "ブランチ名"
@rem マージ時点でリモートブランチの自動削除を忘れていた場合
git push origin --delete "ブランチ名"
@rem マージ時点でリモートブランチの自動削除をオンにする設定
gh api repos/"リポジトリ名" -X PATCH -f delete_branch_on_merge=ture --jq .delete_branch_on_merge

MCPサーバ登録しよう

GitHubにはMCPサーバがあるようなので，コマンドじゃなくてそっち使った方がいいですね．

まず，GitHubの設定画面からトークン発行します．
あとは以下のような感じで設定するだけです．

.env

GITHUB_PERSONAL_ACCESS_TOKEN="発行したトークン"

.mcp.json

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-github"
      ],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_PERSONAL_ACCESS_TOKEN}"
      }
    }
  }
}

ただ使ってみた感じ微妙かもです．
実行許可を求められる時に，改行が\nになって全部一行で表示されるので非常に見づらい．
コマンドだったらEOFを使って複数行で表示してくれるんですけどね．

これを仕組化しよう

せっかくなので，これを仕組化しましょう．
issueの作成と対応をそれぞれSkillにしました．

issue-create

---
name: issue-create
description: 課題や要望をGitHub issueとして起票する。「issue作って」「〜についてissue化して」で起動。
---

課題や要望を，GitHub issueとして起票する．この時点ではソース調査は行わない (調査はissue対応時に行う)．

## 手順

1. issueにしたい内容を話し合い詳細にする
2. タイトルと本文をドラフトする．タイトルは，追加してほしい機能または発生している不具合の概要が分かるような文章にする．本文には以下を含める
   - 課題: 修正を依頼する動機．機能追加なら，追加したい機能がない現状，不便・不満に感じている事．不具合なら発生している事象
   - ゴール: 上記課題を解決して実現したいこと．機能追加なら，具体的にどのような機能が欲しいのか．不具合なら理想の動作
   - 補足: 何かあれば．不具合の場合，再現条件を明示する必要があるならここに記載
3. 対象リポジトリを判定する
   - 内容が単一リポジトリに閉じるなら，そのリポジトリにissueを作成する
   - 複数リポジトリにまたがる可能性がある場合は，1つのissueで複数リポジトリをまとめて扱うか，リポジトリごとに分けるかをユーザーに確認する
4. ドラフトをユーザーに提示し，承認を得てから作成する (GitHub上に公開される操作のため，作成前に必ず確認する) 
5. `gh issue create --repo <owner>/<repo> --title "<タイトル>" --body "<本文>"` で作成する
6. 作成したissueのURLをユーザーに報告する

## 注意

- issue本文は日本語で記述し，句読点は「，」「．」を使う
- 事実 (確認済みの挙動・再現手順など) と推測 (未検証の仮説) を区別して書く．推測は「〜と思われる」「〜ではないか」のように，推測であることが分かる書き方にする
- 未承認のまま`gh issue create`を実行しない

issue-resolve

---
name: issue-resolve
description: GitHub issueに対応する。1issue=1回の実行で，複数リポジトリにまたがる修正もスキル内部で完結させる。「issue #Nに対応して」で起動。
---

GitHub issueへの対応 (調査・ブランチ作成・修正・PR作成) を行う．粒度は1issue=1回の実行．対応が複数リポジトリにまたがる場合も，このスキル内で完結させる．

## 手順

1. issue内容を取得する
   ```
   gh issue view <番号> --repo <owner>/<repo>
   ```
2. 原因調査を行い，影響範囲 (対象リポジトリ・対象ファイル) を特定する．issue本文中に推測が書かれている場合は，事実かどうかをここで検証する
3. 調査結果と修正方針をユーザーに提示し，承認を得る (実装前に必ず説明する)
4. 影響リポジトリごとに以下を行う
   1. デフォルトブランチを最新化する
      ```
      git checkout <デフォルトブランチ>
      git pull
      ```
   2. ブランチを作成する (命名: `fix/issue-<番号>-<内容を表す短い語句>`)
      ```
      git checkout -b fix/issue-<番号>-<内容を表す短い語句>
      ```
   3. 修正を行う (ユーザーの承認を得てから実施する)
   4. コミットしてpushし，Draft状態のPRを作成する
      ```
      git add <変更したファイル>
      git commit -m "<コミットメッセージ>"
      git push -u origin fix/issue-<番号>-<内容を表す短い語句>
      gh pr create --repo <owner>/<repo> --draft --title "<タイトル>" --body "<本文>"
      ```
   5. ソースレビューを行い，指摘があれば修正してコミット・pushする．レビューと修正は1回で終わるとは限らず，このコミット・push は複数回繰り返してよい
      ```
      claude -p --tools "Read,Grep,Glob" -- "コードレビューを依頼する文言" > review.md
      ```
      ```
      git add <変更したファイル>
      git commit -m "<コミットメッセージ>"
      git push
      ```
   6. レビューで問題がなくなったら，Draftを解除する
      ```
      gh pr ready <PR番号> --repo <owner>/<repo>
      ```
   7. closeキーワード (`Closes owner/repo#番号`) は1箇所のPRのみに付与する．issueが存在するリポジトリのPR，またはユーザーが指定したPRに付与する (PR作成時の`--body`，またはマージ前に`gh pr edit <PR番号> --repo <owner>/<repo> --body "<本文>"`で追記する)
   8. それ以外のリポジトリのPRは `Related to owner/repo#番号` のみを記載し，closeキーワードは使わない
5. マージはユーザー自身が行う (共有状態を変更する操作のため，スキルは代行しない)
6. マージ完了の報告を受けたら，issueがクローズされたことを確認し，各リポジトリのローカルを最新化してローカルブランチを削除する
   ```
   gh issue view <番号> --repo <owner>/<repo>
   git checkout <デフォルトブランチ>
   git pull
   git branch -d fix/issue-<番号>-<内容を表す短い語句>
   ```

## 注意

- 1issueに対して複数のPRがある場合，closeキーワードを持つPRは1つだけにする
- 影響リポジトリが不明な場合は，ユーザーに確認する
- ブランチ作成・コミット・push・PR作成は実行前に都度確認する必要はないが，破壊的操作 (force push，reset --hard等) とマージは必ずユーザーに確認する

今後の展望

さて，これでやっと開発環境が整いましたので，やっっっとOS作成に入れますね！！