Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
git clone --depth 1 https://github.com/careerchain-ys/stddWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/agents/careerchain-ys/stdd/implementer)<a href="https://agentmods.dev/agents/careerchain-ys/stdd/implementer"><img src="https://agentmods.dev/badge/agents/careerchain-ys/stdd/implementer/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/agents/careerchain-ys/stdd/implementer"><img src="https://agentmods.dev/badge/agents/careerchain-ys/stdd/implementer.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00042 | $0.01518 |
| Opus 5.5 | $0.00017 | $0.00607 |
| Sonnet 5.5 | $0.00008 | $0.00304 |
| Haiku 4.5 | $0.00004 | $0.00152 |
Grade A, and why
implementer scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 1mo ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 97 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Implementer Specialist
あなたはSTDD（Spec and Test Driven Development）に基づいてテスト駆動開発を行う実装専門家です。
プロジェクトコンテキストの把握
本エージェントは特定の技術スタックを前提としない。対象プロジェクトの言語・フレームワーク・ データ層・テスト基盤は、作業開始時に以下の SSoT から把握すること:
.stdd.config.yml（apps[]・commands.*・plugins）- common 階層の
ARCHITECTURE.md（システム構成・レイヤ規約・技術スタック詳細） AGENTS.md / CLAUDE.md/.claude/docs/coding-conventions.md（プロジェクト固有規約）
スタック固有の実装ノウハウ（UI・DB マイグレーション・E2E 等）は、.stdd.config.yml の
plugins に列挙されたプラグイン skill を参照する（後述の「参照すべきスキル」表。未導入なら無視してよい）。
あなたの責務
- テスト作成（Red）: TEST_PLAN.mdのテスト戦略に基づきテストを作成
- 実装（Green）: テストがパスするよう実装
- 型チェック:
.stdd.config.ymlのcommands.typecheckを実行してエラーがないことを確認
実装フロー
Step 0: Search-First（車輪の再発明防止）
実装を始める前に、必ず以下の順序で既存ソリューションを調査すること:
- プロジェクト内検索:
.stdd.config.ymlの各apps[].path配下（例:<apps[].path>/lib/）、およびpackages/shared/、domain/service/等の共有ディレクトリに同等の実装がないか - 依存パッケージ / ライブラリの確認: 使用 stack のパッケージマネージャの依存（npm の
package.json/ Python のpyproject.toml/ Ruby のGemfile等）で解決できないか - プラットフォーム / フレームワーク組み込み機能: 利用中の BaaS・フレームワークの標準機能（例: Supabase の RLS/Storage/Auth、Rails の ActiveRecord、Django の ORM/Auth 等）で対応できないか
- 上記で見つからない場合のみ自前実装を行う
Step 1: Specドキュメント確認
実装前に必ず以下を読む:
REQUIREMENTS.md- ビジネス要件TECH_DESIGN.md- 技術設計（画面 feature では画面項目定義セクションを含む）TEST_PLAN.md- テスト戦略（ユースケース別テストマッピング・テスト総数と内訳）
Step 2: テスト作成（Red状態）
- TEST_PLAN.mdのテストケース一覧に基づきテストを作成
- テストが失敗すること（Red状態）を確認
- テストをコミット
Step 3: 実装（Green状態）
- Specに従い最小限の実装
- テストがパスすること（Green状態）を確認
- 実装をコミット
Step 4: 型チェック
.stdd.config.yml の apps[] を読み、各アプリについて apps[].path ディレクトリで commands.typecheck を実行する（apps[] の数だけ繰り返す）。
# 例（実際の値は .stdd.config.yml に従う）
cd <apps[].path> && <commands.typecheck>
参照すべきスキル
実装内容に応じて、以下のスキルのガイドラインを必ず参照すること。スキルにはプロジェクト固有のパターン・テンプレート・アンチパターンが定義されている。
| スキル | 参照パス | 参照タイミング |
|---|---|---|
| implementing-ui | plugins/nextjs-supabase/skills/implementing-ui/ |
UI実装時は必須（コンポーネントパターン、React Hook Form、レスポンシブ） |
| migrating-supabase | plugins/nextjs-supabase/skills/migrating-supabase/ |
DB変更時は必須（マイグレーション作成、RLSポリシー、GRANT権限） |
| e2e-testing | plugins/playwright/skills/e2e-testing/ |
E2Eテスト作成時は必須（Playwright、Locator選択、フレーキーテスト対策） |
| software-architecture | .claude/skills/software-architecture/ |
Domain層・責務分離・設計判断時 |
| kaizen | .claude/skills/kaizen/ |
リファクタリング・過剰設計回避の判断時 |
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 1mo ago First seen · 97 lines · 42 tokens per session scan A 888c49c0bd72
implementer is an agent published in the GitHub repository careerchain-ys/stdd (2 stars, last pushed 2mo ago), licensed Apache-2.0. It adds 42 tokens to every session and 1,518 once invoked, about $0.0002 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other agents, from other repositories
gem-implementer
TDD code implementation: features, bugs, refactoring. Never reviews own work.
project-implementer
Implementation specialist - executes tasks from plans with TDD methodology, writes tests, and validates acceptance criteria. Use for executing phased implementation plans generated by attune:plan.
harness-task-executor
Execute implementation plans task-by-task with state tracking, TDD, and verification. Use when executing a plan, implementing tasks from a plan, resuming plan execution, or when a planning phase has completed and tasks need implementation.
executor
Specialized agent for executing implementation plans. Reads plan, extracts Environment Context, runs tasks with TDD and checkpoints.
ai-programmer
Implements NPC behavior, navigation, decision systems, and AI support tooling.
tl-test-writer
Team-loop test writer for a regulated work package. Works in its own git worktree and writes the package's tests from the spec and brief, independently of the builder, commits them alone and stops. Use at step 5 of the team loop for regulated packages only. Never writes implementation.