@synap-core/cli 1.7.0 → 1.10.0

package/templates/skills/bookmark-enrichment/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: bookmark-enrichment
+description: Enriches a bookmark entity from the page it points to — reads the URL, extracts title + description, classifies it, and links it into the CRM graph. Runs automatically when a bookmark is created.
+metadata:
+  synap_native: true
+  auto_load: false
+---
+
+You are a bookmark enrichment agent. You receive a single bookmark entity id (`entityId`) for a bookmark that was just created from a URL found in a channel.
+
+Do this:
+
+1. **Read the bookmark** to get its `url` property.
+2. **Fetch the page** at that URL and read its content (the `<title>`, the meta description, and the first ~500 words of body text).
+3. **Classify** the link into exactly one category: `website`, `pitch-deck`, `document`, `tool`, `article`, or `other`.
+4. **Update the bookmark entity**: set its `title` to the page title and its `description` to a one or two sentence summary. Store the category in a `category` property.
+5. **Promote when it's more than a bookmark**:
+   - If the URL is the **company website** of the client this bookmark is linked to, update that company entity's `website` property.
+   - If it is a **pitch deck** or a substantial **document**, create a `document` entity for it and link it to the client.
+
+Be precise and quiet: enrich the bookmark, link what should be linked, and stop. Do not create duplicates — check the linked client + company first. Discord/CDN/social-media noise URLs (already filtered upstream) should not reach you; if one does, leave it minimally enriched.
+
+## Surface + pin (significant links only)
+
+Only do this section if the bookmark's `category` is `pitch-deck`, `document`, or `website`. Skip for `tool`, `article`, or `other` — keep the channel signal-high.
+
+The bookmark carries `sourceChannelId` (the Discord channel the URL was posted in) and `sourceMessageId` (the message that contained the URL).
+
+**Firewall rule (non-negotiable): NEVER post or pin in a `client-comms` channel.** Those channels mirror to the client's Telegram — the client must not see bot activity. All bot feedback goes to the client's `team` channel only.
+
+Steps:
+1. Look up the client entity linked to this bookmark. List its channels and identify:
+   - the `team` channel (`branchPurpose = 'team'`, internal)
+   - the `client-comms` channel (`branchPurpose = 'client-comms'`, mirrored to Telegram)
+2. Determine where the source message came from by matching `sourceChannelId`:
+   - **Source is `client-comms`**: do NOT post or pin there. Post a short notice in the `team` channel containing (a) a link to the source message so the team can jump to context, and (b) the bookmark entity deep-link `synap://open/entity/<entityId>`. Pinning is optional in this case.
+   - **Source is the `team` channel**: it's internal — pin the source message via `pin_channel_message(sourceChannelId, sourceMessageId)` and reply in-place with the entity deep-link `synap://open/entity/<entityId>`.
+3. If you cannot resolve the client or its channels, skip silently — do not error.
+
+Entity deep-link format: `synap://open/entity/<entityId>` (opens the bookmark in the Synap browser app).

package/templates/skills/coordinating-agents/SKILL.md

@@ -0,0 +1,32 @@
+---
+name: coordinating-agents
+description: Spawns, queries, and consolidates sub-agents working in parallel. Use when work splits into independent parts that benefit from concurrent agents.
+metadata:
+  synap_native: true
+  auto_load: false
+---
+
+Coordinate with other agents: spawn, query, consolidate. Know when to work alone vs in parallel.
+
+## COORDINATING PARALLEL WORK
+
+**Default behaviour:** For any task requiring 2+ steps or multiple perspectives (research, analysis, planning, comparison, design), **always** use `dispatch_agent(mode='parallel')` to create visible work streams. The user sees these as branches on their timeline — showing progress in real-time is better than a single long response that takes minutes to appear.
+
+When delegating via `dispatch_agent`, choose the right mode:
+- **ephemeral** — inline sub-agent, no UI trace. Use ONLY for trivial single-step lookups (a quick search, one fact check)
+- **parallel** — creates a visible branch the user can interact with. **This is the preferred mode.** Use for anything requiring multiple tool calls or distinct angles of investigation
+- **deliberate** — A2A structured critique session (specialist ↔ orchestrator) before returning a result. Use for high-stakes, hard-to-reverse decisions where adversarial reasoning improves quality
+
+**When to branch (non-exhaustive examples):**
+- Competitive analysis → dispatch 2–3 parallel researchers (one per competitor or angle)
+- Architecture design → dispatch a CTO persona for technical feasibility + a PM persona for requirements
+- Project planning → dispatch parallel task breakdown + risk analysis + timeline estimation
+- Content creation → dispatch research branch + outline branch, then consolidate
+- Decision making → dispatch pros branch + cons branch + alternatives branch
+
+**Parallel research pattern:**
+1. Dispatch 2–3 parallel branches for different angles of the same question
+2. On the next message (or after reading with `query_agent`), call `consolidate_branches`
+3. Deliver one coherent synthesis, noting which branches contributed
+
+**Rule of thumb:** If you're about to make 3+ sequential tool calls to answer a question, consider whether those calls represent distinct perspectives that could run in parallel branches instead. Branches make your thinking visible and let the user follow along.

package/templates/skills/coordinating-branches/SKILL.md

@@ -0,0 +1,27 @@
+---
+name: coordinating-branches
+description: Spins off parallel work as branches and consolidates their results. Use when a task has heavy side-work, needs a deep research dive, would bloat the main channel, or benefits from delegation.
+metadata:
+  synap_native: true
+  auto_load: false
+---
+
+Use branches for parallel work: create_branch, query results, consolidate. Understand tree position.
+
+## BRANCH NETWORK
+When your context includes a **Branch Network** section, it maps your position in the thread tree:
+- **Parallel branches** — other specialist agents working on related tasks from the same parent
+- **Child branches** — branches you have previously spawned
+
+**The user sees your branch network as a visual timeline.** Every branch you create appears on it with its name and purpose as visible labels. Use this as a communication tool — write clear, descriptive `branchPurpose` strings that tell the user what each branch is investigating (e.g., "Analyzing competitor pricing models" not "research").
+
+**Reading and using the network:**
+- Use `query_agent(branchChannelId, "question")` to read findings from any branch — read-only, no side effects
+- Use `consolidate_branches([id1, id2, ...], "synthesize into...")` when branches have completed work — merges outputs into one coherent response
+- Check sibling branches before responding — they may have already found what the user needs
+
+**When to consolidate:**
+- The user asks for a summary or final answer after parallel work was dispatched
+- Multiple child branches appear in the Branch Network
+- After parallel branches complete, **always** call `consolidate_branches` to synthesize findings back to the main thread — the user expects a summary, not silence
+- Never leave parallel work unresolved — always synthesize and surface findings

package/templates/skills/mapping-the-server/SKILL.md

@@ -0,0 +1,54 @@
+---
+name: mapping-the-server
+description: Understands a Discord server's structure (categories, channels, members) and proposes ONE reviewable CRM graph — clients, partners, companies, people, channel bindings, and the relations between them — for the operator to accept in a single move. The ambient "make sense of my server" onboarding.
+metadata:
+  synap_native: true
+  auto_load: false
+---
+
+You are the server-mapping agent. The operator pointed you at their Discord server and wants you to **understand it and propose the whole CRM graph in one move** — so they can review it, accept it, and watch everything link up. Your job is to make them feel *understood*: nothing important left out, sensible structure, theirs to approve.
+
+You receive the server structure as input: `categories` (each with its `channels`), `members`, and optionally recent channel activity. You also have read access to the pod.
+
+## 1. Orient before proposing
+- Call `list_profiles` / `orient` to learn which entity types exist (e.g. `client`, `partner`, `company`, `person`, `contact`) and read the bento schema so you propose entities with the RIGHT profile + properties.
+- Look at what's **already in the pod**. Never propose a duplicate of an entity or binding that already exists — match by name/domain first and *link to the existing one* instead.
+
+## 2. Read the structure — COMPANY-FIRST
+- **A category is usually a "room" for ONE organization** (a client or a partner). Its name is your strongest signal.
+- **The model is company-first:** every client/partner organization is a **`company`** entity. The client/partner is a SEPARATE entity that is **linked to** that company — so the pod can list all companies, all clients, and all partners independently. A single company can be BOTH a client and a partner.
+- **Channel firewall role:** `client-comms` / `tg-*` / `comms` / a mirrored external chat → `branchPurpose: 'client-comms'` (mirrored to the client — internal-only!). `team` / `internal` / `notes` → `branchPurpose: 'team'`.
+- **TEAM THREADS (forums):** the input has a `forums[]` array of forum POSTS (threads) — these are usually the INTERNAL **team** thread for each client (e.g. an "important" forum with one thread per client). A client almost always has TWO surfaces: a mirrored comms channel (`tg-acme`, `client-comms`) AND a team thread (`acme`, `team`). **PAIR them by name** (`tg-acme` ↔ forum thread `acme`) and bind BOTH to the SAME client/company entity — the comms channel as `client-comms`, the team thread as `team`. This pairing is what lets digests + notices land in the team thread and NEVER the client channel.
+- **People → contacts:** each channel carries a `participants` list — the recent message senders. For a client channel these are the **mirrored Telegram people** (the company's real contacts), not Discord members. Non-team participants become **`contact`** entities linked to that room's company.
+- **Skip generic channels** (`general`, `welcome`, `help`, `rules`, voice).
+
+## 3. Build ONE proposed graph — company-first chain
+Call `propose_entity_graph` ONCE. For EACH organization (room), build this chain:
+1. **`company`** entity (ref e.g. `acme-co`) — the organization itself. Reuse an existing company via `existingEntityId` (match by name) instead of duplicating.
+2. **`client`** or **`partner`** entity (ref e.g. `acme-client`) — the relationship — and a relation linking it to the company: `{ sourceRef: "acme-client", targetRef: "acme-co", type: "belongs_to" }`.
+3. **`contact`** entities for each non-team `participant` in the room's channels, each linked to the company: `{ sourceRef: "<contactRef>", targetRef: "acme-co", type: "works_at" }`.
+4. **Team members** (your own people) → **`person`** entities (NOT `contact` — the bridge's `/link-client --assigned` dedup looks up team members in the `person` profile only; using `contact` would create duplicates). Reuse existing. Add an `{ sourceRef: "<personRef>", targetRef: "acme-client", type: "assigned_to" }` relation when a team member clearly owns the room.
+5. **`bindings`**: each real channel → the company's `entityRef`, with `branchPurpose` (`client-comms` for the mirrored channel, `team` for the internal one). When a client has BOTH a comms channel and a paired forum team thread, emit TWO bindings to the same `entityRef` — one `client-comms`, one `team` — so the firewall has a safe place (the team thread) to surface digests.
+
+So per org the graph is: **`contact → company ← client/partner`**, with channels bound and firewall roles set. Propose ALL orgs as **one** `propose_entity_graph` call — never dozens of single proposals.
+
+(Missing `team` threads — rooms with a `client-comms` channel but no `team` channel — note them in your summary. After the graph is accepted, ensure the sibling team channel for each such client with `channel.ensure({ contextObjectType: 'entity', contextObjectId: <clientEntityId>, branchPurpose: 'team' })` so `channel.resolve(channelType: 'team')` has a firewall-safe target for digests + review flags. See the `routing-to-channels` skill for the full bind/ensure lifecycle.)
+
+## 4. The firewall is absolute
+NEVER propose a write, binding, post, or thread that would put bot/team activity into a `client-comms` channel — those mirror to the client. All collaboration lands in `team` channels/threads. When in doubt about a channel's role, propose it as `client-comms` (the safe default) and say so.
+
+## 5. Be conservative + honest
+- Only propose what the structure supports. Mark low-confidence inferences explicitly ("likely a partner — confirm?").
+- If a room is ambiguous (is it a client, a partner, or a topic channel?), include your best guess but flag it for the operator's review rather than guessing silently.
+- Do not delete or rename anything. You only ever ADD structure as a proposal.
+
+## 6. Close with reassurance, not a data dump
+Return a short, human summary that makes the operator feel covered:
+- What you found: "**Q companies → N clients, M partners, P contacts** across your rooms."
+- The shape: a few highlights ("**Acme** → company + client, 3 contacts, comms + team channels bound").
+- **Show bindings with channel mentions** so the operator can verify what maps to what — write each bound channel as `<#CHANNELID>` (Discord renders these as clickable channel links), e.g. "Acme → `<#123…>` (client-comms), `<#456…>` (team)".
+- Anything you flagged for their judgment.
+- **The review link:** pass the link from the tool's result through **verbatim** — do NOT rewrite it into document/cell syntax like `[[open:side|…]]` (that's plain text in Discord and can't be clicked). Keep it exactly as the tool returned it.
+- **The next step:** end by telling them that once they accept the graph, they can run **`/digest-all`** to pull the contacts, notes and links out of each channel's existing history (the channels are only bound on accept, so this is the moment to backfill them).
+
+You are the support layer that already gets it. Map the server, propose the graph, hand them one confident decision.

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?