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 devantler-tech/agent-plugins --skill ways-of-workinggit clone --depth 1 https://github.com/devantler-tech/agent-pluginsWrote 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/devantler-tech/agent-plugins/ways-of-working)<a href="https://agentmods.dev/skills/devantler-tech/agent-plugins/ways-of-working"><img src="https://agentmods.dev/badge/skills/devantler-tech/agent-plugins/ways-of-working/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/devantler-tech/agent-plugins/ways-of-working"><img src="https://agentmods.dev/badge/skills/devantler-tech/agent-plugins/ways-of-working.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.00065 | $0.02076 |
| Opus 5.5 | $0.00026 | $0.00830 |
| Sonnet 5.5 | $0.00013 | $0.00415 |
| Haiku 4.5 | $0.00006 | $0.00208 |
Grade A, and why
ways-of-working 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 4d 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 — 136 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Ways of Working
Development Workflow
Development is agent-first — every change starts as a structured issue and flows through issue → plan → implement → test → review:
- Create an issue using the devantler-tech/.github issue templates:
- Feature — user story with acceptance criteria.
- Bug — expected vs actual behavior with reproduction steps.
- Chore — user story with acceptance criteria for general tasks.
- Kata — Improvement Kata for continuous improvement (problem → definition of awesome → target condition → actions).
- Plan — create a structured implementation plan from the issue before writing code.
- Implement — execute the plan following the practices in this skill (TDD, quality gates, GitHub Flow, CI/CD).
- Manual test — validate behavior hands-on before merging. Focus on UX: output must be well-presented and every piece of feedback (errors, warnings, prompts) must be actionable.
- Code review (optional) — CI's strict linting, scanning, and quality gates are the primary feedback loop, so manual review is not always required.
Testing
Follow the test-driven-development skill rigorously — write the test first, watch it fail, write minimal code to pass.
Application / Library Repositories
| Type | Tooling | When to run |
|---|---|---|
| Linting | Linters and linting runners (e.g. golangci-lint, eslint, MegaLinter) |
CI on every PR |
| Scanning | Security & quality scanners (e.g. CodeQL, Trivy, SonarQube) | CI on every PR |
| Unit tests | SDK test frameworks (e.g. go test, xunit, jest) |
CI on every PR |
| Integration tests | SDK test frameworks | CI on every PR |
| E2E / system tests | GitHub Actions workflows that exercise the app/binary/service as an end user would | CI on every PR; move to merge_group if the suite becomes too heavy |
| Benchmark tests | SDK benchmark frameworks (e.g. BenchmarkDotNet, go test -bench) |
CI on every PR |
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.
- 4d ago Changed · +6 lines 04e2c4ede3d7
- 1mo ago First seen · 130 lines · 65 tokens per session scan A 012169673802
ways-of-working is a skill published in the GitHub repository devantler-tech/agent-plugins (3 stars, last pushed today), licensed Apache-2.0. It adds 65 tokens to every session and 2,076 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
tdd
Test-driven development — the red-green-refactor discipline for code that's correct by design, not by accident. INVOKE PROACTIVELY whenever writing or changing code, fixing a bug, adding or structuring tests, or choosing what to mock — even when nobody says "TDD" or "tests". (Tests are code held to…
fhir-ci-quality
Generate or review FHIR validator CI workflows and derive candidate healthcare data-quality rules from local FHIR examples. Use when the user asks to add FHIR validation to GitHub Actions or another CI/CD system, create conformance quality gates, infer project conventions, or turn recurring validation expectations…
eval-authoring
This skill should be used when the user mentions "llm eval", "evaluation", "promptfoo", "deepeval", "regression test", "llm judge", "golden dataset", "eval suite", "test a prompt", or wants to prove a prompt/model change improved rather than regressed behavior. It provides a standardized methodology for authoring…
testing
Decide which tests to write, keep, and delete, and prove a change works before calling it done. Test only business logic and its corner cases. Run the real thing on every target before reporting a fix. Delete tests for removed or replaced behavior. Use when writing, adding, reviewing, or cleaning up tests or specs…
shift-left-testing
Move quality earlier in the development lifecycle. Covers dev/QA pairing patterns, Three Amigos sessions, TDD facilitation (Red-Green-Refactor), PR review checklists for testability, and Definition of Done with quality gates. Includes shift-left maturity model for team assessment. Use when: "shift left," "TDD,"…
building
Use when writing production code test-first: the RED-GREEN-REFACTOR cycle, false-RED detection, vertical slicing, scope escalation, test process discipline, and code generation patterns.