Name: payment-rails
Rating: 52.8 (1 reviews)
Author: membranedev

payment-rails

Payment Rails integration. Manage data, records, and automate workflows. Use when the user wants to interact with Payment Rails data.

Quality

59%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Medium

Suggest reviewing before use

Fix and improve this skill with Tessl

tessl review fix ./skills/payment-rails/SKILL.md

Quality

Content

57%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The content is actionable with copy-paste CLI commands and a clear connection state machine, but it inlines reference-grade detail that belongs in bundled files, over-explains the platform concept, and critically omits validation steps before destructive payout actions.

Suggestions

Add an explicit validate/verify checkpoint before running payout or batch actions (e.g. dry-run, confirm recipient, check status after run) since sending money is irreversible.

Move the detailed connection state machine and proxy options table into a references/ file, keeping SKILL.md a lean overview with one-level-deep links.

Trim the introductory paragraph that explains what Payment Rails/Trolley is and what payouts are, since Claude already knows this.

Dimension	Reasoning	Score
Conciseness	The body is mostly concrete CLI commands, but the intro paragraph pads with concepts Claude already knows ("Think of it as a tool for managing and streamlining outgoing payments...automating the complexities of international mass payouts"), placing it at "mostly efficient but includes some unnecessary explanation".	3 / 5
Actionability	It provides concrete, executable commands throughout (npm install, membrane login, connection ensure, action run with --input JSON, a proxy flags table), with only minor gaps from placeholder values like CONNECTION_ID and the thin "Popular actions" section.	4 / 5
Workflow Clarity	The connection flow has good state checkpoints (READY/BUILDING/CLIENT_ACTION_REQUIRED polling), but Payment Rails is a payout platform where running actions is destructive/irreversible, and the action-running workflow lacks any validation or verification step before sending payments, capping this dimension at 3 per the batch/destructive guideline.	3 / 5
Progressive Disclosure	Sections are well labeled, but the ~140-line body inlines detailed reference material (the connection state machine with nested clientAction fields and the proxy options table) that could live in separate files, and no bundle references are used at all.	3 / 5
	Total	13 / 20 Passed

Description

61%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

The description clearly identifies the niche and includes an explicit Use-when clause, but its capability verbs are generic and it lacks the natural payout/payment vocabulary users would actually say.

Suggestions

Replace generic verbs with concrete Payment Rails actions, e.g. "send payouts, manage recipients, and process batches".

Add natural trigger terms users say, such as "payouts", "mass payments", "recipients", and the "Trolley" brand name.

Sharpen the when clause with concrete triggers, e.g. "Use when the user wants to send payouts or manage Payment Rails/Trolley recipients and batches".

Dimension	Reasoning	Score
Specificity	The phrase "Manage data, records, and automate workflows" names the domain but the actions are generic rather than concrete (no "create payouts", "manage recipients", "process batches"), matching the "names the domain but actions are minimal or generic" anchor.	2 / 5
Completeness	It states both a what ("Payment Rails integration. Manage data, records, and automate workflows") and a when ("Use when the user wants to interact with Payment Rails data"), but the when clause is somewhat generic rather than a concrete trigger phrase, so it falls short of a 5.	4 / 5
Trigger Term Quality	"Payment Rails" is a relevant natural keyword, but the surrounding terms ("data", "records", "workflows") are generic and miss common variations users would say such as "payouts", "payments", "recipients", or the "Trolley" rebrand.	3 / 5
Distinctiveness Conflict Risk	"Payment Rails integration" paired with the "Payment Rails" trigger carves a clear, named niche with minimal overlap risk against unrelated skills.	5 / 5
	Total	14 / 20 Passed

Validation

93%

Warnings & errors only

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 15 / 16 Passed

Validation for skill structure

Criteria	Description	Result
frontmatter_unknown_keys	Unknown frontmatter key(s) found; consider removing or moving to metadata	Warning

	Total	15 / 16 Passed

Repository: membranedev/application-skills
Path: skills/payment-rails/SKILL.md
Commit: f484c82

Reviewed: 5 days ago

Table of Contents

Discovery Implementation Validation

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.