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 yarlson/yarstack --skill behavior-implementgit clone --depth 1 https://github.com/yarlson/yarstackWrote 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/yarlson/yarstack/behavior-implement)<a href="https://agentmods.dev/skills/yarlson/yarstack/behavior-implement"><img src="https://agentmods.dev/badge/skills/yarlson/yarstack/behavior-implement/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/skills/yarlson/yarstack/behavior-implement"><img src="https://agentmods.dev/badge/skills/yarlson/yarstack/behavior-implement.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.00074 | $0.00587 |
| Opus 5.5 | $0.00030 | $0.00235 |
| Sonnet 5.5 | $0.00015 | $0.00117 |
| Haiku 4.5 | $0.00007 | $0.00059 |
Grade A, and why
behavior-implement 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 yesterday.
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 — 30 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Test-Driven Implementation
Implement one coherent observable behavior and prove it with a test that failed before the change and passes after it.
Workflow
- Read the behavior contract, the repository instructions, the closest implementation and test patterns, and the callers of the code you will change.
- For tooling or infrastructure, prove the change with the native checks and skip the red test, unless those checks cannot show behavior that matters.
- Define the observable result, the side effects, and the state that must stay unchanged on failure. Rely only on the documented behavior of dependencies.
- Choose the smallest mechanism, and stop at the first option that works: no change, existing code, the standard library or platform, an installed dependency, or one clear line. Never drop validation, data-loss prevention, security, accessibility, or an explicit requirement to make the change smaller. If the contract needs much more scope than expected, explain the gap and ask for direction instead of building an approximation.
- Use
test-designwhen the test level, cases, or fixtures are not obvious. Otherwise extend the existing test pattern. - Write the smallest focused test in the repository's style, with the scenario values visible. Run it and confirm that it fails because the behavior is missing or wrong, not because of a setup, import, or compile error.
- Write the minimum production code that makes the test pass.
- For several cases, repeat steps 6 and 7 one case at a time.
- Refactor only where the new code needs it for clarity. Run the tests after each refactoring step.
- Run the surrounding tests and the checks that the repository requires. Use
crap-index-assesswhen the user asks for it or the repository's CRAP check covers the changed methods.
Never edit the new test or an existing test to make it pass. If a test seems wrong or the contract seems impossible, stop and explain why.
If a test is impractical for an in-scope behavior, say why before you edit, name the evidence that will replace it, and state the remaining risk. Do not build a test harness that grows the scope. Do not use this workflow for documentation, formatting, metadata, or generated-state changes that do not change behavior.
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.
- yesterday Changed · +1 lines · +29 tokens per session 192ec2fc0af0
- 1mo ago Changed · -1 lines · -3 tokens per session 9d74a241f605
- 1mo ago Changed 7b73324918a2
- 1mo ago First seen · 30 lines · 48 tokens per session scan A 22238808c4e0
behavior-implement is a skill published in the GitHub repository yarlson/yarstack (3 stars, last pushed today), licensed MIT. It adds 74 tokens to every session and 587 once invoked, about $0.0003 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 skills, from other repositories
gentle-ai
Use Gentle AI harness discipline for Pi work: clarify first, preserve OpenSpec artifacts, use strict TDD where available, delegate through subagents when useful, and protect review workload.
ring:running-dev-cycle
Running the backend dev cycle: implements every task in a rolling-wave plan.md (ring:writing-plans format) for a Go/TS service, driving specialist agents through Gate 0 implementation/TDD, Gate 8 parallel review, and Gate 9 validation per epic, elaborating later phases at each phase boundary. Use when starting or…
ring:instrumenting-streaming-events
Instrumenting streaming events: wires lib-streaming event emission end-to-end into a Lerian Go service via a 13-gate cycle (catalog, Builder bootstrap, Emit sites, outbox, HTTP manifest, NoopEmitter fallback, integration and chaos tests), dispatching ring:backend-go under TDD. Consumes the validated…
ring:implementing-tasks
Implementing a single planned task (Task N.M.T) end-to-end: selects the right backend agent by language and service type, drives one TDD RED->GREEN turn, then verifies coverage, lint, license headers, runtime, and delivery before handoff. Runs as Gate 0 before ring:reviewing-code. Use to drive ONE task inside an…
testing-strategy
Design test strategies and test plans with coverage targets. Complements /draft:coverage which measures what this skill plans. Auto-loaded by /draft:implement before TDD.
plan
Analyzes architecture, selects patterns, assesses testability, then decomposes work into ordered TDD tasks with exact verification commands and explicit acceptance mapping. Works from an approved spec (zuvo:brainstorm output) or directly from a user-provided description.