Getting it into your agent
It runs from inside its repository, so the clone comes first — what it calls does not travel with the file alone.
git clone --depth 1 https://github.com/addxai/enterprise-harness-engineeringnpx agentmods add skills/addxai/enterprise-harness-engineering/uat-story-writerWrote 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/addxai/enterprise-harness-engineering/uat-story-writer)<a href="https://agentmods.dev/skills/addxai/enterprise-harness-engineering/uat-story-writer"><img src="https://agentmods.dev/badge/skills/addxai/enterprise-harness-engineering/uat-story-writer/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/addxai/enterprise-harness-engineering/uat-story-writer"><img src="https://agentmods.dev/badge/skills/addxai/enterprise-harness-engineering/uat-story-writer.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.00104 | $0.01796 |
| Opus 5 | $0.00052 | $0.00898 |
| Sonnet 5 | $0.00021 | $0.00359 |
| Haiku 4.5 | $0.00010 | $0.00180 |
Grade A, and why
uat-story-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 12d 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 — 160 lines — stays where its author put it; the contents beside it link to each section on GitHub.
UAT Story Writer
Discover missing UAT test scenarios from real user usage contexts and output structured user story documents.
Core philosophy: UAT tests start from user stories, not from technical implementation. "Checking order status while on the go" reveals real needs better than "HTTP API test."
Rules
- User perspective first: Each scenario must correspond to a real user behavior or usage context, not a technical condition. Technical conditions are the scenario's background, not the scenario itself
- Do not fabricate when information is lacking: Key constraints like test environment capabilities and actual topology must be obtained through interviews, not assumed
- Acceptance criteria must be executable: Each AC uses Gherkin Given/When/Then format, ensuring automation tools can directly consume them
- Output to cases/ directory: User stories go in the project's
cases/directory;features/directory is reserved for AI-generated executable automation cases - Follow story-craftsman template: File structure strictly follows the story-craftsman template format (background, goals, roles, user stories, progress, update log)
Execution Flow
Step 1: Explore Existing Test Coverage
First understand the project's existing test cases and find coverage gaps:
- Read related
.featurefiles underfeatures/scenarios/to understand existing scenarios - Read existing user story files under
cases/to avoid duplication - List the currently covered scenario inventory and clearly indicate the missing dimensions
Step 2: Guided Interview (one question at a time, multiple-choice preferred)
Confirm key constraints through questioning — ask only one question at a time, preferring multiple-choice options:
| Dimension | Purpose | Example Question |
|---|---|---|
| Test environment capability | Determine scenario granularity | "Can your test environment simulate network conditions? A) Router/firewall control B) Physical switching only C) Both" |
| Actual usage topology | Determine coverage scope | "Which of the following do you actually encounter? A) Local network B) Mobile remote C) Cross-network D) All of the above" |
| Focus dimension | Determine acceptance depth | "Are you focused on functionality only or also on experience metrics? A) Functionality only B) Also experience C) Both" |
| Variable control | Determine what is under test | "Which end is the variable you can control? Phone side? Device side? Or both?" |
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.
- 12d ago First seen · 160 lines · 104 tokens per session scan A 16082f3726c4
uat-story-writer is a skill published in the GitHub repository addxai/enterprise-harness-engineering (44 stars, last pushed 4mo ago), licensed Apache-2.0. It adds 104 tokens to every session and 1,796 once invoked, about $0.0005 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-30.
Other skills, from other repositories
screen-reader-testing
Test web applications with screen readers including VoiceOver, NVDA, and JAWS. Use when validating screen reader compatibility, debugging accessibility issues, or ensuring assistive technology support.
e2e-testing-patterns
Master end-to-end testing with Playwright and Cypress to build reliable test suites that catch bugs, improve confidence, and enable fast deployment. Use when implementing E2E tests, debugging flaky tests, or establishing testing standards.
browser-testing-with-devtools
Tests in real browsers via Chrome DevTools MCP. Use when building or debugging anything that runs in a browser. Use when you need to inspect the DOM, capture console errors, analyze network requests, profile performance, or verify visual output with real runtime data. Requires the chrome-devtools MCP server to be…
designing-tests
Designs and implements testing strategies for any codebase. Use when adding tests, improving coverage, setting up testing infrastructure, debugging test failures, or when asked about unit tests, integration tests, or E2E testing.
agent-browser
Automates browser interactions for web testing, form filling, screenshots, and data extraction. Use when the user needs to navigate websites, interact with web pages, fill forms, take screenshots, test web applications, or extract information from web pages.
qa/e2e-playwright
A method for writing Playwright end-to-end tests, which automate a browser to verify complete user journeys. It covers setup, reusable page objects, login reuse, API mocking, visual checks, multiple browsers and screen sizes, CI, and debugging.