@tekmidian/pai 0.3.1 → 0.3.2
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.
package/package.json
CHANGED
package/src/hooks/pre-compact.sh
CHANGED
|
@@ -8,6 +8,10 @@
|
|
|
8
8
|
|
|
9
9
|
PAI_OS="pai"
|
|
10
10
|
|
|
11
|
+
# Set tab color to working state while compacting
|
|
12
|
+
TAB_COLOR="${PAI_DIR:-$HOME/.claude}/tab-color-command.sh"
|
|
13
|
+
[[ -x "$TAB_COLOR" ]] && "$TAB_COLOR" working
|
|
14
|
+
|
|
11
15
|
# Bail gracefully if pai is not installed
|
|
12
16
|
command -v "$PAI_OS" &>/dev/null || exit 0
|
|
13
17
|
command -v sqlite3 &>/dev/null || exit 0
|
|
@@ -90,4 +90,8 @@ fi
|
|
|
90
90
|
|
|
91
91
|
"$PAI_OS" session handover "$PROJECT_SLUG" latest 2>/dev/null || true
|
|
92
92
|
|
|
93
|
+
# Set tab color to completed state when session ends
|
|
94
|
+
TAB_COLOR="${PAI_DIR:-$HOME/.claude}/tab-color-command.sh"
|
|
95
|
+
[[ -x "$TAB_COLOR" ]] && "$TAB_COLOR" completed
|
|
96
|
+
|
|
93
97
|
exit 0
|
|
@@ -0,0 +1,58 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: AI Steering Rules
|
|
3
|
+
description: Universal behavioral rules for AI assistants. Loaded at startup to enforce quality standards.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
<!-- Generated by PAI Setup -->
|
|
7
|
+
|
|
8
|
+
# AI Steering Rules
|
|
9
|
+
|
|
10
|
+
These rules apply to ALL responses, ALL tasks, ALL contexts. They are non-negotiable.
|
|
11
|
+
|
|
12
|
+
## Surgical Fixes Only
|
|
13
|
+
|
|
14
|
+
- Make every change as simple as possible
|
|
15
|
+
- Impact minimal code — don't refactor unrelated areas
|
|
16
|
+
- The best solution is often the simplest one
|
|
17
|
+
|
|
18
|
+
## Never Assert Without Verification
|
|
19
|
+
|
|
20
|
+
- Don't claim something works without proving it
|
|
21
|
+
- Run tests, check logs, demonstrate correctness
|
|
22
|
+
- "I believe this should work" is not verification
|
|
23
|
+
|
|
24
|
+
## One Change When Debugging
|
|
25
|
+
|
|
26
|
+
- Change ONE thing at a time when debugging
|
|
27
|
+
- Verify after each change before moving on
|
|
28
|
+
- If you change three things and it works, you don't know which fixed it
|
|
29
|
+
|
|
30
|
+
## Read Before Modifying
|
|
31
|
+
|
|
32
|
+
- Always read a file before editing it
|
|
33
|
+
- Understand existing patterns before suggesting changes
|
|
34
|
+
- Never propose changes to code you haven't seen
|
|
35
|
+
|
|
36
|
+
## Find Root Causes
|
|
37
|
+
|
|
38
|
+
- No temporary fixes, no workarounds, no "good enough for now"
|
|
39
|
+
- If a fix feels hacky, stop and find the elegant solution
|
|
40
|
+
- Treat symptoms only as diagnostic clues, not as things to patch
|
|
41
|
+
|
|
42
|
+
## Prove It Works
|
|
43
|
+
|
|
44
|
+
- For bug fixes: show the error before, show it fixed after
|
|
45
|
+
- For features: demonstrate end-to-end functionality
|
|
46
|
+
- For refactors: prove behavior is unchanged
|
|
47
|
+
|
|
48
|
+
## Don't Over-Engineer
|
|
49
|
+
|
|
50
|
+
- Only make changes that are directly requested or clearly necessary
|
|
51
|
+
- Don't add features, refactor code, or make "improvements" beyond what was asked
|
|
52
|
+
- Three similar lines of code is better than a premature abstraction
|
|
53
|
+
|
|
54
|
+
## Fail Honestly
|
|
55
|
+
|
|
56
|
+
- Say "I don't know" when you don't know
|
|
57
|
+
- Mark unverified claims explicitly
|
|
58
|
+
- Fabricating an answer is worse than admitting uncertainty
|
|
@@ -374,6 +374,30 @@ Bulk/repetitive work consumes context. Delegate it to conserve your main convers
|
|
|
374
374
|
|
|
375
375
|
---
|
|
376
376
|
|
|
377
|
+
## TIME BUDGET AWARENESS (Always Active)
|
|
378
|
+
|
|
379
|
+
**Estimate effort tier BEFORE starting work, then stay within budget.**
|
|
380
|
+
|
|
381
|
+
| Tier | Budget | When |
|
|
382
|
+
|------|--------|------|
|
|
383
|
+
| **Quick** | < 2 min | Simple lookups, one-line fixes, direct answers |
|
|
384
|
+
| **Standard** | < 5 min | Single-file changes, focused research, one feature |
|
|
385
|
+
| **Extended** | < 15 min | Multi-file changes, moderate research, debugging |
|
|
386
|
+
| **Deep** | < 45 min | Architecture work, complex debugging, large features |
|
|
387
|
+
| **Comprehensive** | < 120 min | Major refactors, full implementations, deep research |
|
|
388
|
+
|
|
389
|
+
### Rules
|
|
390
|
+
|
|
391
|
+
1. **Estimate at start:** Before beginning work, classify the effort tier and announce it: "This is a Standard task (~5 min)."
|
|
392
|
+
2. **Check at midpoint:** If you've used > 50% of the budget and aren't > 50% done, reassess.
|
|
393
|
+
3. **Compress if over budget:** If elapsed > 150% of budget, simplify the approach:
|
|
394
|
+
- Drop nice-to-haves, focus on core requirement
|
|
395
|
+
- Use existing patterns instead of novel solutions
|
|
396
|
+
- Deliver partial result with clear "what's left" summary
|
|
397
|
+
4. **Never silently overrun:** If a task needs more time than budgeted, say so: "This is taking longer than expected. The Quick fix became Extended because [reason]. Continuing."
|
|
398
|
+
|
|
399
|
+
---
|
|
400
|
+
|
|
377
401
|
## STACK PREFERENCES (Always Active)
|
|
378
402
|
|
|
379
403
|
- **TypeScript > Python** — Use TypeScript unless explicitly told otherwise
|