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 Intai/story-flow --skill review-story-against-ticketgit clone --depth 1 https://github.com/Intai/story-flowWrote 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/intai/story-flow/review-story-against-ticket)<a href="https://agentmods.dev/skills/intai/story-flow/review-story-against-ticket"><img src="https://agentmods.dev/badge/skills/intai/story-flow/review-story-against-ticket/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/intai/story-flow/review-story-against-ticket"><img src="https://agentmods.dev/badge/skills/intai/story-flow/review-story-against-ticket.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.00024 | $0.01025 |
| Opus 5 | $0.00012 | $0.00513 |
| Sonnet 5 | $0.00005 | $0.00205 |
| Haiku 4.5 | $0.00002 | $0.00103 |
Grade A, and why
Review a story markdown against a story tracker 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 — 48 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Review a story markdown against a story tracker
Instructions
- Fetch the story by its ticket ID (e.g. PROJ-123, 86d2uf1mh, 4821, AB#4821) using the project's story tracker MCP tools (Jira, ClickUp, Azure DevOps), to retrieve the complete story details including type, description, acceptance criteria, and subtasks, and download its attachments. If no story tracker MCP tool is available, tell the developer the project has no story tracker MCP server configured (
/mcpto check status) and ask them to paste the story details or drop the ticket argument — never guess at the story content. - Treat the ticket as a bug when its type is
Bug,Defect,Incidentor equivalent, or when it carries steps to reproduce with actual and expected behaviour. - For a bug ticket, also extract the steps to reproduce, and the actual and expected behaviour. Review the downloaded attachments for details the description omits.
- If the ticket is a bug, reproduce it before reviewing. Follow its steps to reproduce by driving the app with
mcp__plugin_story-flow_playwright__*tools, ormcp__plugin_story-flow_appium__*for a mobile app. Navigate relative to the base URL fromBASE_URL, falling back touse.baseURLin the project's @playwright.config.js. Note the failing step, the actual behaviour and any console or network errors. - If the bug does not reproduce, carry on reviewing and report it as a finding for the developer to confirm the environment, version, account or seed data.
- Read the local story markdown file using the Read tool.
- Compare the story content against the markdown file and identify discrepancies.
- Review the following aspects:
- Requirements Completeness: Verify all acceptance criteria and requirements from the story are documented in the markdown.
- Task Breakdown: Check that tasks in the markdown align with the story requirements and subtasks.
- Agent Assignments: Ensure tasks have appropriate agent assignments (Use backend-developer subagent to, Use frontend-developer subagent to, etc.).
- Technical Accuracy: Validate that the technical approach and implementation details match the story specifications.
- Root Cause Coverage (bug tickets): Using the reproduction findings, verify the tasks address the failing step and any console or network errors observed — flag tasks that only treat the symptom described in the ticket.
- Maintainability & Readability: Assess whether each task, as scoped, promotes maintainable code. Using the similar existing implementations found during Codebase Verification, flag tasks that would duplicate logic that already exists (should reuse an existing utility/component instead), or that over- or under-engineer relative to the codebase's established patterns. Prefer pure, single-responsibility units with meaningful naming. Do NOT review implemented code here (none exists yet) — only the intent and scope of the planned tasks.
- Redundant Unit Testing Tasks: Flag any tasks that are solely about writing or updating unit tests. Unit testing is automatically handled as part of each implementation task by the
implement-story-markdownskill — separate testing tasks create duplication and should be removed or merged into the relevant implementation tasks. - Task Dependency Ordering: Do NOT flag missing explicit task dependency ordering or parallel/sequential grouping. This is handled separately by the
analyze-task-dependenciesskill.
- Report findings with specific examples of what's missing, incomplete, or misaligned.
- Highlight any requirements from the story that are not reflected in the markdown.
- Note any tasks in the markdown that don't map to the story requirements.
- Task Implementation Summary: For each task in the markdown, provide a summary of what will be implemented:
- Describe the key changes, features, or components that will be built
- Codebase Verification:
- For files to modify: Confirm they exist and identify relevant code sections
- For new files: Verify target directories exist and check naming conventions against similar files
- For dependencies: Check that referenced modules, components, or APIs exist
- Identify similar existing implementations as reference patterns
- Implementability Assessment: Mark each task as:
- ✅ Doable - Can be implemented as described
- ⚠️ Needs Adjustment - Feasible with modifications (explain what)
- ❌ Blocked - Cannot be implemented (list blockers)
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 · 48 lines · 24 tokens per session scan A f7c638c36bcf
Review a story markdown against a story tracker is a skill published in the GitHub repository Intai/story-flow (12 stars, last pushed yesterday), licensed MIT. It adds 24 tokens to every session and 1,025 once invoked, about $0.0001 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
onboard
Interviews someone about a software project as a whole — the problem it solves, who it serves, what is in and out of scope, the hard constraints, and the domain vocabulary — and writes it up as a project constitution that every later feature specification inherits. Use this at the start of a project, before any…
fabrik-implement
Use when operating as the Fabrik Implement stage agent. This skill guides the implementation of a planned feature, following the task checklist to produce committed, tested, pushed code on a feature branch.
fabrik-plan
Use when operating as the Fabrik Plan stage agent. This skill guides the design of an implementation approach, producing a concrete plan with task checklist that the Implement stage will follow.
fabrik-setup
Bootstrap a project to use Fabrik (the GitHub-Project-driven SDLC pipeline orchestrator that drives Claude Code workers through Specify/Research/Plan/Implement/Review/Validate stages). Use this skill when the user wants to install, set up, initialize, or get started with Fabrik for the first time — especially when…
forge-prd
Generate a structured PRD (markdown + meta) for a non-trivial build and auto-create a ticket per acceptance criterion (Forge Mission Control Phase 2, WP3 "PRD generator"). Use before starting a non-trivial feature/build, typically right after Deep Learn Mode. Trigger on "write a PRD", "generate a PRD", "scope this…
ticket
Write or draft a minimal tracker ticket: a type/parent line, a terse " :" title, and 2 to 4 bullets of what should change and why in product language, and nothing else (no headings, no acceptance criteria, no Out-of-scope block, no verification gate). Project tokens read from .claude/harness/profile.md. Use when…