Create tessl tiles with docs, rules, and skills.
Does it follow best practices?
Evaluation — 97%
↑ 1.98xAgent success when using this tile
Validation for skill structure
Rules tell agents how to behave. They're loaded into the agent's instruction context.
Rules are for critical behavioral guidance only. Most content belongs in docs or skills instead.
| Content Type | Use For | Example |
|---|---|---|
| Docs | Facts, knowledge, reference | API documentation, schemas |
| Skills | Procedures, workflows | Deployment process, code generation |
| Rules | Must-follow constraints | Security requirements, naming conventions |
Ask yourself: Is this a constraint the agent must always follow, or information it should know? Constraints → rules. Information → docs.
Rules consume context on every request. Keep them minimal:
Good rule content:
# API Error Responses
Return errors as:
\`\`\`json
{"error": {"code": "ERROR_CODE", "message": "Description"}}
\`\`\`
Status codes: 400 (validation), 401 (auth), 403 (forbidden), 404 (not found), 500 (server)Bad rule content: Multi-page explanations of why these patterns matter, history of error handling approaches, comparisons with alternatives.
rules/
├── security.md # Critical security constraints
└── code-style.md # Core conventions (if truly essential)Each rule is a separate file referenced in tile.json under steering.
Every rule file requires frontmatter:
| Field | Required | Description |
|---|---|---|
alwaysApply | Yes | true = always loaded, false = conditional |
description | If alwaysApply: false | Trigger description (2-3 sentences, include "Use when") |
Use sparingly - these load on every request:
---
alwaysApply: true
---
# Security
- Never log secrets or credentials
- Sanitize all user input before database queries
- Use parameterized queries, never string concatenationLoaded only when the trigger matches:
---
description: Database migration patterns. Use when creating or modifying database schemas.
alwaysApply: false
---
# Migrations
1. Include both up and down migrations
2. Use transactions for data modifications
3. Test on copy of production data firstThe description acts as a trigger. Be specific:
Good:
description: TypeScript error handling patterns. Use when implementing try/catch or error types.Bad:
description: Error handling guide.{
"steering": {
"security": { "rules": "rules/security.md" },
"migrations": { "rules": "rules/migrations.md" }
}
}