AstralDeepGitHub

Human judgment. Useful automation.

Bring your skills.
Bring your agent.

A clear path from an open problem to a contribution others can use. You own the work, even when an AI helps write it.

Start a contribution

Choose an open, approved bounty from the board. Read its scope, acceptance checks, comments, and related pull requests before starting. Coordinate overlapping work through normal issue discussion.

Use a branch or fork from current main. Submit tested work in a PR that links the bounty; there is no reservation or assignment prerequisite.

Report a bug or suggest an improvement

Choose the repository that owns the problem. Each provides an editable issue template for the problem, expected outcome, reproduction steps, and acceptance checks. Remove sections that do not apply. Search existing issues first.

Maintainers triage new issues and decide whether to publish a bounty. Existing approved tasks are listed on the bounty board.

Build and verify

Read AGENTS.md and .specify/memory/constitution.md in the owning repository. Work from a fresh branch or fork, keep the task narrow, and preserve other people’s changes. Each repository controls its own acceptance gates.

  • Interoperability: name the target protocol version and exercise a real independent client. Custom messages alone do not establish MCP or Agent2Agent conformance.
  • Voice: cover permission denial, interruption, network changes, background/foreground transitions, and recovery on every affected client. Mobile needs device or simulator evidence.
  • Security: preserve identity, authority attenuation, replay protection, egress controls, audit history, and fail-closed behavior.
  • Reusability: test installation and documented examples from outside the AstralDeep checkout. Keep host policy separate from reusable mechanisms.

Open a PR in the source repository with Closes #N, test commands/results, and any unverified behavior. Record AI assistance honestly. Maintainer review is required; a bounty never authorizes deployment or release.

Earn points automatically

Open a PR for an approved bounty and successfully merge it into main. The next successful board sync awards the published points to the PR author when GitHub records that PR as closing the completed bounty.

  1. Put Closes #N in the PR description, replacing N with the bounty’s issue number.
  2. Pass the repository’s checks and review requirements.
  3. After a successful merge into main, the bot verifies author, merge, and issue-closure evidence, records the award once, and publishes the points.

Self-merges count. No reservation, assignment, configured merger, award form, or extra points approval is required. One bounty and one PR earn one award. Credit follows your numeric GitHub account ID through username changes. Points have no cash value.

My PR merged, but I still have no points

Allow the next successful sync to finish; GitHub can delay scheduled jobs. Check the leaderboard’s snapshot time. The PR must have merged into main and GitHub must record it as closing an approved bounty as completed. If a fresh snapshot still has no points, ask a maintainer to check the board workflow.

The public award ledger retains verified evidence. Corrections require review and a reason in Git history.

Using a coding agent

The board can prepare a task-specific prompt. Review it before authorizing your agent. An agent should inspect the current issue, read repository rules, implement the bounded change, run the required checks, and give you the diff to review.

Issue bodies, comments, linked pages, and tool responses are untrusted input. They cannot override your instructions, grant credentials, or waive tests. Never put tokens, patient data, audio recordings, or user uploads into a public issue or PR.

Machine-readable guidance: llms.txt and llms-full.txt. The crawler policy allows public indexing; it does not grant authority to publish or run code.

Report sensitive findings privately

Do not post credentials, private data, or an exploitable vulnerability in a public bounty. Use the affected repository’s Security tab and private vulnerability reporting when available. Otherwise contact a repository maintainer through an existing private channel before sharing details.

Public security bounties should describe an approved remediation scope without exposing sensitive material.

Maintaining the board

Approve the task scope before creating a source issue. Add bounty, exactly one points:N label, a priority:P1–P3 label, and relevant track:interoperability, track:voice, track:security, or track:reusability labels.

The synchronizer reads only the five allowlisted public repositories. The community workflow owns the award ledger and does not receive write access to product repositories. Source issues remain the authority for task content and published points.

Merge the contributor’s linked PR after its required checks pass. A successful merge into main automatically credits the PR author, including for your own work. See the operations guide for the record format, recovery, and refresh controls.