General-purpose coding policy for Baruch's AI agents
90
91%
Does it follow best practices?
Impact
90%
1.30xAverage score across 18 eval scenarios
Advisory
Suggest reviewing before use
alwaysApply: true in the rule file frontmatterapplyTo: — the rule has no narrowed scopedescription: is optional for always-on rules; add it when the README rules-table row needs a complement, otherwise the rule body's H1 + sections speak for themselvesalwaysApply: false in the rule file frontmatter and add applyTo:applyTo: syntax is "<glob list> — <natural-language clause>" — both halves required. Example: applyTo: "skills/**/SKILL.md — when authoring or modifying skills"globs: and paths: are accepted field-name aliases for applyTo: — the value still follows the em-dash glob+prose form; pick one field name per filedescription: is a rule summary, not a scoping mechanism — never put scope prose only in description: as a substitute for applyTo: on a conditional rulerules/, skills/, evals/ are good candidates)applyTo: is exclusionary at the model layer, so a too-narrow scope drops the broad bitsdependency-management covers two practices:
dependency-management to manifests would silently drop the code-level guidance, so the rule stays universalalwaysApply and applyTo: live only in the rule file frontmatter — .tessl-plugin/plugin.json lists rule paths in its rules array and carries no per-rule configdocs/tessl-rule-frontmatter.md is the repo-internal draft of additions for docs.tessl.io. The docs/ directory is .tesslignored and does not ship with the published plugin, so consumers read the integrated content on docs.tessl.io once it lands; until then, read the source on GitHub.tessl-plugin
evals
scenario-1
scenario-2
scenario-3
scenario-4
scenario-5
scenario-6
scenario-7
scenario-8
scenario-9
scenario-10
scenario-11
scenario-12
scenario-13
scenario-14
scenario-15
scenario-16
scenario-17
scenario-18
rules
skills
adopt-fork-pr
eval-curation
install-reviewer