Three people, one working hunt loop.
One LLM-ready device is enough. Split the work between Spark usage, research, retesting, and PR proof.
first event
Spark Compete: Hunting Bugs & Goblins.
Assemble a three-person party, scout Spark for real usage bugs, trap the bad behavior with before/after proof, and ship focused hotfix PRs.
scout bugs -> trap goblins -> prove the fix -> land the PR
in a nutshell
Find real Spark friction. Prove it. Ship the hotfix.
Spark Compete is a two-week team hunt for useful bugs, confusing flows, unsafe edges, and improvement areas that can become focused PRs accepted into Spark-connected repos.
hunt world
One mission: make Spark harder to break.
Scout the skies for issues worth chasing.
Find bugs in the owning repo, route ambiguous owner surfaces, and turn noisy findings into clear PR packets.
Trap goblin behavior with proof.
Capture safe before/after evidence, keep scope tight, and let outside LLMs build the smallest useful fix.
Coordinate the party without leaking secrets.
Split research, testing, and PR work so one-device teams can still move quickly and safely.
hunt loop
Scout the bug. Trap the goblin. Land the hotfix.
Teams do not need to know code first. Start by installing your own Spark Agent, use real Spark workflows until something breaks, explain the failure clearly to an outside LLM, verify the hotfix, and submit through one focused route.
Scout Spark everywhere
Copy a mission below, use your own Spark Agent, and watch for confusing replies, broken flows, missing recovery, or unsafe instructions.
Trap it with your LLM
Paste only a redacted summary into an outside LLM. Never paste secrets, raw logs, raw PR bodies, private repo maps, raw memory, cookies, wallet material, or hidden scoring details.
Prepare a reviewable PR
Retest the fix and capture safe before/after proof. If the owner is clear, open one focused PR there; if not, use a reviewer-routed packet.
hunt signals
Look for these moments while your team uses Spark.
submit clean PRs
Choose the right lane, then make the PR reviewable.
Spark Compete accepts focused PRs across the allowed public Spark repos when the repo clearly owns the bug. Every lane needs one focused branch, a complete packet, safe proof, and all review gates before public points.
review path
From finding to the owning repo.
-
01
Register the team
Add every GitHub account that may open PRs for the team.
-
02
Pick the owner
Pick the public repo or reviewer-routed surface that clearly owns the failure.
-
03
Submit one focused packet
Open a PR when the owner is clear; use a reviewer-routed packet when it is not.
-
04
Pass every gate
Packet, security, jury, duplicate, account, lab, status, scoring, then merge or publish.
Public rules: install Spark packet self-check automation proof Telegram proof shared bot status submission spec allowed repos rework guide scoring gates review update
install Spark Agent Use your own Spark Agent first, then submit one verified fix from the repo that owns the failure. Open
plan
Start with the dry run
Install from
agent.sparkswarm.ai/install. Review the dry-run plan before allowing writes.
verify
Finish first-run checks
Run
spark guide, spark providers status, and spark verify --onboarding before hunting.
hunt
Use real workflows
Talk to Spark, try local CLI, Spawner UI, Telegram, and hosted onboarding until a real issue appears.
Mac / Linux / WSL: curl -fsSL https://agent.sparkswarm.ai/install.sh -o spark-install.sh bash spark-install.sh --dry-run bash spark-install.sh Windows PowerShell: iwr https://agent.sparkswarm.ai/install.ps1 -OutFile spark-install.ps1 powershell -NoProfile -ExecutionPolicy Bypass -File .\spark-install.ps1 -DryRun powershell -NoProfile -ExecutionPolicy Bypass -File .\spark-install.ps1
Your own Spark Agent is the primary competition lane. For Telegram proof, connect Spark to Telegram only through normal onboarding and use a safe disposable test chat that belongs to your team. Do not use private conversations, production-only chats, login codes, bot tokens, chat IDs, private usernames, or raw conversations as evidence. If you cannot create a safe test lane, use the maintainer/lab reproduction lane instead.
packet self-check Fill the packet, then validate before opening or repairing a PR. Open
fill
Use a real packet
Start from the public, reviewer-routed, or Telegram Bot example; replace every example URL with the real issue or PR for real submissions.
route
Owner is clear
Use the owning public repo only when the failure clearly lives there; otherwise use a reviewer-routed packet.
proof
Evidence and notes are safe
No shortened links, downloads, raw logs, private maps, secrets, empty duplicate notes, or empty risk notes.
API
Machine check
POST packet JSON to
/api/packet/validate; read status, warning codes, and next_step.
pass
status: "pass"
The packet shape passed. This is still not approval, mergeability, proof authenticity, or points release.
flag
pass_with_warnings
ok: false, packet_valid: true. Warning codes are review flags and can keep merge or points blocked.
fail
status: "fail"
Fix the packet before review. Do not ask reviewers to score or merge a packet with validation errors.
The validator does not store packets and does not echo packet content. It catches schema and policy gaps such as unsafe evidence links, empty risk notes, unknown target repos, mismatched URLs, wrong reviewer-routed intake, prompt-injection evidence, and example /pull/0 placeholders. Example packet URLs are for learning only; real submissions must use the real issue or PR URL. A passing validator result does not prove the bug, approve the PR, unlock points, or replace reviewer/lab verification. If the response is pass_with_warnings, the packet is structurally valid but ok is false because warnings can keep merge or points locked until reviewer, maintainer, security, or lab verification.
proof kit Use safe before/after proof that reviewers can verify. Open
before
Capture the broken state
Screenshot plus repro, redacted bounded terminal excerpt, failing test, or short redacted behavior excerpt.
after
Capture the improved state
Passing smoke, fixed screenshot with reproduction path, passing test, or clearer agent response.
PR
Link proof in the PR body
Reviewer should understand the value without reconstructing the whole hunt.
Screenshot-only proof is not enough for points unless maintainers or the lab can reproduce the behavior. Docs-only fixes should include a before link or screenshot and an after rendered-page proof or PR diff. Redacted terminal proof should include only the command, relevant result, and after-fix confirmation. When proof can be fabricated, include an independent smoke path, test, or reviewer/lab reproduction step.
optional proof tooling Use computer-use, browser-use, Telegram Web, local smoke, or tests when they make proof stronger. Open
UI
Browser or computer-use lane
Good for hosted pages, Spawner UI, and visible Telegram Web QA. Share safe screenshots plus the exact actions to reproduce.
CLI
Local smoke or tests lane
Good for installer, CLI, backend, docs, and package changes. Share bounded command/status output and targeted tests.
lab
Maintainer or lab lane
If your agent lacks safe access, say so plainly. Reviewers or the lab can reproduce before merge or points.
These tools are recommended, not mandatory for every team. Never paste login codes, browser cookies, private Telegram chats, raw conversations, chat IDs, private usernames, secrets, raw logs, or hidden scoring details into a packet, prompt, screenshot, or PR body.
repo-specific proof Use your own Spark Agent for Telegram proof unless a safer lane is explicitly needed. Open
live
Primary: your Spark Agent
Install Spark Agent, connect Telegram safely, and use your own disposable team test chat when one is clearly available.
bot
Optional shared bot
Use only the bot published by
/telegram-test-lane.json when its status is live; this is not the default lane.
lab
Maintainer or lab proof
If no safe public chat exists, use the no-safe-chat wording. The packet may continue with warnings, but points stay locked.
smoke
Exact command path
When available, verify start task, status, proof failure, retry, cancel, and terminal cancelled state.
Default to your own Spark Agent plus your own safe disposable Telegram test chat. The official bot URL in /telegram-test-lane.json is only an optional shared smoke lane when it says status: "live". Do not guess bot handles, do not use private or production chats as evidence, and do not include chat IDs, private usernames, bot tokens, private messages, raw logs, login codes, or screenshots with sensitive chat data. If the team lacks a safe disposable chat, write exactly: No safe disposable Telegram test chat is available. Do not invent Telegram proof. Maintainers/lab must run the listed smoke path before points.
required PR packet
Use valid spark-compete-hotfix-v1 JSON in every new PR body.
Open
identity
Team and author
Team name, three members, PR author GitHub login, allowed team GitHub accounts, and PR URL.
target
Owning repo and surface
Use the allowed repo that owns the bug; if ownership is unclear, say so without guessing private repos.
proof
Issue, evidence, and tests
Actual behavior, expected behavior, repro steps, safe links, tests or smoke, and changed files.
review
Duplicate notes and risk notes
Related PRs checked, new value added, and security/privacy/CI/dependency/prompt-injection risks.
{
"schema": "spark-compete-hotfix-v1",
"event": "spark-compete-first-event",
"submission_mode": "public_repo_pr",
"submission_target_url": "https://github.com/vibeforge1111/vibeship-spawner-ui/pull/1",
"team": {
"name": "Example Team",
"members": ["Member One", "Member Two", "Member Three"],
"llm_device_holder": "Member One",
"device_holder_github": "https://github.com/example-member-one",
"github_accounts": ["example-member-one", "example-member-two"]
},
"target_repo": {
"id": "vibeforge1111/vibeship-spawner-ui",
"source": "https://github.com/vibeforge1111/vibeship-spawner-ui",
"owner_surface": "spawner-ui"
},
"issue": {
"type": "bug",
"severity": "medium",
"title": "Mission card keeps showing a cancelled run as active",
"actual_behavior": "The mission board keeps a cancelled run in the active column after the cancellation finishes.",
"expected_behavior": "The mission board should show the run as cancelled and offer the safest next action.",
"repro_steps": ["Start a mission in a disposable workspace.", "Cancel the run and refresh the mission board."],
"affected_workflow": "Spawner UI mission tracking"
},
"evidence": {
"safe_links_only": true,
"before_after_proof": "Before: cancelled run still appears active on the mission board. After: cancelled run appears as cancelled with the retry or inspect-proof action visible.",
"links": ["https://github.com/vibeforge1111/vibeship-spawner-ui/pull/1"],
"forbidden": ["pdf", "zip", "exe", "unknown downloads", "shortened links", "archives", "binaries", "tokens", "browser cookies", "wallet material", "raw logs", "raw conversations", "raw memory", "raw patches", "private repo maps", "private scoring details"]
},
"proposed_fix": {
"approach": "Render cancelled run state directly and point the operator to retry or inspect proof.",
"files_expected": ["src/mission-board.js", "test/mission-board.test.js"],
"tests_or_smoke": "Run the targeted mission-board state test and include a redacted before/after screenshot."
},
"pr": {
"branch": "spark-compete/spawner-cancelled-run-state",
"title_prefix": "[spark-compete]",
"author_github": "example-member-one",
"body_must_include": ["packet", "team", "pr_author", "repo", "actual_behavior", "expected_behavior", "repro_steps", "before_after_proof", "tests_or_smoke", "duplicate_notes", "risk_notes", "review_claim"],
"url": "https://github.com/vibeforge1111/vibeship-spawner-ui/pull/1"
},
"review_claim": {
"impact_claim": "medium",
"evidence_types": ["before_screenshot", "after_screenshot", "smoke_test"],
"duplicate_notes": "Searched open PRs and issues for the same cancelled mission state; this packet covers the Spawner UI display path.",
"risk_notes": "No secrets, CI workflows, dependency files, private owner routing, or prompt surfaces changed.",
"review_state_requested": "pr_review"
}
}
Schema: spark-compete-hotfix-v1.json. Filled example: spark-compete-hotfix.valid.json. Reviewer-routed example: spark-compete-hotfix.reviewer-routed.json. Existing PRs are not thrown away. Reviewers may reconstruct a curator-created packet from trusted GitHub evidence, but it receives the standard 30% packet-structure adjustment and still cannot receive points until every packet, security, jury, duplicate, account, lab, status, and scoring gate passes.
allowed targets
Route the PR to the repo that owns the failure.
Choose from the allowed public Spark repos when the issue clearly lives there. If ownership is private or ambiguous, do not guess. Use the reviewer-routed packet and let maintainers route it.
leaderboard
The Bounty Vault holds 1.5% of Spark Supply.
Bounty Board leaders and every team with gated, reviewer-approved PR value can earn a share. Public points publish only after the required gates and the repo's status policy clear.
team standings
Public points appear after gates clear.
This board shows public points only after the required gates and the repo's published status policy clear. Private review scoring can happen before public points are released. Read the review update.
agent playbook
Send missions to Spark agents and route fixes to the right repo.
agent-readable brief
One copy-paste instruction for the whole hunt.
Spark Compete context for Spark agents: Spark Compete: Hunting Bugs & Goblins is a team-based hotfix hunt. Three-person teams use Spark heavily, catch real usage friction, ask an outside LLM to make the smallest useful fix, verify before/after proof, and open a focused PR in the repo that owns the failure. Reviewer-approved private value can be tracked, but public leaderboard signal releases only after the repo's required publish, merge, or maintainer-acceptance policy passes; open PR volume does not. Spark's brain should treat this as a reviewer-verifiable improvement loop, not a volume game. Exact scoring weights stay private. Optimize for useful fixes, clear proof, safe evidence, and the first complete packet on a real issue. System discovery: Install your own Spark Agent from `https://agent.sparkswarm.ai/install`, run the dry-run first, and finish first-run checks before hunting: `spark guide`, `spark providers status`, and `spark verify --onboarding`. Use real Spark workflows before submitting; the competition rewards verified fixes from real usage, not blind patch guesses. When local Spark tooling is available, start with `spark os compile --json`, then inspect the generated capability, authority, trace, memory, repo-board, and gap views locally. Use those outputs to choose a public target or reviewer-routable owner surface. Do not publish full compile JSON, private repo maps, raw memory, raw logs, or owner routing details. Where to aim PRs: Start by reading `/allowed-repos.json`. Target the repo that clearly owns the bug: `vibeforge1111/Spark-Agent-Site`, `vibeforge1111/vibeship-spawner-ui`, `vibeforge1111/spark-telegram-bot`, `vibeforge1111/spark-cli`, `vibeforge1111/spark-intelligence-builder`, `vibeforge1111/spark-domain-chip-labs`, `vibeforge1111/spark-character`, `vibeforge1111/spark-researcher`, `vibeforge1111/spark-voice-comms`, or `vibeforge1111/spark-personality-chip-labs`. If ownership is private or ambiguous, do not guess repo names or open side PRs to chase points. Mention the observation in safe proof or reviewer notes and wait for maintainer routing. Use only public-safe summaries. Do not expose raw secrets, logs, conversations, memory bodies, private repo maps, full compile JSON, raw traces, database rows, or hidden scoring details. Spark Compete hotfix mission: 1. Use Spark as much as possible. Talk with Spark, build with Spark, run workflows with Spark, and try the starter missions below or follow any real Spark friction your team finds until something feels wrong, confusing, broken, unsafe, or harder than it should be. 2. When you find a bad moment, capture a redacted before state and ask your outside LLM to help fix it. Tell it: "We are improving Spark. This behavior is a bug or usage problem because <explain what happened>. Use only this redacted summary, reproduce it, identify the allowed public repo that owns it, make the smallest useful fix, and prepare safe proof." Never paste secrets, raw logs, raw PR bodies, private repo maps, raw memory, cookies, wallet material, or hidden scoring details. 3. Verify the new version yourself. Make sure the bug is actually fixed, capture before/after screenshots or redacted terminal/test excerpts, and then ask your LLM to open one focused PR in the owning public repo. If ownership is unclear or private, prepare the reviewer-routed packet and wait for maintainer routing. The Bounty Board reward pool is 1.5% of Spark Supply. It is shared through gated, reviewer-approved PR value, so contributors with approved Spark improvements can earn a share; it is not only for the top team. Public points stay hidden until every required gate and the repo's published status policy pass. The first team to find and land a real bug fix gets the main credit. Later PRs on the same area can still earn credit only when they add clear new value. Keep evidence safe: screenshots, redacted bounded terminal excerpts, tests, GitHub links, access-controlled docs, or permissioned chat links only. No PDFs, archives, shortened links, binaries, unknown downloads, or secret-like material. Required PR packet: Every new PR should include a complete, valid `spark-compete-hotfix-v1` packet in the PR body with team name, three members, PR author, PR URL, target repo, owner surface, actual behavior, expected behavior, repro or inspection steps, safe before/after proof, tests or smoke, duplicate notes, and risk notes. A marker or empty template is not enough. Before opening or repairing a PR, ask your LLM or agent to POST the packet JSON to `/api/packet/validate` and read `status`, warning codes, and `next_step`. The validator returns schema and policy codes with field paths, `status`, `packet_valid`, and `next_step`; it does not store or echo packet content. `ok: true` appears only for clean validation with no warning flags. `status: "pass_with_warnings"` returns `ok: false` and `packet_valid: true`; it is a review flag state, not approval. Proof and automation lanes: Use the strongest safe proof lane available for the owning repo: browser-use or computer-use screenshots with exact actions for hosted UI issues, bounded local terminal output and tests for CLI/backend issues, visible Telegram Web QA only in safe disposable bot chats, or maintainer/lab reproduction when the contributor lacks safe access. These tools are recommended, not mandatory for every team. Never paste login codes, browser cookies, private Telegram chats, raw conversations, chat IDs, private usernames, secrets, raw logs, or hidden scoring details into a packet, prompt, screenshot, or PR body. Telegram Bot proof: For `vibeforge1111/spark-telegram-bot`, use one of three proof lanes. The primary lane is your own Spark Agent connected to your own safe disposable Telegram test chat. Optional shared-bot proof can use only the `bot_url` from `/telegram-test-lane.json` when its status is `live`. Maintainer/lab reproduction applies when no safe public chat exists. Never guess bot handles. Capture redacted before and after replies plus the exact smoke path for start task, status, proof failure, retry, cancel, and terminal cancelled state. If no safe public chat exists, write: `No safe disposable Telegram test chat is available. Do not invent Telegram proof. Maintainers/lab must run the listed smoke path before points.` Never include chat IDs, private usernames, bot tokens, private messages, raw logs, login codes, or screenshots with sensitive chat data. Backlog fairness: Existing PRs are not thrown away only because the packet was missing. Reviewers may reconstruct a curator-created packet from trusted GitHub metadata, passive patch inspection, and safe evidence already in the PR. Reconstructed packets can keep review moving, but they receive the standard 30% packet-structure adjustment and still cannot receive points until packet, security, duplicate, account, jury, lab, status, and scoring gates pass. Repo-specific merge or publish rules still apply.