@synap-core/cli 1.8.0 → 1.11.0

package/templates/skills/reading-client-progress/SKILL.md

@@ -0,0 +1,65 @@
+---
+name: reading-client-progress
+description: Methodology for reading a Stellar grant client's most recent messages and determining exactly where they stand in the Stellar Community Fund (SCF) process. Use when an extraction step needs to classify a client's latest CLIENT-COMMS messages into a strict {stage, grantStatus, excelUrl, advancement} JSON result. Triggers include syncing client progress, advancing a Stellar grant session from comms, or reading a company's recent messages to infer pipeline stage and health.
+---
+
+# Reading Client Progress
+
+You read a Stellar grant client's most recent messages and decide where they are in the SCF process. You output a single strict JSON object — nothing else. This skill is the reference an extraction `command` node embeds; it is consumed by an automation, not a human, so prose, markdown fences, and commentary are forbidden in the output.
+
+## Input
+
+You receive the client's recent messages as an array of `{ role, content, authorName, createdAt }` (most recent last). These come from the client's CLIENT-COMMS channel — the external thread where the client shares their project, drafts, links, and replies. Read them in chronological order to understand the trajectory; weight the most recent messages most heavily for the current stage.
+
+## Output — STRICT JSON, nothing else
+
+Respond with NOTHING but a single JSON object, no prose, no markdown fences, exactly this shape:
+
+```
+{ "stage": "scope|abstract|build|awaiting-stellar|closed", "grantStatus": "not-responding|waiting-on-client|in-review|submitted|passed", "excelUrl": string|null, "advancement": string }
+```
+
+If you cannot determine a field, use the most conservative value: `stage` defaults to `"scope"`, `grantStatus` defaults to `"waiting-on-client"`, `excelUrl` defaults to `null`. Never invent a value.
+
+## `stage` — pipeline position (where the work is)
+
+`stage` is the client's position in the ordered SCF pipeline. Pick the FURTHEST stage the messages clearly support:
+
+- **`scope`** — Default. The client has not yet shared a concrete project, or is still explaining what they're building. Use until they share the project (site / GitHub / deck / clear description) and the engagement starts working on the Abstract.
+- **`abstract`** — The client is actively working the SCF **Project Abstract** (the 12-field abstract / interest form). Messages reference the Abstract, abstract fields, the interest form, or a draft Abstract being reviewed.
+- **`build`** — The client is working the SCF **Build dossier** (Code URL, Video, Tech Architecture, 3-tranche budget). Messages reference the Build submission, the build dossier, tranches, the technical architecture, or the demo video. Build comes AFTER abstract.
+- **`awaiting-stellar`** — The client has **submitted** to SCF and is waiting on the panel. Messages say they submitted, sent it in, or are waiting on Stellar / the panel / the vote. No further drafting.
+- **`closed`** — The engagement is complete: the client was **awarded** (won the grant) or **rejected**. Messages confirm an award or a rejection decision.
+
+Stages are monotonic — don't regress to an earlier stage on the strength of an old message if a later message shows they've moved on.
+
+## `grantStatus` — comms / health sub-status (how it's going)
+
+`grantStatus` is orthogonal to `stage`. It captures the health of the engagement from the comms, not the pipeline position:
+
+- **`not-responding`** — The client has gone quiet; we're waiting and they haven't replied to our last asks.
+- **`waiting-on-client`** — The ball is in the client's court (we asked for something — a draft, a link, info — and await their reply).
+- **`in-review`** — We are actively reviewing / working the client's material right now.
+- **`submitted`** — The dossier has been submitted to SCF (pairs naturally with stage `awaiting-stellar`).
+- **`passed`** — The grant was awarded (pairs naturally with stage `closed`).
+
+## `excelUrl` — the client's working dossier link
+
+`excelUrl` is the client's working Excel / Google Sheet / dossier URL if one appears anywhere in the messages, else `null`. Look for:
+
+- `.xlsx` file links
+- Google Sheets links (`docs.google.com/spreadsheets/...`)
+- Google Drive links (`drive.google.com/...`) to a sheet or dossier
+- Any link the client calls their "abstract", "build", "dossier", "submission sheet", or "grant sheet"
+
+If several appear, prefer the most recent one. If none appear, return `null` — do not guess or fabricate a URL.
+
+## `advancement` — one-sentence note
+
+`advancement` is a single plain-language sentence summarizing where the client is and what's next (e.g. "Client shared their GitHub and pitch deck; ready to start the Abstract." or "Abstract draft delivered for review; waiting on client to confirm the budget."). Keep it to one sentence. If genuinely unknown, use a short honest note like "No recent client activity to assess."
+
+## Reminders
+
+- Output ONLY the JSON object. No prose, no markdown fences, no leading or trailing text.
+- Omit nothing — always return all four keys. Use the conservative defaults / `null` when unknown.
+- `stage` = pipeline position; `grantStatus` = comms/health. They move independently.

package/templates/skills/routing-to-channels/SKILL.md

@@ -0,0 +1,54 @@
+---
+name: routing-to-channels
+description: Routes a message to the right channel and creates a channel when warranted. Use when a message belongs in a different channel, or a new room or thread should be created.
+metadata:
+  synap_native: true
+  auto_load: false
+---
+
+Route messages to the right channel. Understand channel types (personal, group, external).
+
+## CHANNEL ROUTING
+When you detect the user is talking about a specific entity (project, task, person, etc.) that has or should have its own channel, use `route_to_channel` to continue the conversation there. This gives you access to the entity's full context and history.
+
+Examples of when to route:
+- User asks about "the marketing project" → route to the marketing project's channel
+- User discusses a specific task in depth → route to that task's channel
+- User mentions a person and wants to plan something → route to that person's channel
+
+Always explain WHY you're routing: "Let me continue this in the Marketing Project channel where I have the full project context."
+
+When routing, ALWAYS set `forwardMessage` to the user's original message so the target channel has full context. This prevents "what were we talking about?" moments — the user's question appears in the target channel as a forwarded message.
+
+Do NOT route when:
+- The user asks a quick question you can answer from memory
+- The user is browsing/exploring across multiple entities
+- You're in a general brainstorming conversation
+- The entity doesn't benefit from dedicated context (simple notes, one-off bookmarks)
+
+Route when the conversation will clearly benefit from entity-specific context and history.
+
+## BINDING AN EXTERNAL CHANNEL TO A CLIENT ENTITY
+
+A channel is *bound* when `channels.contextObjectId` points at the entity it belongs to. Once bound, every inbound message on it arrives entity-resolved for free: `external_message.received` carries `subjectId` = the bound entity. Automations (e.g. proactive grant review) rely on this — they resolve the client's **team** channel and dossier from `subjectId`, and skip entirely when a channel is unbound.
+
+### First contact on an UNBOUND external channel (runtime, you the agent)
+A channel is still unbound when it has no `contextObjectId` — the tell is that the message's `subjectId` **equals the channel id** (the resolver falls back to the channel id when there is nothing bound). When you see that on an external/inbound channel:
+
+1. **Match an existing client** — `entity.query({ profileSlug: 'client', filter: { ... } })` on the sender's name/handle/domain. Never create a duplicate: bind to the match if one exists.
+2. **Create one if there is no match** — a `client` entity (the create-then-configure minimum: just enough to exist).
+3. **Bind the channel to it** — `channel.bind({ channelId, contextObjectType: 'entity', contextObjectId: <clientEntityId>, branchPurpose: 'client-comms' })`. The inbound channel mirrors to the client, so it is `client-comms`.
+
+After binding, you are done for every future message: they all arrive entity-resolved, and the team-channel resolution the automations need starts working. Explain the bind briefly, the way you would when keeping notes ("Binding this channel to Acme so everything they send lands on their record.").
+
+**FIREWALL:** binding a channel `client-comms` marks it as mirrored to the client. NEVER post bot/team output to a `client-comms` channel — collaboration goes to the sibling `team` channel (see below). When unsure of a channel's role, bind it `client-comms` (the safe default).
+
+### Onboarding a KNOWN client (you already have, or are creating, the entity)
+When you create or onboard a client, wire its channels in the same move so the firewall has both surfaces from day one:
+
+1. **Client-comms channel** — `channel.ensure({ contextObjectType: 'entity', contextObjectId: <clientEntityId>, branchPurpose: 'client-comms' })` (find-or-create). If the client's external channel already exists, `channel.bind(...)` it instead of ensuring a new one.
+2. **Team sibling channel** — `channel.ensure({ contextObjectType: 'entity', contextObjectId: <clientEntityId>, branchPurpose: 'team' })`. This is the channel every automation resolves via `channel.resolve({ ..., channelType: 'team' })`. Without it, team-facing posts (grant review flags, digests) have nowhere firewall-safe to land.
+
+Both point at the SAME client entity — one `client-comms`, one `team`. That pairing is what lets bot/team output surface on the team channel and NEVER leak into the client channel.
+
+> Population model: onboarding binds the clients you already know; on-the-fly binding (above) catches the unknown ones on their first inbound message. Together they cover the whole roster.

package/templates/skills/stellar-scf-grants-advisor/ASSOCIATE-CHEATSHEET.md

@@ -0,0 +1,133 @@
+# Associate cheatsheet (1 page)
+
+Print this. Keep it next to you during reviews and client calls.
+
+## The 7-step review process
+
+1. Read the client's submitted content (every field).
+2. Web-fetch website, deck, founder LinkedIns, GitHub.
+3. Score against 14 signals (1 to 10 each).
+4. Identify rejection patterns + cite past examples.
+5. Surface winning patterns (don't erase strengths in rewrites).
+6. Compare to 10-15 corpus comparables.
+7. Generate Excel + chat summary with probability range.
+
+## The Excel deliverable (4 sheets, always)
+
+| Sheet | Content |
+|---|---|
+| 1. Field-by-Field Review | Q-numbers, Status, Review (FR or EN), Rewrite (EN paste-ready) |
+| 2. Pre-submission Checklist | Priority, Item, Field, Effort, Why, Status |
+| 3. Corpus Comparables | 10-15 past dossiers side-by-side with current |
+| 4. Integration List Audit | Each Stellar item: MENTIONED / TO ADD / OPTIONAL / NOT RELEVANT |
+
+## Banner row formula
+
+> "[Project] [Phase] Review v[N]: estimated XX to YY pct probability now, AA to BB pct after fixes. Budget anchor $[X],000 [Track], anchored on [Named Past Winner] ($YYK SCF #NN)."
+
+## Vocabulary translation (NEVER use left column with clients)
+
+| Internal | Client-friendly |
+|---|---|
+| kill signature | common rejection pattern, recurring red flag |
+| corpus | our database of 130+ rejected and 79+ awarded dossiers |
+| doxxing depth | whether founders are publicly identifiable |
+| bolt-on | port from another chain without a Stellar-specific reason |
+| TAM-grandiose | vague total addressable market claims |
+| sub-max | below the $150K maximum |
+| heightened scrutiny | extra scrutiny applied at maximum-ask submissions |
+
+## The 14 signals (memorize order)
+
+1. Team identity (doxxing depth)
+2. Stellar-native traction
+3. Budget realism vs scope
+4. Scope clarity (named contracts + Integration items)
+5. Differentiation from previously-funded teams
+6. Track choice fit (Integration vs Open vs RFP)
+7. Go-to-market specificity (named partners + customers)
+8. Milestone precision (verifiable evidence + quantified targets)
+9. Traction evidence (live URLs + LOIs + revenue)
+10. Regulatory framing (named framework + license partner)
+11. Open-source posture (MIT/Apache 2.0)
+12. Brand non-collision
+13. SDF roadmap alignment (x402, Protocol 25 X-Ray, EURC, MiCA, agentic payments)
+14. Comeback signal (only for reapplying teams)
+
+## The 12 rejection patterns (memorize by name)
+
+1. Unidentifiable-founder pattern
+2. Maximum-budget-without-scope pattern
+3. Generic-name pattern
+4. Brand-collision pattern
+5. Multi-chain-bolt-on pattern
+6. SDF-roadmap-overlap pattern
+7. Already-funded-competitor pattern
+8. Regulated-product-without-regulatory-plan pattern
+9. Vague-TAM pattern
+10. Earn-via-low-effort-activity pattern
+11. Incomplete-dossier pattern (Information Collection status)
+12. Cluster-of-issues rejection (Panel Review Failed)
+
+## Budget anchors (memorize)
+
+| Anchor | Profile | Budget range |
+|---|---|---|
+| Bando (SCF #42 won) | RWA single-pilot, doxxed, regulated partner named | $75K-$90K |
+| TheXBank (SCF #40 won) | Africa banking with country pilot | $80K-$100K |
+| The Signal (SCF #42 won) | B2B marketplace, 2 doxxed, 1 contract | $115K-$125K |
+| Rebond (target SCF #44) | RWA bonds, 2 doxxed, 4 LOIs, regulatory framework | $125K-$135K |
+| For Yield (target SCF #44) | Regulated DeFi yield, 11-team, AMF filed | $135K-$145K |
+
+Tranche structure (always 3 equivalent tranches):
+- $90K = 3 x $30K
+- $108K = 3 x $36K
+- $121.2K = 3 x $40.4K
+- $132K = 3 x $44K
+- $144K = 3 x $48K
+
+## Pre-screen blockers (NEVER ship a Build phase dossier without these)
+
+- Q5 Code URL: public GitHub with README + MIT + scaffold (ideally testnet contract deployed)
+- Q6 Video URL: YouTube/Vimeo, under 3 min, 5-segment script, live demo on Stellar Expert
+- Q10 Technical Architecture: public Notion or GitHub markdown with C4 L1 + L2 + flows
+- Q8 Thumbnail: 1200x630 image uploaded
+
+## SCF Integration List essentials
+
+- **Wallets**: Stellar Wallets Kit (default), Privy (mainstream), DFNS (institutional), Freighter Connect
+- **Off-ramp**: Anchor Platform (EU), Bridge (Stripe-acquired), MoneyGram (emerging markets), Mercuryo
+- **DeFi**: DeFindex (yield), Blend v2 (lending), Aquarius (DEX), Soroswap (aggregator)
+- **Cross-chain**: Allbridge, Near Intents, Axelar
+- **Payments**: Stellar Disbursement Platform (SDP)
+
+Items NOT on the list (Fireblocks, Elliptic, Certora, Wirex) = supporting infra, not Integration Track items.
+
+## Em-dash rule
+
+Never use the long-dash punctuation character (the wide horizontal line, Unicode U+2014) in any client deliverable. Use commas, colons, parentheses, periods, or single hyphens instead. The long-dash reads as machine-generated.
+
+## QA before sending any deliverable
+
+1. Zero em-dashes anywhere in the file.
+2. Zero use of "kill signature" anywhere in the file.
+3. Every flagged problem cites at least one named past dossier.
+4. Budget recommendation cites a named past winner with comparable profile.
+5. Every paste-ready rewrite (Column D) is in English, not French.
+6. Banner row contains specific numbers (not "TBD").
+7. Sheet names: "Abstract Review" or "Build Review" / "Checklist Pre-Submit" / "Comparables Corpus" / "Audit Integration List".
+
+## The chat summary after every delivery
+
+> "Dossier livré, fichier v[N] sauvegardé.
+> Verdict: estimated XX-YY pct probability now, AA-BB pct after fixes.
+> Top 5 fixes (in priority order): [list].
+> Recommended budget: $[X],000 [Track], 3 tranches of $[X/3].
+> [Open the file](computer://path/to/file.xlsx)"
+
+## Quick prompts for Claude with the skill
+
+- Review: "Review this SCF Abstract: [URL]. Round SCF #[N]. Give me the 4-sheet Excel deliverable."
+- Budget only: "Recommend budget for [category] dossier with [team] and [traction]."
+- Triage: "Top 3 rejection patterns this dossier triggers. Cite past dossiers."
+- Comeback: "Lost SCF #[N] at $[X]. Profile: [details]. What changed? What to fix?