2. The Core Task Route

Postman runs as a resident daemon in a tmux pane:

tmux-a2a-postman start

A trimmed and anonymized view looks like this. The project names are synthetic, but the emoji/status-marker style follows the current daemon output:

tmux-a2a-postman git-b2c8283   [up/down:move] [p:ping] [q:quit]

[sessions]
  ⚫ [0] shell
> 🟡 [1] article-edit
  🟢 [2] docs-review
  🔷 [3] runtime-workbench

[nodes]
messenger     🟡  waiting
orchestrator  🔷  pending
worker        🟢  ready
guardian      🟢  ready
critic        🟢  ready
boss          🟢  ready

The important part is not the dashboard itself. Once a task is handed off, postman keeps the route and reply obligation outside terminal scrollback: messenger to orchestrator to worker to reviewer to messenger can be a Markdown-defined path instead of a human remembering which pane should answer next. Agent Skills add local operating rules for each role when they materially help.

The compact heartbeat is deliberately dense:

[0]⚫ [1]🟡:🟡🔷🟢🟢🟢🟢 [2]🟢:🟢🟢🟢🟢🟢🟢 [3]🔷:🔷🟢🟢🟢🟢🟢

I use get-status for full inspection and get-status-oneline for a status-bar-sized heartbeat. This is the concrete value: I can see that mail is moving, a reply is still open, or a role is waiting without treating the agent panes as the source of truth.

The README quick start is still the right place for installation and command details. The article-level point is smaller: postman turns terminal-agent handoffs into visible local state.

3. What It Is

tmux-a2a-postman is a local mailbox and coordination layer for terminal agents, implemented on top of tmux.

It does not create the model, write the code, isolate a container, or decide a workflow by itself. It delivers Markdown messages between role-labeled terminal panes, records unread and read mail, tracks reply-required obligations, and exposes status.

The value spine is simple: turn “I told that agent something” into “there is a Markdown mail item with a sender, receiver, inbox/read state, and an exact reply slot when one is required.”

This is not internal agent memory. It does not make an agent remember everything. It makes pending work, delivered mail, unread/read state, reply obligations, and delivery evidence visible as local state.

For larger investigation notes, I use a separate Markdown artifact workflow such as mkmd. The two fit well together, but they are not the same layer.

4. postman.md as the Control Surface

The center of the setup is postman.md.

It is a Markdown file that humans can review and agents can read. It can contain the team topology, role instructions, shared rules, and Agent Skills catalog references.

This is the part I usually want outside a native model feature. A runtime may provide its own subagents or task tools, but postman.md is a local Markdown contract I can review in Git and apply across terminal tools. Behavior changes by editing Markdown, not by writing framework code; that keeps orchestration readable, versionable, and easy for an AI agent to patch in a normal diff.

A compact synthetic postman.md can show the moving parts without exposing private workflow details:

postman.md

---
skill_path:
  - path: ~/.codex/skills
    inject: ping
    skills:
      - postman-session-operator
      - postman-send-message
---

## `edges`

```mermaid
graph LR
    messenger --- orchestrator
    orchestrator --- worker
    orchestrator --- reviewer
    class messenger ui_node
    classDef ui_node fill:#e0f2fe
```

## `common_template`

Use postman mail for handoffs. Required work ends with DONE or BLOCKED and evidence.

## `orchestrator`

### `role`

Coordinator. Delegate implementation to `worker` and request review from `reviewer`.

## `worker`

### `role`

Implementation role. Reply with changed files, validation, and blockers.

## `reviewer`

### `role`

Review role. Return evidence-backed APPROVED or NOT APPROVED.

Rendered, the same edges section is intentionally small:

graph LR
    messenger["messenger"]
    orchestrator["orchestrator"]
    worker["worker"]
    reviewer["reviewer"]

    messenger --- orchestrator
    orchestrator --- worker
    orchestrator --- reviewer

    class messenger entry
    class orchestrator,worker,reviewer role
    classDef entry fill:#dbeafe,stroke:#2563eb,color:#0f172a
    classDef role fill:#f8fafc,stroke:#64748b,color:#0f172a

The diagram is not decoration. The node names and --- edges define which roles may talk to each other. With inject: ping, the skill_path block injects a compact Agent Skills catalog into recurring daemon PING role content, while the role sections keep the review loop and reply expectations local to Markdown. Postman only treats a small parsed subset as routing and Agent Skills catalog data; the rest stays useful as human-readable role context.

Each received mail item carries the relevant postman.md instructions with the request: role context, routing expectations, reply shape, and available Agent Skills when configured. That matters over longer tasks because the receiving agent can re-read its local contract instead of relying on nearby pane history.

A review loop can then stay in mail instead of terminal scrollback:

messenger -> orchestrator: tighten the article and validate it

orchestrator -> worker: make the scoped edit

worker -> orchestrator: DONE with changed files and checks

orchestrator -> reviewer: verify before user-facing completion

reviewer -> orchestrator: APPROVED or NOT APPROVED with evidence

This block is not displayed by tmux-a2a-postman’s TUI. It is a compact example of Markdown mail handoff and reply shape.

That does not make the result correct by itself. It makes three kinds of forgetting harder: role drift, dropped reply-required loops, and forgotten local capabilities. postman.md carries role and routing expectations with the mail, reply-required keeps open loops visible, and the Agent Skills catalog gives the receiver compact names and descriptions for local capabilities it can choose when needed.

The full SKILL.md body stays out of the prompt until the task actually needs it. The catalog is a reminder to use known local behavior before improvising.

5. The Mail Handoff Agents Can Operate

The mail handoff is intentionally small: one role sends Markdown mail, the receiver claims it, reads the archived body, and answers required requests with DONE or BLOCKED plus evidence.

tmux-a2a-postman’s own Agent Skills make the handoff operational: sender roles learn the heredoc send path; receiver roles learn that archived mail must be read, required replies must close exact input requests, and blocked or delivery failures must be reported. postman-config-auditor covers topology and config checks when routes or role definitions need review.

This closes transport state, not truth. A DONE reply still needs evidence. A reviewer, orchestrator, or human can inspect changed files, test output, and the task artifact before accepting the result.

6. Why tmux-Native

Postman is intentionally tmux-native today. That is an implementation choice, not the reader identity.

It uses tmux-specific surfaces: session, window, and pane discovery; operator-controlled pane titles as role labels and routing keys; tmux input delivery; pane capture for bounded activity evidence; and tmux pane metadata.

Those are implementation facts, not universal claims about terminal tools. The portable ideas are shell-first operation, local filesystem mail, human-reviewable Markdown contracts, heterogeneous CLI agents side by side, and visible handoff state.

So the comparison I care about is category-level:

Postman lives in the last row and currently runs on tmux.

7. Boundaries and Composition

tmux-a2a-postman is not an AI coding agent, a full multi-agent framework, a workflow engine, a sandbox, an MCP server, an A2A-compliant server, or a replacement for Claude Code, Codex CLI, tmux, or vde-layout.

The name uses a2a in the agent-to-agent handoff sense and borrows useful A2A-style vocabulary for messages, contexts, artifacts, and input-required states. It is not currently a standards-compliant A2A endpoint.

I use native subagents or team features for work inside one runtime, tmux for the workbench, vde-layout for repeatable pane creation, Agent Skills or local instructions for role behavior, mkmd for larger task artifacts, and postman for handoffs between terminal roles and tools.

Each layer can be replaced or improved without pretending one tool should own everything. The transport cares about pane titles, shell commands, and local mail files, not a specific model vendor or agent API. Claude Code, Codex CLI, Gemini CLI, OpenCode, or another terminal agent can sit behind the same role name as long as it can read mail, act, and reply.

8. Summary

Terminal agents can already think, edit, run commands, and sometimes delegate to native subagents or team features. Keep those capabilities.

The missing piece is the local handoff layer: who may talk to whom, what was delivered, what remains unread, who owes a reply, and what evidence remains when delivery or task completion needs inspection.

tmux-a2a-postman is a mailbox, not a brain. It is a receipt layer, not a proof of correctness. It is Markdown-forward, not attachment-based. It is tmux-native today, while the core idea is portable: local agents work better when handoffs are explicit, reviewable, and recoverable.

2. Why tmux

For this workflow, tmux is useful because it gives long-lived terminal surfaces that can be controlled from the outside.

The important pieces are:

A pane title is not a permanent identity guarantee. It is an operator-controlled label that helps humans and scripts route attention. The stable part of the workflow comes from combining tmux’s process model with explicit configuration and checks, not from pretending that a title can never change.

tmux is not the only possible terminal substrate. Zellij, editor-integrated terminals, and AI-first editor environments all have strong workflows. My point here is narrower: tmux exposes a mature local model of sessions, windows, panes, pane titles, input commands, and pane capture. That makes it a practical substrate for shell-first agent work today.

3. The Minimum tmux Model

The mental model is close to a browser:

I keep one tmux session per project. Inside that session, I can have a main work window, a review window, or a monitoring window. Inside each window, each pane owns one long-lived process.

That sounds simple, but it matters for CLI agents. A pane can keep a conversation alive while I inspect another pane. A session can detach and survive terminal restarts. A window can group related roles without mixing every process into one crowded screen.

The goal is not to make tmux fancy. The goal is to give agents stable places to run.

4. A Few tmux Settings That Matter

I try to reduce prefix-heavy operations because multi-pane work requires frequent movement.

For window and session movement:

~/.config/tmux/tmux.conf

bind-key -n M-Left previous-window
bind-key -n M-Right next-window
bind-key -n M-Up switch-client -p
bind-key -n M-Down switch-client -n

For pane movement:

~/.config/tmux/tmux.conf

bind-key -n S-Left select-pane -L
bind-key -n S-Right select-pane -R
bind-key -n S-Up select-pane -U
bind-key -n S-Down select-pane -D

On macOS, M- is usually Option. On Linux, it is usually Alt.

I also inherit the current directory when opening new panes or windows:

~/.config/tmux/tmux.conf

bind-key % split-window -h -c "#{pane_current_path}"
bind-key '"' split-window -v -c "#{pane_current_path}"
bind-key c new-window -c "#{pane_current_path}"

And I use popup windows for quick checks:

~/.config/tmux/tmux.conf

bind-key u display-popup -d '#{pane_current_path}' -w 90% -h 90% -E
bind-key g display-popup -d '#{pane_current_path}' -w 90% -h 90% -E 'lazygit'

The popup is useful when an agent is working and I want to inspect Git state without disturbing the main pane layout.

These settings are not the center of the workflow. They just make the workbench pleasant enough to use all day.

5. vde-layout Is the Floor Plan

vde-layout is a tmux layout tool by yuki-yano. You define panes and windows in YAML, then run one command to materialize them.

Repository: https://github.com/yuki-yano/vde-layout

This is the turning point. Instead of remembering tmux split commands, I define the workspace once:

~/.config/vde/layout.yml

presets:
  main:
    name: main
    description: editor plus one worker
    windowMode: current-window
    layout:
      type: horizontal
      ratio: [1, 1]
      panes:
        - name: editor
          command: vim
          focus: true
        - name: worker
          command: claude

Then I run:

vde-layout main

That creates two panes: an editor and a worker agent.

The exact command is replaceable. Use codex, gemini, opencode, a plain shell, or any other long-running CLI process. The important part is that the physical workspace shape is now declared in a file.

6. Scaling Beyond Two Panes

Two panes are enough to show the idea, but the same model scales to a small local agent team.

For example:

~/.config/vde/layout.yml

presets:
  concierge:
    name: concierge
    description: editor and user-facing shell
    windowMode: current-window
    layout:
      type: horizontal
      ratio: [1, 1]
      panes:
        - name: editor
          command: vim
          focus: true
        - name: messenger
          command: codex

  builders:
    name: builders
    description: implementation agents
    windowMode: new-window
    layout:
      type: horizontal
      ratio: [1, 1]
      panes:
        - name: worker
          command: codex
        - name: worker-alt
          command: claude

  review:
    name: review
    description: review and final decision
    windowMode: new-window
    layout:
      type: horizontal
      ratio: [1, 1]
      panes:
        - name: reviewer
          command: claude
        - name: shell
          command: bash

Then:

vde-layout concierge
vde-layout builders
vde-layout review

Only the first preset uses current-window. The later presets use new-window, so one command sequence can build a multi-window workspace.

The names in this YAML are role labels for the human operator. They make the workspace legible. They also become useful later when a coordination layer needs to address a pane by role.

7. Short Commands Help

I do not want to type three long vde-layout commands every time.

I use shell snippets for that. With zeno.zsh, a short keyword can expand into the full command sequence.

Repository: https://github.com/yuki-yano/zeno.zsh

For example:

~/.config/zeno/config.yaml

snippets:
  - name: (vde-layout) agent workspace
    keyword: va
    snippet: vde-layout concierge && vde-layout builders && vde-layout review

Now va can expand into the complete layout command.

This is optional. A shell alias, an abbreviation, a Make target, or a small script would also work. The principle is the same: the workspace is defined in text and recreated with a short command.

8. Session Names Matter

When multiple projects are open, tmux session names become part of the operator interface.

I like repository-based session names. If I move into my-project, the tmux session should be named my-project. If the repository name contains dots, I usually replace them with dashes so it is easier to target from shell commands.

The managed version I would point readers to is zeno.zsh’s repository jump hook. If you use zeno-ghq-cd to choose a repository, register a post-hook that derives the tmux session name from the selected path:

~/.zshrc

function zeno-ghq-cd-post-hook-impl() {
  local dir="$ZENO_GHQ_CD_DIR"
  [[ -z "$TMUX" || -z "$dir" ]] && return

  local repository="${dir:t}"
  local session="${repository//./-}"
  tmux rename-session "$session"
}

zle -N zeno-ghq-cd-post-hook zeno-ghq-cd-post-hook-impl

With that shape, repository selection is the managed entry point. my.project becomes my-project, and any vde-layout preset you run afterward lands in a tmux session whose project identity is already visible.

This is not required for vde-layout, but it helps when several agent workspaces are open at once. A session name tells me which project I am looking at before I even inspect the panes, and scripts can use the same label when targeting a workspace.

9. What This Layer Solves

After tmux and vde-layout, I get:

This is already enough to improve daily work. I can restart a project workspace quickly. I can keep several agents visible. I can swap one agent runtime without redesigning the whole setup.

It also makes experimentation cheaper. If a layout is bad, I edit YAML. If an agent command changes, I edit one command string. If a role should move to another window, I change the floor plan.

10. What This Layer Does Not Solve

tmux and vde-layout create places for agents to run. They do not define handoffs.

After the workspace exists, new questions appear:

• Which pane is allowed to send work to which pane?
• Did the receiver read the request?
• Is someone waiting for a required reply?
• Which reply closes which request?
• Where is the durable evidence for a handoff?
• What should happen when delivery fails?

You can answer some of this with conventions and direct tmux send-keys calls, but the state is easy to lose. The terminal screen shows activity, not a durable delivery record.

That is the boundary I care about:

This article is about the first three rows.

11. The Next Layer

At this point tmux gives me stable places for agents to run, and vde-layout gives me a repeatable way to create those places.

The remaining problem is handoffs.

The next article is about the small mailbox layer I built on top of this setup: tmux-a2a-postman.

It does not replace tmux or vde-layout. It adds messages, reply obligations, readable routing rules, and archived delivery evidence between panes.

That separation is the important idea: first make the physical workspace repeatable, then make the coordination inside it explicit.

2. Target Behavior

In lazygit’s files panel, I want Ctrl+G to:

1. Read the staged diff
2. Ask AI for a one-line Conventional Commits message
3. Start the normal git commit flow
4. Run pre-commit hooks while the message is being generated
5. Open Vim with the generated draft inserted at the top

The final commit still goes through the normal editor step. I can edit the message, replace it, or abort.

3. lazygit Configuration

I keep the lazygit custom command short and move the real logic into a shell script.

~/.config/lazygit/config.yml

customCommands:
  - key: <c-g>
    context: files
    output: terminal
    command: bash ~/.config/lazygit/lazygit-ai-commit.sh

Ctrl+G is registered for the files panel. output: terminal lets git commit and Vim run in the terminal instead of inside a small lazygit prompt.

4. Shell Script

Here is the full ~/.config/lazygit/lazygit-ai-commit.sh script.

I checked this with Codex CLI v0.130.0.

~/.config/lazygit/lazygit-ai-commit.sh

#!/usr/bin/env bash

editor=$(mktemp /tmp/lazygit-ai-commit-editor.XXXXXX)
staged_diff=$(mktemp /tmp/lazygit-ai-commit-staged-diff.XXXXXX)
ai_message=$(mktemp /tmp/lazygit-ai-commit-ai-message.XXXXXX)
ai_status=$(mktemp /tmp/lazygit-ai-commit-ai-status.XXXXXX)
ai_stderr=$(mktemp /tmp/lazygit-ai-commit-ai-stderr.XXXXXX)
ai_pid=

cleanup() {
  if [ -n "$ai_pid" ] && kill -0 "$ai_pid" >/dev/null 2>&1; then
    kill "$ai_pid" >/dev/null 2>&1 || true
    wait "$ai_pid" >/dev/null 2>&1 || true
  fi
  rm -f "$editor" "$staged_diff" "$ai_message" "$ai_status" "$ai_stderr"
}
trap cleanup EXIT INT TERM

git diff --cached --no-ext-diff >"$staged_diff"

cat >"$editor" <<'AI_COMMIT_EDITOR'
#!/usr/bin/env bash
set -u

msg_file=$1
ai_message=$LAZYGIT_AI_COMMIT_MESSAGE
ai_status=$LAZYGIT_AI_COMMIT_STATUS

while [ ! -s "$ai_status" ]; do
  sleep 0.1
done

if [ -s "$ai_message" ]; then
  buffer=$(mktemp /tmp/lazygit-ai-commit-editor-buffer.XXXXXX)
  {
    head -n 1 "$ai_message"
    printf '\n'
    cat "$msg_file"
  } >"$buffer"
  cat "$buffer" >"$msg_file"
  rm -f "$buffer"
elif ! grep -qx 'ok' "$ai_status"; then
  cat "$ai_status" >&2
fi

exec vim "$msg_file"
AI_COMMIT_EDITOR

chmod +x "$editor"

if command -v codex >/dev/null 2>&1; then
  {
    prompt='Generate ONLY a one-line Git commit message following Conventional Commits format (type(scope): description). Types: feat, fix, docs, style, refactor, test, chore. Based strictly on the diff from stdin. Output ONLY the message, nothing else.'
    if codex exec -m gpt-5.4-mini --ephemeral --ignore-rules --sandbox read-only -c approval_policy='"never"' -c model_reasoning_effort='"low"' --color never --output-last-message "$ai_message" "$prompt" <"$staged_diff" >/dev/null 2>"$ai_stderr"; then
      msg=$(head -n 1 "$ai_message")
      if [ -n "$msg" ]; then
        printf '%s\n' "$msg" >"$ai_message"
        printf '%s\n' 'ok' >"$ai_status"
      else
        printf '%s\n' 'AI commit message generation returned an empty message; opening editor without AI message.' >"$ai_status"
      fi
    else
      printf '%s\n' 'AI commit message generation failed; opening editor without AI message.' >"$ai_status"
    fi
  } &
  ai_pid=$!
else
  printf '%s\n' 'codex not found; opening editor without AI message.' >"$ai_status"
fi

LAZYGIT_AI_COMMIT_MESSAGE="$ai_message" \
  LAZYGIT_AI_COMMIT_STATUS="$ai_status" \
  GIT_EDITOR="$editor" \
  git commit

The AI part is intentionally small. It reads the staged diff from stdin and returns only one line: a Conventional Commits message.

5. Where the Parallelism Comes From

The background behavior comes from the shell script, not from codex exec.

This block starts the message-generation process in the background:

{
  # codex exec ...
} &
ai_pid=$!

Right after that, the script starts git commit:

LAZYGIT_AI_COMMIT_MESSAGE="$ai_message" \
  LAZYGIT_AI_COMMIT_STATUS="$ai_status" \
  GIT_EDITOR="$editor" \
  git commit

If the repository has pre-commit hooks, Git runs those hooks before opening the commit-message editor. While that is happening, the background process is already asking codex exec for a message draft.

The temporary editor script waits until the AI process has written a status file:

while [ ! -s "$ai_status" ]; do
  sleep 0.1
done

Then it prepends the generated first line to the commit message file and opens Vim.

If Codex CLI is missing or message generation fails, the script still opens the normal editor, so the fallback is just a manual commit message.

6. Why I Like This Shape

The biggest win is that pre-commit hook time is no longer pure waiting time. Message generation happens during that window.

I also like that the workflow stays semi-automatic. The AI drafts one line, but I still see the final message in the editor before the commit is created. That fits lazygit well: fast enough for daily use, but still explicit.

7. Summary

This lazygit command now uses codex exec for non-interactive commit-message generation.

The important implementation detail is the shell script around it. The script backgrounds the AI generation, starts git commit, lets pre-commit hooks run in parallel with generation, and then opens Vim with the generated message draft.

Codex CLI may also get different limits or billing rules someday. If that happens, I will probably look at a local LLM version for this helper. For now, this small codex exec workflow is a good fit.

2. 設定

vimrc に以下のように書きます。

vimrc

" Resize Window
nmap <C-w>-    <C-w>-<SID>ws
nmap <C-w>+    <C-w>+<SID>ws
nmap <C-w><lt> <C-w><lt><SID>ws
nmap <C-w>>    <C-w>><SID>ws
nmap <SID>ws <Nop>
nnoremap <script> <SID>ws-    <C-w>-<SID>ws
nnoremap <script> <SID>ws+    <C-w>+<SID>ws
nnoremap <script> <SID>ws<lt> <C-w><lt><SID>ws
nnoremap <script> <SID>ws>    <C-w>><SID>ws

これで以下のように resize できます。

<C-w>----
<C-w>++++
<C-w><<<
<C-w>>>>

< は key notation の開始記号として扱われるので <lt> と書きます。 一方で > はそのまま書けます。

3. 仕組み

最初の mapping は標準の resize 操作を実行したあと、<SID>ws という script-local な中継地点に入ります。

nmap <C-w>- <C-w>-<SID>ws

<SID>ws 自体は何もしない mapping です。

nmap <SID>ws <Nop>

ただし、<SID>ws- や <SID>ws+ のような続きの mapping も定義しておきます。 そのため、<SID>ws に入った直後に - を押すと、もう一度 <C-w>- が実行されます。

nnoremap <script> <SID>ws- <C-w>-<SID>ws

そして RHS の最後でまた <SID>ws に戻るので、- を押し続けるだけで resize を繰り返せます。

<script> を付けているのは、RHS の <SID>ws だけをこの script-local mapping として解決したいからです。 通常のユーザー定義 mapping と混ざりにくくなります。

4. キーを変える場合

標準の <C-w>-, <C-w>+, <C-w><, <C-w>> を尊重したい場合は上の設定でよいです。

もし Vim のデフォルトにこだわらないなら、H, J, K, L に割り当てる形にもできます。

vimrc

" Resize Window
nmap <C-w>H <C-w><lt><SID>ws
nmap <C-w>J <C-w>-<SID>ws
nmap <C-w>K <C-w>+<SID>ws
nmap <C-w>L <C-w>><SID>ws
nmap <SID>ws <Nop>
nnoremap <script> <SID>wsH <C-w><lt><SID>ws
nnoremap <script> <SID>wsJ <C-w>-<SID>ws
nnoremap <script> <SID>wsK <C-w>+<SID>ws
nnoremap <script> <SID>wsL <C-w>><SID>ws

ただし、この形は <C-w>H などの Vim 標準の window 移動系キーバインドを上書きします。 そのため、標準キーバインドを残したい場合は -, +, <, > のままにするのが無難です。

5. おわりに

私の dotfiles では今は不要になったので外しましたが、設定としてはちゃんと動くのでメモとして残しておきます。

2. 英語名を覚えるとどこでも打てる

SKK には abbrev モードという入力モードがあります。

/ を打って英語キーワードを入力すると、辞書に登録されたエントリを変換候補として引けます。

/tada          → 🎉
/partying_face → 🥳
/fire          → 🔥

スニペット展開に近い感覚です。tada と打てば変換できますが、そのためには tada というキーワードが登録されていることを知っている必要があります。結局は英語名を覚えることが前提です。

emoji-cheat-sheet は絵文字の英語名を一覧できるリファレンスです。「この絵文字は英語で何と呼ぶか」をここで確認しながら覚えておけば、SKK が動いている環境ならどこでも絵文字が打てるようになります。

スマホでもキーワードを覚えていれば絵文字をヒットさせることができる場合があるので、その点でも便利です。

3. skk-emoji-jisyo

skk-emoji-jisyo は SKK 用の絵文字辞書です。gemoji の shortcode 名をキーとした英語のみのエントリで構成されています。

tada /🎉/
partying_face /🥳/
fire /🔥/
clinking_glasses /🥂/
star /⭐/

この辞書を追加しておくことで、abbrev モードでの英語変換が機能します。

4. クライアント別設定

let s:skk_dev_path = $XDG_CACHE_HOME->expand() .. '/dpp/repos/github.com/skk-dev/dict'
let s:skk_emoji_path = $XDG_CACHE_HOME->expand() .. '/dpp/repos/github.com/uasi/skk-emoji-jisyo'
call skkeleton#config({
\   'globalDictionaries': [
\     s:skk_dev_path .. '/SKK-JISYO.L',
\     s:skk_dev_path .. '/SKK-JISYO.jinmei',
\     s:skk_dev_path .. '/SKK-JISYO.assoc',
\     s:skk_emoji_path .. '/SKK-JISYO.emoji.utf8',
\   ],
\   'userDictionary': '~/path/to/skkdict.utf8',
\ })
call skkeleton#register_keymap('input', ';', 'henkanPoint')
imap <C-k> <Plug>(skkeleton-enable)

home.activation.setupMacSkkDict = lib.hm.dag.entryAfter [ "writeBoundary" ] ''
  macSkkDir="$HOME/Library/Containers/net.mtgto.inputmethod.macSKK/Data/Documents/Dictionaries"
  dppSkkDev="${XDG_CACHE_HOME:-$HOME/.cache}/dpp/repos/github.com/skk-dev/dict"
  dppSkkEmoji="${XDG_CACHE_HOME:-$HOME/.cache}/dpp/repos/github.com/uasi/skk-emoji-jisyo"
  mkdir -p "$macSkkDir"
  [[ -f "$dppSkkDev/SKK-JISYO.L" ]] && cp -f "$dppSkkDev/SKK-JISYO.L" "$macSkkDir/SKK-JISYO.L"
  [[ -f "$dppSkkEmoji/SKK-JISYO.emoji.utf8" ]] && cp -f "$dppSkkEmoji/SKK-JISYO.emoji.utf8" "$macSkkDir/SKK-JISYO.emoji.utf8"
'';

5. まとめ

• SKK abbrev モード (/ + 英語名) で絵文字変換できる
• 英語名を覚えることが本質で、emoji-cheat-sheet がその辞書になる
• skk-emoji-jisyo を追加することで gemoji shortcode 名で絵文字を変換できるようになる
• macSKK なら OS レベルで動くのでどのアプリでも使える
• skkeleton なら Vim / Neovim 内で完結する

2. どう便利か

~/.local/state/mkmd/
├── i9wa4-dotfiles/
│   └── 2026-03-22-main/
│       ├── research/
│       │   └── nix-investigation-aB3xKq.md
│       └── plans/
│           └── plan-Xk9mZw.md
├── i9wa4-i9wa4.github.io/
│   └── 2026-03-22-feat-auth/
│       └── draft/
│           └── design-doc-pQ7rLs.md
└── mycompany-api/
    └── 2026-03-21-issue-42/
        └── reviews/
            └── completion-nW2vHj.md

mkmd --dir research --label api-investigation

rm -rf ~/.local/state/mkmd/i9wa4-dotfiles/2026-03-20-*

3. mkmd：mktemp の Markdown wrapper

mktemp は一時ファイルをアトミックに作成する UNIX の基本コマンドです。

mkmd はその wrapper として作っています。

$ mkmd --dir research --label api-investigation
~/.local/state/mkmd/i9wa4-dotfiles/2026-03-22-main/research/api-investigation-xEZZqX.md

生成されるパスの構造はこうなっています。

$MKMD_BASE_DIR/<owner>-<repo>/YYYY-MM-DD-<branch>/<DIR>/<LABEL>-<XXXXXX>.md

git リポジトリ外で実行した場合は local-<dirname>/...-local/ にフォールバックします。

4. スクリプト全文

PATH の通ったディレクトリに置いて chmod +x するだけで使えます。

chmod +x mkmd

mkmd

#!/usr/bin/env bash
set -o errexit
set -o nounset
set -o pipefail
set -o posix

BASE_DIR="${MKMD_BASE_DIR:-${XDG_STATE_HOME:-$HOME/.local/state}/mkmd}"

print_usage() {
  cat <<EOF
Usage:
  mkmd --dir DIR --label LABEL

mktemp wrapper that creates a markdown working file.

Creates:
  \$MKMD_BASE_DIR/<owner>-<repo>/YYYY-MM-DD-<branch>/<DIR>/<LABEL>-<XXXXXX>.md

  Base directory: ${BASE_DIR}
  Works in git repos (uses owner/repo from remote URL) and outside git (uses "local"/dirname).

Environment:
  MKMD_BASE_DIR  Override base directory (default: \$XDG_STATE_HOME/mkmd)

Options:
  --dir DIR      Directory name under the daily session
  --label LABEL  File label included in the filename
  -h, --help     Show this help and exit
EOF
}

LABEL=""
DIR=""

# Parse arguments
while [[ $# -gt 0 ]]; do
  case $1 in
  -h | --help)
    print_usage
    exit 0
    ;;
  --dir)
    DIR="$2"
    shift 2
    ;;
  --label)
    LABEL="$2"
    shift 2
    ;;
  -*)
    echo "Unknown option: $1" >&2
    exit 1
    ;;
  *)
    echo "Error: Unknown argument: $1" >&2
    exit 1
    ;;
  esac
done

# Validate DIR and LABEL
if [[ -z $DIR || -z $LABEL ]]; then
  echo "Error: --dir and --label are required" >&2
  print_usage >&2
  exit 1
fi

repo_root="$(git rev-parse --show-toplevel 2>/dev/null || true)"

if [[ -n $repo_root ]]; then
  remote_url="$(git remote get-url origin 2>/dev/null || true)"
  if [[ -n $remote_url ]]; then
    # Extract owner/repo from remote URL (handles both SSH and HTTPS)
    remote_url="${remote_url%.git}"
    project_name="${remote_url##*/}"
    remote_url="${remote_url%/*}"
    project_owner="${remote_url##*[:/]}"
  else
    project_owner="local"
    project_name="$(basename "$repo_root")"
  fi
  branch_name="$(git rev-parse --abbrev-ref HEAD 2>/dev/null || echo unknown)"
  branch_name="${branch_name//\//-}"
else
  project_owner="local"
  project_name="$(basename "$(pwd -P)")"
  branch_name="local"
fi
date_dir="$(date +%Y-%m-%d)-${branch_name}"
TARGET_DIR="${BASE_DIR}/${project_owner}-${project_name}/${date_dir}/${DIR}"

mkdir -p "$TARGET_DIR"
# BSD mktemp requires XXXXXX at the end of the template (no suffix allowed)
TEMP_PATH=$(mktemp "${TARGET_DIR}/${LABEL}-XXXXXX")
trap 'rm -f "$TEMP_PATH"' EXIT
FILE_PATH="${TEMP_PATH}.md"
mv "$TEMP_PATH" "$FILE_PATH"
trap - EXIT
echo "$FILE_PATH"
echo "Created: $FILE_PATH" >&2

5. AIエージェントとの Integration

- Create working files (not tracked by git) with `mkmd` (`mkmd --help`)
- Common dir/label combinations:

    | --dir     | --label                          |
    | --------- | -------------------------------- |
    | draft     | `${topic}`                       |
    | research  | `${feature}-investigation`       |
    | plans     | plan                             |
    | reviews   | completion                       |
    | tmp       | `${purpose}`                     |

elif [[ -n $FILE_PATH && $FILE_PATH == "$HOME/.local/state/mkmd/"* ]]; then
  : # Allow writes to mkmd state directory

FILE=$(mkmd --dir tmp --label compact-save)
echo "# Context Save" > "$FILE"

6. まとめ

AIエージェントの作業ファイル管理は地味ですが、散らかると生産性に響きます。

mktemp を薄く wrap して「プロジェクト/日付/用途」の構造を自動付与するだけで、以下が手に入ります。

• git status が常にクリーン
• 作業ファイルがプロジェクト/日付/ブランチで自動整理される
• エージェントが自律的にファイルを作り、人間がパスを気にする必要がない
• 不要になったらディレクトリごと消せる

AIエージェントに作業ファイルの置き場所を教えるのに苦労している方は、試してみてください。

2. How It Helps

~/.local/state/mkmd/
├── i9wa4-dotfiles/
│   └── 2026-03-22-main/
│       ├── research/
│       │   └── nix-investigation-aB3xKq.md
│       └── plans/
│           └── plan-Xk9mZw.md
├── i9wa4-i9wa4.github.io/
│   └── 2026-03-22-feat-auth/
│       └── draft/
│           └── design-doc-pQ7rLs.md
└── mycompany-api/
    └── 2026-03-21-issue-42/
        └── reviews/
            └── completion-nW2vHj.md

mkmd --dir research --label api-investigation

rm -rf ~/.local/state/mkmd/i9wa4-dotfiles/2026-03-20-*

3. mkmd: A Markdown Wrapper for mktemp

mktemp is the standard Unix command for atomically creating temporary files.

mkmd is a thin wrapper around it.

$ mkmd --dir research --label api-investigation
~/.local/state/mkmd/i9wa4-dotfiles/2026-03-22-main/research/api-investigation-xEZZqX.md

The generated path follows this structure:

$MKMD_BASE_DIR/<owner>-<repo>/YYYY-MM-DD-<branch>/<DIR>/<LABEL>-<XXXXXX>.md

When run outside a git repository, it falls back to local-<dirname>/...-local/.

4. Full Script

Place it in a directory on your PATH and make it executable.

chmod +x mkmd

mkmd

#!/usr/bin/env bash
set -o errexit
set -o nounset
set -o pipefail
set -o posix

BASE_DIR="${MKMD_BASE_DIR:-${XDG_STATE_HOME:-$HOME/.local/state}/mkmd}"

print_usage() {
  cat <<EOF
Usage:
  mkmd --dir DIR --label LABEL

mktemp wrapper that creates a markdown working file.

Creates:
  \$MKMD_BASE_DIR/<owner>-<repo>/YYYY-MM-DD-<branch>/<DIR>/<LABEL>-<XXXXXX>.md

  Base directory: ${BASE_DIR}
  Works in git repos (uses owner/repo from remote URL) and outside git (uses "local"/dirname).

Environment:
  MKMD_BASE_DIR  Override base directory (default: \$XDG_STATE_HOME/mkmd)

Options:
  --dir DIR      Directory name under the daily session
  --label LABEL  File label included in the filename
  -h, --help     Show this help and exit
EOF
}

LABEL=""
DIR=""

# Parse arguments
while [[ $# -gt 0 ]]; do
  case $1 in
  -h | --help)
    print_usage
    exit 0
    ;;
  --dir)
    DIR="$2"
    shift 2
    ;;
  --label)
    LABEL="$2"
    shift 2
    ;;
  -*)
    echo "Unknown option: $1" >&2
    exit 1
    ;;
  *)
    echo "Error: Unknown argument: $1" >&2
    exit 1
    ;;
  esac
done

# Validate DIR and LABEL
if [[ -z $DIR || -z $LABEL ]]; then
  echo "Error: --dir and --label are required" >&2
  print_usage >&2
  exit 1
fi

repo_root="$(git rev-parse --show-toplevel 2>/dev/null || true)"

if [[ -n $repo_root ]]; then
  remote_url="$(git remote get-url origin 2>/dev/null || true)"
  if [[ -n $remote_url ]]; then
    # Extract owner/repo from remote URL (handles both SSH and HTTPS)
    remote_url="${remote_url%.git}"
    project_name="${remote_url##*/}"
    remote_url="${remote_url%/*}"
    project_owner="${remote_url##*[:/]}"
  else
    project_owner="local"
    project_name="$(basename "$repo_root")"
  fi
  branch_name="$(git rev-parse --abbrev-ref HEAD 2>/dev/null || echo unknown)"
  branch_name="${branch_name//\//-}"
else
  project_owner="local"
  project_name="$(basename "$(pwd -P)")"
  branch_name="local"
fi
date_dir="$(date +%Y-%m-%d)-${branch_name}"
TARGET_DIR="${BASE_DIR}/${project_owner}-${project_name}/${date_dir}/${DIR}"

mkdir -p "$TARGET_DIR"
# BSD mktemp requires XXXXXX at the end of the template (no suffix allowed)
TEMP_PATH=$(mktemp "${TARGET_DIR}/${LABEL}-XXXXXX")
trap 'rm -f "$TEMP_PATH"' EXIT
FILE_PATH="${TEMP_PATH}.md"
mv "$TEMP_PATH" "$FILE_PATH"
trap - EXIT
echo "$FILE_PATH"
echo "Created: $FILE_PATH" >&2

5. Integration with AI Agents

- Create working files (not tracked by git) with `mkmd` (`mkmd --help`)
- Common dir/label combinations:

    | --dir     | --label                          |
    | --------- | -------------------------------- |
    | draft     | `${topic}`                       |
    | research  | `${feature}-investigation`       |
    | plans     | plan                             |
    | reviews   | completion                       |
    | tmp       | `${purpose}`                     |

elif [[ -n $FILE_PATH && $FILE_PATH == "$HOME/.local/state/mkmd/"* ]]; then
  : # Allow writes to mkmd state directory

FILE=$(mkmd --dir tmp --label compact-save)
echo "# Context Save" > "$FILE"

6. Summary

Managing AI agent work files is unglamorous, but clutter kills productivity.

A thin wrapper around mktemp that automatically applies a “project / date / purpose” structure gives you:

• git status stays clean at all times
• Work files automatically organized by project, date, and branch
• Agents create files autonomously; humans never have to think about paths
• Delete an entire directory when you are done

If you have been struggling with where to put AI agent work files, give it a try.

2. Claude Code の情報収集

claude --version

2.1.76 (Claude Code)

FILE=$(mktemp /tmp/claude-changelog-XXXXXX.md)
gh api repos/anthropics/claude-code/contents/CHANGELOG.md \
  -H "Accept: application/vnd.github.raw+json" > "$FILE"

grep "^## " "$FILE" | head -20

grep -i "deprecated\|removed\|breaking\|changed" "$FILE"

3. Codex CLI の情報収集

codex --version

codex-cli 0.115.0

LOCAL_VERSION=$(codex --version | grep -o '[0-9]\+\.[0-9]\+\.[0-9]\+')
FILE=$(mktemp /tmp/codex-releases-XXXXXX.json)
gh api "repos/openai/codex/releases/tags/rust-v${LOCAL_VERSION}" > "$FILE"

jq '{tag_name, body}' "$FILE"

jq -r '.body' "$FILE" | grep -i "breaking\|removed\|deprecated"

4. まとめ

5. スキルとして使う

~/.claude/skills/claude-config-optimizer/
  SKILL.md
  references/
    changelog-tracking.md   # 蓄積ファイル (1 ファイルに追記)

~/.claude/skills/codex-config-optimizer/
  SKILL.md
  references/
    release-tracking.md     # 蓄積ファイル (1 ファイルに追記)

mkdir -p ~/.claude/skills/claude-config-optimizer/references

~/.claude/skills/claude-config-optimizer/SKILL.md

---
name: claude-config-optimizer
description: |
  Claude Code の CHANGELOG をインストール済みバージョンに絞って確認する。
  Use when:
  - User says "changelog" or "updates" about Claude Code
  - Checking for breaking changes before upgrading
---

# Claude Config Optimizer Skill

全ステップを順番に実行し、結果をまとめて報告する。
途中で確認を求めず、最後まで一気に進める。
設定ファイルの書き換えは行わない。

## 1. インストール済みバージョンを確認する

```{.bash}
claude --version
```

この番号以下の CHANGELOG セクションのみを分析対象にする。

## 2. CHANGELOG を取得する

```{.bash}
FILE=$(mktemp /tmp/claude-changelog-XXXXXX.md)
gh api repos/anthropics/claude-code/contents/CHANGELOG.md \
  -H "Accept: application/vnd.github.raw+json" > "$FILE"
echo "Saved to $FILE"
```

## 3. バージョンセクション一覧を確認する

```{.bash}
grep "^## " "$FILE" | head -20
```

## 4. 破壊的変更を検索する

```{.bash}
grep -i "deprecated\|removed\|breaking\|changed" "$FILE"
```

インストール済みバージョン以下のセクションのヒットのみを報告する。

## 5. 報告をまとめる

ステップ 3-4 の結果をもとに、以下を一括で報告する。

1. アップデート情報の要約 (Added/Fixed/Deprecated)
2. 設定ファイルへの影響判定と変更提案
   - `~/.claude/settings.json`
   - `CLAUDE.md`、`rules/`、`skills/`

## 6. 調査結果を references/ に蓄積する

`references/changelog-tracking.md` に追記する。
ファイルが存在しなければ新規作成する。
以下のセクション構成で管理する。

- Applied: 採用した変更と適用内容
- Not Adopting: 見送った項目と理由
- Version Notes: バージョンごとの主要変更メモ (日付付き)

既存の記録があれば前回との差分のみ追記する。

mkdir -p ~/.claude/skills/codex-config-optimizer/references

~/.claude/skills/codex-config-optimizer/SKILL.md

---
name: codex-config-optimizer
description: |
  インストール済みバージョンの Codex CLI リリースノートを取得して確認する。
  Use when:
  - User says "codex changelog" or "codex updates"
  - Checking for breaking changes in Codex CLI
---

# Codex Config Optimizer Skill

全ステップを順番に実行し、結果をまとめて報告する。
途中で確認を求めず、最後まで一気に進める。
設定ファイルの書き換えは行わない。
タグ形式は `rust-v<version>` (例: `rust-v0.115.0`)。

## 1. インストール済みバージョンを確認する

```{.bash}
codex --version
```

このバージョン以下のリリースのみを分析対象にする。

## 2. リリースノートを取得する

```{.bash}
LOCAL_VERSION=$(codex --version | grep -o '[0-9]\+\.[0-9]\+\.[0-9]\+')
FILE=$(mktemp /tmp/codex-releases-XXXXXX.json)
gh api "repos/openai/codex/releases/tags/rust-v${LOCAL_VERSION}" > "$FILE"
echo "Saved to $FILE"
```

## 3. 内容を確認する

```{.bash}
jq '{tag_name, body}' "$FILE"
```

## 4. 破壊的変更を検索する

```{.bash}
jq -r '.body' "$FILE" | grep -i "breaking\|removed\|deprecated"
```

## 5. 報告をまとめる

ステップ 3-4 の結果をもとに、以下を一括で報告する。

1. アップデート情報の要約 (New Features/Bug Fixes/Breaking)
2. 設定ファイルへの影響判定と変更提案
   - `~/.codex/config.toml`
   - `AGENTS.md`、`rules/`、`skills/`

## 6. 調査結果を references/ に蓄積する

`references/release-tracking.md` に追記する。
ファイルが存在しなければ新規作成する。
以下のセクション構成で管理する。

- Applied: 採用した変更と適用内容
- Not Adopting: 見送った項目と理由
- Version Notes: バージョンごとの主要変更メモ (日付付き)

既存の記録があれば前回との差分のみ追記する。

2. Makefile 全体

bin/Makefile

# [タスク・ランナーとしてのMake \#Makefile - Qiita](https://qiita.com/shakiyam/items/cdd3c11eba978202a628)
SHELL := /bin/bash
.SHELLFLAGS := -o errexit -o nounset -o pipefail -c
.DEFAULT_GOAL := help
.ONESHELL:

# all targets are phony
PHONY_TARGETS := $(shell grep -E '^[a-zA-Z_-]+:' $(MAKEFILE_LIST) | sed 's/://')
.PHONY: $(PHONY_TARGETS)

help:  ## print this help
    @echo 'Usage: make [target]'
    @echo ''
    @echo 'Targets:'
    @awk 'BEGIN {FS = ":.*?## "} /^[a-zA-Z_-]+:.*?## / {printf "\033[36m%-30s\033[0m %s\n", $$1, $$2}' $(MAKEFILE_LIST)


# --------------------------------------
# Global Variables
#
MF_GITHUB_DIR := $(shell ghq root)/github.com
MF_DETECTED_OS := $(shell \
    _uname="$$(uname -a)"; \
    if echo "$${_uname}" | grep -q Darwin; then \
        echo "macOS"; \
    elif echo "$${_uname}" | grep -q WSL2; then \
        echo "WSL2"; \
    elif echo "$${_uname}" | grep -q Ubuntu; then \
        echo "Ubuntu"; \
    else \
        echo "Unknown"; \
    fi)

MF_WIN_UTIL_DIR := /mnt/c/work/util


# nvim-build:  ## build Neovim from source
#   ghq get -p neovim/neovim
#   cd $(MF_GITHUB_DIR)/neovim/neovim && \
#   make distclean || true && \
#   make CMAKE_BUILD_TYPE=Release CMAKE_INSTALL_PREFIX="$${HOME}"/.local && \
#   make install && \
#   rm -rf build

# vim-build:  ## build Vim from source
#   ghq get -p vim/vim
# ifeq ($(MF_DETECTED_OS),macOS)
#   cd $(MF_GITHUB_DIR)/vim/vim/src && \
#   make distclean || true && \
#   ./configure \
#       --disable-gui \
#       --enable-clipboard \
#       --enable-darwin \
#       --enable-fail-if-missing \
#       --enable-multibyte \
#       --prefix="$${HOME}"/.local \
#       --with-features=huge \
#       --without-wayland && \
#   make && \
#   make install
# else
#   cd $(MF_GITHUB_DIR)/vim/vim/src && \
#   make distclean || true && \
#   ./configure \
#       --disable-gui \
#       --enable-clipboard \
#       --enable-fail-if-missing \
#       --enable-multibyte \
#       --prefix="$${HOME}"/.local \
#       --with-features=huge \
#       --without-x \
#       --without-wayland && \
#   make && \
#   make install
# endif


# --------------------------------------
# Ubuntu Tasks
#
ubuntu-apt:  ## update and upgrade packages in Ubuntu
    sudo apt-get update && sudo apt-get upgrade -y


# --------------------------------------
# WSL Tasks (Windows integration)
#
define MF_WSLCONF_IN_WSL
[boot]
systemd=true

[interop]
appendWindowsPath=true
endef
export MF_WSLCONF_IN_WSL

define MF_WSLCONFIG_IN_WINDOWS
[wsl2]
localhostForwarding=true
processors=2
swap=0

[experimental]
autoMemoryReclaim=gradual
endef
export MF_WSLCONFIG_IN_WINDOWS

win-copy:  ## copy config files for Windows (WSL only)
    # WSL2
    echo "$${MF_WSLCONF_IN_WSL}" | sudo tee /etc/wsl.conf
    # Windows
    echo "$${MF_WSLCONFIG_IN_WINDOWS}" | \
        tee $(MF_WIN_UTIL_DIR)/etc/dot.wslconfig
    rm -rf $(MF_WIN_UTIL_DIR)
    cp -rf $(MF_GITHUB_DIR)/i9wa4/dotfiles/bin $(MF_WIN_UTIL_DIR)

3. テクニック解説

SHELL := /bin/bash
.SHELLFLAGS := -o errexit -o nounset -o pipefail -c
.ONESHELL:

help:  ## print this help
    @awk 'BEGIN {FS = ":.*?## "} /^[a-zA-Z_-]+:.*?## / {printf "\033[36m%-30s\033[0m %s\n", $$1, $$2}' $(MAKEFILE_LIST)

PHONY_TARGETS := $(shell grep -E '^[a-zA-Z_-]+:' $(MAKEFILE_LIST) | sed 's/://')
.PHONY: $(PHONY_TARGETS)

MF_DETECTED_OS := $(shell \
    _uname="$$(uname -a)"; \
    if echo "$${_uname}" | grep -q Darwin; then \
        echo "macOS"; \
    elif echo "$${_uname}" | grep -q WSL2; then \
        echo "WSL2"; \
    elif echo "$${_uname}" | grep -q Ubuntu; then \
        echo "Ubuntu"; \
    else \
        echo "Unknown"; \
    fi)

define MF_WSLCONF_IN_WSL
[boot]
systemd=true

[interop]
appendWindowsPath=true
endef
export MF_WSLCONF_IN_WSL

4. まとめ

タスク・ランナーとしての Makefile は .ONESHELL: や define/endef を活用すればシェルスクリプトの管理ツールとして十分機能します。特に自己文書化 help ターゲットは他のプロジェクトでも使える汎用的なパターンです。Nix に移行した今は不要になりましたが、Nix を使わない環境では今でも有用な選択肢だと思います。

2. SSOT 化した要素

denied-bash-commands.nix

[
  {
    argv = [ "git" "-C" ];
    justification = "cross-directory git operations are denied";
  }
  {
    argv = [ "git" "push" ];
    justification = "pushing is denied";
  }
  {
    argv = [ "git" "rebase" ];
    justification = "rebase is denied";
  }
  {
    argv = [ "git" "reset" ];
    justification = "reset is denied";
  }
  {
    argv = [ "git" "commit" "--amend" ];
    justification = "amend is denied (causes force push requirement)";
  }
  {
    argv = [ "git" "merge" ];
    justification = "merge is denied";
  }
  {
    argv = [ "git" "branch" "-d" ];
    justification = "branch deletion is denied";
  }
  {
    argv = [ "git" "branch" "-D" ];
    justification = "branch force-deletion is denied";
  }
  {
    argv = [ "rm" ];
    justification = "rm is denied; use mv /tmp/ instead";
    claudeSettingsJson = true;
  }
  {
    argv = [ "sudo" ];
    justification = "sudo is denied";
    claudeSettingsJson = true;
  }
]

denied-bash-commands.nix (モジュール部分)

{ pkgs }:
let
  entries = [ ... ]; # 上記のエントリリスト

  # hookRegex を argv から自動導出
  # 1 token → ^token\b, 2+ tokens → ^token1.*token2 (末尾 \b なし)
  mkHookRegex = cmd:
    cmd.hookRegex or (
      let
        anchored = cmd.anchored or true;
        prefix = if anchored then "^" else "";
      in
      if builtins.length cmd.argv == 1
      then "${prefix}${builtins.head cmd.argv}\\b"
      else prefix + builtins.concatStringsSep ".*" cmd.argv
    );

  mkPrefixRule = cmd:
    let
      escapedJustification = builtins.replaceStrings [ "\\" "\"" ] [ "\\\\" "\\\"" ] cmd.justification;
    in
    ''
      prefix_rule(
          pattern = [${patternItems}],
          decision = "forbidden",
          justification = "${escapedJustification}",
      )
    '';
in
{
  inherit entries;
  claudeCode = {
    denyPermissions = ...; # claudeSettingsJson = true のエントリのみ
    patternsFile = ...;    # 全エントリの hookRegex + justification
  };
  codexCli = {
    rulesContent = ...;    # 全エントリの prefix_rule
  };
}

claude-code.nix

deniedBash = import ./denied-bash-commands.nix { inherit pkgs; };

# permissions.deny (claudeSettingsJson = true のエントリのみ)
permissions.deny = deniedBash.claudeCode.denyPermissions ++ [ ... ];

# PreToolUse hook 用パターンファイルを含む scripts ディレクトリ (全エントリ)
home.file.".claude/scripts".source = scriptsDir;

codex-cli.nix

deniedBash = import ./denied-bash-commands.nix { inherit pkgs; };

# default.rules (全エントリ)
rulesContent = deniedBash.codexCli.rulesContent;

denied-bash-commands.nix (追加するエントリ)

{ argv = [ "git" "merge" ]; anchored = false; justification = "merge is denied"; }

denied-bash-commands.nix (追加するエントリ)

{ argv = [ "rm" ]; justification = "rm is denied; use mv /tmp/ instead"; claudeSettingsJson = true; }

claude-pretooluse-deny-bash.sh

#!/usr/bin/env bash
set -o errexit
set -o nounset
set -o pipefail
set -o posix

# claude-pretooluse-deny-bash.sh - Bash command deny hook
# Hook: PreToolUse | Matcher: Bash
# Patterns: deny-bash-patterns.sh (generated from denied-bash-commands.nix)

SCRIPT_DIR=$(cd "$(dirname "$0")" && pwd)
PATTERNS_FILE="$SCRIPT_DIR/deny-bash-patterns.sh"
[[ ! -f $PATTERNS_FILE ]] && exit 0

# shellcheck source=/dev/null
source "$PATTERNS_FILE"

COMMAND=$(jq -r '.tool_input.command // empty' 2>/dev/null) || true
[[ -z $COMMAND ]] && exit 0

while IFS=$';&|' read -ra line_fragments; do
  for fragment in "${line_fragments[@]}"; do
    fragment="${fragment#"${fragment%%[![:space:]]*}"}"
    fragment="${fragment%"${fragment##*[![:space:]]}"}"
    [[ -z $fragment ]] && continue
    for i in "${!DENY_PATTERNS[@]}"; do
      if [[ $fragment =~ ${DENY_PATTERNS[$i]} ]]; then
        jq -n --arg reason "Command denied: ${DENY_JUSTIFICATIONS[$i]}"$'\n'"Fragment: $fragment" \
          '{ hookSpecificOutput: { hookEventName: "PreToolUse", permissionDecision: "deny", permissionDecisionReason: $reason } }'
        exit 0
      fi
    done
  done
done <<<"$COMMAND"

exit 0

claude-code.nix

bashDenyPatternsName = "deny-bash-patterns.sh";

scriptsDir = pkgs.runCommand "claude-scripts" { } ''
  mkdir -p $out
  for f in ${./scripts}/*; do
    ln -s "$f" "$out/$(basename "$f")"
  done
  ln -s ${deniedBash.claudeCode.patternsFile} $out/${bashDenyPatternsName}
'';

# hooks.PreToolUse
command = "$CLAUDE_CONFIG_DIR/scripts/claude-pretooluse-deny-bash.sh";

# home.file
".claude/scripts".source = scriptsDir;

mcp-servers.nix

{
  pkgs,
  inputs,
}:
let
  # mcp-servers-nix で管理されているサーバー (Nix でバージョン固定)
  nixServers =
    (inputs.mcp-servers-nix.lib.evalModule pkgs {
      programs = {
        context7.enable = true;
      };
    }).config.settings.servers;

  # mcp-servers-nix 未収録のサーバー (uvx またはインストール済みバイナリで実行)
  manualServers = {
    awslabs-aws-documentation-mcp-server = {
      command = "uvx";
      args = [ "awslabs.aws-documentation-mcp-server@latest" ];
    };
    drawio = {
      command = "drawio-mcp";
    };
  };
in
nixServers // manualServers

agent-skills.nix

# Agent skills declarative management via agent-skills-nix
# cf. https://github.com/Kyure-A/agent-skills-nix
{
  inputs,
  config,
  ...
}:
let
  homeDir = config.home.homeDirectory;
in
{
  imports = [
    inputs.agent-skills.homeManagerModules.default
  ];

  programs.agent-skills = {
    enable = true;

    # Skill sources
    sources = {
      # Local skills from this dotfiles repository
      local = {
        path = inputs.self;
        subdir = "agents/skills";
      };
      # tmux-a2a-postman skills
      tmux-a2a-postman = {
        path = inputs.tmux-a2a-postman;
        subdir = "skills";
      };
      # dbt-labs official agent skills (split by skill group)
      dbt = {
        path = inputs.dbt-agent-skills;
        subdir = "skills/dbt/skills";
      };
      dbt-migration = {
        path = inputs.dbt-agent-skills;
        subdir = "skills/dbt-migration/skills";
      };
      # Anthropic official agent skills
      anthropic = {
        path = inputs.anthropic-skills;
        subdir = "skills";
      };
      # Streamlit official agent skills
      streamlit = {
        path = inputs.streamlit-skills;
        subdir = "developing-with-streamlit/skills";
      };
      # Databricks official agent skills (ai-dev-kit)
      # cf. https://github.com/databricks-solutions/ai-dev-kit/tree/main/databricks-skills
      databricks = {
        path = inputs.databricks-agent-skills;
        subdir = "databricks-skills";
      };
      # cf. https://github.com/databricks-solutions/ai-dev-kit/tree/main/.claude/skills
      databricks-claude = {
        path = inputs.databricks-agent-skills;
        subdir = ".claude/skills";
        filter.nameRegex = "python-dev"; # exclude databricks-python-sdk (duplicate)
      };
      # Databricks official agent skills (databricks org)
      # cf. https://github.com/databricks/databricks-agent-skills
      databricks-official = {
        path = inputs.databricks-official-skills;
        subdir = "skills";
        filter.nameRegex = "databricks(-apps|-pipelines)?"; # exclude databricks-jobs (duplicate)
      };
      # draw.io skill (jgraph/drawio-mcp)
      # cf. https://github.com/jgraph/drawio-mcp
      drawio-mcp = {
        path = inputs.drawio-mcp;
        subdir = "skill-cli";
      };
      # freee MCP skills
      # cf. https://github.com/freee/freee-mcp
      freee = {
        path = inputs.freee-mcp;
        subdir = "skills";
      };
      # HashiCorp agent skills (split by plugin)
      # cf. https://github.com/hashicorp/agent-skills
      hashicorp-terraform-codegen = {
        path = inputs.hashicorp-agent-skills;
        subdir = "terraform/code-generation/skills";
      };
      hashicorp-terraform-module = {
        path = inputs.hashicorp-agent-skills;
        subdir = "terraform/module-generation/skills";
      };
      hashicorp-terraform-provider = {
        path = inputs.hashicorp-agent-skills;
        subdir = "terraform/provider-development/skills";
      };
    };

    # Enable all skills from all sources
    skills = {
      enableAll = true;
      # Explicit skill definitions (for rename or custom config)
      explicit.databricks-jobs-bundles = {
        from = "databricks-official";
        path = "databricks-jobs";
        rename = "databricks-jobs-bundles"; # avoid duplicate with ai-dev-kit
      };
    };

    # Target destinations (symlink-tree uses activation rsync)
    targets = {
      # Claude Code: ~/.claude/skills
      claude-home = {
        dest = "${homeDir}/.claude/skills";
        structure = "symlink-tree";
      };
      # Codex CLI: ~/.codex/skills
      codex = {
        dest = "${homeDir}/.codex/skills";
        structure = "symlink-tree";
      };
    };

    # Preserve .system directory (created by agents at runtime)
    excludePatterns = [ "/.system" ];
  };
}

codex-cli.nix

codexAgentsDir = pkgs.runCommand "codex-agents" { } ''
  mkdir -p $out
  for md in ${./subagents}/*.md; do
    basename="$(basename "$md" .md)"
    agent_name="$(${pkgs.gnused}/bin/sed -n 's/^name: //p' "$md")"
    description="$(${pkgs.gnused}/bin/sed -n 's/^description: //p' "$md")"
    body="$(${pkgs.gawk}/bin/awk 'BEGIN{n=0} /^---$/{n++; next} n>=2{print}' "$md")"
    printf 'name = "%s"\ndescription = "%s"\ndeveloper_instructions = """\n%s\n"""\n' \
      "$agent_name" "$description" "$body" > "$out/$basename.toml"
  done
'';

3. 実装のはまりポイント

claude-code.nix

claudeSettings = lib.hm.dag.entryAfter [ "writeBoundary" ] ''
  install -Dm644 ${settingsFile} "$HOME/.claude/settings.json"
'';

codex-cli.nix

${pkgs.fd}/bin/fd --type d --hidden --no-ignore "^\.git$" "${ghqRoot}" --max-depth 4 2>/dev/null |
  sort |
  while read -r gitdir; do
    repo=$(dirname "$gitdir")
    echo ""
    echo "[projects.\"$repo/\"]"
    echo "trust_level = \"trusted\""
  done >> "$_output"

agent-skills.nix

drawio-mcp = {
  path = inputs.drawio-mcp;
  subdir = "skill-cli";
};

agent-skills.nix

databricks-official = {
  path = inputs.databricks-official-skills;
  subdir = "skills";
  filter.nameRegex = "databricks(-apps|-pipelines)?"; # exclude databricks-jobs (duplicate)
};

agent-skills.nix

skills = {
  enableAll = true;
  explicit.databricks-jobs-bundles = {
    from = "databricks-official";
    path = "databricks-jobs";
    rename = "databricks-jobs-bundles"; # avoid duplicate with ai-dev-kit
  };
};

~/.codex/skills/.system/

.codex-system-skills.marker
skill-creator/
skill-installer/

agent-skills.nix

excludePatterns = [ "/.system" ];

4. まとめ

2. 設定

lazygit.nix

programs.lazygit.settings.customCommands = [
  {
    key = "<c-g>";
    context = "files";
    output = "terminal";
    command = ''
      MSG=$(git diff --cached | claude --no-session-persistence --print --model haiku \
        'Generate ONLY a one-line Git commit message following Conventional Commits format \
        (type(scope): description). Types: feat, fix, docs, style, refactor, test, chore. \
        Based strictly on the diff from stdin. Output ONLY the message, nothing else.') \
        && git commit -e -m "$MSG"
    '';
  }
];

output = "terminal" にすることで git commit -e がターミナル上で動き、エディタが開きます。

3. 使い方

1. lazygit でファイルをステージする
2. files パネルで Ctrl+G を押す
3. Claude Haiku が diff を読んでコミットメッセージを生成する
4. エディタが生成されたメッセージを pre-fill した状態で開く
5. 内容を確認・修正してコミット

モデルは Haiku を指定しているので速くて安上がりです。

4. まとめ

git diff --cached をそのまま LLM に渡すシンプルな構成で、実用的な下書きが得られます。 最終確認はエディタで自分の目を通すので、完全に任せきりにならないのがちょうどいいバランスです。

2. 機能比較は意味がなくなる

.claude/
├── CLAUDE.md
├── rules/
├── skills/
├── agents/
└── commands/

3. 残るもの：環境構築力

4. dotfiles のすすめ

dotfiles/
├── .config/
│   ├── claude/      # AIコーディングエージェント設定
│   ├── tmux/        # ターミナルマルチプレクサ設定
│   ├── wezterm/     # ターミナル設定
│   └── nvim/        # テキストエディタ設定
├── .zshrc            # シェル設定
└── bin/              # 自作スクリプト

dotfiles/
├── .config/
│   ├── claude/         # <- IDEでも使える
│   │   ├── CLAUDE.md
│   │   ├── rules/
│   │   ├── agents/
│   │   └── commands/
│   │
│   ├── tmux/           # <- ターミナル固有
│   │   └── tmux.conf
│   │
│   └── wezterm/        # <- ターミナル固有
│       └── wezterm.lua
│
├── .zshrc               # <- ターミナル固有
│
└── bin/                 # <- ターミナル固有

5. dotfiles の始め方

dotfiles の始め方については、以下の記事が親しみがあってわかりやすいと思いました。

• ようこそdotfilesの世界へ - Qiita
• ゆるりとはじめる dotfiles 入門 - Zenn

dotfiles は一日で完成しません。使いながら情報感度を上げつつ徐々に育てていくものです。

まずは Claude Code の設定など小さいところから始めて、徐々に充実させていくのがおすすめです。

6. まとめ