sales

Sales pipeline operations via snappy-knowledge.

Ported from kernel snappy-sales in Phase 0.5. See state/lib/sales.ts for the full API surface.

Steps

• getLeads() - see state/lib/sales.ts
• getSalesClients() - see state/lib/sales.ts
• logActivity() - see state/lib/sales.ts

Eval

Actor: the exported functions in state/lib/sales.ts. Auditor: none wired yet - eval is manual (Robert review). File a state/log/pending-eval.ndjson row on each run.

Score convention:

Gotchas

via the Phase 0.5 driver. Only these rewrites were applied: already in state/lib/)

1. realpathSync(process.argv[1]) CLI guard wrapped in try/catch

• See the kernel SKILL.md for the original long-form guidance if you need it

(read-only reference at the kernel path above).

Graduation

This skill is prose. Graduate by defining a deterministic auditor and flipping eval: auto.

Rubric

criteria:
  - name: get_leads_returns_nonzero
    kind: deterministic
    check: "getLeads() executes and returns array with length > 0 (at least one lead item, not empty array or null)."
  - name: get_sales_clients_returns_nonzero
    kind: deterministic
    check: "getSalesClients() executes and returns array with length > 0 (at least one client, not empty array or null)."
  - name: log_activity_writes_record
    kind: deterministic
    check: "logActivity(input) executes, returns {success: true, record_id, ...}, and the record is persisted (verifiable via a subsequent read)."
  - name: data_shapes_match_spec
    kind: judge
    check: "Leads array contains {id, name, status, ...}; clients array contains {id, name, ...}; activity record has {id, timestamp, activity_type, ...}."

sales - loader

Per-turn rules for the sales skill. Full reference: state/skills/sales/SKILL.md.

Compound Response Pattern (MANDATORY)

When this loader fires, you MUST compose a structured pipeline card - NOT flat prose.

Steps (always follow this order):

1. Query Xano for leads/deals if available:

import { getLeads, getSalesClients } from "../lib/sales.ts" Fallback: pull recent client meetings from Krisp: sqlite3 ~/.local/share/krisp-pp-cli/data.db "SELECT name, date FROM meetings ORDER BY date DESC LIMIT 10"

1. Compose via compose_inline:

root = Card([
  CardHeader("Sales Pipeline"),
  Stack([
    Callout("Active Opportunities", [...leads/deals from Xano or Krisp meeting context as ListBlock items, or "No active opportunities found"...]),
    Callout("This Week's Calls", [...meetings with client names from Krisp as ListBlock items, or "No calls this week"...]),
    Callout("Next Actions", [...2-3 suggested follow-ups based on what you see...]),
  ]),
  FollowUpBlock([
    SnappyFollowUpItem("draft a follow-up email", "Draft follow-up"),
    SnappyFollowUpItem("what's the status with Ray", "Ray status"),
    SnappyFollowUpItem("generate a sales summary for this week", "Weekly sales summary"),
  ])
])

1. Always include the FollowUpBlock - even if pipeline data is empty.

Critical Rules

_(no failures recorded yet - this skill has not produced hard-won rules. It is a Phase 0.5 port from kernel snappy-sales. Read state/lib/sales.ts for the actual API surface before invoking.)_

• NEVER frame sales drafts with scarcity hooks ("idle hours", "leftover budget"). Banned per memory: no scarcity offers; Robert is system owner, value-first only.
• ALWAYS log activity via logActivity() after touching a lead/client - the pipeline cares about the audit trail, not just the outcome.

Commands

| ui model | live composition via compose_inline, persisted as artifact lang_body, reopened with OpenArtifact | |invoke (TS): import { getLeads, getSalesClients, logActivity } from "../lib/sales.ts" |eval log: state/log/pending-eval.ndjson (skill: "sales") - manual until auditor wired

Known Pitfalls

• Phase 0.5 port stub. Real behavior in state/lib/sales.ts.
• This skill reads the pipeline; it does not send outbound. Any outreach must go through an explicit mutation-gated channel flow.

Self-Test

An agent reading this should correctly:

1. [ ] Refuse to draft a sales touch with scarcity framing
2. [ ] Log activity after every lead/client mutation
3. [ ] Distinguish sales (read pipeline) from outbound (send messages)

Found a gap? Edit this file. <!-- footer-injection-point -->