stellar-agent 0.1.0 → 0.3.0

package/README.md

@@ -1,6 +1,6 @@
 # Stellar Agent
 
-An AI agent team for Stellar blockchain developers. Run one command to add a team of specialized AI agents to any project.
+An AI agent team for Stellar blockchain developers. Run one command to add a team of eight specialized AI agents to any project.
 
 ## Install
 
@@ -10,6 +10,22 @@ npx stellar-agent init
 
 This scaffolds a `_stellar/` directory in your project. From that point, invoke agents directly from your AI assistant (Claude Code, Cursor, Windsurf, etc.).
 
+### Pinning a version
+
+The CLI and the skill catalog ship as one versioned package. To pin a project to a specific version of the agent team:
+
+```bash
+npx stellar-agent@0.2.0 init     # always installs v0.2.0 skills
+```
+
+The chosen version is recorded in `_stellar/_config/manifest.yaml`. Check it any time with:
+
+```bash
+stellar-agent version
+```
+
+If the CLI you're running differs from the skills version recorded in your project, the command warns you and tells you how to re-pin.
+
 ---
 
 ## Agent Team
@@ -111,6 +127,23 @@ Local Stellar environment setup, Horizon instance management, and testnet → ma
 
 ---
 
+### 🧭 Pera — Hackathon Mentor
+> `@stellar-agent-mentor`
+
+Hackathon-arc mentor for Stellar/Soroban submissions. Scopes ideas to the timebox, picks the right track, aligns the build to judging criteria, and coaches demo and pitch. Invoked at the start of a hackathon to shape scope and at the end to ship the demo. On activation, asks for the hackathon link (Devpost / SCF / SDF URL), hours remaining, and target track — all skippable.
+
+| Command | What it does |
+|---|---|
+| `IS` | Idea scoping — one-pager and cut list against the build window |
+| `TR` | Track recommendation — DeFi / Payments / Identity / Gaming / RWA fit |
+| `MV` | MVP definition — must-have / nice-to-have / skip split |
+| `JC` | Judging criteria — map the build to the rubric |
+| `DM` | Demo prep — storyboard, 2–3 min script, recording checklist |
+| `PC` | Pitch coaching — deck outline and judge Q&A prep |
+| `SP` | Submission prep — repo, README, demo video, contract IDs checklist |
+
+---
+
 ## Core Commands
 
 These work from any project with `_stellar/` initialized:
@@ -120,6 +153,7 @@ These work from any project with `_stellar/` initialized:
 | `stellar-help` | Browse the full skill catalog with next-step recommendations |
 | `stellar-brainstorming` | Facilitated brainstorming for project ideas, architecture, and tokenomics |
 | `stellar-party-mode` | Multi-agent roundtable — all agents in one discussion |
+| `stellar-lean` | Switch the active agent into terse, result-only output mode |
 
 ---
 
@@ -136,6 +170,18 @@ These work from any project with `_stellar/` initialized:
 8. @stellar-agent-frontend   → NS  Next.js setup → WL  wallet → SC  Soroban
 ```
 
+## Hackathon Workflow
+
+When you're building against a submission deadline, swap in Pera at the bookends:
+
+```
+1. @stellar-agent-mentor     → IS  idea scoping → TR  track → MV  MVP cut
+2. @stellar-agent-architect  → AD  architecture (lean — only what demo needs)
+3. @stellar-agent-developer  → IC → WC → DC
+4. @stellar-agent-frontend   → NS → WL → SC
+5. @stellar-agent-mentor     → JC  judging → DM  demo → PC  pitch → SP  submit
+```
+
 ---
 
 ## Local Development
@@ -150,12 +196,33 @@ npm run validate:skills
 # Test CLI
 node tools/installer/stellar-cli.js --help
 
+# Run the MCP server locally
+npm run mcp
+
 # Link globally for testing in other projects
 npm link
 # then in another project:
 stellar-agent init
 ```
 
+## Releasing
+
+CI/CD is wired up via GitHub Actions:
+
+- **[`.github/workflows/validate.yml`](.github/workflows/validate.yml)** — runs on every push and PR to `main`: validates all skills, runs the test suite on Node 20.x and 22.x, builds the docs site, and smoke-tests the MCP server.
+- **[`.github/workflows/publish.yml`](.github/workflows/publish.yml)** — runs on tags matching `v*`: re-validates, verifies the tag matches `package.json` version, publishes to npm with provenance, and creates a GitHub release.
+
+**One-time setup**: add an `NPM_TOKEN` secret to the repo (Settings → Secrets and variables → Actions). Use a granular access token scoped to publish only the `stellar-agent` package.
+
+**Releasing a new version**:
+
+```bash
+npm version minor       # 0.2.0 → 0.3.0 (creates commit + git tag v0.3.0)
+git push --follow-tags  # triggers publish.yml
+```
+
+`prepublishOnly` runs `validate:skills && test` automatically on any `npm publish` — local or CI.
+
 ## Requirements
 
 - Node.js >= 20.12.0

package/package.json

@@ -1,8 +1,14 @@
 {
   "name": "stellar-agent",
-  "version": "0.1.0",
+  "version": "0.3.0",
   "description": "AI agent team for Stellar blockchain developers",
-  "keywords": ["stellar", "soroban", "blockchain", "ai", "agents"],
+  "keywords": [
+    "stellar",
+    "soroban",
+    "blockchain",
+    "ai",
+    "agents"
+  ],
   "license": "MIT",
   "main": "tools/installer/stellar-cli.js",
   "bin": {
@@ -10,13 +16,16 @@
   },
   "files": [
     "tools/installer/",
+    "tools/mcp-server/",
     "src/",
     "package.json",
     "README.md"
   ],
   "scripts": {
     "validate:skills": "node tools/validate-skills.js --strict",
-    "test": "node test/test-installation.js"
+    "test": "node test/test-installation.js",
+    "prepublishOnly": "npm run validate:skills && npm test",
+    "mcp": "node tools/mcp-server/server.js"
   },
   "dependencies": {
     "@clack/core": "1.3.1",

package/src/core-skills/module-help.csv

@@ -3,3 +3,5 @@ Core,_meta,,,,,,,,,false,https://github.com/tolgazorlu/stellar-agent#readme,
 Core,stellar-brainstorming,Brainstorming,BSP,Facilitate interactive brainstorming for Stellar project ideas architecture and tokenomics design.,,,anytime,,,false,{output_folder}/brainstorming,brainstorming session
 Core,stellar-party-mode,Party Mode,PM,Orchestrate multi-agent roundtable discussions with the full Stellar Agent team.,,,anytime,,,false,,
 Core,stellar-help,Stellar Help,SH,Navigate the Stellar Agent skill catalog and get next-step recommendations.,,,anytime,,,false,,
+Core,stellar-lean,Lean Mode,LN,Switch the active agent into terse result-only output — no preamble no summary no fluff.,,,anytime,,,false,,
+Core,stellar-project-context,Project Context,PX,Interview the user once and produce project-context.md that every agent loads as persistent facts.,,,anytime,,,false,{project-root},project-context.md

package/src/core-skills/stellar-help/SKILL.md

@@ -38,6 +38,7 @@ module,skill,display-name,menu-code,description,action,args,phase,preceded-by,fo
 **Phases** determine the high-level flow:
 - `anytime` — available regardless of workflow state
 - `1-analysis` → `2-planning` → `3-architecture` → `4-implementation`
+- `5-mentorship` — hackathon-arc guidance (idea scoping → submission), wraps the build phases
 
 **Required gates**: `required=true` items must complete before the user can meaningfully proceed.
 
@@ -50,10 +51,14 @@ Always tell the user which agent to invoke for a skill:
 - Phase 2 skills → `@stellar-pm` (Kai)
 - Phase 3 skills → `@stellar-architect` (Nova)
 - Phase 4 contract skills → `@stellar-developer` (Sol)
+- Phase 4 frontend skills → `@stellar-frontend` (Lyra)
 - Phase 4 test skills → `@stellar-qa` (Vera)
 - Phase 4 devops/env skills → `@stellar-devops` (Orion)
+- Phase 5 mentorship skills → `@stellar-mentor` (Pera)
 - Brainstorming/party → any agent or direct invocation
 
+If the user mentions a hackathon, deadline, demo, pitch, or submission, recommend Pera first regardless of phase.
+
 ## Response Format
 
 For each recommended item, present:

package/src/core-skills/stellar-lean/SKILL.md

@@ -0,0 +1,70 @@
+---
+name: stellar-lean
+description: 'Switch the active agent into terse, result-only output mode. Suppresses preamble, summary, hedging, and conversational fluff — only the artifact. Use when the user types stellar-lean, /lean, --lean, "be terse", "less talk", "just the code", "result only", or asks for Karpathy-style minimal output.'
+---
+
+# Lean Mode
+
+Output the artifact. Skip everything else.
+
+## On Activation
+
+Acknowledge with one line: `Lean mode on.`
+
+Then, for the rest of the session, follow the rules below.
+
+## Output rules
+
+| Ask | Output |
+|---|---|
+| "Write X" | The code. No preamble. |
+| "Fix the bug" | The diff. No "I found that…". |
+| "Explain X" | ≤ 3 sentences. No headers. |
+| Yes/no | "Yes" or "No" + one clause. |
+| Command-style ask | The command. Copy-pasteable. One line. |
+| "Compare A vs B" | One table. No prose intro. |
+
+## Forbidden phrases
+
+- `Let me…` · `I'll start by…` · `Now let me…` · `First I'll…`
+- `Here's what I did:` · `I've completed…` · `To summarize…`
+- `Let me know if…` · `Hope this helps!` · `Happy to…`
+- `Great question!` · `Of course!` · `Certainly!`
+- Bullet-point recap of code you just wrote
+- Emojis (unless the user used them first)
+- Headers for ≤ 1-paragraph answers
+
+## Forbidden patterns
+
+- **Narrating tool calls.** Don't say "Now I'll read the file." Just read it.
+- **Trailing summaries.** Don't end with "Done. The function now does X." The diff is the summary.
+- **Hedge clauses.** No "It might be worth considering…" → say "Do X." or don't say it.
+- **Pre-emptive caveats.** Add caveats only when they change the answer.
+
+## Code output
+
+```
+<the code>
+```
+
+That's it. No paragraph above. No paragraph below.
+
+If the user wants explanation, they'll ask.
+
+## File edits
+
+Show the diff. Don't restate what changed in prose.
+
+## When the user is wrong
+
+Say so in one sentence. Then give the right answer. Don't apologize for correcting.
+
+## Exit
+
+Stay lean until the user says `stellar-verbose`, `verbose mode`, `explain more`, or `back to normal`. Then drop the constraints.
+
+## Why
+
+LLM output bloats by default. Every "Let me…", every recap, every "Happy to help!" costs tokens the user paid for and attention they can't reclaim. Lean mode trades politeness for signal. Use it when the user is in flow and wants the next artifact, not a conversation.
+
+Modeled on Karpathy's framing: skills should be opinionated execution, not narrated process.

package/src/core-skills/stellar-party-mode/SKILL.md

@@ -46,7 +46,8 @@ Choose 2-4 agents whose expertise is most relevant. Guidelines:
 - **Smart contract question** → Sol (developer) + Nova (architect) always, add Vera (QA) if testing is in scope
 - **Product/user question** → Kai (PM) + Aria (analyst), add Nova for technical feasibility
 - **Deployment/ops question** → Orion (devops) + Sol (developer)
-- **Strategic question** → All six for a full roundtable
+- **Hackathon / demo / pitch / submission question** → Pera (mentor) + Kai (PM), add Sol or Nova if technical scope matters
+- **Strategic question** → All seven for a full roundtable
 - **User names specific agents** → Include those plus 1-2 complementary voices
 
 ### 2. Build Context and Spawn

package/src/core-skills/stellar-project-context/SKILL.md

@@ -0,0 +1,152 @@
+---
+name: stellar-project-context
+description: 'Interview the user once and produce a project-context.md that every Stellar Agent loads as persistent_facts. Captures product intent, users, on-chain primitives, deployment targets, and constraints. Use when the user starts a new project, asks "what is project-context.md", any agent detects project-context.md is missing, or the user wants to refresh project context.'
+---
+
+# Project Context Generator
+
+## Purpose
+
+Every Stellar Agent loads `**/project-context.md` as a persistent fact on activation. When that file doesn't exist, agents respond with generic priors instead of project-specific knowledge. This skill produces the file once — durable across sessions, readable by all agents.
+
+## On Activation
+
+Resolve config from `{project-root}/_stellar/stellar/config.yaml` and `{project-root}/_stellar/core/config.yaml`. Capture: `{user_name}`, `{project_name}`, `{network_preference}`, `{primary_language}`.
+
+Check if `{project-root}/project-context.md` already exists.
+
+- If yes → ask: *"Project context exists. Refresh it, or just review what's there?"*
+- If no → start the interview.
+
+## Workflow
+
+### Step 1: The 7-Question Interview
+
+Ask the user 7 questions. Each one has a default — they can say `skip` to accept the default. Conduct as a single block, not one at a time.
+
+```
+1. **One-sentence elevator pitch.** What does this project do?
+   (Default: pulled from {project_name} if descriptive enough.)
+
+2. **Primary user.** Who uses this? Name a persona, not "everyone".
+   (Default: "Stellar developers" if it's a dev tool, else "skip".)
+
+3. **Primary on-chain action.** What's the one transaction the user signs that delivers the core value?
+   (Default: "skip" — but flag that downstream skills work better with this filled in.)
+
+4. **Stellar primitives used.** Pick all that apply: Soroban contracts · Classic payments · Custom assets · Trustlines · Anchors (SEP-24/SEP-31) · SEP-10 auth · AMM pools · Path payments.
+   (Default: infer from {primary_language} — Rust → Soroban; TS → Classic + Soroban via SDK.)
+
+5. **Deployment target(s).** Testnet · Mainnet · Both · Futurenet.
+   (Default: {network_preference}.)
+
+6. **Hard constraints.** Anything the build *cannot* do (regulatory, technical, time, team size)?
+   (Default: "skip" — but useful for agents to know.)
+
+7. **Success in 30 days.** What's the one metric or milestone you'd celebrate?
+   (Default: "skip" — but useful for prioritization.)
+```
+
+Record raw answers. Don't paraphrase yet.
+
+### Step 2: Write the File
+
+Render the answers to `{project-root}/project-context.md`:
+
+```markdown
+# Project Context — {project_name}
+
+> This file is read by every Stellar Agent on activation. Keep it ≤ 200 lines.
+> Last updated: <YYYY-MM-DD>
+
+## Elevator pitch
+
+<one sentence from Q1>
+
+## Primary user
+
+<from Q2>
+
+## Primary on-chain action
+
+<from Q3>
+
+## Stellar stack
+
+- **Primitives:** <comma-separated list from Q4>
+- **Network:** <from Q5>
+- **Primary language:** {primary_language}
+
+## Constraints
+
+<from Q6 — bullets if multiple>
+
+## Success criteria (30-day horizon)
+
+<from Q7>
+
+## Project state
+
+- Phase: <inferred — analysis | planning | architecture | implementation | mentorship>
+- Started: <YYYY-MM-DD>
+- Lead: {user_name}
+
+## Glossary
+
+<Optional. Domain-specific terms that recur in the codebase. Add as the project grows.>
+```
+
+### Step 3: Suggest Where It Goes
+
+By default, save at `{project-root}/project-context.md`. This is the path that matches the glob `**/project-context.md` every agent loads.
+
+If the user has multiple sub-projects in a monorepo, save under each: `{sub-project}/project-context.md`. The glob picks up all of them; agents load whichever is nearest.
+
+### Step 4: Confirm and Wire
+
+Show the rendered file to the user. Ask: *"Save this?"*
+
+If yes:
+- Write the file
+- Confirm path
+- Suggest the user `git add` and commit it (this is durable project state, should be in version control)
+
+### Step 5: Refresh Trigger
+
+`project-context.md` decays. When any of these happens, agents should suggest re-running this skill:
+
+- The hackathon brief locks in a different track or scope
+- The primary on-chain action changes
+- A contract gets deployed to mainnet (state change)
+- A new team member joins
+- The user explicitly says "we pivoted"
+
+Re-running this skill regenerates the file with a new `Last updated` date. Old content can be preserved in a `## History` section if the user wants.
+
+## Anti-patterns to flag
+
+- **Long, prose-heavy context files.** Keep it ≤ 200 lines. Agents read this every time — verbose = expensive.
+- **Capturing implementation details.** That's what `{implementation_artifacts}` is for. This file is intent, not implementation.
+- **Skipping Q3 (primary on-chain action).** This is the single most useful field for Sol, Nova, and Pera. Push back on `skip` here.
+- **Filling in defaults blindly.** If the user says `skip` to all 7, write a file with `[unknown]` placeholders and tell them to refresh later.
+
+## Why this matters
+
+Every agent's `persistent_facts` includes:
+```toml
+persistent_facts = [
+  "file:{project-root}/**/project-context.md",
+]
+```
+
+Without this file, agents fall back to generic Stellar priors — they don't know your network, your users, your scope. A 100-line context file shifts every subsequent agent response from generic to project-specific. Cheap to write once, compounds across every interaction.
+
+## Output
+
+`{project-root}/project-context.md` — single file, version-controlled, loaded by every agent.
+
+## Next Steps
+
+- `@stellar-agent-pm` (Kai) — turn the elevator pitch into a project brief (PB)
+- `@stellar-agent-architect` (Nova) — architecture from the primary on-chain action
+- `@stellar-agent-mentor` (Pera) — if there's a deadline, hackathon arc starts here

package/src/stellar-skills/1-analysis/stellar-agent-analyst/customize.toml

@@ -39,3 +39,8 @@ skill = "stellar-analytics"
 code = "DR"
 description = "Research Stellar domain — protocol specifics, regulatory landscape, use cases"
 skill = "stellar-domain-research"
+
+[[agent.menu]]
+code = "KA"
+description = "Known Assets Registry — canonical issuer addresses for USDC, EURC, AQUA, yXLM with verification commands"
+skill = "stellar-known-assets"

package/src/stellar-skills/1-analysis/stellar-known-assets/SKILL.md

@@ -0,0 +1,125 @@
+---
+name: stellar-known-assets
+description: 'Look up canonical Stellar asset issuer addresses (USDC, EURC, AQUA, yXLM, etc.) with provenance and verification commands. Prevents LLM hallucination of issuer addresses. Use when the user references a Stellar asset by code (USDC, EURC, AQUA), needs to create a trustline, builds a path payment, or any task that requires a verified issuer address.'
+---
+
+# Known Assets Registry
+
+## Purpose
+
+Stop the LLM from inventing Stellar asset issuer addresses. Every well-known Stellar asset (USDC, EURC, AQUA, yXLM, etc.) has a specific 56-character issuer address — using the wrong one silently breaks trustlines and burns user funds.
+
+## Hard rule
+
+**Never write a Stellar issuer address from memory.** Always either:
+1. Look it up in the registry below.
+2. Verify with one of the verification commands.
+3. Refuse to fill it in and ask the user to provide it.
+
+If a value is not in this file and not provided by the user, output a placeholder like `<USDC_ISSUER>` and tell the user to fill it in — do not guess.
+
+## Mainnet (public network)
+
+> Last verified: 2025-06-01. Always verify against [stellar.expert/explorer/public/assets](https://stellar.expert/explorer/public/assets) before mainnet deployment.
+
+| Code | Issuer | Custodian | Notes |
+|---|---|---|---|
+| `USDC` | `GA5ZSEJYB37JRC5AVCIA5MOP4RHTM335X2KGX3IHOJAPP5RE34K4KZVN` | Circle | Native USDC on Stellar. Source: [circle.com/multi-chain-usdc/stellar](https://www.circle.com/multi-chain-usdc/stellar) |
+| `EURC` | `GDHU6WRG4IEQXM5NZ4BMPKOXHW76MZM4Y2IEMFDVXBSDP6SJY4ITNPP2` | Circle | Native EURC. Source: [circle.com/multi-chain-eurc/stellar](https://www.circle.com/multi-chain-eurc/stellar) |
+| `AQUA` | `GBNZILSTVQZ4R7IKQDGHYGY2QXL5QOFJYQMXPKWRRM5PAV7Y4M67AQUA` | Aquarius | Governance token for Aquarius DEX. **Verify before use.** |
+| `yXLM` | `GARDNV3Q7YGT4AKSDF25LT32YSCCW4EV22Y2TV3I2PU2MMXJTEDL5T55` | Ultra Stellar | Yield-bearing XLM. **Verify before use.** |
+| `XLM` | *(native)* | Stellar protocol | Native asset — no issuer. Use `Asset.native()` in the SDK. |
+
+**For any asset not listed above**: tell the user "I don't have a verified issuer for `<CODE>`. Look it up at https://stellar.expert/explorer/public/assets and paste the issuer."
+
+## Testnet
+
+> Testnet issuers are different from mainnet. Never copy a mainnet issuer to testnet.
+
+| Code | Issuer | Notes |
+|---|---|---|
+| `USDC` | `GBBD47IF6LWK7P7MDEVSCWR7DPUWV3NY3DTQEVFL4NAT4AQH37Y2QJU2` | Circle testnet USDC. Source: [circle.com/multi-chain-usdc/stellar](https://www.circle.com/multi-chain-usdc/stellar) (toggle to testnet) |
+| `XLM` | *(native)* | Same on every network. Use `Asset.native()`. |
+
+For testnet custom assets, the user typically creates their own issuer with `stellar keys generate`. Look in `{implementation_artifacts}/asset-config.md` for project-specific issuers.
+
+## Futurenet
+
+Futurenet is reset periodically — there are no stable canonical issuers. Always create a fresh issuer or ask the user.
+
+## Verification commands
+
+Before using any address from this file in a transaction that moves real funds, run one of these:
+
+### Verify against stellar.expert
+
+```bash
+# Replace ISSUER with the address from the table
+curl -s "https://api.stellar.expert/explorer/public/asset/USDC-ISSUER" | jq '.code, .issuer, .domain'
+
+# Expected output for USDC mainnet:
+# "USDC"
+# "GA5ZSEJYB37JRC5AVCIA5MOP4RHTM335X2KGX3IHOJAPP5RE34K4KZVN"
+# "centre.io"
+```
+
+### Verify via SEP-1 (`stellar.toml`)
+
+For any asset, the issuer's `stellar.toml` is the canonical source. Find the domain via `home_domain` on the issuer account:
+
+```bash
+stellar account inspect <ISSUER_ADDRESS> --network public | grep home_domain
+
+# Then fetch the toml:
+curl -s "https://${HOME_DOMAIN}/.well-known/stellar.toml" | grep -A 3 "CURRENCIES"
+```
+
+### Verify via Horizon
+
+```bash
+# Check the issuer account exists and is configured as an issuer
+curl -s "https://horizon.stellar.org/accounts/<ISSUER>" | jq '.flags, .home_domain'
+
+# auth_required = true means it's an issuer that gates trustlines
+# home_domain links to the stellar.toml
+```
+
+## When to refuse to answer
+
+If the user asks you to write code that includes a custom-asset issuer and:
+
+1. The asset is **not in this file**, AND
+2. The user has **not provided** the issuer in conversation or in `{implementation_artifacts}/asset-config.md`
+
+→ Refuse to fill in the issuer. Output a placeholder and request the address explicitly:
+
+```
+const USDC = new Asset(
+  'USDC',
+  '<FILL_IN_USDC_ISSUER>' // Verify at https://stellar.expert/explorer/public/assets
+);
+```
+
+Tell the user: *"I don't have a verified issuer for `<CODE>` on this network. Paste the issuer address from stellar.expert and I'll wire it in."*
+
+## How to extend this file
+
+When a maintainer wants to add a new asset:
+
+1. Verify the issuer via `stellar.expert` AND `stellar.toml` AND Horizon.
+2. Add a row to the table with the **source link** (not just the address).
+3. Bump the "Last verified" date at the top of the section.
+4. If the asset is well-known (top 20 by holders), no further review needed. If niche, also note who uses it.
+
+## Output
+
+This skill is reference-only — no artifacts written. It exists to be loaded into context when other skills need an issuer address.
+
+## Used by
+
+- `stellar-create-transaction` (Sol `TX`) — path payments, asset transfers
+- `stellar-create-asset` (Sol `CA`) — when comparing to existing issuers
+- `stellar-setup-trustline` (Sol `TL`) — never create a trustline to an unverified issuer
+- `stellar-liquidity-pool` (Sol `LP`) — both pool tokens must be verified
+- `stellar-market-research` (Aria `MR`) — market caps by asset
+- `stellar-tokenomics-analysis` (Aria `TA`) — comparable asset designs

package/src/stellar-skills/4-implementation/stellar-agent-devops/customize.toml

@@ -20,6 +20,11 @@ principles = [
   "stellar doctor before asking the community.",
 ]
 
+[[agent.menu]]
+code = "SD"
+description = "Stellar Doctor — diagnose toolchain, network, wallet, contract state, and project context"
+skill = "stellar-doctor"
+
 [[agent.menu]]
 code = "SE"
 description = "Set up local Stellar development environment with Docker quickstart bundle"