チャットに指示を貼り付けてコードを生成し、結果を見て再度プロンプトを調整する。このサイクルは小さな修正には機能するが、アーキテクチャの変更やテスト・プルリクエスト作成を伴うタスクに拡張しようとすると急速に破綻する。エージェント型コーディング（agentic coding）を「ワークフロー」として再設計しようとしている動きが、開発者コミュニティで具体的な形を取り始めている。
「プロンプト連打」と「パイプライン」の違い
AIによるコード生成支援の多くは、会話履歴（スクロールバック）にコンテキストを保持している。セッションが途切れたり、トピックが変わったりすると、それまでの文脈が失われる。これを補うためにエンジニアは手動で「前回の続きですが…」と再説明するコストを払い続けることになる。
エージェント型ワークフローが目指すのは、このコンテキストの再構築コストを仕組みで取り除くことだ。具体的には、タスクを「要件定義→アーキテクチャ設計→実装→検証→レビュー→PR作成」という複数のステージに分割し、各ステージが終わるたびに読み返し可能なアーティファクト（成果物）を残す。ステージ単位で中断・再開できるため、翌朝にセッションを再開しても「どこまで進んでいたか」を人間の記憶に頼る必要がなくなる。
agentic-skills リポジトリの構造
シード記事で紹介されている `po8rewq/agentic-skills` は、このパイプライン思想を実装したPythonパッケージとCLIの組み合わせだ。リポジトリの構成は以下のように分けられている。
- `agentic/` : PythonパッケージとCLIエントリポイント
- `pipelines/` : パイプライン定義ファイル（`default.yaml`, `cheap.yaml`, `production.yaml`）
- `skills/` : 各ステージが使うMarkdown形式の指示書
- `templates/`, `scripts/` : セットアップ補助ファイル
オーケストレーション（複数の処理を連携させる制御）のロジックは共有リポジトリに集約し、各プロジェクトには最小限のファイルだけを置く設計になっている。プロジェクト側に必要なのは `agentic.yaml`、`.ai/skills/`、そして任意で `.ai/context/` と `.ai/memory/` だけだ。
この分離は、Gitリポジトリの観点から見ても自然な粒度に感じられる。ワークフロー定義はモノレポ的に一か所で管理し、プロジェクト固有のコマンドやコンテキストは各リポジトリが持つ。
設定ファイルが「境界線」として機能する
このツールの特徴的な点は、`agentic.yaml` という設定ファイルがモデルの動作境界を定義することだ。たとえば次のように書く。
project:
name: my-api
default_branch: main
providers:
default: claude-code
available:
claude-code: { command: claude }
forge:
provider: github
create_pr: true
commands:
install: pnpm install
lint: pnpm lint
typecheck: pnpm typecheck
test: pnpm test
build: pnpm buildこの設定を見ると、モデルが呼び出すプロバイダー（ここではClaude）、チェックとして実行するコマンド群、PRを作成するかどうかといった動作が一か所に収まっている。モデルは「ツールとして何でもやる」のではなく、「この設定ファイルが定めた枠の中で動く」という制約のもとで動作する。
類似するアプローチとして、GitHub ActionsのYAMLワークフローが思い浮かぶ読者もいるだろう。CI/CDパイプライン（コードの統合とデプロイを自動化する仕組み）が「何をいつ実行するか」を宣言的に定義するように、このツールはAIエージェントの行動範囲を宣言的に定義する。
既存のAIコーディングツールとの位置づけ
GitHub CopilotやCursorのようなIDEプラグイン型のツールは、主に「今開いているファイルの補完・編集」に特化している。複数ファイルにまたがるリファクタリングや、テストの実行結果をフィードバックとして次のステップに繋げるといった多段階の処理には向いていない。
Anthropicが提供するClaude CodeやDevinのようなエージェント型ツールは、より長い文脈で自律的に動けるが、「どのステージで何を出力すべきか」をユーザー側が制御する手段は限られている。`agentic-skills` はこのギャップを埋める位置に立つ。エージェントの能力を使いながら、パイプラインの構造はエンジニア側が定義できる。
フロントエンド開発の文脈では、`pnpm lint`、`pnpm typecheck`、`pnpm test` といったコマンドが設定例に登場していることから、TypeScriptを使うWebプロジェクトを想定した設計になっていることが読み取れる。Viteや Next.js のようなビルドツールを使う現代的なフロントエンドプロジェクトとも親和性は高いと見られる。
AIの生成物をそのまま信頼するのではなく、lintやtypecheckといった機械的な検証をパイプラインのゲート（通過条件）として組み込む発想は、テスト駆動開発の考え方に近い。人間が確認するレビューステージをパイプラインの一部として明示的に定義している点も、単なる自動化ツールと一線を画す設計上の選択だ。
プロンプトをどう書くかではなく、「どのステージにいて、次に何が存在すべきか」を問うワークフロー設計の視点は、今後のAI駆動開発の評価軸として定着していく可能性がある。