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.
npx skills add yuri-semenenko/ai-engineering-workspace --skill rfcgit clone --depth 1 https://github.com/yuri-semenenko/ai-engineering-workspaceWrote 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/skills/yuri-semenenko/ai-engineering-workspace/rfc)<a href="https://agentmods.dev/skills/yuri-semenenko/ai-engineering-workspace/rfc"><img src="https://agentmods.dev/badge/skills/yuri-semenenko/ai-engineering-workspace/rfc.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.00083 | $0.00636 |
| Opus 5 | $0.00042 | $0.00318 |
| Sonnet 5 | $0.00017 | $0.00127 |
| Haiku 4.5 | $0.00008 | $0.00064 |
Grade A, and why
rfc 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 — 36 lines — stays where its author put it; the contents beside it link to each section on GitHub.
RFC
Produce an architecture RFC in the user's canonical format. The user is a Staff Engineer biased toward simplicity, FP, modular monoliths, and pragmatic DDD — challenge over-engineering inside the doc itself, do not defer it to review.
Steps
- Clarify scope before writing. If the input is vague ("RFC for caching"), ask 1-3 targeted questions: what problem prompted it, what's the current state, what's the deadline / urgency. Do not invent context.
- Read the repo if relevant —
package.json, top-level structure, existing ADRs/RFCs (docs/rfc/,docs/adr/,.docs/) to mirror naming and tone. - Draft all 10 sections. Do not skip any. If a section is genuinely empty, write
N/A — <one-line reason>rather than removing it. - Surface 2-3 realistic options. Never present a single recommendation as "the" answer. Include a "do nothing / defer" option when honest.
- Trade-offs must be concrete. Cost in dev hours, operational complexity, blast radius if it fails. No marketing prose.
- Recommendation must justify itself against the other options, not in isolation.
- Risks ≠ trade-offs. Risks are what could go wrong despite the right choice (regression, scope creep, dependency change, hiring gap).
Required sections (in order)
- Problem Statement — one paragraph, no jargon. What hurts today.
- Context — current architecture, team, constraints from history. Link to relevant code/docs.
- Constraints — hard limits (compliance, deadline, headcount, infra).
- Assumptions — explicit, refutable. Each one should be a sentence someone could disagree with.
- Options — 2-4 alternatives. Include status quo.
- Trade-offs — table preferred: option × (dev cost, ops cost, time-to-value, reversibility, risk).
- Recommendation — chosen option + why it beats each alternative.
- Risks — what we accept by choosing this. Include mitigations only where they're real.
- Migration Strategy — phased plan if non-trivial. Define rollback criteria.
- Open Questions — things this RFC explicitly does not answer.
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 · 36 lines · 83 tokens per session scan A e6b631bc0452
rfc is a skill published in the GitHub repository yuri-semenenko/ai-engineering-workspace (1 stars, last pushed 7d ago), licensed MIT. It adds 83 tokens to every session and 636 once invoked, about $0.0004 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 skills, from other repositories
rework-rate
Measure and interpret PR rework rate — the emerging 5th DORA metric.
My Skill
Content here.
task-generation
Reference material with the canonical task-format grammar and decomposition rules for plan-to-tasks expansion. Loaded on demand by generate-tasks; not directly invokable.
implementation-standards
Reference material with coding standards (defensive coding, error handling, testing patterns). Loaded on demand by the Developer sub-agent (.github/agents/developer.md); not directly invokable.
spec-authoring
Reference material for writing product, technical, and operational specifications (work-item priorities, requirement families, success criteria). Loaded on demand by specify-feature; not directly invokable.
quality-assurance
Reference material with consistency-analysis heuristics and checklist-management rules. Loaded on demand by analyze-compliance and quality-control; not directly invokable.