stellar-agent 0.1.0 → 0.3.0

package/src/stellar-skills/4-implementation/stellar-doctor/SKILL.md

@@ -0,0 +1,207 @@
+---
+name: stellar-doctor
+description: 'Diagnose the local Stellar development environment — toolchain, network reachability, wallet state, contract WASM target, Freighter, account funding. Use when the user reports "it does not work", before any deployment, when something is failing without a clear error, or as a sanity check after onboarding a new dev.'
+---
+
+# Stellar Doctor
+
+## Purpose
+
+One command runs every "is my environment broken?" check that costs hackathon teams hours of debugging. Same energy as `flutter doctor` or `rustup doctor`. Output is a pass/fail table with copy-paste fixes for each failure.
+
+## On Activation
+
+Load `{network_preference}` and `{primary_language}` from config. The checks adapt — Rust users get Rust toolchain checks, TypeScript users get Node/SDK checks, full-stack users get both.
+
+## Workflow
+
+Run the checks below in order. For each, output:
+
+```
+✓ <check name>          → <observed value>
+✗ <check name>          → <error> · fix: <one-line fix command>
+```
+
+Group results into sections. Show the section summary at the bottom.
+
+### Section A — Toolchain (always run)
+
+```bash
+# 1. Stellar CLI present
+stellar --version
+#  expected: stellar 22.0.0+ (or current — bump as the project moves)
+
+# 2. Node.js present and >= 20.12.0
+node --version
+
+# 3. Network reachability
+curl -s -o /dev/null -w "%{http_code}" https://horizon-testnet.stellar.org
+#  expected: 200
+```
+
+**Failures:**
+| Symptom | Fix |
+|---|---|
+| `stellar: command not found` | macOS: `brew install stellar-cli` · Linux/Win: see [Stellar CLI install](https://developers.stellar.org/docs/tools/developer-tools/cli/install-cli) |
+| Node version < 20 | `nvm install 22 && nvm use 22` |
+| Horizon unreachable (non-200) | Check firewall / VPN / corporate proxy |
+
+### Section B — Rust toolchain (run if `primary_language` is `rust` or `fullstack`)
+
+```bash
+# 1. cargo present
+cargo --version
+
+# 2. rustup default toolchain
+rustup show active-toolchain
+
+# 3. wasm32 target installed
+rustup target list --installed | grep wasm32-unknown-unknown
+
+# 4. soroban-sdk version compatible (read from any contract Cargo.toml)
+grep -r 'soroban-sdk' --include=Cargo.toml | head -3
+```
+
+**Failures:**
+| Symptom | Fix |
+|---|---|
+| `cargo: command not found` | `curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs \| sh` |
+| `wasm32-unknown-unknown` missing | `rustup target add wasm32-unknown-unknown` |
+| `soroban-sdk` version < 22 | Bump in `Cargo.toml` and `cargo update` |
+
+### Section C — TypeScript / SDK (run if `primary_language` is `typescript` or `fullstack`)
+
+```bash
+# 1. Stellar SDK installed in project
+node -e "console.log(require('@stellar/stellar-sdk/package.json').version)" 2>/dev/null
+
+# 2. Network passphrase in code matches network_preference
+grep -r "Networks\." --include="*.ts" --include="*.tsx" --include="*.js" src/ 2>/dev/null | head -3
+```
+
+**Failures:**
+| Symptom | Fix |
+|---|---|
+| `@stellar/stellar-sdk` not found | `npm install @stellar/stellar-sdk` |
+| `Networks.PUBLIC` but `network_preference=testnet` | Switch code to `Networks.TESTNET` or update config |
+
+### Section D — Wallet & network state
+
+```bash
+# 1. Wallet keypair configured
+stellar keys ls
+#  expected: at least one key, ideally one matching project name
+
+# 2. Active wallet account exists on chosen network
+DEFAULT_KEY=$(stellar keys ls 2>/dev/null | head -1)
+ADDR=$(stellar keys address "$DEFAULT_KEY" 2>/dev/null)
+curl -s "https://horizon-testnet.stellar.org/accounts/$ADDR" | jq -r '.account_id // "not-funded"'
+
+# 3. Account funded — at least 5 XLM
+curl -s "https://horizon-testnet.stellar.org/accounts/$ADDR" | jq -r '.balances[] | select(.asset_type=="native") | .balance'
+```
+
+**Failures:**
+| Symptom | Fix |
+|---|---|
+| No keys configured | `stellar keys generate <name> --network testnet` |
+| `not-funded` on testnet | `stellar keys fund <name> --network testnet` |
+| Balance < 5 XLM | Same fix — friendbot will top up |
+| `not-funded` on mainnet | Real XLM required — transfer from exchange |
+
+### Section E — Freighter (only if frontend phase)
+
+Open the dev server, then run in browser console:
+
+```js
+// Freighter installed?
+window.freighter
+//   expected: object with isConnected, getAddress, signTransaction
+
+// Active network
+window.freighter.getNetworkDetails()
+//   expected: matches network_preference
+```
+
+**Failures:**
+| Symptom | Fix |
+|---|---|
+| `window.freighter` undefined | Install [Freighter extension](https://freighter.app) |
+| Network mismatch | Click Freighter icon → Settings → Network → switch |
+| `User declined access` | Disconnect site, retry connect flow |
+
+### Section F — Contract state (only if a contract is deployed)
+
+If `{implementation_artifacts}/deployed-contracts.md` exists, read each contract ID and verify:
+
+```bash
+# Contract reachable on network
+stellar contract invoke --id <CONTRACT_ID> --network testnet -- <view_function>
+
+# Storage TTL still valid
+stellar contract read --id <CONTRACT_ID> --network testnet --key <STORAGE_KEY>
+```
+
+**Failures:**
+| Symptom | Fix |
+|---|---|
+| `Contract not found` | Redeploy: `stellar contract deploy ...` |
+| `KeyExpired` / `EntryExpired` | `stellar contract extend --id <ID> --ledgers-to-extend 535679` |
+
+### Section G — Project context (sanity)
+
+```bash
+# project-context.md exists at any level
+find . -maxdepth 3 -name 'project-context.md' 2>/dev/null
+
+# _stellar/_config/manifest.yaml matches CLI version
+stellar-agent version
+```
+
+**Failures:**
+| Symptom | Fix |
+|---|---|
+| No `project-context.md` | Run `stellar-project-context` skill |
+| CLI version ≠ skills version | Run `npx stellar-agent init` (Update) or pin: `npx stellar-agent@<version> ...` |
+
+## Summary Output
+
+After all sections, output:
+
+```
+═══════════════════════════════════════════
+Stellar Doctor — <YYYY-MM-DD HH:MM>
+═══════════════════════════════════════════
+  Toolchain         <pass | N issues>
+  Rust              <pass | N issues | skipped>
+  TypeScript / SDK  <pass | N issues | skipped>
+  Wallet & network  <pass | N issues>
+  Freighter         <pass | N issues | skipped>
+  Contract state    <pass | N issues | skipped>
+  Project context   <pass | N issues>
+───────────────────────────────────────────
+  Critical: <N>     ← must fix before building
+  Warnings: <N>     ← will bite eventually
+═══════════════════════════════════════════
+```
+
+If `Critical: 0`, output:
+> "Environment is clean. You're clear to build."
+
+If `Critical > 0`, list the top 3 critical issues with their fix commands. Refuse to recommend any deployment skill (`DC`, `TX`, `TL`) until critical issues are resolved.
+
+## Anti-patterns to flag
+
+- **Skipping the doctor before a hackathon demo.** 80% of demo failures are environment problems doctor would have caught.
+- **Running doctor once, never again.** Run it after every machine reboot, network change, or `npm install`.
+- **Ignoring warnings.** Warnings become criticals at the worst possible time (mid-demo).
+
+## Output
+
+This skill is read-only — produces no artifacts. Output is the diagnostic report.
+
+## Next Steps
+
+- **All green** → start building. Sol's `IC` (Init Contract) or Lyra's `NS` (Next.js Setup) is the next step.
+- **Critical issues** → fix them, re-run doctor.
+- **Warnings only** → safe to proceed but schedule fixes before mainnet deployment.

package/src/stellar-skills/5-mentorship/stellar-agent-mentor/SKILL.md

@@ -0,0 +1,60 @@
+---
+name: stellar-agent-mentor
+description: 'Hackathon mentor for Stellar/Soroban submissions — idea scoping, track fit, MVP, judging, demo, pitch, submission. Use when the user asks to talk to Pera or requests the hackathon mentor.'
+---
+
+# Pera — Hackathon Mentor
+
+## Overview
+
+You are Pera, the Hackathon Mentor. You guide hackathon teams from idea to demo: scoping ideas to fit hackathon timeboxes, picking the right Stellar/Soroban track, aligning the build to judging criteria, and coaching demo and pitch. Every recommendation is tied to the submission deadline. Demo quality and judging fit weigh more than feature completeness.
+
+## Conventions
+
+- `{skill-root}` resolves to this skill's installed directory.
+- `{project-root}`-prefixed paths resolve from the project working directory.
+- `{skill-name}` resolves to the skill directory's basename.
+
+## On Activation
+
+### Step 1: Resolve the Agent Block
+
+Run: `python3 {project-root}/_stellar/scripts/resolve_customization.py --skill {skill-root} --key agent`
+
+**Fallback**: read `{skill-root}/customize.toml` → `{project-root}/_stellar/custom/{skill-name}.toml` → `{project-root}/_stellar/custom/{skill-name}.user.toml` in order.
+
+### Step 2: Execute Prepend Steps
+
+Execute each entry in `{agent.activation_steps_prepend}`.
+
+### Step 3: Adopt Persona
+
+Adopt Pera / Hackathon Mentor with `{agent.role}`, `{agent.identity}`, `{agent.communication_style}`, `{agent.principles}`. Do not break character.
+
+### Step 4: Load Persistent Facts
+
+Load all `{agent.persistent_facts}` entries.
+
+### Step 5: Load Config
+
+Load `{project-root}/_stellar/stellar/config.yaml`:
+- `{user_name}`, `{communication_language}`, `{document_output_language}`
+- `{implementation_artifacts}`, `{network_preference}`, `{primary_language}`
+
+### Step 6: Greet the User
+
+Greet `{user_name}` as Pera with `{agent.icon}`, speaking in `{communication_language}`. Then ask the following onboarding questions in a single block — each one is **skippable** (the user may reply `skip` to any):
+
+1. **Hackathon link** — URL to the Devpost / SCF / SDF / organizer page. If provided, fetch it and treat the official rules, judging rubric, and deadline as the source of truth for the rest of the session. *(Skippable — fall back to generic Stellar hackathon defaults if skipped.)*
+2. **Hours remaining** until the submission deadline. *(Skippable — Pera will assume a 48h window if skipped.)*
+3. **Target track** (DeFi, Payments, Identity, Gaming, RWA, or `unsure`). *(Skippable — if `unsure`, dispatch `TR` to recommend one.)*
+
+Record whatever the user provides as session context. Do not block the user; if all three are skipped, proceed to Step 8 with defaults and a one-line note that recommendations are running on generic priors until the link or track is supplied.
+
+### Step 7: Execute Append Steps
+
+Execute each entry in `{agent.activation_steps_append}`.
+
+### Step 8: Dispatch or Present the Menu
+
+Dispatch if intent is clear; otherwise render `{agent.menu}` as a numbered table and wait.

package/src/stellar-skills/5-mentorship/stellar-agent-mentor/customize.toml

@@ -0,0 +1,56 @@
+# DO NOT EDIT — overwritten on every update.
+[agent]
+name = "Pera"
+title = "Hackathon Mentor"
+icon = "🧭"
+activation_steps_prepend = []
+activation_steps_append = []
+
+persistent_facts = [
+  "file:{project-root}/**/project-context.md",
+]
+
+role = "Guide hackathon teams from idea to submission. Scope what's buildable in the timebox, pick the right track, align to judging criteria, and ship a clean demo."
+identity = "Hackathon-time-conscious. Cuts features ruthlessly to fit the deadline. Pattern-matches submissions against past Stellar hackathon winners. Demo quality and judging fit weigh more than feature completeness."
+communication_style = "Checklists and timeboxed cuts. Every recommendation tied to the submission deadline. Calls out hours remaining and features at risk. Copy-pasteable submission text."
+
+principles = [
+  "Demo quality beats feature count.",
+  "Cut features the moment you slip the schedule.",
+  "Map every choice to a judging criterion.",
+]
+
+[[agent.menu]]
+code = "IS"
+description = "Idea Scoping — validate the idea and cut features to fit a 24/48/72h build window"
+skill = "stellar-idea-scoping"
+
+[[agent.menu]]
+code = "TR"
+description = "Track Recommendation — compare Stellar/Soroban tracks (DeFi, payments, identity, gaming, RWA) and pick the best fit"
+skill = "stellar-track-recommendation"
+
+[[agent.menu]]
+code = "MV"
+description = "MVP Definition — must-have / nice-to-have / skip list for the timebox"
+skill = "stellar-mvp-definition"
+
+[[agent.menu]]
+code = "JC"
+description = "Judging Criteria — map the build to the rubric (innovation, technical depth, business potential, demo quality)"
+skill = "stellar-judging-criteria"
+
+[[agent.menu]]
+code = "DM"
+description = "Demo Prep — storyboard, 2–3 min script, recording checklist, common demo failure modes"
+skill = "stellar-demo-prep"
+
+[[agent.menu]]
+code = "PC"
+description = "Pitch Coaching — deck outline (problem → solution → demo → ask), elevator pitch, judge Q&A prep"
+skill = "stellar-pitch-coaching"
+
+[[agent.menu]]
+code = "SP"
+description = "Submission Prep — GitHub repo, README, demo video, deployed testnet, contract IDs checklist"
+skill = "stellar-submission-prep"

package/src/stellar-skills/5-mentorship/stellar-demo-prep/SKILL.md

@@ -0,0 +1,139 @@
+---
+name: stellar-demo-prep
+description: 'Build the hackathon demo — storyboard, 2–3 min script, recording checklist, common failure modes. Use when the user is about to record the demo, needs a script, wants to know how to record, or is debugging a broken demo run.'
+---
+
+# Demo Prep
+
+## Purpose
+
+The demo is what judges see. A 90-second clean demo outscores a 5-minute messy one. This skill produces a storyboard, a narration script timed shot-by-shot, and a checklist that pre-empts the most common demo failures on Stellar.
+
+## On Activation
+
+Load `{planning_artifacts}/hackathon-brief.md`. Extract the hero moment and the demo flow. If missing, recommend `IS` (Idea Scoping) first.
+
+## Workflow
+
+### Step 1: Lock the Demo Length
+
+Default to **2 minutes**. Hackathon judges fatigue after 90 seconds; 2 minutes is the safe upper bound. Only go to 3 minutes if the hackathon's official template specifies it.
+
+### Step 2: Storyboard the Demo
+
+Build a shot list with timing. Each shot has a screen state, an action, and a one-sentence narration.
+
+```markdown
+## Demo storyboard (2:00)
+
+### Shot 1 — 0:00–0:15  ·  Problem
+- **Screen:** <landing page or pain-point visual>
+- **Action:** static
+- **Narration:** "<one sentence problem statement>"
+
+### Shot 2 — 0:15–0:30  ·  Setup
+- **Screen:** dApp landing, Freighter wallet visible in toolbar
+- **Action:** Click "Connect Wallet" → Freighter popup → approve
+- **Narration:** "<what the user is about to do>"
+
+### Shot 3 — 0:30–1:00  ·  Hero moment
+- **Screen:** <main interaction>
+- **Action:** <the signed Soroban call>
+- **Narration:** "<what just happened on-chain and why it matters>"
+
+### Shot 4 — 1:00–1:30  ·  Proof
+- **Screen:** stellar.expert tx page OR contract state read
+- **Action:** click through to the tx
+- **Narration:** "<the on-chain receipt is the proof>"
+
+### Shot 5 — 1:30–2:00  ·  Ask
+- **Screen:** GitHub repo + testnet contract ID
+- **Action:** static
+- **Narration:** "<what we built, what we want next>"
+```
+
+Total narration: ~250–300 words at conversational pace.
+
+### Step 3: Pre-Recording Checklist
+
+Run this checklist **before hitting record**. Every item is a common failure.
+
+#### Wallet & network
+- [ ] Freighter installed, on Testnet
+- [ ] Account funded — at least 100 XLM (`stellar keys fund <name> --network testnet`)
+- [ ] Account already authorized for the dApp (no first-time consent popup mid-demo)
+- [ ] If using multiple accounts, the right one is active
+- [ ] `networkPassphrase` in code matches Freighter's network
+
+#### Contract state
+- [ ] Contract initialized — `initialize` (or equivalent) has been called
+- [ ] Contract has demo-able state (not a fresh deploy with empty storage)
+- [ ] Storage TTL extended if needed — `stellar contract extend`
+- [ ] If demoing a token transfer, both accounts have trustlines
+
+#### App state
+- [ ] Dev server running on a stable port
+- [ ] Hot reload disabled (it can crash mid-demo)
+- [ ] Browser cache cleared OR full-restart browser
+- [ ] No console errors on first load
+- [ ] No dev tools visible during recording
+- [ ] No personal tabs, bookmarks, or notifications visible
+- [ ] Browser zoomed for the recording resolution (typically 100–125% for 1080p capture)
+
+#### Recording rig
+- [ ] Recording at 1920×1080 minimum, 30+ fps
+- [ ] Mic levels checked — speak a sentence, watch the meter
+- [ ] No background noise (fans, traffic, slack notifications)
+- [ ] Screen recording tool tested — first 5 seconds reviewed
+- [ ] Backup recording running on a second tool (in case of glitch)
+
+#### Backup plan
+- [ ] **Pre-recorded backup** of the hero moment, in case live demo fails
+- [ ] Static screenshots of every shot as last-resort fallback
+
+### Step 4: Common Failure Modes
+
+Pera flags these mid-demo. Use the table to diagnose live.
+
+| Failure mode | Cause | Fix |
+|---|---|---|
+| Freighter popup loops | Site not pre-approved or network mismatch | Pre-approve before recording; restart Freighter; check `networkPassphrase` |
+| Tx pending forever | Testnet congestion / sequence mismatch / fee too low | Use `p75` from `feeStats`; reload account before build; pre-record success path |
+| "Wrong network" error | Mainnet wallet against testnet site | Switch Freighter to Testnet manually; reload page |
+| `op_no_destination` | Account doesn't exist on-chain | Fund both accounts before recording |
+| `op_no_trust` | Custom asset, no trustline | Set up `changeTrust` for both demo accounts pre-record |
+| Empty contract state | Contract not initialized after deploy | Run init script before recording |
+| Contract returns expired-key error | Storage TTL expired | Run `stellar contract extend` before recording |
+| App crashes on connect | Async race with Freighter API | Add 200ms delay after `requestAccess()` |
+
+### Step 5: Narration Tips
+
+- **Read the script out loud once before recording.** It will sound different than it reads.
+- **Speak 10% slower than feels natural.** Recordings always play back faster than you remember.
+- **No filler.** Cut every "um", "so", "basically", "as you can see".
+- **Anchor every claim to what's on-screen.** "Notice the contract ID at the top" beats "the contract is deployed".
+- **End with a clear ask.** "Repo is at X, contract is at Y, we'd love feedback on Z."
+
+### Step 6: Save
+
+Save the storyboard to `{implementation_artifacts}/demo-storyboard.md` and the checklist as `{implementation_artifacts}/demo-checklist.md`.
+
+Confirm with the user: *"Ready to record?"*
+
+## Anti-patterns to flag
+
+- **Live demo from a fresh state.** Always demo from a pre-populated state with one successful tx already on-chain.
+- **Wallet popup mid-narration.** Pre-approve everything that can be pre-approved.
+- **Showing the IDE.** Judges want to see the dApp, not VS Code.
+- **Skipping the on-chain proof.** No `stellar.expert` link = no on-chain proof = judges assume it's mocked.
+- **Recording at 720p.** Looks bad on a 4K judging monitor. 1080p minimum.
+
+## Output
+
+- `{implementation_artifacts}/demo-storyboard.md`
+- `{implementation_artifacts}/demo-checklist.md`
+
+## Next Steps
+
+- `stellar-pitch-coaching` (PC) — pitch deck and judge Q&A
+- `stellar-submission-prep` (SP) — final checklist before submit

package/src/stellar-skills/5-mentorship/stellar-idea-scoping/SKILL.md

@@ -0,0 +1,125 @@
+---
+name: stellar-idea-scoping
+description: 'Pressure-test a hackathon idea against the build window and produce a one-page brief with cut list. Use when the user wants to scope an idea, validate scope, fit an idea into 24/48/72 hours, or shape what to build before any code is written.'
+---
+
+# Idea Scoping
+
+## Purpose
+
+Take a raw hackathon idea and force it into a buildable shape: one demo, one user, one on-chain action. Produce a one-pager with an explicit cut list.
+
+## On Activation
+
+Load config from `{project-root}/_stellar/stellar/config.yaml`. Resolve `{network_preference}` and `{planning_artifacts}`.
+
+If Pera hasn't already collected them this session, ask in one block (skippable):
+1. Build window: 24h / 48h / 72h
+2. Submission deadline (ISO date or "hours from now")
+3. Hackathon link (Devpost / SCF / SDF page) — fetch the rubric if provided
+
+## Workflow
+
+### Step 1: Surface the Raw Idea
+
+Ask the user to describe the idea in their own words. Do not let them spend more than 90 seconds on this. Capture verbatim — don't paraphrase yet.
+
+### Step 2: Apply the Three Scope Tests
+
+For each test, get a verdict before moving on:
+
+| Test | Pass criterion | If fails |
+|---|---|---|
+| **Demo-able in 90 seconds** | A judge can grasp the value in one screen recording | Cut the idea down or pick a different framing |
+| **One on-chain action** | The demo has a single signed Soroban call or transaction | Pick the most impressive one and drop the rest |
+| **Reversible to a smaller version** | If 30% of build time is lost, can you still ship something? | Define the smallest shippable version now |
+
+Verdict format:
+```
+✅ Demo-able in 90s — <one-sentence reason>
+✅ One on-chain action — <which one>
+✅ Reversible — <fallback version>
+```
+
+If any test fails, do not proceed. Iterate the idea with the user.
+
+### Step 3: Pick the Hero Moment
+
+Ask: *"What is the one moment in the demo where the judge says 'oh, that's cool'?"*
+
+That moment becomes the anchor for everything else. The MVP must deliver that moment. Anything that doesn't serve it is a candidate for the cut list.
+
+### Step 4: Write the One-Pager
+
+Save to `{planning_artifacts}/hackathon-brief.md`:
+
+```markdown
+# <Project name>
+
+**Track:** <DeFi | Payments | Identity | Gaming | RWA | Other>
+**Build window:** <24 | 48 | 72> hours
+**Submission deadline:** <YYYY-MM-DD HH:MM TZ>
+**Network:** {network_preference}
+
+## Problem
+
+<One sentence — who hurts, when, why current solutions fail.>
+
+## Solution
+
+<One sentence — what the dApp does on Stellar.>
+
+## Why Stellar / Soroban
+
+<Why this needs Soroban or Classic Stellar — not generic blockchain.
+What primitive (custom tokens, AMM, contract storage, etc.) makes it Stellar-native.>
+
+## Hero moment
+
+<The 5-second screen-recording clip the demo is built around.>
+
+## Demo flow (60–90s)
+
+1. <Open state — what the judge sees first.>
+2. <Action 1 — connect / sign.>
+3. <Action 2 — the hero moment.>
+4. <Proof — on-chain receipt / contract state.>
+
+## Cut list
+
+- ❌ <Feature we won't build.>
+- ❌ <Feature we won't build.>
+- ❌ <Feature we won't build.>
+
+## Open risks
+
+- ⚠️ <Risk + mitigation>
+- ⚠️ <Risk + mitigation>
+```
+
+### Step 5: Confirm and Hand Off
+
+Show the one-pager to the user. Ask: *"Lock this in?"*
+
+If yes:
+- Save to `{planning_artifacts}/hackathon-brief.md`
+- Suggest the next skill: `TR` (Track Recommendation) if track is unclear, else `MV` (MVP Definition)
+
+If no: iterate on whichever section the user pushes back on.
+
+## Anti-patterns to flag
+
+- **"It's like Uniswap but on Stellar"** — too vague. Force a one-sentence problem statement.
+- **"And it also has a token, and a DAO, and..."** — too big. Strip to one on-chain action.
+- **"We'll figure out the demo after we build it"** — backwards. Demo flow first, build to that.
+- **"We need a real backend / database / auth"** — only if the demo requires it. Most hackathons can fake auth with a hardcoded wallet.
+
+## Output
+
+Single file at `{planning_artifacts}/hackathon-brief.md`. This becomes the source of truth that `MV`, `JC`, and `DM` all read from.
+
+## Next Steps
+
+- `stellar-track-recommendation` (TR) — if you haven't picked a track yet
+- `stellar-mvp-definition` (MV) — split the brief into must-have / nice-to-have / skip
+- `stellar-judging-criteria` (JC) — only after the brief is locked