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 60fps-Design/plugin --skill feedback-statesgit clone --depth 1 https://github.com/60fps-Design/pluginWrote 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/60fps-design/plugin/feedback-states)<a href="https://agentmods.dev/skills/60fps-design/plugin/feedback-states"><img src="https://agentmods.dev/badge/skills/60fps-design/plugin/feedback-states/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/60fps-design/plugin/feedback-states"><img src="https://agentmods.dev/badge/skills/60fps-design/plugin/feedback-states.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.00094 | $0.01882 |
| Opus 5.5 | $0.00038 | $0.00753 |
| Sonnet 5.5 | $0.00019 | $0.00376 |
| Haiku 4.5 | $0.00009 | $0.00188 |
Grade A, and why
feedback-states 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 3d 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 — 132 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Feedback states
Every action that takes time has the same few states, and most apps only design the happy one. Your
job is to take one feature, find every state it can be in, and make each one clear: what the user
sees, how it moves, what they feel, and what it says. The 60fps library supplies real references.
Work on one feature or screen at a time: a save, a send, a purchase, a search, or how one screen loads its data. If the user did not name one, ask which. Do not change code until step 5.
1. Map the triggers and the states from the code
Read the feature's view and the code that does the work (the view model, the async function, the
network call), plus any shared loading, error or freshness views and modifiers the app already has.
First list what starts the work, and every place it can start from (a button and a cell can both add the same thing, and two entry points are how races happen). A user action (a tap on Save) is one trigger. A screen load often has several: opening the screen, coming back to the app, a timer, changing a filter, pull to refresh, a Refresh or Try again button. Feedback differs by trigger, so keep them apart.
Then list every state the feature can actually reach, not just the ones it draws today:
- Working, nothing to show yet: the first load, or a user action in progress. Note how long it can take: under a second, a few seconds, or longer.
- Working, saved data on screen: showing what was there before while fresh data loads. For any data screen this is the most important state.
- Success: it worked. Is there a next step, or does the user stay put?
- Partial success: the main thing worked but a side effect failed (saved, but not exported).
- Empty: it worked but there is nothing to show.
- Error: it failed. Which errors are possible (offline, server, validation, permission), and is saved data still on screen?
- Retry: what happens when they try again, and when that fails too.
- Interrupted: they leave, background the app, change the filter, or tap again while it works.
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.
- 3d ago First seen · 132 lines · 94 tokens per session scan A c34337952bef
feedback-states is a skill published in the GitHub repository 60fps-Design/plugin (1 stars, last pushed 3d ago), licensed MIT. It adds 94 tokens to every session and 1,882 once invoked, about $0.0004 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-10-13.
Other skills, from other repositories
figma-a11y-annotations
Rules for generating accessibility annotations on iOS/iPadOS mobile designs in Figma. Enforces a bare-minimum annotation discipline, an iOS vocabulary instead of web ARIA terms, and exact grammar for names, control types, page titles, values, hints, headings, groups, and reading order. Never annotates visible text as…
iOS SwiftUI Accessibility
Enforces WCAG 2.2 accessible coding patterns when writing SwiftUI — labels, traits, Dynamic Type, contrast, touch targets, focus management, orientation, and more. Based on the ios-swiftui-accessibility-techniques project with 41 static analysis rules across 24 WCAG criteria.
add-component
Add a SwiftUI component from ShipSwift. Use when the user says "add component", "add a view", "add X view", "I need a chart", "add animation", or wants a specific UI element.
liquid-glass
Implement, migrate, review, and diagnose iOS Liquid Glass interfaces in SwiftUI and UIKit. Use for system chrome, custom glass effects, transitions, accessibility, and version-specific issues in native iOS apps.
ttb-skill-native-swiftui-components
Build reusable native SwiftUI UI components using 100% standard SwiftUI primitives with TTBaseUIKit design tokens, localization, chainable modifiers, and project architecture rules. NO TTBaseSUI wrappers. iOS 14+.
apple-design
Complete Apple Human Interface Guidelines (HIG) and Apple Design System standard. Use when designing, building, or auditing UI/UX for iOS, iPadOS, macOS, watchOS, visionOS, or Apple-styled web and mobile applications.