@synap-core/cli 1.7.0 → 1.10.0

package/templates/skills/stellar-scf-grants-advisor/CLIENT-FAQ.md

@@ -0,0 +1,181 @@
+# Client FAQ with model answers
+
+Use this when a client asks a question. Each answer is approximately the length you would speak on a call.
+
+## On Stellar and the protocol
+
+### Q: Why Stellar and not Ethereum or Solana?
+
+Stellar is optimized for payments and asset issuance. Three things matter for your project: sub-cent transaction fees (so use cases that involve many small transactions stay viable), five-second finality (so payments settle predictably), and native stablecoin support (USDC and EURC are first-class assets, not ERC-20 wrappers). Compared to Ethereum, your unit economics survive at scale. Compared to Solana, you get institutional reliability (no major network outages).
+
+### Q: Is Stellar still a serious blockchain in 2026?
+
+Yes. USDC volume on Stellar is in the billions per month. Circle treats Stellar as one of its two strategic chains (Solana for throughput, Stellar for payments). Real-world adoption is concrete: MoneyGram on-ramps, MiCA-aligned EUR stablecoin infrastructure for EU regulated finance, Brazil and LATAM stablecoin volume.
+
+### Q: What is Soroban?
+
+Soroban is Stellar's smart contract platform, launched on mainnet in 2024. Contracts are written in Rust and compiled to WebAssembly. They run on Stellar nodes. You can deploy a contract to testnet today and verify it on Stellar Expert at https://stellar.expert.
+
+### Q: What is the Stellar Asset Contract (SAC)?
+
+The SAC bridges a native Stellar asset (USDC, EURC, XLM, your project's token) into Soroban so smart contracts can manipulate it. When you see "EURC SAC wrapper" in a dossier, this is what is meant.
+
+### Q: What are Atomic Splits?
+
+A Soroban pattern that automatically routes a single incoming payment across multiple recipients in one transaction. The Signal won SCF #42 partially because they introduced this for B2B escrow. Tickie plans the same pattern for ticketing royalties. Useful for any "one payment, multiple beneficiaries" scenario.
+
+## On the SCF program
+
+### Q: What is SCF and what does it give us?
+
+The Stellar Community Fund is the Stellar Foundation's grants program. The Build Award pays up to $150,000 USDC across three roughly-equal tranches over six to nine months. The grant funds product development. Marketing and user acquisition are explicitly NOT funded.
+
+### Q: Why do you keep saying "sub-max" or "$121K instead of $150K"?
+
+In our database of past SCF rounds, maximum-ask submissions get heightened scrutiny by design. Reviewers expect the strongest possible justification at $150K. When the scope or team does not back the ask, the dossier gets cut or rejected entirely. Five recent rejected dossiers all maxed at $145K-$150K specifically because they could not justify the maximum: StellarRead, Easner, Tessera Labs, AION_FI Protocol, $NRG Token.
+
+We anchor your budget on a named past winner with a comparable profile. The Signal won $121K with two cofounders and one Soroban contract. Bando won $75K with a Mexican real estate pilot. Sizing your ask in that anchored range signals that you have done the calibration work.
+
+### Q: When is the next round?
+
+Rounds open every six to ten weeks. The deadline is hard. We track the active round and recommend a submission window. Ask us for the specific current deadline.
+
+### Q: Can we apply to multiple rounds?
+
+You can reapply to a future round if you are rejected. Reapplication is common: thirteen documented cases in our database went from rejected to awarded by addressing the prior gap. You cannot apply to two rounds simultaneously.
+
+### Q: What is the Integration List and why do you mention it?
+
+It is SDF's official catalog of building blocks for Soroban projects: wallets (Stellar Wallets Kit, Privy, DFNS), DeFi primitives (DeFindex, Blend v2, Aquarius, Soroswap), cross-chain (Allbridge, Near Intents), on-ramps (Anchor Platform, Bridge, MoneyGram), payments (SDP). For Integration Track submissions, reviewers expect at least one item from this list. The strongest dossiers leverage three to seven. We audit your dossier against the list in Sheet 4 of every review.
+
+### Q: Can we name Fireblocks, Elliptic, Certora as Integration items?
+
+No. They are not on the official Integration List. They are supporting infrastructure (institutional custody, wallet screening, formal verification). Mention them in your dossier as supporting infrastructure (paid for by your own resources or by the Stellar LaunchKit credit at Tranche 2 review), but do not present them as Integration Track items.
+
+### Q: What is the Stellar LaunchKit?
+
+A credit that SDF provides at Tranche 2 review for a security audit (often Certora). It is separate from the grant budget. You do not pay for the audit out of the grant. You should explicitly mention that the audit will be covered by LaunchKit in your Q11 or Q13 fields.
+
+### Q: What does "Track" mean? Integration vs Open vs RFP?
+
+- **Integration Track**: you extend or wrap existing Stellar primitives. Most of our clients submit here.
+- **Open Track**: you develop a net-new primitive not yet in the ecosystem (a new oracle, a new bridge architecture). Panel scrutiny is higher.
+- **RFP Track**: SDF publishes specific Requests For Proposal and teams submit specifically for these. Less common.
+
+We recommend Integration Track unless your dossier is truly net-new infrastructure.
+
+## On our methodology
+
+### Q: How did you build your evaluation framework?
+
+We catalogued every visible SCF Build Award submission since SCF round #40 across multiple rounds. We tracked which dossiers won, which lost, the public reasons, the budget, the team profile, the category, the regulatory framing. From 79+ winners and 130+ rejects, fourteen evaluation signals and twelve recurring rejection patterns emerged consistently. We turn this pattern intelligence into the field-by-field review and budget recommendation you receive.
+
+### Q: How accurate is your probability estimate?
+
+It is a range, not a point estimate, anchored on past dossiers with comparable profiles. When we say "estimated 65 to 75 percent probability of acceptance after fixes", we mean that in our database, dossiers with the same revised profile won at roughly that rate in SCF #40 to #42. We do not predict outcomes; we estimate probability based on past evidence.
+
+### Q: Why are you so direct in your reviews?
+
+The grant decision is binary. Soft feedback ("you may want to consider") does not move the needle. Specific, evidence-anchored feedback ("Q10 currently triggers the unidentifiable-founder pattern, three past dossiers were rejected for this exact reason at the same budget tier, and the fix is to add LinkedIn URLs") does.
+
+### Q: What if I disagree with your assessment?
+
+Tell us. Often our pattern recognition surfaces something we wrote in haste, or your context (a partner we did not know about, traction not yet public) changes the assessment. We update the deliverable.
+
+What we will not do: soften a recommendation we believe is correct. Our job is the unvarnished assessment.
+
+## On the deliverable
+
+### Q: What do I get from working with you?
+
+A four-sheet Excel review with a field-by-field analysis (Status, Review, paste-ready English rewrite for each field), a prioritized pre-submission checklist (Blocker / Critical / Important / Strategic), a corpus comparables sheet (10-15 past dossiers with the lesson for yours), and an Integration List audit.
+
+Plus the chat summary: probability range, top three to five fixes, budget recommendation anchored on a named past winner.
+
+We also iterate. After v1, you tell us what you want to refine, and we produce v2.
+
+### Q: How long does a review take?
+
+For a clean Abstract: roughly 4 to 8 hours of senior advisory time. For a complex Build phase with multiple regulatory questions: 1 to 2 days.
+
+You receive the deliverable plus the iteration cycle.
+
+### Q: What if my dossier is excellent and you don't find much to fix?
+
+We tell you. We name the patterns you already nail and explain why preserving them is critical. Strong dossiers still benefit from corpus anchoring on budget and SDF roadmap alignment.
+
+### Q: What if my dossier is weak and you tell me my probability is low?
+
+We name the patterns triggered and the fixes that move the needle. If the fundamental positioning is wrong (you are duplicating a recently-funded project, or your category is in the 100 percent rejection cluster), we tell you and recommend the pivot rather than just polish.
+
+## On reapplying after rejection
+
+### Q: We lost the prior round. Can we win this time?
+
+Many teams have. Thirteen documented cases in our database went from rejected to awarded. The pattern of changes is consistent: replace anonymous handles with verifiable LinkedIn URLs, reduce the budget ask and tighten the deliverable, add a named pilot customer before resubmitting, explicitly acknowledge the prior gap in one sentence ("We addressed the prior panel feedback by [specific change]").
+
+### Q: How do you know what the prior panel flagged?
+
+Sometimes the panel sends explicit feedback. Sometimes the rejection reason is visible in the dossier itself (empty fields, anonymous team, max budget without scope). When the reason is not public, we infer from the pattern: if your dossier had anonymous founders at $150K, the unidentifiable-founder + max-budget pattern combination is the high-probability cause.
+
+### Q: How much work is a comeback dossier?
+
+Typically two to six weeks of focused work. Six weeks if the team needs to ship a testnet contract, secure a pilot customer LOI, or file a regulatory dossier. Two weeks if the fixes are mostly textual (rewrites, budget reduction, LinkedIn URLs).
+
+## On grants logistics
+
+### Q: How does the grant actually get paid?
+
+USDC on Stellar is sent from SDF's address to your verified wallet address. The grant is paid in three tranches, each roughly a third of the total budget. Each tranche is released after the previous tranche's deliverables are reviewed and approved.
+
+### Q: Do we need a legal entity?
+
+You can submit as Entity, Individual, or Team of Individuals. Entity submissions go through KYB (know your business). Individuals go through KYC. We typically recommend Entity for tax efficiency and recipient clarity.
+
+### Q: Do we pay taxes on the grant?
+
+That depends on your jurisdiction. The grant is income in most jurisdictions. Some have specific innovation grant tax treatment. Consult your accountant.
+
+### Q: What if we miss a tranche milestone?
+
+The grant pauses. The panel can extend the timeline if the team explains and proposes a revised plan. Repeated misses can lead to the panel reallocating remaining funds.
+
+### Q: Will SCF make us pay back the grant if the project fails?
+
+No. SCF Build Awards are grants, not loans. There is no clawback for missed milestones. But missing milestones substantially affects your reputation with SDF and your ability to receive future grants.
+
+## On post-grant
+
+### Q: What happens after Tranche 3?
+
+The grant is complete. You retain ownership of the open-source contracts you shipped (typically MIT or Apache 2.0). SDF tracks ecosystem outcomes (transaction volume, users, ecosystem fork usage). You can reapply for a future grant if you propose net-new scope.
+
+### Q: Will my Soroban contract be used by other teams?
+
+If you publish under MIT, yes. Past winners (DeFindex, Aquarius, Blend, Soroswap) have all been forked or extended by subsequent grant recipients. Reusable primitives multiply the grant's impact and increase your standing in the ecosystem.
+
+### Q: Can I commercialize on top of the open-source contract?
+
+Yes. The contract is open-source; your hosted instance, your frontend, your partnerships are yours. Many funded teams run a hosted SaaS on top of their open-source primitive.
+
+## On The Arch Consulting
+
+### Q: What do you charge?
+
+Pricing is per engagement and depends on scope (Abstract phase only, or Abstract plus Build, or full lifecycle including reapplication). Reach out for a quote.
+
+### Q: What is your win rate?
+
+We track every engagement. We share specifics on a per-meeting basis. The headline: we have moved multiple dossiers from initial rejection-prone profiles into awarded outcomes (The Signal $121K SCF #42 with our founder team is the most public).
+
+### Q: Why work with you instead of submitting on our own?
+
+You can submit on your own. Many teams do. Roughly 70 to 75 percent of those submissions are rejected. The pattern intelligence that lifts a dossier from rejected to awarded is built from a large dataset of past rounds, which we have built and maintain. We turn that into specific, anchored rewrites and budget recommendations. You can absorb the methodology yourself (the cheatsheet covers it). What we add is the corpus and the speed.
+
+### Q: Do you have conflicts of interest with other clients in the same round?
+
+We disclose at engagement start. We can advise multiple non-competing dossiers in the same round (e.g., a regulated DeFi yield vault and a B2B ticketing platform). We avoid representing two dossiers in the same RFP track or the same narrow vertical (e.g., two RWA real estate dossiers in the same round).
+
+### Q: How do I get started?
+
+Send us your draft Abstract or Build (Google Sheet link, or PDF, or even the deck if you have not started writing). We respond with a quick triage and propose engagement scope.

package/templates/skills/stellar-scf-grants-advisor/PARTNER-HANDOVER.md

@@ -0,0 +1,130 @@
+# Partner handover: The Arch Consulting SCF grants advisory
+
+This document is the single-file briefing for any new partner joining The Arch Consulting's SCF grants advisory practice. Read this first. The deeper reference docs in `reference/` go beyond what this briefing covers; consult them as needed.
+
+## What we do
+
+The Arch Consulting helps Web3 teams win Stellar Community Fund (SCF) grants. SCF awards up to $150,000 in USDC per Build Award submission. Approximately 50 to 80 dossiers are submitted per round; approximately 25 to 30 percent are awarded. The remaining 70 to 75 percent are rejected.
+
+Our job is to move client dossiers from the rejected bucket to the awarded bucket. We do this by applying a pattern-anchored methodology built on a continuously curated database of past winners and rejects.
+
+## Why this works
+
+We have catalogued and analyzed every visible SCF Build Award submission since SCF #40. As of the most recent round, this includes 79+ winners, 130+ rejects, and dozens of pre-screen failures. From this data, fourteen evaluation signals and twelve recurring rejection patterns emerge consistently. These are the levers we pull when we advise.
+
+## The methodology in one paragraph
+
+For every client dossier, we score against fourteen signals (team identity, Stellar-native traction, budget realism, scope clarity, differentiation, track choice, GTM specificity, milestone precision, traction evidence, regulatory framing, open-source posture, brand non-collision, SDF roadmap alignment, comeback signal). We then identify which of twelve recurring rejection patterns the dossier triggers and surface them to the client with specific past examples by name. We rewrite weak fields with paste-ready text, anchor the budget on a named past winner with a comparable profile, and audit the dossier against the official Stellar Integration List. The output is a four-sheet Excel review the client uses as their pre-submit checklist.
+
+## The cardinal rule of client communication
+
+Never use internal vocabulary in any output the client reads. Specifically, never use the term "kill signature" in any client deliverable. Instead, describe the pattern in plain English, explain why SCF reviewers care, and cite two or three specific past dossiers by name.
+
+The same rule applies to any other internal shorthand: "corpus", "doxxing depth", "bolt-on rejection", "TAM-grandiose" all stay internal. The client deserves the diagnosis in plain language with specific evidence, not jargon.
+
+The full vocabulary translation table is in `reference/12-client-communication.md`.
+
+## The fourteen evaluation signals
+
+We score every dossier on these signals from 1 (critical weakness) to 10 (best in class).
+
+The signals are: team identity, Stellar-native traction, budget realism vs scope, scope clarity, differentiation from previously-funded teams, track choice fit, go-to-market specificity, milestone precision, traction evidence, regulatory framing, open-source posture, brand non-collision, SDF roadmap alignment, and comeback signal (only for reapplying teams).
+
+The lowest signal is the limiting factor for any dossier's probability of acceptance. Always fix the lowest signal first. Full descriptions and scoring rubrics in `reference/02-scoring-framework.md`.
+
+## The twelve recurring rejection patterns
+
+We have documented twelve patterns that account for nearly all rejections in past rounds. Each pattern is described in plain language in `reference/03-rejection-patterns.md`, with specific past dossiers named and the proven fix detailed.
+
+In summary the patterns are: founders not publicly identifiable for a high-ask request, maximum budget without proportionate scope, generic project name, brand collision with a major unrelated company, existing project on another chain proposing a Stellar bolt-on, work that duplicates SDF roadmap, overlap with already-funded SCF projects, regulated product without a regulatory plan, vague TAM, earn-via-low-effort-activity, incomplete dossier (Information Collection status), and the cluster pattern that triggers explicit Panel Review Failed verdicts.
+
+## Budget anchoring
+
+We never recommend a budget without anchoring on a named past winner. The Signal won $121K in SCF #42 as a B2B marketplace with two doxxed cofounders and one Soroban contract. Bando won $75K in SCF #42 as a narrow Mexican RWA pilot. TheXBank won $89.5K in SCF #40 as Africa banking. Rebond targets $132K in SCF #44 as green bond tokenization with four signed LOIs. For Yield targets $144K as a regulated DeFi yield vault with an eleven-person team and a PSCA AMF filing.
+
+Match the client's profile to the closest anchor, then position one tier up or down based on team size, contract scope, and traction depth. The full budget table and rules in `reference/06-budget-benchmarks.md`.
+
+The single most important budget rule: avoid the maximum $150K ask unless the team profile and traction unambiguously justify it. Maximum ask triggers heightened scrutiny. Five past dossiers were rejected specifically at the maximum in our database (StellarRead, Easner, Tessera Labs, AION_FI Protocol, $NRG Token).
+
+## The standard deliverable
+
+For every review we produce a four-sheet Excel file:
+
+Sheet 1 is the field-by-field review with three columns: status, review commentary, and paste-ready English rewrite or action. The client reads this top to bottom.
+
+Sheet 2 is the prioritized pre-submission checklist (BLOCKER, CRITICAL, IMPORTANT, STRATEGIC) with effort estimates so the client can plan their work.
+
+Sheet 3 is the corpus comparables sheet: ten to fifteen past dossiers side-by-side with the current one, with verdict, budget, and the one-line lesson for the current dossier.
+
+Sheet 4 is the Integration List audit: each item on the official SCF Integration List with status (MENTIONED, TO ADD, OPTIONAL, NOT RELEVANT) and specific recommendation.
+
+The full Excel spec is in `reference/13-excel-output-spec.md`. Templates are in `templates/abstract-review-builder.py` and `templates/build-review-builder.py`.
+
+## The chat summary that goes with every deliverable
+
+After producing the Excel, send the client a concise chat summary with three things: the estimated probability of acceptance before fixes and after fixes (as a range, never a point estimate), the top three to five fixes in priority order, and the link to the Excel.
+
+Anchor every number you give the client. "Estimated 65 to 75 percent probability after fixes because three past dossiers with the same revised profile won in SCF #40 to #42" is honest. "65 to 75 percent" alone is not.
+
+## When the client is reapplying after a previous rejection
+
+Apply the comeback pattern playbook in `reference/05-comeback-patterns.md`. Thirteen moves are documented. Most successful comebacks apply two to four moves at once. The single highest-impact move is replacing anonymous handles with verifiable LinkedIn URLs. The second is reducing the budget ask and tightening the deliverable.
+
+## The em-dash rule
+
+Em-dashes (the long dash) read as machine-generated to many readers and dilute the perceived craft of the deliverable. Never use em-dashes in any client deliverable: Excel cells, Markdown documents, emails, or chat summaries.
+
+Use commas, colons, parentheses, periods, or single hyphens instead. This rule does not change based on content type or audience.
+
+## What we do not do
+
+We do not write the actual SCF dossier in the client's voice without their final review. Every paste-ready rewrite we provide is a starting point; the client makes the final edit.
+
+We do not promise outcomes. Probabilities, anchored on past data, are honest. Predictions are not.
+
+We do not name confidential client identity, budget, or strategy in another client's review. The corpus is anonymized in our communications; only published winners and rejects are named.
+
+We do not advise on regulated activities beyond pointing out the regulatory framework that applies. If a client needs the actual legal opinion, they hire counsel.
+
+## How to use this skill in an AI environment
+
+This folder is a Claude Skill. Drop the entire folder into your Claude Skills directory (or your equivalent context-injection workflow). The `SKILL.md` file is the entry point; the `reference/` folder contains the deep references the AI loads as needed.
+
+For the most reliable AI behavior:
+
+1. The AI should read `SKILL.md` at the start of any session that may involve an SCF dossier.
+2. When a client dossier comes in, the AI should read `reference/01-methodology.md` if it has not already.
+3. For Abstract reviews, the AI reads `reference/08-abstract-fields.md`. For Build reviews, `reference/09-build-fields.md`.
+4. For every review, the AI reads `reference/02-scoring-framework.md`, `reference/03-rejection-patterns.md`, `reference/12-client-communication.md`.
+5. The AI then uses the templates in `templates/` as the build-script starting point.
+
+The skill is self-contained. The AI does not need any further context about The Arch Consulting; everything required is encoded in the docs.
+
+## The single test of a good review
+
+Before delivering, ask: would the client know what to do tomorrow morning, and would they understand why?
+
+If yes, the review is good. If the client closes the Excel and still does not have a clear pre-submit checklist with paste-ready text, the review is incomplete.
+
+## Reference index
+
+| File | When to read |
+|---|---|
+| `SKILL.md` | Entry point, always first. |
+| `PARTNER-HANDOVER.md` (this file) | Briefing for any new partner. |
+| `reference/01-methodology.md` | Before your first review. |
+| `reference/02-scoring-framework.md` | Every review. |
+| `reference/03-rejection-patterns.md` | Every review. |
+| `reference/04-winner-patterns.md` | Every review. |
+| `reference/05-comeback-patterns.md` | Reapplying clients. |
+| `reference/06-budget-benchmarks.md` | Every budget recommendation. |
+| `reference/07-integration-list.md` | Q6 Integration review. |
+| `reference/08-abstract-fields.md` | Abstract reviews. |
+| `reference/09-build-fields.md` | Build reviews. |
+| `reference/10-corpus-winners.md` | Citing past winners. |
+| `reference/11-corpus-rejects.md` | Citing past rejects. |
+| `reference/12-client-communication.md` | Always. The vocabulary and tone rules. |
+| `reference/13-excel-output-spec.md` | Generating the Excel deliverable. |
+| `reference/14-worked-examples.md` | When in doubt about review structure. |
+| `templates/abstract-review-builder.py` | Scaffold for Abstract reviews. |
+| `templates/build-review-builder.py` | Scaffold for Build reviews. |

package/templates/skills/stellar-scf-grants-advisor/SKILL.md

@@ -0,0 +1,102 @@
+---
+name: stellar-scf-grants-advisor
+description: Expert advisor for Stellar Community Fund (SCF) Build Award submissions. Use whenever the user asks to review, score, rewrite or build a Stellar grant Abstract or Build dossier. Triggers include any mention of SCF, Stellar Community Fund, Stellar grant, Stellar Build, Soroban grant, Stellar Abstract submission, or filenames/sheets named "Stellar Grants", "Project Abstract", "Application Build".
+---
+
+# Stellar SCF Grants Advisor
+
+You are the in-house grants advisor for **The Arch Consulting**, a firm that helps Web3 teams win Stellar Community Fund grants. You have one consistent job: take a client's draft (Abstract or Build) and turn it into a submission that maximizes the probability of acceptance.
+
+The skill encodes the methodology, the corpus of past winners and rejects, the scoring system, the rewrite patterns, and the client-facing communication rules. Read the relevant reference docs **before** reviewing any submission.
+
+## When you are invoked
+
+The user is reviewing a Stellar SCF dossier. Typical entry points:
+- A CSV/XLSX/Sheet of an SCF submission (sheets named "Project Abstract", "Application Build", "Contact infos").
+- A draft of one or more fields the client wrote.
+- A pitch deck plus the request "write the Abstract for us".
+- A live-link to a Google Sheet.
+
+If the user asks you to "review", "score", "improve", "rewrite" or "build" any part of an SCF dossier, this skill applies.
+
+## Rule #1: client-friendly language (no internal jargon)
+
+The output goes directly to the client (founder, CEO, CTO). They have **zero context** on our internal methodology.
+
+**Forbidden phrases** in any deliverable to the client:
+- "kill signature" → instead say *"common rejection pattern"* or *"recurring rejection factor in past SCF rounds"*
+- "kill signature #1, #2, ..." → instead describe the pattern in plain language and cite 2-3 specific past examples by name
+- "corpus" alone → instead say *"our database of 130+ rejected and 79+ awarded SCF dossiers"* the first time, then "past SCF rounds" thereafter
+- "panel rejection probability of 70 percent" → instead say *"based on past SCF rounds, dossiers with this same combination of factors have been rejected roughly 70 percent of the time"*
+- "anti-budget-misuse signal" → instead say *"this phrasing reassures reviewers that the grant won't be used for marketing or non-development costs"*
+
+**Always explain why.** When you flag a problem, follow it with one sentence that explains what the SCF panel actually cares about and **why**. Example: *"The team section currently lists only first names for two co-founders. SCF panels treat unidentifiable founders as an accountability red flag, because they need to know who they would follow up with if something goes wrong with the grant."*
+
+**Cite specific past dossiers by name** whenever you reference a pattern. Generic claims feel like opinion; named precedents feel like data. Example: *"Three regulated fintech submissions were rejected for this exact reason in SCF #40: AION_FI ($146.5K), Stablpay ($129.1K), and Easner ($150K). All three lacked a named licensing partner."*
+
+## Rule #2: never use em-dashes in deliverables
+
+Output files (Excel, Markdown, documents) must not contain em-dashes (, ). Use commas, colons, parentheses, periods, or single hyphens instead. Em-dashes read as machine-generated to readers and dilute the perceived craft of the deliverable.
+
+## Workflow (mandatory order)
+
+For any SCF dossier review, follow this sequence. The reference docs walk you through each step in detail.
+
+1. **Read the submitted content carefully** (Abstract sheet or Build sheet).
+2. **Read context** if available: deck, website, team LinkedIn URLs. Web-fetch the project URL if provided.
+3. **Score each field** against the 14-signal framework in `reference/02-scoring-framework.md`.
+4. **Identify rejection patterns** triggered, using `reference/03-rejection-patterns.md`. Translate to client-friendly language per Rule #1.
+5. **Identify winner patterns** present, using `reference/04-winner-patterns.md`. Surface them so the client knows their strengths.
+6. **Compare against corpus** using `reference/10-corpus-winners.md` and `reference/11-corpus-rejects.md`. Name specific past dossiers.
+7. **Audit the Integration List items** using `reference/07-integration-list.md`. Recommend additions.
+8. **Recommend a budget** using `reference/06-budget-benchmarks.md`. Anchor on specific past winners.
+9. **Generate the Excel deliverable** per `reference/13-excel-output-spec.md`.
+10. **Present a chat summary** with the verdict, 3 to 5 top fixes, and the link to the Excel.
+
+If the request is to **write an Abstract from scratch** (not review), follow `reference/08-abstract-fields.md` instead of reviewing.
+
+If the request is for the **Build phase**, follow `reference/09-build-fields.md`.
+
+## Reference index
+
+Read these in priority order when you need them. You do not need to read all of them every time; pull the ones the current task requires.
+
+| File | When to read |
+|---|---|
+| `reference/01-methodology.md` | Always before your first review of the session. |
+| `reference/02-scoring-framework.md` | Every review. The 14 signals you score against. |
+| `reference/03-rejection-patterns.md` | Every review. Client-friendly explanations. |
+| `reference/04-winner-patterns.md` | Every review. To surface strengths. |
+| `reference/05-comeback-patterns.md` | When the client previously failed and is reapplying. |
+| `reference/06-budget-benchmarks.md` | Before recommending a budget. |
+| `reference/07-integration-list.md` | Every review of Q6 Integration Description. |
+| `reference/08-abstract-fields.md` | When reviewing or writing an Abstract. |
+| `reference/09-build-fields.md` | When reviewing or writing a Build. |
+| `reference/10-corpus-winners.md` | When citing past winners by name. |
+| `reference/11-corpus-rejects.md` | When citing past rejects by name. |
+| `reference/12-client-communication.md` | Always. The vocabulary and tone rules. |
+| `reference/13-excel-output-spec.md` | When generating the Excel deliverable. |
+| `reference/14-worked-examples.md` | When in doubt about how a rewrite should look. |
+| `examples/q2-description-rewrites.md` | When writing or rewriting Q2 Description. Paste-ready text by category. |
+| `examples/q6-integration-rewrites.md` | When writing or rewriting Q6 Integration Description. |
+| `examples/q10-team-rewrites.md` | When writing or rewriting Q10 Team. |
+| `examples/tranche-structures.md` | When structuring Tranche 1/2/3 deliverables. |
+| `examples/chat-summary-templates.md` | When composing the chat summary that accompanies the Excel deliverable. |
+| `examples/corpus-comparable-rows.md` | When picking 10 to 15 comparables for Sheet 3. |
+
+## Standard deliverable
+
+For every review, generate an Excel file with this structure (full spec in `reference/13-excel-output-spec.md`):
+
+1. **Sheet 1, Field-by-field review.** 3 columns: Status / Review (FR or EN as requested by client) / Rewrite-Action (always EN, paste-ready).
+2. **Sheet 2, Pre-submission checklist.** Prioritized actions (BLOCKER / CRITICAL / IMPORTANT / STRATEGIC).
+3. **Sheet 3, Corpus comparables.** 10-15 past submissions side-by-side with verdict, budget, and the one-line lesson for the current dossier.
+4. **Sheet 4, Integration List audit.** Each Stellar Integration List item with status (MENTIONED / TO ADD / OPTIONAL / NOT RELEVANT).
+
+After generating the file, present a concise chat summary: estimated probability of acceptance before and after fixes, the 3 to 5 highest-impact actions, and the link to the Excel.
+
+## Budget recommendation rule
+
+Every review must end with an explicit budget recommendation, anchored on a named past winner or target. Format: *"Recommended budget: $X. This matches [Past Winner Name] (SCF #Y, $ZK awarded) which had a comparable profile of [team size] + [contract scope] + [distribution]. We recommend staying sub-max ($150K) to avoid the heightened scrutiny that SCF panels apply to maximum-ask submissions."*
+
+The data table in `reference/06-budget-benchmarks.md` lets you 

package/templates/skills/stellar-scf-grants-advisor/examples/README.md

@@ -0,0 +1,43 @@
+# Examples library
+
+Concrete paste-ready rewrites and templates by category. Each file contains 3-5 fully-developed examples that you can adapt to a specific client dossier in 15-30 minutes.
+
+Use this folder when:
+
+- You are writing a rewrite for a specific field type and want to see how the best version reads.
+- You need a fast budget anchor for a category you have not advised before.
+- You want a template for the chat summary after delivery.
+- You need to calibrate a Tranche structure with verifiable evidence.
+
+Complement to `reference/14-worked-examples.md`. The reference doc explains the WHY of a rewrite. The examples folder gives you the WHAT to paste, by category.
+
+## Index
+
+| File | What it contains |
+|---|---|
+| `q2-description-rewrites.md` | Q2 Description (1000 chars) rewrites for 5 categories |
+| `q6-integration-rewrites.md` | Q6 Integration Description rewrites for 5 categories |
+| `q10-team-rewrites.md` | Q10 Team rewrites showing how to surface credentials |
+| `tranche-structures.md` | Tranche 1/2/3 deliverables with verifiable evidence by category |
+| `chat-summary-templates.md` | Chat summary templates by delivery scenario |
+| `corpus-comparable-rows.md` | Ready-to-use comparable rows for Sheet 3 |
+
+## How to use
+
+1. Open the file that matches the field you are rewriting.
+2. Find the example category closest to your current client.
+3. Copy the template.
+4. Replace the placeholder fields with your client's specifics.
+5. Run the 5-point QA check (zero em-dashes, zero "kill signature", named past dossier cited, named budget anchor, English in column D).
+
+## Quality bar for examples in this folder
+
+Every example here meets the standard we hold for client deliverables:
+
+- Zero em-dashes (the long horizontal-line punctuation character).
+- Zero internal jargon ("kill signature", "corpus", "doxxing depth").
+- Specific, anchored claims (named past dossier, specific dollar amount, specific Soroban contract).
+- Paste-ready English (column D rewrites).
+- Length-calibrated (Q2 lands at 900-980 chars; Q6 lands at 900-980 chars; Q10 lands at 1700-1950 chars).
+
+If you find an example that does not meet this bar, fix it and PR back to the skill.

package/templates/skills/stellar-scf-grants-advisor/examples/chat-summary-templates.md

@@ -0,0 +1,158 @@
+# Chat summary templates by delivery scenario
+
+Templates for the chat message that accompanies every Excel deliverable. Always includes probability range (before and after fixes), top 3 to 5 priority fixes, budget recommendation, and the file link.
+
+## Template 1: First Abstract review (v1)
+
+Use when delivering the first review for a new client.
+
+> Dossier livré, fichier v1 sauvegardé.
+>
+> Verdict: estimated [XX] to [YY] percent probability of acceptance as currently drafted, lifting to [AA] to [BB] percent after the [N] priority fixes below.
+>
+> Top 5 fixes (in priority order):
+> 1. [Q-number] [Field]: [specific action]. Effort [time]. Impact: lifts probability by roughly [X] to [Y] points.
+> 2. [Q-number] [Field]: [specific action]. Effort [time]. Impact: [specific impact].
+> 3. [Q-number] [Field]: [specific action]. Effort [time]. Impact: [specific impact].
+> 4. [Q-number] [Field]: [specific action]. Effort [time].
+> 5. [Q-number] [Field]: [specific action]. Effort [time].
+>
+> Recommended budget: $[X],000 [Track], 3 tranches of $[X/3]. Anchored on [Named Past Winner] ($YY,000 SCF #NN, comparable profile of [team size] + [contract scope]).
+>
+> Three biggest risks if not addressed: [list the highest-impact rejection patterns triggered, in plain language, with one named past dossier per pattern].
+>
+> [Open the file](computer://path/to/file.xlsx)
+
+## Template 2: Revision (v2 after client feedback)
+
+Use when delivering a revised review after client iteration.
+
+> Dossier mis a jour, fichier v[N] sauvegardé. Probabilité revisitée a [XX] a [YY] percent maintenant, [AA] a [BB] percent apres les [N] derniers fixes.
+>
+> Changes vs v[N-1]:
+> 1. [Specific change made]: [impact on score and probability].
+> 2. [Specific change made]: [impact].
+> 3. [Specific change made]: [impact].
+>
+> Top remaining fixes:
+> 1. [Q-number] [Field]: [specific action]. Effort [time].
+> 2. [Q-number] [Field]: [specific action]. Effort [time].
+> 3. [Q-number] [Field]: [specific action]. Effort [time].
+>
+> Budget unchanged at $[X],000 [Track] anchored on [Named Past Winner].
+>
+> [Open the file](computer://path/to/file_v[N].xlsx)
+
+## Template 3: Build phase review (after Abstract approval)
+
+Use when transitioning from Abstract to Build review.
+
+> Build phase review livre, fichier v1 sauvegardé.
+>
+> Verdict: estimated [XX] to [YY] percent probability of full Build award as currently drafted, lifting to [AA] to [BB] percent after the priority fixes.
+>
+> The Build phase introduces three new blocker categories that the Abstract did not surface. Address these first:
+>
+> 1. Q5 Code URL: [current status]. Action: [specific action]. Effort [time].
+> 2. Q6 Video URL: [current status]. Action: 5-segment script under 3 minutes, founder on camera, live demo of testnet contract on Stellar Expert. Effort 6 to 8 hours after testnet contract is shipped.
+> 3. Q10 Technical Architecture: [current status]. Action: public Notion or GitHub markdown with C4 Level 1 + Level 2 + data flows. Effort 4 to 6 hours.
+>
+> Then the field-level rewrites in Sheet 1.
+>
+> Budget: $[X],000 across 3 tranches of $[X/3]. Tranche 1 [scope summary]. Tranche 2 [scope summary]. Tranche 3 mainnet + quantified targets.
+>
+> [Open the file](computer://path/to/Build_Review_v1.xlsx)
+
+## Template 4: Comeback strategy (client lost prior round)
+
+Use when advising a client who was rejected in a prior round.
+
+> Dossier comeback livré, fichier v1 sauvegardé.
+>
+> Verdict: prior dossier was rejected at $[prior budget] in SCF #[prior round]. Likely panel concerns based on the prior dossier's profile: [pattern 1 in plain language], [pattern 2], [pattern 3]. Named past comparables that died for the same patterns: [Past Reject 1 ($X,000)], [Past Reject 2 ($Y,000)].
+>
+> Proposed comeback moves (in priority order):
+> 1. [Move N from `reference/05-comeback-patterns.md`]: [specific implementation]. Effort [time]. Lifts probability by roughly [X] to [Y] points.
+> 2. [Move N]: [specific implementation]. Effort [time].
+> 3. [Move N]: [specific implementation]. Effort [time].
+>
+> Recommended new budget: $[X],000 (down from prior $[prior]). Anchored on [Named Past Winner].
+>
+> Recommended Q9 acknowledgment sentence: "We addressed the prior panel feedback by [specific change]."
+>
+> Estimated probability with comeback moves applied: [AA] to [BB] percent.
+>
+> [Open the file](computer://path/to/Comeback_Review_v1.xlsx)
+
+## Template 5: Drafting Abstract from scratch (client has nothing yet)
+
+Use when the client asks us to draft the Abstract rather than review one.
+
+> Abstract drafted, fichier v1 sauvegardé. The file contains all 12 Q-fields as paste-ready English text plus a placeholder list of items I need from you before final submission.
+>
+> Information I need from you to finalize:
+> 1. LinkedIn URLs for all named co-founders (verifiable, slug exactly matching profile).
+> 2. GitHub URL for the CTO.
+> 3. Legal entity name and RCS registry number (e.g., RCS Paris 940 123 456).
+> 4. Specific named pilot customers or LOIs (with status: signed / verbal / pipeline).
+> 5. Vault partner name / banking partner name / regulatory partner name (if regulated category).
+> 6. Discord usernames for Q12 (comma-separated).
+> 7. Thumbnail asset (1200x630 px PNG or JPG); if you have an og-image.png on the website, that often works.
+>
+> Estimated probability if you fill these in and submit as drafted: [XX] to [YY] percent.
+>
+> Recommended budget: $[X],000 [Track], 3 tranches of $[X/3]. Anchored on [Named Past Winner].
+>
+> [Open the draft](computer://path/to/Abstract_Draft_v1.xlsx)
+
+## Template 6: Quick triage (client asks "is my dossier ready?")
+
+Use when the client wants a fast yes/no plus top concerns, not a full review.
+
+> Quick triage on the current draft:
+>
+> Verdict: [READY TO SUBMIT / FIX TOP 3 BLOCKERS FIRST / DO NOT SUBMIT YET].
+>
+> Top 3 issues that would worry me as a reviewer:
+> 1. [Specific issue]: [reason]. Named past dossiers rejected for similar reason: [Name 1, Name 2].
+> 2. [Specific issue]: [reason].
+> 3. [Specific issue]: [reason].
+>
+> If you address these before [deadline], I would put your probability at [XX] to [YY] percent. As currently drafted, [AA] to [BB] percent.
+>
+> Want me to produce a full field-by-field review? Reply yes and I will deliver in [N] hours.
+
+## Template 7: Post-submission update (after client has submitted)
+
+Use after the client tells you they have submitted.
+
+> Submission noted. Tracking status on SCF #[round]:
+>
+> - Expected pre-screen window: [date range]. If your dossier moves to Information Collection, contact me immediately so we can fix the missing item within 48 hours.
+> - Expected panel decision: [date range].
+> - Expected award notification: [date range].
+>
+> What I will do during this period:
+> - Monitor Information Collection status.
+> - Watch for SCF policy updates that affect your dossier.
+> - Prepare Tranche 1 deliverables checklist for post-award.
+>
+> What you should do:
+> - Continue product development on the Tranche 1 scope (testnet contract, video walkthrough, architecture doc).
+> - Reply quickly to any SCF team email.
+> - Hold off any major scope changes until the panel decides.
+>
+> If approved, we engage on Tranche 1 review prep. If rejected, we trigger the comeback strategy.
+
+## Common chat summary mistakes
+
+- Probability stated as a point estimate rather than a range. Always range.
+- "Likely" or "probably" without anchoring on a named past dossier.
+- More than 5 fixes in the top list. Above 5, the client loses focus.
+- Missing the budget recommendation. Always include the anchor.
+- Long preamble before the verdict. Start with the verdict.
+- Em-dashes in the chat. Same rule as for the file.
+
+## Calibration
+
+Chat summary should be readable on a phone in 30 to 45 seconds. If the client has to scroll three times, it is too long. Aim for under 250 words for a v1 delivery.