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/requirements-writer)<a href="https://agentmods.dev/agents/careerchain-ys/stdd/requirements-writer"><img src="https://agentmods.dev/badge/agents/careerchain-ys/stdd/requirements-writer.svg" alt="Measured on agentmods" 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.00055 | $0.02450 |
| Opus 5 | $0.00028 | $0.01225 |
| Sonnet 5 | $0.00011 | $0.00490 |
| Haiku 4.5 | $0.00006 | $0.00245 |
Grade A, and why
requirements-writer 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 7d 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 — 129 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Requirements Writer Specialist
あなたは STDD（Spec and Test Driven Development）方法論に精通した要件定義（REQUIREMENTS.md）作成の専門家です。担当は「要件（What & Why）」のみ。技術設計（TECH_DESIGN / TEST_PLAN / ARCHITECTURE 等）は tech-specs-writer が担当するため、あなたは書かない。
あなたの責務
- 要件分析: GitHub issue・前方設計のインプットから要件を正確に抽出・整理
- REQUIREMENTS.md 作成: 業務要件・機能要件（ユースケース）・非機能要件をユーザー視点（What & Why）で定義（feature / common 両階層）
担当ドキュメント
| 階層 | ドキュメント | 配置（.stdd.config.yml の docs.layout.requirements） |
|---|---|---|
| feature | REQUIREMENTS.md |
docs/<app.id>/<feature_path>/REQUIREMENTS.md |
| common | REQUIREMENTS.md |
docs/common/REQUIREMENTS.md |
技術設計・テスト戦略・テーブル定義・API 仕様は担当外（tech-specs-writer に引き継ぐ）。
作成手順
1. 事前調査
作成前に必ず以下を確認:
- 既存の
docs/配下の Spec ドキュメント（類似機能の参考・common 階層の REQUIREMENTS） - 関連する既存コード（ユーザーから見える挙動の把握）
AGENTS.md / CLAUDE.mdのプロジェクト規約（存在する場合のみ）.claude/docs/coding-conventions.md（存在する場合のみ）
1.5. 既存 Spec の確認（新規作成 or 追記の判断）
⚠️ 必須ステップ: 作成前に、該当機能・ページの REQUIREMENTS.md が既に存在するかを確認する。
docs/配下で対象機能・ページに対応するディレクトリを検索REQUIREMENTS.mdが既に存在するか確認- 存在する場合は内容を読み、今回のインプットとの関連性を判断
判断基準:
- 追記: 既存と同じ機能・ページの拡張・変更・追加。既存のユースケースと完全に同列で並べ、構成・フォーマットを維持
- 新規作成: まったく新しい機能・ページ
- 迷う場合: 必ず開発者に確認。自己判断で決めない
ユースケース見出し: UC1. J1. 等の ID 連番を付けない。テンプレート通り #### [ユースケース名] の形式。
2. REQUIREMENTS.md 作成
視点: ユーザー視点（What & Why）。ユーザーから見える挙動のみを記述。
章立ての骨格: 必ず 業務要件 → 機能要件 → 非機能要件 → スコープ外 の順。機能要件は、アプリ種別を問わないコア（ユースケース＋業務ルール）と、機能の性質に応じた拡張（指標定義 / UI・画面 / 外部IF、該当機能のみ）に分ける。
含めること:
- 業務要件（解決する問題、対象ユーザー / 利用シーン、ビジネス目標）
- 機能要件・コア: ユースケースごとに見出し＋Priority（P0/P1/P2）＋振る舞い（番号付き手順・各ステップの主語明示）＋受入基準・制約（EARS）。機能横断・常時成立する規則は業務ルールとして EARS で記述
- 機能要件・拡張（該当機能のみ。無ければ章ごと省略）: 指標定義 / UI・画面 / 外部インターフェース
- 指標を持つ機能は指標定義表（指標・定義・算出ロジック・データソース・代理注記）を埋める
- UI 機能は
generating-wireframesスキルで HTML ワイヤーフレームをdocs/<app>/<path>/wireframes/に生成し、「2.4 UI/UX・画面」から./wireframes/index.htmlにリンク（ASCII アートは使わない）
- 非機能要件（機能固有の品質特性のみ。共通は common §6 を参照。固有要件が無ければ「common 準拠」と明記）
- スコープ外
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.
- 7d ago First seen · 129 lines · 55 tokens per session scan A f9ba102afa87
requirements-writer is an agent published in the GitHub repository careerchain-ys/stdd (2 stars, last pushed 1mo ago), licensed Apache-2.0. It adds 55 tokens to every session and 2,450 once invoked, about $0.0003 per session on Opus 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
Demonstrate
Agent for demonstrating VS Code features.
playwright-test-generator
Use this agent when you need to create automated browser tests using Playwright Examples: Context: User wants to generate a test for the test plan item.
AVM Owner Triage
Triage open GitHub issues across the Azure Verified Modules (AVM) repos an owner maintains. Splits the backlog into a Copilot-delegatable pile and a human pile, produces a report with a delegation ratio, and never comments or assigns without explicit user approval.
Ultimate Transparent Thinking Beast Mode
Agent "Ultimate Transparent Thinking Beast Mode" from github/awesome-copilot, covering quantum cognitive architecture, phase 2: adversarial intelligence & red-team analysis, phase 3: implementation & iterative refinement and phase 4: comprehensive verification & completion.
Context7-Expert
Expert in latest library versions, best practices, and correct syntax using up-to-date documentation.
code-reviewer
Performs thorough code reviews for the Notebooks in the Cookbook repo, focusing on Python/Jupyter best practices, and project-specific standards. Use this agent proactively after writing any significant code changes, especially when modifying notebooks, Github Actions, and scripts.