add
This commit is contained in:
@@ -0,0 +1,24 @@
|
||||
---
|
||||
title: abtop
|
||||
created: 2026-06-30
|
||||
updated: 2026-06-30
|
||||
type: entity
|
||||
tags: [tool, agent, dev-tool, automation, workflow]
|
||||
sources: [raw/articles/abtop-ai-coding-agent-monitor-2026.md]
|
||||
confidence: medium
|
||||
---
|
||||
|
||||
# abtop
|
||||
|
||||
abtop は、Claude Code、Codex CLI、OpenCode などの AI coding agent セッションを、`btop` のような端末 UI で横断監視するローカル道具。複数プロジェクトでエージェントを同時に走らせるときに、token usage、context window、rate limit、child process、open port、git status などを一画面で見るためのものとして設計されている。[[loop-engineering]] で問題になる「並列ループの見えなさ」を、まずローカル観測可能性として扱う実装例である。
|
||||
|
||||
## 見るべき点
|
||||
|
||||
- **read-only first**: README は「No API keys, no auth」とし、ローカルファイル・プロセス・open-file metadata を読むだけだと説明している。これは [[ci-cd-runtime-security]] のような実行時観測と近いが、対象は CI runner ではなく個人の agent 作業環境である。
|
||||
- **agent-specific telemetry**: Claude Code / Codex CLI / OpenCode ごとに session discovery、token tracking、context window、status、rate limit、children / ports などの対応状況を分けている。単なる process monitor ではなく、AI coding agent の失敗モードに寄せた監視面になっている。
|
||||
- **operator workflow**: `abtop --once` や `abtop --json` は、TUI だけでなく script や dashboard にも状態を渡せる。[[wiki-maintenance-loop]] のような scheduled job でも、将来的には実行中 agent の状態を別ループの入力にする余地がある。
|
||||
- **privacy boundary**: JSON snapshot は local dashboard 用の rich data を含み、working directory、tool-call preview、bounded/redacted chat text などを含み得るため、共有ログやネットワーク公開には追加の access control が必要だと README は明記している。
|
||||
|
||||
## Why it matters
|
||||
|
||||
Yuta のエージェント運用では、エージェント数が増えるほど「何が動いているか」「どの port を開いたままか」「rate limit や context が詰まっていないか」が品質・安全性の一部になる。abtop は、AI agent を便利な生成器としてだけでなく、観測・中断・移動・監査の対象として扱う方向を示している。
|
||||
@@ -0,0 +1,29 @@
|
||||
---
|
||||
title: Kiro
|
||||
created: 2026-06-30
|
||||
updated: 2026-06-30
|
||||
type: entity
|
||||
tags: [tool, agent, dev-tool, workflow]
|
||||
sources: [raw/articles/kiro-ide-1-0-agent-focus-2026.md]
|
||||
confidence: medium
|
||||
---
|
||||
|
||||
# Kiro
|
||||
|
||||
Kiro は Amazon の仕様駆動型 AI コーディング環境。開発者が仕様を定め、AI エージェントが実装タスクを分解し、人間が実行と承認を制御する前提の IDE / CLI / Web / iOS の道具群として説明されている。v1.0 では、従来の「コードを中心にしたエディタ」よりも、セッション、会話、spec、diff を中心に置く Agent Focus レイアウトが強調された。
|
||||
|
||||
[[loop-engineering]] の観点では、Kiro は仕様、タスク、差分、実行履歴、承認を作業画面に残すことで、エージェント作業を単発チャットではなく状態を持つ開発ループに近づけている。[[abtop]] が複数エージェントの外側から運用状態を観測する道具だとすると、Kiro は IDE 内にエージェント操作面を寄せる設計と言える。
|
||||
|
||||
## 重要な設計要素
|
||||
|
||||
- **Spec-driven workflow**: 仕様を起点に、AI エージェントが大小のタスクを立案し、人間が実行を制御する。
|
||||
- **Agent Focus**: 左にセッション、中央に会話、右に spec / diff を置き、コード編集よりエージェント指示を前面に出す。
|
||||
- **Capability-based permissions**: ファイル書き込み、コマンド実行、MCP ツール呼び出しなどを操作ごとに承認し、許可・拒否のルールを保存できる。これは [[ai-agent-identity-security]] の最小権限・監査の論点に近い。
|
||||
- **Markdown custom agents**: 専用エージェントを Markdown で定義し、MCP サーバーや権限ルールをプロフィールに埋め込める。
|
||||
- **Natural-language hooks**: ファイル保存や作成などを契機に、自然言語で定義したフックを自動化へ変換する。
|
||||
|
||||
## 見るべき問い
|
||||
|
||||
- Agent Focus 型 UI は、開発者がコードではなくエージェント操作を主作業にする流れを本当に強めるのか。
|
||||
- 承認ルールやカスタムエージェント定義をチームで共有したとき、便利さと権限管理の境界はどこで崩れやすいか。
|
||||
- [[ci-cd-runtime-security]] のような実行時監査と、IDE 内のエージェント承認ログをどう接続できるか。
|
||||
@@ -0,0 +1,28 @@
|
||||
---
|
||||
title: Litho
|
||||
created: 2026-06-30
|
||||
updated: 2026-06-30
|
||||
type: entity
|
||||
tags: [tool, wiki, knowledge-base, markdown, dev-tool, automation]
|
||||
sources: [raw/articles/litho-deepwiki-rs-code-documentation-2026.md]
|
||||
confidence: medium
|
||||
---
|
||||
|
||||
# Litho
|
||||
|
||||
Litho（`deepwiki-rs`）は、ソースコードから C4 model のアーキテクチャ図と Wiki 風ドキュメントを自動生成する Rust 製の AI 文書化エンジン。README では、コードベース解析、依存関係・構造抽出、LLM によるドキュメント生成、Mermaid 図、CI/CD 連携、外部知識の取り込みを特徴としている。
|
||||
|
||||
Yuta の Wiki 文脈では、これは [[digital-gardening-cms]] や [[llm-wiki-pattern]] と同じ「読むたびに都度検索する」のではなく、「コードから持続的に読める知識面を作る」方向の道具。ただし Litho は人間の研究 Wiki というより、コードベース理解・オンボーディング・設計書の鮮度維持に寄っている。
|
||||
|
||||
## Design implications
|
||||
|
||||
- 設計書が腐る問題を、手書きドキュメントではなくコード解析と生成のループで扱う。
|
||||
- C4 の context/container/component/code レベルを出力するため、単なる README 生成よりも構造化された設計理解を狙う。
|
||||
- CI/CD で毎コミット生成できると説明しており、[[wiki-maintenance-loop]] 的な継続更新をソフトウェア設計書に適用する例になる。
|
||||
- 生成物は便利だが、アーキテクチャ判断の正しさや命名の妥当性は別途レビューが必要。自動生成 Wiki は、信頼できる最終文書というより、保守される下書き・索引として扱うのが安全。
|
||||
|
||||
## Open questions
|
||||
|
||||
- 生成された C4 図や説明が、実際の設計意図とずれたときに誰がどう検証するか。
|
||||
- コードから抽出できない運用上の制約、歴史的経緯、暗黙の責務をどこで補うか。
|
||||
- LLM 生成ドキュメントを CI/CD に組み込む場合、差分レビューとノイズ抑制をどう設計するか。
|
||||
@@ -0,0 +1,24 @@
|
||||
---
|
||||
title: pi-coding-agent
|
||||
created: 2026-06-30
|
||||
updated: 2026-06-30
|
||||
type: entity
|
||||
tags: [tool, agent, dev-tool, cli, workflow]
|
||||
sources: [raw/articles/pi-coding-agent-2025.md]
|
||||
confidence: medium
|
||||
---
|
||||
|
||||
# pi-coding-agent
|
||||
|
||||
pi-coding-agent は、Mario Zechner が自分のために作った最小主義の AI coding agent harness。[[loop-engineering]] で重要になる context control、session serialization、provider handoff、token/cost tracking、headless JSON/RPC、HTML export などを、巨大な隠れ system prompt や不可視の sub-agent に寄せず、自分で観測・改造できる形に置くことを重視している。
|
||||
|
||||
## 設計上の特徴
|
||||
|
||||
- **小さい agent surface**: read / write / edit / bash を中心に、1000 token 未満の system prompt と最小の tool set で成立させようとする。これは [[abtop]] のような外部観測や、tmux での明示的なプロセス管理と相性がよい。
|
||||
- **provider abstraction**: `pi-ai` は Anthropic、OpenAI、Google、OpenAI-compatible provider などをまたいだ streaming、tool calling、thinking/reasoning、context handoff を扱う。各 provider の API 差分や token accounting の不安定さを、個人用に十分な粒度で吸収する設計になっている。
|
||||
- **context engineering first**: 既存 harness が裏で何を context に入れているか見えにくいことを問題視し、session format、tool result、UI 表示用 details を分けて扱う。これは [[ai-agent-identity-security]] の権限・監査論点とは別方向の、運用者が何を見て判断できるかという安全性である。
|
||||
- **terminal-native UI**: `pi-tui` は scrollback を活かす append 型 TUI と differential rendering を選び、full-screen TUI より端末本来の検索・スクロールに寄せる。coding agent をチャット型の線形作業として扱う判断が、実装の単純さにつながっている。
|
||||
|
||||
## Why it matters
|
||||
|
||||
Yuta の関心から見ると、pi-coding-agent の価値は「また一つ coding agent が増えた」ことではなく、agent harness をどこまで小さく、見える形で、ファイル・端末・tmux・README という既存道具に寄せられるかを実装で示している点にある。MCP や sub-agent、background bash、built-in todo をあえて持たない判断は、[[wiki-maintenance-loop]] のような自動化でも「状態をどこに残し、誰が見られるか」を考える材料になる。
|
||||
@@ -0,0 +1,33 @@
|
||||
---
|
||||
title: Scrutineer
|
||||
created: 2026-06-30
|
||||
updated: 2026-06-30
|
||||
type: entity
|
||||
tags: [tool, security, supply-chain, automation, quality, human-in-the-loop]
|
||||
sources: [raw/articles/scrutineer-oss-security-workflow-2026.md]
|
||||
confidence: medium
|
||||
---
|
||||
|
||||
# Scrutineer
|
||||
|
||||
Scrutineer は、オープンソースリポジトリを AI 支援で脆弱性スキャンし、検証、連絡先特定、修正案、開示、リリース確認までを一つのワークフローで扱うローカルツール。James Nesbitt の紹介記事では、LLM が脆弱性らしきものを大量に見つけられるようになった一方で、未検証の報告がメンテナの注意を消耗する問題を避けるため、モデルの出力を直接メンテナに送らない設計が強調されている。
|
||||
|
||||
この道具は [[ci-cd-runtime-security]] と同じ供給網防御の文脈にあるが、焦点は CI ジョブの実行時監視ではなく、OSS の脆弱性探索・検証・開示を人間のゲート付きで運用することにある。AI エージェントがコードを読む力を、[[ai-agent-identity-security]] 的な権限管理だけでなく、誰に何をいつ報告するかという社会的境界にも接続している。
|
||||
|
||||
## Workflow pattern
|
||||
|
||||
- スキャンは `SKILL.md`、JSON schema、補助 script からなる skill として定義される。
|
||||
- `triage` が先に走り、`security-deep-dive`、`threat-model`、`maintainers`、`patch`、`breaking-change`、`release-watch` などの skill を並列・段階的に起動する。
|
||||
- 深掘りは sink inventory を作り、敵対入力が trust boundary から到達できるかを確認してから finding にする。
|
||||
- finding は human gate を通って、検証、triage、開示文面、GitHub private vulnerability reporting、修正リリース確認へ進む。
|
||||
- patch skill は最小差分と regression test を提案するが、危険経路と正当利用の境界が読めないときは推測せず拒否する。
|
||||
|
||||
## Why it matters
|
||||
|
||||
Scrutineer の重要な設計判断は、「AI で見つける量」を増やすだけでなく、「AI が出したものをどこで止めるか」をワークフローに含めている点。これは [[loop-engineering]] の実例でもある。発見、検証、修正、開示、リリース監視という loop を、メンテナの受信箱ではなくローカルの操作面と状態管理に閉じ込め、外部に出す前に証拠と人間判断を要求する。
|
||||
|
||||
## Open questions
|
||||
|
||||
- skill 化された脆弱性探索が増えたとき、誤検知だけでなく「検証コスト」をどう測るか。
|
||||
- 人間 gate の担当者に必要な監査ログ、反証材料、再現手順をどこまで標準化できるか。
|
||||
- エコシステム横断スキャンを行う主体が、各プロジェクトの SECURITY.md や開示慣行をどれだけ尊重できるか。
|
||||
Reference in New Issue
Block a user