Use when building fintech apps. Keywords: fintech, trading, decimal, currency, financial, money, transaction, ledger, payment, exchange rate, precision, rounding, accounting, 金融, 交易系统, 货币, 支付
Install with Tessl CLI
npx tessl i github:actionbook/rust-skills --skill domain-fintech64
Does it follow best practices?
If you maintain this skill, you can automatically optimize it using the tessl CLI to improve its score:
npx tessl skill review --optimize ./path/to/skillValidation for skill structure
Discovery
37%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This description has strong trigger term coverage with relevant financial keywords in multiple languages, but critically fails to explain what the skill actually does. It reads more like a tag list than a skill description, leaving Claude unable to understand the specific capabilities being offered.
Suggestions
Add concrete actions describing what the skill does, e.g., 'Handles decimal precision for monetary calculations, formats currencies, manages exchange rate conversions, implements double-entry ledger patterns.'
Restructure to follow the pattern: '[What it does]. Use when [triggers].' - move keywords into a natural 'Use when...' clause rather than listing them separately.
Specify the unique value this skill provides over general coding assistance, such as 'Prevents floating-point errors in financial calculations' or 'Implements banking-grade transaction handling.'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description only says 'Use when building fintech apps' without describing any concrete actions or capabilities. It lists keywords but doesn't explain what the skill actually does (e.g., handle decimal precision, format currencies, calculate exchange rates). | 1 / 3 |
Completeness | The description answers 'when' (building fintech apps) but completely fails to answer 'what' - there's no explanation of what capabilities or actions this skill provides. The keyword list hints at topics but doesn't describe functionality. | 1 / 3 |
Trigger Term Quality | Excellent coverage of natural keywords users would say: 'fintech', 'trading', 'currency', 'money', 'payment', 'transaction', 'ledger', 'exchange rate', 'accounting', plus Chinese equivalents. These are terms users would naturally use when needing financial functionality. | 3 / 3 |
Distinctiveness Conflict Risk | The financial/fintech domain is fairly specific and the extensive keyword list helps distinguish it, but 'building fintech apps' is broad enough that it could overlap with database skills, API skills, or general coding skills that might also apply to fintech contexts. | 2 / 3 |
Total | 7 / 12 Passed |
Implementation
72%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill effectively communicates fintech domain constraints and their Rust implications through well-organized tables and concise rules. The content excels at progressive disclosure and token efficiency, but would benefit from more executable code examples for patterns beyond the basic Currency type, and clearer step-by-step workflows for implementing financial transactions with validation checkpoints.
Suggestions
Add executable code examples for the event sourcing pattern and audit logging, not just the Currency newtype
Include a step-by-step workflow for implementing a financial transaction with explicit validation checkpoints (e.g., balance verification before transfer)
Add a concrete example showing checked arithmetic to prevent silent overflow, since this is listed as a common mistake
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is lean and efficient, using tables and code blocks to convey information densely. No unnecessary explanations of concepts Claude would already know; every section adds domain-specific value. | 3 / 3 |
Actionability | Provides one concrete, executable code example for the Currency type, but other patterns (event sourcing, audit logging, ledger) are described abstractly without implementation examples. The 'Design Patterns' table lists patterns without showing how to implement them. | 2 / 3 |
Workflow Clarity | The 'Trace Down' section shows conceptual flow from constraints to design, but lacks explicit step-by-step workflows for implementing fintech features. No validation checkpoints or feedback loops for financial operations that would benefit from them. | 2 / 3 |
Progressive Disclosure | Well-organized with clear sections, tables for quick reference, and explicit 'Related Skills' section pointing to other resources. Content is appropriately structured for an overview skill with one-level-deep references. | 3 / 3 |
Total | 10 / 12 Passed |
Validation
75%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 12 / 16 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
metadata_version | 'metadata' field is not a dictionary | Warning |
license_field | 'license' field is missing | Warning |
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
body_steps | No step-by-step structure detected (no ordered list); consider adding a simple workflow | Warning |
Total | 12 / 16 Passed | |
Table of Contents
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.