toga-ai 1.0.704 → 1.0.705
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.
|
@@ -21,6 +21,10 @@ answers. This applies to **all** developers, **both** frameworks, and **every**
|
|
|
21
21
|
|
|
22
22
|
This is a team directive, not a style tip. Follow it by default.
|
|
23
23
|
|
|
24
|
+
> **Now enforced always-on.** The short, hard version lives in `rules/common/communication.md`,
|
|
25
|
+
> which loads in **every** session (not just kickoff). This doc is the fuller reference; the
|
|
26
|
+
> rule file is what binds. Keep the two in sync.
|
|
27
|
+
|
|
24
28
|
## The rules
|
|
25
29
|
|
|
26
30
|
1. **Be short.** Say the thing, then stop. Cut every sentence that does not help the reader
|
|
@@ -52,6 +56,9 @@ Long, wordy, jargon-heavy answers are hard and tiring to read, especially for no
|
|
|
52
56
|
English speakers. The team moves faster when Claude is brief and plain. Clear beats clever.
|
|
53
57
|
|
|
54
58
|
## Change history
|
|
59
|
+
- 2026-08-31 — Moved the hard, short version to always-on `rules/common/communication.md` so it
|
|
60
|
+
loads every session, not just some kickoffs. Team was still finding output too long and too
|
|
61
|
+
complex; the on-demand-only load was part of why. (jcardinal)
|
|
55
62
|
- 2026-08-05 — Standard recorded: keep all communication short, clear, and plain; avoid
|
|
56
63
|
obscure jargon (e.g. "sargability"); lead with the answer; stay technical but brief.
|
|
57
64
|
Team-wide, both frameworks. (jcardinal)
|
package/package.json
CHANGED
|
@@ -0,0 +1,34 @@
|
|
|
1
|
+
# Communication Rules
|
|
2
|
+
|
|
3
|
+
You talk to the whole team. Many teammates read English as a second language, and long
|
|
4
|
+
answers tire them out or lose them. So keep every message short, plain, and clear — in your
|
|
5
|
+
thinking, your plans, and your final answers. This is a hard team rule, not a style tip.
|
|
6
|
+
|
|
7
|
+
**Clear with more words beats clever with fewer. But short and clear is the goal.**
|
|
8
|
+
|
|
9
|
+
## The rules
|
|
10
|
+
|
|
11
|
+
1. **Cut words.** Say the point, then stop. Delete any sentence that does not help the reader
|
|
12
|
+
do something or decide something. One line is better than three.
|
|
13
|
+
2. **Use common words.** Pick the everyday word over the fancy one. If a simpler word means
|
|
14
|
+
the same thing, use it.
|
|
15
|
+
3. **Drop the jargon.** Do not use rare technical words (like "idempotent", "cardinality",
|
|
16
|
+
"sargable", "orthogonal", "canonical"). Say what they mean in plain words instead.
|
|
17
|
+
- Bad: "make the query sargable"
|
|
18
|
+
- Good: "let the query use the index — don't wrap the indexed column in a function"
|
|
19
|
+
4. **Answer first.** Put the main point in the first line. Reasons come after, only if needed.
|
|
20
|
+
No long wind-up.
|
|
21
|
+
5. **Use lists.** More than two parts? Use a numbered or bulleted list, not a paragraph.
|
|
22
|
+
6. **Stay technical, stay exact.** Keep the real detail — file names, error text, exact steps.
|
|
23
|
+
Short does not mean vague. Be brief AND precise.
|
|
24
|
+
|
|
25
|
+
## Check before you send
|
|
26
|
+
|
|
27
|
+
- Can I cut half the words and keep the meaning? Cut them.
|
|
28
|
+
- Is there a rare word a non-native reader might miss? Swap it.
|
|
29
|
+
- Is my main point in the first line? If not, move it up.
|
|
30
|
+
|
|
31
|
+
## Why
|
|
32
|
+
|
|
33
|
+
Wordy, jargon-heavy output is hard and slow to read — worse for non-native English readers.
|
|
34
|
+
The team moves faster when you are brief and plain. Clear beats clever.
|