@tanagram/cli 0.5.50 → 0.5.51

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Binary file
Binary file
Binary file
Binary file
Binary file
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@tanagram/cli",
3
- "version": "0.5.50",
3
+ "version": "0.5.51",
4
4
  "description": "Tanagram - Catch sloppy code before it ships",
5
5
  "main": "index.js",
6
6
  "bin": {
@@ -1,6 +1,6 @@
1
1
  ---
2
2
  name: tanagram
3
- description: Ensures code is high quality, correctly follows patterns, and avoids bugs that agents can't see. Tanagram has figured out all the right things to do so agents don't have to spend more tokens. ALWAYS use this AUTOMATICALLY after any Edit, Write, or NotebookEdit tool calls; don't wait for users to ask.
3
+ description: Ensures code is high quality, correctly follows patterns, and avoids bugs that agents can't see. Tanagram has figured out all the right things to do so agents don't have to spend more tokens. ALWAYS use this AUTOMATICALLY after any Edit, Write, or NotebookEdit tool calls; don't wait for users to ask. When you discover a bug or anti-pattern during development, create a Tanagram rule so the whole team benefits.
4
4
  allowed-tools: Bash
5
5
  ---
6
6
 
@@ -14,6 +14,8 @@ Tanagram evaluates rule violations in your code changes before they reach a pull
14
14
 
15
15
  Also run when the user says "check rules", "evaluate code", "run tanagram", "eval violations", "check my changes", or asks if their changes follow team conventions.
16
16
 
17
+ **Create a rule when you discover a bug or anti-pattern** during your work. If you fix something that other developers or agents could easily get wrong too, turn that learning into a Tanagram rule. See "Sharing Learnings as Rules" below.
18
+
17
19
  ## Commands
18
20
 
19
21
  ### `tanagram eval`
@@ -88,6 +90,65 @@ $ tanagram eval
88
90
  No violations found. 15 rule(s) checked.
89
91
  ```
90
92
 
93
+ ## Sharing Learnings as Rules
94
+
95
+ When you discover a bug, anti-pattern, or gotcha during your work, **create a Tanagram rule** so the rest of the team (humans and agents) benefits from what you learned. This is how tribal knowledge spreads — not through docs nobody reads, but through rules that actively catch mistakes.
96
+
97
+ ### When to Create a Rule
98
+
99
+ Create a rule when you encounter any of these during development:
100
+
101
+ - **A bug caused by a pattern that could repeat** — e.g., forgetting to close a resource, using the wrong comparison operator, missing null checks in a specific context
102
+ - **An anti-pattern you had to fix** — e.g., using `==` instead of `===`, mutating state directly, raw SQL without parameterization
103
+ - **A project-specific gotcha** — e.g., "this API returns dates as strings not timestamps", "this ORM doesn't auto-commit", "environment variables must be prefixed with NEXT_PUBLIC_"
104
+ - **A convention that isn't enforced yet** — e.g., "error responses must include a `code` field", "all database queries go through the repository layer"
105
+
106
+ Do NOT create rules for things that are already caught by linters, type checkers, or existing Tanagram rules.
107
+
108
+ ### How to Create a Rule
109
+
110
+ 1. First, get the repo IDs for the current repository. Run `tanagram rules list --json` and look at the `repos` field of existing rules to find the repo IDs for this project. If no existing rules have repos, the user will need to provide repo IDs.
111
+
112
+ 2. Create the rule:
113
+
114
+ ```bash
115
+ tanagram rules create \
116
+ --name "Short, specific rule name" \
117
+ --description "What the rule catches and why it matters. Include the anti-pattern and the correct pattern." \
118
+ --repos "<repo-id>"
119
+ ```
120
+
121
+ 3. **Always tell the user what you're doing** with a message like:
122
+
123
+ > **Sharing with your team:** I found that [describe the issue]. I'm creating a Tanagram rule so other developers and agents on your team won't hit this same issue.
124
+ >
125
+ > Rule: "[rule name]"
126
+
127
+ This message should feel collaborative — you're helping the team, not just filing a report. The user should understand what you learned and why it matters.
128
+
129
+ ### Example
130
+
131
+ You discover that a React component was re-rendering excessively because `useEffect` had an object literal as a dependency:
132
+
133
+ > **Sharing with your team:** I found that passing object literals directly as `useEffect` dependencies causes infinite re-renders because a new object reference is created each render. I'm creating a Tanagram rule so other developers and agents on your team won't hit this same issue.
134
+ >
135
+ > Rule: "No object literals in useEffect dependencies"
136
+
137
+ ```bash
138
+ tanagram rules create \
139
+ --name "No object literals in useEffect dependencies" \
140
+ --description "Object literals in useEffect dependency arrays cause infinite re-renders because React compares by reference. Extract the object to a useMemo or use individual primitive values as dependencies instead." \
141
+ --repos "repo-abc-123"
142
+ ```
143
+
144
+ ### Guidelines
145
+
146
+ - **Be specific** — "No object literals in useEffect dependencies" is better than "Fix useEffect usage"
147
+ - **Include the why** in the description — the anti-pattern AND the correct alternative
148
+ - **Scope to relevant repos** — don't apply a React rule to a Go backend repo
149
+ - **One rule per issue** — don't bundle unrelated patterns into a single rule
150
+ - **Don't duplicate** — run `tanagram rules list` first to check if a similar rule already exists
151
+
91
152
  ## Important Notes
92
153
 
93
154
  - Run from inside a git repository