TigerStyle Skill
Coding style from TigerBeetle optimized for Safety > Performance > DX.
Usage Modes
| Invocation |
Mode |
Output |
/tiger-style |
Writing |
Guidance for writing new code |
/tiger-style analyze <file> |
Analysis |
Complete report: Aligned + Violations + Gray Areas |
/tiger-style check |
Quick check |
Violations only (brief) |
Mode Instructions
Writing Mode (/tiger-style)
When invoked without arguments, activate TigerStyle for all code you write or modify in this session:
- Read SAFETY.md, PERFORMANCE.md, and DX.md to load the full rule set.
- Apply all rules as you write Zig code. Every function you produce must have 2+ assertions (preconditions, postconditions, or invariants).
- Before presenting code to the user, validate it against CHECKLIST.md.
- If a rule would be violated, fix it before showing the code. If a gray area arises, flag it to the user.
Analyze Mode (/tiger-style analyze <file>)
When invoked with analyze and a file path:
- Read the file specified in
$ARGUMENTS (the path after analyze).
- Read SAFETY.md, PERFORMANCE.md, and DX.md for the complete rule set.
- Produce a structured report following the template in REPORT_FORMAT.md.
- Check every rule against the file. Be thorough - scan for all violation types, not just obvious ones.
- Group aligned patterns by category. Group violations by severity. Note gray areas with reasoning.
Check Mode (/tiger-style check)
When invoked with check:
- Scan the current file, staged changes, or recently modified Zig files.
- Report only violations, grouped by severity (CRITICAL first, then MAJOR, then MINOR).
- Skip aligned patterns and gray areas - keep output brief.
- Use the format:
SEVERITY | location | rule | issue (one line per violation).
Workflow
After analysis or check, guide the user through fixing:
- Fix CRITICAL violations first - these are safety risks.
- Fix MAJOR violations - these affect maintainability.
- MINOR violations are worth fixing but should not block progress.
- Run
/tiger-style check to verify fixes.
- Repeat until clean.
Quick Lookup
| Topic |
See |
Key Rules |
| Assertions |
SAFETY.md |
Min 2 per function, pair assertions, split compound |
| Control flow |
SAFETY.md |
No recursion, split compound conditions, every if has else |
| Memory |
SAFETY.md |
Static only, no dynamic after init |
| Function size |
SAFETY.md |
Max 70 lines |
| Types |
SAFETY.md |
Explicit sizes (u32 not usize) |
| Performance |
PERFORMANCE.md |
Design-time thinking, batching, buffer bleeds |
| Resources |
PERFORMANCE.md |
Network > disk > memory > CPU |
| Naming |
DX.md |
snake_case, units last, semantic richness |
| Formatting |
DX.md |
80 cols, 4-space indent, braces on ifs |
| Bug prevention |
DX.md |
Off-by-one, explicit division, options structs |
| Pre-submit |
CHECKLIST.md |
Quick validation checklist |
| Report format |
REPORT_FORMAT.md |
Analysis output template |
Our Customizations (vs pure TigerStyle)
| Rule |
TigerStyle |
Our Standard |
| Line length |
100 columns |
80 columns |
| Assertions |
2+ per function |
Same |
| Memory in structs |
Never store allocator |
Same + never store Io |
Severity Definitions
| Severity |
Criteria |
| CRITICAL |
Safety risk: missing assertions, unbounded loops, dynamic memory, ignored errors, missing else branches |
| MAJOR |
Maintainability: function too long, complex control flow, usize instead of explicit type |
| MINOR |
Style: naming, formatting, comments |
1---2name: tiger-style3description: TigerBeetle coding style for safety-critical Zig code. Use for writing new code aligned with TigerStyle, or analyzing existing code to produce structured reports showing aligned patterns, violations, and gray areas.4---56# TigerStyle Skill78Coding style from TigerBeetle optimized for **Safety > Performance > DX**.910## Usage Modes1112| Invocation | Mode | Output |13|------------|------|--------|14| `/tiger-style` | Writing | Guidance for writing new code |15| `/tiger-style analyze <file>` | Analysis | Complete report: Aligned + Violations + Gray Areas |16| `/tiger-style check` | Quick check | Violations only (brief) |1718## Mode Instructions1920### Writing Mode (`/tiger-style`)2122When invoked without arguments, activate TigerStyle for all code you write or modify in this session:23241. Read [SAFETY.md](SAFETY.md), [PERFORMANCE.md](PERFORMANCE.md), and [DX.md](DX.md) to load the full rule set.252. Apply all rules as you write Zig code. Every function you produce must have 2+ assertions (preconditions, postconditions, or invariants).263. Before presenting code to the user, validate it against [CHECKLIST.md](CHECKLIST.md).274. If a rule would be violated, fix it before showing the code. If a gray area arises, flag it to the user.2829### Analyze Mode (`/tiger-style analyze <file>`)3031When invoked with `analyze` and a file path:32331. Read the file specified in `$ARGUMENTS` (the path after `analyze`).342. Read [SAFETY.md](SAFETY.md), [PERFORMANCE.md](PERFORMANCE.md), and [DX.md](DX.md) for the complete rule set.353. Produce a structured report following the template in [REPORT_FORMAT.md](REPORT_FORMAT.md).364. Check every rule against the file. Be thorough - scan for all violation types, not just obvious ones.375. Group aligned patterns by category. Group violations by severity. Note gray areas with reasoning.3839### Check Mode (`/tiger-style check`)4041When invoked with `check`:42431. Scan the current file, staged changes, or recently modified Zig files.442. Report only violations, grouped by severity (CRITICAL first, then MAJOR, then MINOR).453. Skip aligned patterns and gray areas - keep output brief.464. Use the format: `SEVERITY | location | rule | issue` (one line per violation).4748## Workflow4950After analysis or check, guide the user through fixing:51521. Fix CRITICAL violations first - these are safety risks.532. Fix MAJOR violations - these affect maintainability.543. MINOR violations are worth fixing but should not block progress.554. Run `/tiger-style check` to verify fixes.565. Repeat until clean.5758## Quick Lookup5960| Topic | See | Key Rules |61|-------|-----|-----------|62| Assertions | [SAFETY.md](SAFETY.md) | Min 2 per function, pair assertions, split compound |63| Control flow | [SAFETY.md](SAFETY.md) | No recursion, split compound conditions, every if has else |64| Memory | [SAFETY.md](SAFETY.md) | Static only, no dynamic after init |65| Function size | [SAFETY.md](SAFETY.md) | Max 70 lines |66| Types | [SAFETY.md](SAFETY.md) | Explicit sizes (u32 not usize) |67| Performance | [PERFORMANCE.md](PERFORMANCE.md) | Design-time thinking, batching, buffer bleeds |68| Resources | [PERFORMANCE.md](PERFORMANCE.md) | Network > disk > memory > CPU |69| Naming | [DX.md](DX.md) | snake_case, units last, semantic richness |70| Formatting | [DX.md](DX.md) | 80 cols, 4-space indent, braces on ifs |71| Bug prevention | [DX.md](DX.md) | Off-by-one, explicit division, options structs |72| Pre-submit | [CHECKLIST.md](CHECKLIST.md) | Quick validation checklist |73| Report format | [REPORT_FORMAT.md](REPORT_FORMAT.md) | Analysis output template |7475## Our Customizations (vs pure TigerStyle)7677| Rule | TigerStyle | Our Standard |78|------|------------|--------------|79| Line length | 100 columns | **80 columns** |80| Assertions | 2+ per function | Same |81| Memory in structs | Never store allocator | Same + never store Io |8283## Severity Definitions8485| Severity | Criteria |86|----------|----------|87| **CRITICAL** | Safety risk: missing assertions, unbounded loops, dynamic memory, ignored errors, missing else branches |88| **MAJOR** | Maintainability: function too long, complex control flow, usize instead of explicit type |89| **MINOR** | Style: naming, formatting, comments |
m64github