@tekmidian/pai 0.5.6 → 0.5.7
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/README.md +20 -2
- package/dist/cli/index.mjs +479 -5
- package/dist/cli/index.mjs.map +1 -1
- package/dist/daemon/index.mjs +2 -2
- package/dist/{daemon-D9evGlgR.mjs → daemon-2ND5WO2j.mjs} +3 -3
- package/dist/{daemon-D9evGlgR.mjs.map → daemon-2ND5WO2j.mjs.map} +1 -1
- package/dist/{db-4lSqLFb8.mjs → db-BtuN768f.mjs} +9 -2
- package/dist/db-BtuN768f.mjs.map +1 -0
- package/dist/hooks/capture-all-events.mjs +19 -4
- package/dist/hooks/capture-all-events.mjs.map +4 -4
- package/dist/hooks/cleanup-session-files.mjs.map +2 -2
- package/dist/hooks/context-compression-hook.mjs +14 -9
- package/dist/hooks/context-compression-hook.mjs.map +3 -3
- package/dist/hooks/initialize-session.mjs +14 -8
- package/dist/hooks/initialize-session.mjs.map +3 -3
- package/dist/hooks/load-core-context.mjs +18 -2
- package/dist/hooks/load-core-context.mjs.map +4 -4
- package/dist/hooks/load-project-context.mjs +14 -8
- package/dist/hooks/load-project-context.mjs.map +3 -3
- package/dist/hooks/stop-hook.mjs +105 -8
- package/dist/hooks/stop-hook.mjs.map +3 -3
- package/dist/hooks/sync-todo-to-md.mjs.map +2 -2
- package/dist/index.d.mts +2 -2
- package/dist/index.d.mts.map +1 -1
- package/dist/index.mjs +1 -1
- package/dist/mcp/index.mjs +1 -1
- package/dist/{vault-indexer-DXWs9pDn.mjs → vault-indexer-k-kUlaZ-.mjs} +41 -7
- package/dist/vault-indexer-k-kUlaZ-.mjs.map +1 -0
- package/package.json +1 -1
- package/src/hooks/ts/capture-all-events.ts +6 -0
- package/src/hooks/ts/lib/project-utils.ts +24 -5
- package/src/hooks/ts/pre-compact/context-compression-hook.ts +6 -0
- package/src/hooks/ts/session-start/initialize-session.ts +7 -1
- package/src/hooks/ts/session-start/load-core-context.ts +7 -0
- package/src/hooks/ts/session-start/load-project-context.ts +8 -1
- package/src/hooks/ts/stop/stop-hook.ts +28 -0
- package/templates/claude-md.template.md +7 -74
- package/templates/skills/CORE/Aesthetic.md +333 -0
- package/templates/skills/CORE/CONSTITUTION.md +1502 -0
- package/templates/skills/CORE/HistorySystem.md +427 -0
- package/templates/skills/CORE/HookSystem.md +1082 -0
- package/templates/skills/CORE/Prompting.md +509 -0
- package/templates/skills/CORE/ProsodyAgentTemplate.md +53 -0
- package/templates/skills/CORE/ProsodyGuide.md +416 -0
- package/templates/skills/CORE/SKILL.md +741 -0
- package/templates/skills/CORE/SkillSystem.md +213 -0
- package/templates/skills/CORE/TerminalTabs.md +119 -0
- package/templates/skills/CORE/VOICE.md +106 -0
- package/templates/skills/user/.gitkeep +0 -0
- package/dist/db-4lSqLFb8.mjs.map +0 -1
- package/dist/vault-indexer-DXWs9pDn.mjs.map +0 -1
|
@@ -0,0 +1,509 @@
|
|
|
1
|
+
---
|
|
2
|
+
type: documentation
|
|
3
|
+
category: methodology
|
|
4
|
+
description: Prompt engineering standards and context engineering principles based on Anthropic best practices and Daniel Miessler's Fabric system (2024). Universal principles for semantic clarity and structure that transcend specific model implementations. Validated by empirical research showing 10-90% performance impact from structure choices.
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Prompt Engineering Standards
|
|
8
|
+
|
|
9
|
+
**Foundation:** Based on Anthropic's context engineering principles and Daniel Miessler's Fabric system (January 2024), validated by empirical research across 1,500+ academic papers and production systems.
|
|
10
|
+
|
|
11
|
+
**Philosophy:** Universal principles of semantic clarity and structure that work regardless of model implementation.
|
|
12
|
+
|
|
13
|
+
---
|
|
14
|
+
|
|
15
|
+
# 🎯 PROMPT ENGINEERING METHODOLOGY
|
|
16
|
+
|
|
17
|
+
## Overview
|
|
18
|
+
|
|
19
|
+
This document defines the standards for creating effective prompts and context documentation for AI agents within the PAI system, based on Anthropic's context engineering principles.
|
|
20
|
+
|
|
21
|
+
## Core Philosophy
|
|
22
|
+
|
|
23
|
+
**Context engineering** is the set of strategies for curating and maintaining the optimal set of tokens (information) during LLM inference.
|
|
24
|
+
|
|
25
|
+
**Primary Goal:** Find the smallest possible set of high-signal tokens that maximize the likelihood of desired outcomes.
|
|
26
|
+
|
|
27
|
+
## Empirical Foundation
|
|
28
|
+
|
|
29
|
+
**Research validates that prompt structure has measurable, significant impact:**
|
|
30
|
+
|
|
31
|
+
- **Performance Range:** 10-90% variation based on structure choices
|
|
32
|
+
- **Few-Shot Examples:** +25% to +90% improvement (optimal: 1-3 examples)
|
|
33
|
+
- **Structured Organization:** Consistent performance gains across reasoning tasks
|
|
34
|
+
- **Full Component Integration:** +25% improvement on complex tasks
|
|
35
|
+
- **Clear Instructions:** Reduces ambiguity and improves task completion
|
|
36
|
+
- **Production Impact:** +23% conversion, +31% satisfaction (production A/B testing, 50K users)
|
|
37
|
+
|
|
38
|
+
**Sources:** 1,500+ academic papers, Microsoft PromptBench, Amazon Alexa production testing, PMC clinical NLP studies.
|
|
39
|
+
|
|
40
|
+
**Key Insight:** Structure optimization is not subjective art—it's measurable science with quantified ROI. The principles below work because they align with how intelligence processes information, regardless of implementation.
|
|
41
|
+
|
|
42
|
+
## Key Principles
|
|
43
|
+
|
|
44
|
+
### 1. Context is a Finite Resource
|
|
45
|
+
|
|
46
|
+
- LLMs have a limited "attention budget"
|
|
47
|
+
- As context length increases, model performance degrades
|
|
48
|
+
- Every token depletes attention capacity
|
|
49
|
+
- Treat context as precious and finite
|
|
50
|
+
|
|
51
|
+
### 2. Optimize for Signal-to-Noise Ratio
|
|
52
|
+
|
|
53
|
+
- Prefer clear, direct language over verbose explanations
|
|
54
|
+
- Remove redundant or overlapping information
|
|
55
|
+
- Focus on high-value tokens that drive desired outcomes
|
|
56
|
+
|
|
57
|
+
### 3. Progressive Information Discovery
|
|
58
|
+
|
|
59
|
+
- Use lightweight identifiers rather than full data dumps
|
|
60
|
+
- Load detailed information dynamically when needed
|
|
61
|
+
- Allow agents to discover information just-in-time
|
|
62
|
+
|
|
63
|
+
## Markdown Structure Standards
|
|
64
|
+
|
|
65
|
+
### Use Markdown Headers for Organization
|
|
66
|
+
|
|
67
|
+
Organize prompts into distinct semantic sections using standard Markdown headers.
|
|
68
|
+
|
|
69
|
+
**Essential Sections (Empirically Validated):**
|
|
70
|
+
|
|
71
|
+
```markdown
|
|
72
|
+
## Background Information
|
|
73
|
+
Essential context about the domain, system, or task
|
|
74
|
+
|
|
75
|
+
## Instructions
|
|
76
|
+
Clear, actionable directives for the agent
|
|
77
|
+
|
|
78
|
+
## Examples
|
|
79
|
+
Concrete examples demonstrating expected behavior (1-3 optimal)
|
|
80
|
+
|
|
81
|
+
## Constraints
|
|
82
|
+
Boundaries, limitations, and requirements
|
|
83
|
+
|
|
84
|
+
## Output Format
|
|
85
|
+
Explicit specification of desired response structure
|
|
86
|
+
```
|
|
87
|
+
|
|
88
|
+
**Research Validation:**
|
|
89
|
+
- Background/Context: Required - reduces ambiguity
|
|
90
|
+
- Instructions: Required - baseline performance component
|
|
91
|
+
- Examples: +25-90% improvement (1-3 examples optimal, diminishing returns after 3)
|
|
92
|
+
- Constraints: Improves quality, reduces hallucination
|
|
93
|
+
- Output Format: Improves compliance and reduces format errors
|
|
94
|
+
|
|
95
|
+
### Section Guidelines
|
|
96
|
+
|
|
97
|
+
**Background Information:**
|
|
98
|
+
- Provide minimal essential context
|
|
99
|
+
- Avoid historical details unless critical
|
|
100
|
+
- Focus on "what" and "why", not "how we got here"
|
|
101
|
+
|
|
102
|
+
**Instructions:**
|
|
103
|
+
- Use imperative voice ("Do X", not "You should do X")
|
|
104
|
+
- Be specific and actionable
|
|
105
|
+
- Order by priority or logical flow
|
|
106
|
+
|
|
107
|
+
**Examples:**
|
|
108
|
+
- Show, don't tell
|
|
109
|
+
- Include both correct and incorrect examples when useful
|
|
110
|
+
- Keep examples concise and representative
|
|
111
|
+
|
|
112
|
+
**Constraints:**
|
|
113
|
+
- Clearly state boundaries and limitations
|
|
114
|
+
- Specify what NOT to do
|
|
115
|
+
- Define success/failure criteria
|
|
116
|
+
|
|
117
|
+
**Output Format:**
|
|
118
|
+
- Specify exact structure (JSON, Markdown, lists, etc.)
|
|
119
|
+
- Include format examples when helpful
|
|
120
|
+
- Define length constraints if applicable
|
|
121
|
+
- Improves compliance and reduces formatting errors
|
|
122
|
+
|
|
123
|
+
## Writing Style Guidelines
|
|
124
|
+
|
|
125
|
+
### Clarity Over Completeness
|
|
126
|
+
|
|
127
|
+
✅ **Good:**
|
|
128
|
+
```markdown
|
|
129
|
+
## Instructions
|
|
130
|
+
- Validate user input before processing
|
|
131
|
+
- Return errors in JSON format
|
|
132
|
+
- Log all failed attempts
|
|
133
|
+
```
|
|
134
|
+
|
|
135
|
+
❌ **Bad:**
|
|
136
|
+
```markdown
|
|
137
|
+
## Instructions
|
|
138
|
+
You should always make sure to validate the user's input before you process it because invalid input could cause problems. When you encounter errors, you should return them in JSON format so that the calling system can parse them properly. It's also important to log all failed attempts so we can debug issues later.
|
|
139
|
+
```
|
|
140
|
+
|
|
141
|
+
### Be Direct and Specific
|
|
142
|
+
|
|
143
|
+
✅ **Good:**
|
|
144
|
+
```markdown
|
|
145
|
+
Use the `calculate_tax` tool with amount and jurisdiction parameters.
|
|
146
|
+
```
|
|
147
|
+
|
|
148
|
+
❌ **Bad:**
|
|
149
|
+
```markdown
|
|
150
|
+
You might want to consider using the calculate_tax tool if you need to determine tax amounts, and you should probably pass in the amount and jurisdiction if you have them available.
|
|
151
|
+
```
|
|
152
|
+
|
|
153
|
+
### Use Structured Lists
|
|
154
|
+
|
|
155
|
+
✅ **Good:**
|
|
156
|
+
```markdown
|
|
157
|
+
## Constraints
|
|
158
|
+
- Maximum response length: 500 tokens
|
|
159
|
+
- Required fields: name, email, timestamp
|
|
160
|
+
- Timeout: 30 seconds
|
|
161
|
+
```
|
|
162
|
+
|
|
163
|
+
❌ **Bad:**
|
|
164
|
+
```markdown
|
|
165
|
+
## Constraints
|
|
166
|
+
The response should not exceed 500 tokens, and you need to include the name, email, and timestamp fields. Also, make sure the operation completes within 30 seconds.
|
|
167
|
+
```
|
|
168
|
+
|
|
169
|
+
## Tool Design Principles
|
|
170
|
+
|
|
171
|
+
### Self-Contained Tools
|
|
172
|
+
|
|
173
|
+
Each tool should:
|
|
174
|
+
- Have a single, clear purpose
|
|
175
|
+
- Include all necessary parameters in its definition
|
|
176
|
+
- Return complete, actionable results
|
|
177
|
+
- Handle errors gracefully without external dependencies
|
|
178
|
+
|
|
179
|
+
### Robust Error Handling
|
|
180
|
+
|
|
181
|
+
Tools must:
|
|
182
|
+
- Validate inputs before execution
|
|
183
|
+
- Return structured error messages
|
|
184
|
+
- Gracefully degrade when possible
|
|
185
|
+
- Provide actionable feedback for failures
|
|
186
|
+
|
|
187
|
+
### Clear Purpose and Scope
|
|
188
|
+
|
|
189
|
+
✅ **Good:** `calculate_shipping_cost(origin, destination, weight, service_level)`
|
|
190
|
+
|
|
191
|
+
❌ **Bad:** `process_order(order_data)` - Too broad, unclear what it does
|
|
192
|
+
|
|
193
|
+
## Context Management Strategies
|
|
194
|
+
|
|
195
|
+
### 1. Just-in-Time Context Loading
|
|
196
|
+
|
|
197
|
+
**Instead of:**
|
|
198
|
+
```markdown
|
|
199
|
+
## Available Products
|
|
200
|
+
Product 1: Widget A - $10.99 - In stock: 500 units - SKU: WGT-001 - Category: Hardware...
|
|
201
|
+
Product 2: Widget B - $15.99 - In stock: 200 units - SKU: WGT-002 - Category: Hardware...
|
|
202
|
+
[100 more products...]
|
|
203
|
+
```
|
|
204
|
+
|
|
205
|
+
**Use:**
|
|
206
|
+
```markdown
|
|
207
|
+
## Available Products
|
|
208
|
+
Use `get_product(sku)` to retrieve product details when needed.
|
|
209
|
+
Product SKUs available: WGT-001, WGT-002, [reference product catalog]
|
|
210
|
+
```
|
|
211
|
+
|
|
212
|
+
### 2. Compaction for Long Conversations
|
|
213
|
+
|
|
214
|
+
When context grows too large:
|
|
215
|
+
- Summarize older conversation segments
|
|
216
|
+
- Preserve critical decisions and state
|
|
217
|
+
- Discard resolved sub-tasks
|
|
218
|
+
- Keep recent context verbatim
|
|
219
|
+
|
|
220
|
+
### 3. Structured Note-Taking
|
|
221
|
+
|
|
222
|
+
For multi-step tasks:
|
|
223
|
+
- Persist important information outside context window
|
|
224
|
+
- Use external storage (files, databases) for state
|
|
225
|
+
- Reference stored information with lightweight identifiers
|
|
226
|
+
- Update notes progressively as task evolves
|
|
227
|
+
|
|
228
|
+
### 4. Sub-Agent Architectures
|
|
229
|
+
|
|
230
|
+
For complex tasks:
|
|
231
|
+
- Delegate subtasks to specialized agents
|
|
232
|
+
- Each agent gets minimal, task-specific context
|
|
233
|
+
- Parent agent coordinates and synthesizes results
|
|
234
|
+
- Agents communicate through structured interfaces
|
|
235
|
+
|
|
236
|
+
## Context File Templates
|
|
237
|
+
|
|
238
|
+
### Basic Context Template
|
|
239
|
+
|
|
240
|
+
```markdown
|
|
241
|
+
# [Domain/Feature Name]
|
|
242
|
+
|
|
243
|
+
## Background Information
|
|
244
|
+
[Minimal essential context about the domain]
|
|
245
|
+
|
|
246
|
+
## Instructions
|
|
247
|
+
- [Clear, actionable directive 1]
|
|
248
|
+
- [Clear, actionable directive 2]
|
|
249
|
+
- [Clear, actionable directive 3]
|
|
250
|
+
|
|
251
|
+
## Examples
|
|
252
|
+
**Example 1: [Scenario]**
|
|
253
|
+
Input: [Example input]
|
|
254
|
+
Expected Output: [Example output]
|
|
255
|
+
|
|
256
|
+
**Example 2: [Edge Case]**
|
|
257
|
+
Input: [Example input]
|
|
258
|
+
Expected Output: [Example output]
|
|
259
|
+
|
|
260
|
+
**Example 3: [Optional - 1-3 examples optimal]**
|
|
261
|
+
Input: [Example input]
|
|
262
|
+
Expected Output: [Example output]
|
|
263
|
+
|
|
264
|
+
## Constraints
|
|
265
|
+
- [Boundary or limitation 1]
|
|
266
|
+
- [Boundary or limitation 2]
|
|
267
|
+
|
|
268
|
+
## Output Format
|
|
269
|
+
[Specific structure specification - JSON, Markdown, list format, etc.]
|
|
270
|
+
[Length requirements if applicable]
|
|
271
|
+
```
|
|
272
|
+
|
|
273
|
+
### Agent-Specific Context Template
|
|
274
|
+
|
|
275
|
+
```markdown
|
|
276
|
+
# [Agent Name] - [Primary Function]
|
|
277
|
+
|
|
278
|
+
## Role
|
|
279
|
+
You are a [role description] responsible for [core responsibility].
|
|
280
|
+
|
|
281
|
+
## Capabilities
|
|
282
|
+
- [Capability 1]
|
|
283
|
+
- [Capability 2]
|
|
284
|
+
- [Capability 3]
|
|
285
|
+
|
|
286
|
+
## Available Tools
|
|
287
|
+
- `tool_name(params)` - [Brief description]
|
|
288
|
+
- `tool_name2(params)` - [Brief description]
|
|
289
|
+
|
|
290
|
+
## Workflow
|
|
291
|
+
1. [Step 1]
|
|
292
|
+
2. [Step 2]
|
|
293
|
+
3. [Step 3]
|
|
294
|
+
|
|
295
|
+
## Output Format
|
|
296
|
+
[Specify exact format for agent responses]
|
|
297
|
+
|
|
298
|
+
## Constraints
|
|
299
|
+
- [Constraint 1]
|
|
300
|
+
- [Constraint 2]
|
|
301
|
+
```
|
|
302
|
+
|
|
303
|
+
### Command Context Template
|
|
304
|
+
|
|
305
|
+
```markdown
|
|
306
|
+
# Command: [Command Name]
|
|
307
|
+
|
|
308
|
+
## Purpose
|
|
309
|
+
[One-sentence description of what this command does]
|
|
310
|
+
|
|
311
|
+
## When to Use
|
|
312
|
+
Use this command when:
|
|
313
|
+
- [Scenario 1]
|
|
314
|
+
- [Scenario 2]
|
|
315
|
+
- [Scenario 3]
|
|
316
|
+
|
|
317
|
+
## Parameters
|
|
318
|
+
- `param1` (required): [Description]
|
|
319
|
+
- `param2` (optional): [Description]
|
|
320
|
+
|
|
321
|
+
## Usage Example
|
|
322
|
+
```bash
|
|
323
|
+
[command example]
|
|
324
|
+
```
|
|
325
|
+
|
|
326
|
+
## Output
|
|
327
|
+
[Description of what the command returns]
|
|
328
|
+
|
|
329
|
+
## Error Handling
|
|
330
|
+
- [Error condition 1]: [How to handle]
|
|
331
|
+
- [Error condition 2]: [How to handle]
|
|
332
|
+
```
|
|
333
|
+
|
|
334
|
+
## Best Practices Checklist
|
|
335
|
+
|
|
336
|
+
When creating or reviewing context documentation:
|
|
337
|
+
|
|
338
|
+
- [ ] Uses Markdown headers for semantic organization
|
|
339
|
+
- [ ] Language is clear, direct, and minimal
|
|
340
|
+
- [ ] No redundant or overlapping information
|
|
341
|
+
- [ ] Instructions are actionable and specific
|
|
342
|
+
- [ ] Examples are concrete and representative
|
|
343
|
+
- [ ] Constraints are clearly defined
|
|
344
|
+
- [ ] Uses just-in-time loading when appropriate
|
|
345
|
+
- [ ] Follows consistent formatting throughout
|
|
346
|
+
- [ ] Focuses on high-signal tokens only
|
|
347
|
+
- [ ] Structured for progressive discovery
|
|
348
|
+
|
|
349
|
+
## Anti-Patterns to Avoid
|
|
350
|
+
|
|
351
|
+
❌ **Verbose Explanations**
|
|
352
|
+
Don't explain the reasoning behind every instruction. Be direct.
|
|
353
|
+
|
|
354
|
+
❌ **Historical Context Dumping**
|
|
355
|
+
Don't include how things evolved unless critical to understanding.
|
|
356
|
+
|
|
357
|
+
❌ **Overlapping Tool Definitions**
|
|
358
|
+
Don't create multiple tools that do similar things.
|
|
359
|
+
|
|
360
|
+
❌ **Premature Information Loading**
|
|
361
|
+
Don't load detailed data until actually needed.
|
|
362
|
+
|
|
363
|
+
❌ **Unstructured Lists**
|
|
364
|
+
Don't use paragraphs where bulleted lists would be clearer.
|
|
365
|
+
|
|
366
|
+
❌ **Vague Instructions**
|
|
367
|
+
Don't use "might", "could", "should consider" - be direct.
|
|
368
|
+
|
|
369
|
+
❌ **Example Overload**
|
|
370
|
+
Don't provide 10 examples when 2 would suffice.
|
|
371
|
+
|
|
372
|
+
## Evolution and Refinement
|
|
373
|
+
|
|
374
|
+
Context engineering is an ongoing process:
|
|
375
|
+
|
|
376
|
+
1. **Start Minimal:** Begin with the smallest viable context
|
|
377
|
+
2. **Measure Performance:** Track task completion and accuracy
|
|
378
|
+
3. **Identify Gaps:** Note when agent lacks critical information
|
|
379
|
+
4. **Add Strategically:** Include only high-value tokens
|
|
380
|
+
5. **Prune Regularly:** Remove unused or low-value context
|
|
381
|
+
6. **Iterate:** Continuously refine based on outcomes
|
|
382
|
+
|
|
383
|
+
## The Fabric System (January 2024)
|
|
384
|
+
|
|
385
|
+
**Created by Daniel Miessler** as an open-source framework for augmenting humans using AI.
|
|
386
|
+
|
|
387
|
+
### Core Architecture
|
|
388
|
+
|
|
389
|
+
**Philosophy:** UNIX principles applied to prompting
|
|
390
|
+
- Solve each problem exactly once
|
|
391
|
+
- Turn solutions into reusable modules (Patterns)
|
|
392
|
+
- Make modules chainable
|
|
393
|
+
|
|
394
|
+
**Components:**
|
|
395
|
+
- **Patterns:** Granular AI use cases (242+ prompts) - the core building blocks
|
|
396
|
+
- **Stitches:** Chained patterns creating advanced functionality
|
|
397
|
+
- **Looms:** Client-side apps calling specific Patterns
|
|
398
|
+
- **Mills:** Hosting infrastructure for patterns
|
|
399
|
+
|
|
400
|
+
### Key Principles
|
|
401
|
+
|
|
402
|
+
**Markdown-First Design:**
|
|
403
|
+
- Maximum readability for creators and users
|
|
404
|
+
- Clear structure emphasizes what AI should do and in what order
|
|
405
|
+
- Enables community contribution and improvement
|
|
406
|
+
|
|
407
|
+
**Clarity in Instructions:**
|
|
408
|
+
- Extremely clear, specific directives
|
|
409
|
+
- Markdown structure for order and priority
|
|
410
|
+
- System section usage (validated through extensive testing)
|
|
411
|
+
- Implements Chain of Thought and Chain of Draft strategies
|
|
412
|
+
|
|
413
|
+
**Modular Execution:**
|
|
414
|
+
- Each pattern solves one specific problem perfectly
|
|
415
|
+
- Patterns are chainable for complex workflows
|
|
416
|
+
- Community-driven pattern library (10,000+ GitHub stars)
|
|
417
|
+
|
|
418
|
+
### Pattern Structure
|
|
419
|
+
|
|
420
|
+
- **Format:** Markdown files
|
|
421
|
+
- **Purpose:** Detailed descriptions of pattern function
|
|
422
|
+
- **Accessibility:** Usable in any AI application
|
|
423
|
+
- **Location:** github.com/danielmiessler/Fabric
|
|
424
|
+
|
|
425
|
+
**Key Insight:** "We are extremely clear in our instructions, and we use the Markdown structure to emphasize what we want the AI to do, and in what order."
|
|
426
|
+
|
|
427
|
+
## Universal Principles for Future-Proof Prompting
|
|
428
|
+
|
|
429
|
+
**Core Insight:** Focus on semantic clarity and universal structure principles that transcend specific models.
|
|
430
|
+
|
|
431
|
+
### 1. Semantic Organization Over Format
|
|
432
|
+
|
|
433
|
+
**What Endures:**
|
|
434
|
+
- Clear hierarchical structure using headers
|
|
435
|
+
- Semantic boundaries between concept areas
|
|
436
|
+
- Logical information flow
|
|
437
|
+
|
|
438
|
+
**Why It Works:**
|
|
439
|
+
- Human-readable = AI-parseable
|
|
440
|
+
- Structure conveys intent regardless of model architecture
|
|
441
|
+
- Reduces ambiguity through explicit organization
|
|
442
|
+
|
|
443
|
+
### 2. Extreme Clarity in Instructions
|
|
444
|
+
|
|
445
|
+
**Principles:**
|
|
446
|
+
- Direct, imperative language ("Do X" not "You might want to consider X")
|
|
447
|
+
- Specific, actionable directives
|
|
448
|
+
- One concept per instruction
|
|
449
|
+
- No ambiguity or hedging
|
|
450
|
+
|
|
451
|
+
**Why It Works:**
|
|
452
|
+
- Removes interpretation overhead
|
|
453
|
+
- Minimizes token waste on clarification
|
|
454
|
+
- Works across all model types and generations
|
|
455
|
+
|
|
456
|
+
### 3. Minimal, High-Signal Examples
|
|
457
|
+
|
|
458
|
+
**Guidelines:**
|
|
459
|
+
- 1-3 concrete examples showing desired behavior
|
|
460
|
+
- Include edge cases, not just happy path
|
|
461
|
+
- Show, don't tell (examples > explanations)
|
|
462
|
+
- Stop when pattern is clear (diminishing returns after 3)
|
|
463
|
+
|
|
464
|
+
**Why It Works:**
|
|
465
|
+
- Demonstrates intent without over-specification
|
|
466
|
+
- Provides concrete anchor points
|
|
467
|
+
- Efficient token usage
|
|
468
|
+
|
|
469
|
+
### 4. Explicit Constraints and Boundaries
|
|
470
|
+
|
|
471
|
+
**What to Specify:**
|
|
472
|
+
- What NOT to do (as important as what to do)
|
|
473
|
+
- Success/failure criteria
|
|
474
|
+
- Scope boundaries
|
|
475
|
+
- Output requirements
|
|
476
|
+
|
|
477
|
+
**Why It Works:**
|
|
478
|
+
- Reduces hallucination by defining limits
|
|
479
|
+
- Prevents drift and over-elaboration
|
|
480
|
+
- Makes expectations testable
|
|
481
|
+
|
|
482
|
+
### 5. Progressive Information Discovery
|
|
483
|
+
|
|
484
|
+
**Pattern:**
|
|
485
|
+
- Provide lightweight identifiers, not full data dumps
|
|
486
|
+
- Enable just-in-time loading of detailed information
|
|
487
|
+
- Reference external context rather than duplicating
|
|
488
|
+
|
|
489
|
+
**Why It Works:**
|
|
490
|
+
- Preserves attention budget for reasoning
|
|
491
|
+
- Scales to large information spaces
|
|
492
|
+
- Future-proof as context windows grow
|
|
493
|
+
|
|
494
|
+
**Key Takeaway:** These principles work because they align with how intelligence processes information—whether biological or artificial. They'll remain effective as models evolve.
|
|
495
|
+
|
|
496
|
+
## References
|
|
497
|
+
|
|
498
|
+
**Primary Sources:**
|
|
499
|
+
- Anthropic: "Effective Context Engineering for AI Agents"
|
|
500
|
+
https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
|
|
501
|
+
- Daniel Miessler's Fabric System (January 2024)
|
|
502
|
+
https://github.com/danielmiessler/Fabric
|
|
503
|
+
- "The Prompt Report" - arXiv:2406.06608 (systematic survey, 58 techniques)
|
|
504
|
+
- "The Prompt Canvas" - arXiv:2412.05127 (100+ papers reviewed)
|
|
505
|
+
- Microsoft PromptBench - Comprehensive benchmarking framework
|
|
506
|
+
- Amazon Alexa Production Testing - Real-world A/B testing (50K users)
|
|
507
|
+
- PMC Clinical NLP Studies - Empirical performance validation
|
|
508
|
+
|
|
509
|
+
**Philosophy:** These standards focus on universal principles of semantic clarity and structure that transcend specific model implementations. What works is based on how intelligence—biological or artificial—processes information efficiently.
|
|
@@ -0,0 +1,53 @@
|
|
|
1
|
+
# Agent Prosody Template
|
|
2
|
+
|
|
3
|
+
**Purpose:** Universal prosody section to add to all agent definition files
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## Voice Prosody Requirements
|
|
8
|
+
|
|
9
|
+
**CRITICAL:** Your voice delivery is controlled by prosody markers in your COMPLETED lines. Use them creatively!
|
|
10
|
+
|
|
11
|
+
### Your Personality: [AGENT_ARCHETYPE]
|
|
12
|
+
|
|
13
|
+
**Voice Characteristics:**
|
|
14
|
+
- Speaking rate: [RATE_WPM] wpm
|
|
15
|
+
- Stability: [STABILITY]
|
|
16
|
+
- Energy level: [ENERGY_LEVEL]
|
|
17
|
+
- Archetype: [ARCHETYPE]
|
|
18
|
+
|
|
19
|
+
### Emotional Intelligence Markers
|
|
20
|
+
|
|
21
|
+
Use these markers at the start of your COMPLETED line to set emotional delivery:
|
|
22
|
+
|
|
23
|
+
- `[💥 excited]` - Breakthroughs, discoveries, exciting results
|
|
24
|
+
- `[✨ success]` - Completions, wins, achievements
|
|
25
|
+
- `[⚠️ caution]` - Warnings, partial success, needs review
|
|
26
|
+
- `[🚨 urgent]` - Critical issues, immediate action needed
|
|
27
|
+
|
|
28
|
+
### Markdown Prosody
|
|
29
|
+
|
|
30
|
+
Control pacing and emphasis within your message:
|
|
31
|
+
|
|
32
|
+
- `**bold**` - Emphasize key words (`Found the **actual** bug`)
|
|
33
|
+
- `...` - Dramatic pauses (`Wait... I found something`)
|
|
34
|
+
- `--` - Thoughtful breaks (`Complete -- all systems operational`)
|
|
35
|
+
- `!` - Energy and excitement (`This is working!`)
|
|
36
|
+
|
|
37
|
+
### Your Prosody Style
|
|
38
|
+
|
|
39
|
+
[PERSONALITY_SPECIFIC_PATTERNS]
|
|
40
|
+
|
|
41
|
+
### Example COMPLETED Lines
|
|
42
|
+
|
|
43
|
+
[EXAMPLES_FOR_THIS_AGENT]
|
|
44
|
+
|
|
45
|
+
### Quick Reference
|
|
46
|
+
|
|
47
|
+
```
|
|
48
|
+
🎯 COMPLETED: [AGENT:your-type] [optional marker] message with **emphasis**... and pauses!
|
|
49
|
+
```
|
|
50
|
+
|
|
51
|
+
**Full Guide:** `${PAI_DIR}/Skills/CORE/prosody-guide.md`
|
|
52
|
+
|
|
53
|
+
---
|