@outlit/pi 2.1.5 → 2.1.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 +1 -1
- package/package.json +2 -2
- package/skills/outlit/SKILL.md +1 -0
package/README.md
CHANGED
|
@@ -31,7 +31,7 @@ The default extension registers the default customer intelligence tools from `@o
|
|
|
31
31
|
- `outlit_list_sources`
|
|
32
32
|
- `outlit_search_customer_context`
|
|
33
33
|
|
|
34
|
-
SQL and the other Pi-supported Platform capabilities are available from `@outlit/tools`, but the default Pi policy intentionally stays focused on customer intelligence. A custom Pi extension can opt into every Pi-supported tool with `piToolNames`, including customer relationship and Attention reads, customer ownership and access actions, product-facing Feature list, create, archive, and customer-usage tools, plus safe integration setup, destination, activation,
|
|
34
|
+
SQL and the other Pi-supported Platform capabilities are available from `@outlit/tools`, but the default Pi policy intentionally stays focused on customer intelligence. A custom Pi extension can opt into every Pi-supported tool with `piToolNames`, including customer relationship and Attention reads, customer ownership and access actions, product-facing Feature list, create, archive, and customer-usage tools, plus safe integration setup, destination, activation, workspace-settings actions, and `outlit_submit_feedback` product feedback intake. The default and analytical policies remain unchanged.
|
|
35
35
|
|
|
36
36
|
For analytical agents that need cohorts, usage trends, revenue filters, activation gaps, or aggregate checks, import `analyticalToolNames`. It combines the default customer intelligence tools with `outlit_schema` and `outlit_query` without exposing every customer tool:
|
|
37
37
|
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@outlit/pi",
|
|
3
|
-
"version": "2.1.
|
|
3
|
+
"version": "2.1.7",
|
|
4
4
|
"description": "Pi package for Outlit customer intelligence tools and skill guidance",
|
|
5
5
|
"license": "Apache-2.0",
|
|
6
6
|
"author": "Outlit AI",
|
|
@@ -66,7 +66,7 @@
|
|
|
66
66
|
"test": "vitest run"
|
|
67
67
|
},
|
|
68
68
|
"dependencies": {
|
|
69
|
-
"@outlit/tools": "^2.2.
|
|
69
|
+
"@outlit/tools": "^2.2.3"
|
|
70
70
|
},
|
|
71
71
|
"peerDependencies": {
|
|
72
72
|
"@mariozechner/pi-coding-agent": "*",
|
package/skills/outlit/SKILL.md
CHANGED
|
@@ -26,6 +26,7 @@ Do not invent customer state when Outlit can answer it. Call out sparse or messy
|
|
|
26
26
|
- Use `outlit_list_features` to inspect the confirmed workspace taxonomy, historical evidence, eligible sources, and event candidates.
|
|
27
27
|
- Use `outlit_create_feature` only when the user explicitly asks to configure one confirmed product capability from one exact event rule. Outlit creates the supporting usage metrics internally.
|
|
28
28
|
- Use `outlit_archive_feature` only when the user explicitly asks to archive a feature and supplies the current opaque id and revision. The MVP has no restore operation and rejects archiving the final active feature.
|
|
29
|
+
- Use `outlit_submit_feedback` when the user wants to report an Outlit product bug, idea, or friction. Feedback is product intake, not a support ticket or a guaranteed reply. Put diagnostics in `context`, never secrets or unnecessary customer data.
|
|
29
30
|
|
|
30
31
|
Use customer lookups before SQL. SQL is for aggregates, joins, cohorts, time-series analysis, and custom reporting.
|
|
31
32
|
|