If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/orbitalindex/awesome-space shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Missing license — unclear to depend on

• Last commit 2w ago
• 32+ active contributors
• ⚠ Concentrated ownership — top contributor handles 51% of recent commits
• ⚠ No license — legally unclear to depend on
• ⚠ No CI workflows detected
• ⚠ No test directory detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live orbitalindex/awesome-space repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/orbitalindex/awesome-space.

What it runs against: a local clone of orbitalindex/awesome-space — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in orbitalindex/awesome-space | Confirms the artifact applies here, not a fork | | 2 | Default branch master exists | Catches branch renames | | 3 | 4 critical file paths still exist | Catches refactors that moved load-bearing code | | 4 | Last commit ≤ 45 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of orbitalindex/awesome-space. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/orbitalindex/awesome-space.git
#   cd awesome-space
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of orbitalindex/awesome-space and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "orbitalindex/awesome-space(\\.git)?\\b" \\
  && ok "origin remote is orbitalindex/awesome-space" \\
  || miss "origin remote is not orbitalindex/awesome-space (artifact may be from a fork)"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f "contributing.md" \\
  && ok "contributing.md" \\
  || miss "missing critical file: contributing.md"
test -f "bin/reformat.rb" \\
  && ok "bin/reformat.rb" \\
  || miss "missing critical file: bin/reformat.rb"
test -f ".gitignore" \\
  && ok ".gitignore" \\
  || miss "missing critical file: .gitignore"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 45 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~15d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/orbitalindex/awesome-space"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

awesome-space is a community-curated list of space-related code, APIs, data, and resources maintained by The Orbital Index. It serves as a discovery hub for developers, researchers, and space enthusiasts to find tools spanning astronomy APIs (astrometry.net, Open Astronomy Catalog), satellite software, mission control systems, orbital mechanics libraries, and earth observation data—organized into categories like Astronomy, Spacecraft, Data, and Community resources. Single-file architecture: README.md is the source of truth, auto-generated by bin/reformat.rb which maintains the Table of Contents and link structure. The .gitignore and contributing.md provide governance. No code directories—pure markdown organization with categories for Astronomy, Community, Data, and Spacecraft subsections, each with curated external links.

Space software developers, mission engineers, amateur astronomers, and data scientists who need to discover existing tools and libraries before building satellite tracking systems, orbital determination algorithms, radio astronomy applications, or space mission planning software. Also useful for space hackathon organizers and educators assembling learning resources.

This is an actively maintained curated list (not a software library with releases). It functions as a living document with community contributions; maturity is measured by curation quality and update frequency rather than code stability. Presence of contributing.md and automated reformat tooling (bin/reformat.rb) suggests structured maintenance, but lack of version tags or releases is typical for README-based resource lists.

Low technical risk as this is a documentation repository, not a runnable package with dependencies. Primary risks are curation drift (outdated or dead links), single-maintainer dependency for merging PRs, and potential for stale resources if contribution review slows. No broken build risk since there's no build process.

Unable to determine from provided metadata (no git commit history, PR list, or issue tracker snapshot included). Based on structure, active work likely involves reviewing contributed links, validating that external resources remain available, and reorganizing categories as new space tools emerge.

git clone https://github.com/orbitalindex/awesome-space.git
cd awesome-space
# No dependencies to install; README.md is the main artifact

Daily commands: This is not a runnable application. To validate or regenerate the README structure: ```bash ruby bin/reformat.rb

• README.md — Entry point and primary documentation; defines the curation scope and table of contents that all contributors must follow.
• contributing.md — Contribution guidelines that every contributor must read before submitting pull requests or additions.
• bin/reformat.rb — Build/linting script that enforces formatting and structure consistency across the curated list.
• .gitignore — Defines version control boundaries and excludes generated or temporary files from the repository.

• README.md (Markdown) — Stores all curated resource entries, categories, descriptions, and links; serves as the single source of truth
  • Failure mode: Manual errors in links, formatting, or category structure; no automated detection until reformat.rb is run
• bin/reformat.rb (Ruby) — Validates and reformats README.md structure; auto-generates table of contents; enforces consistency
  • Failure mode: Script bugs could mangle markdown; missing execution before PR can introduce inconsistencies
• contributing.md (Markdown) — Documents submission standards, quality criteria, and community guidelines
  • Failure mode: Outdated or unclear guidelines lead to low-quality or off-topic submissions
• Git/GitHub (Git, GitHub) — Manages version history, pull requests, and community contribution workflow
  • Failure mode: Merge conflicts or lost history if collaboration coordination breaks down

• Contributor → README.md — Contributor adds or edits resource entries following contributing.md guidelines
• Contributor → bin/reformat.rb — Contributor runs local formatting script to validate and auto-correct markdown
• bin/reformat.rb → README.md — Script regenerates table of contents, reformats links, and validates structure in place
• README.md → GitHub — Contributor commits formatted README.md and pushes to remote for PR review
• GitHub → CI/Validation — CI runs reformat.rb and linting checks on PR to ensure consistency before merge
• GitHub main branch → GitHub Pages — Merged README.md is rendered as static HTML on GitHub repository page

Add a new resource to the awesome list

1. Open README.md and locate the appropriate category section (Astronomy, Community, Data, Spacecraft, etc.) (README.md)
2. Add your resource entry in the existing format with name, description, and URL following the established pattern (README.md)
3. Run bin/reformat.rb to validate link format, table of contents, and markdown consistency (bin/reformat.rb)
4. Review contributing.md guidelines to ensure your entry meets quality standards (active project, space-related, useful to community) (contributing.md)

Create a new category section

1. Add the new category heading and description to README.md in logical alphabetical order within appropriate parent section (README.md)
2. Update the Table of Contents (TOC) section at the top of README.md to include the new category (README.md)
3. Run bin/reformat.rb to regenerate the TOC automatically and validate structure (bin/reformat.rb)

Maintain list quality and consistency

1. Review contributing.md for current quality criteria and submission requirements (contributing.md)
2. Audit entries in README.md for broken links, outdated projects, or inconsistent formatting (README.md)
3. Execute bin/reformat.rb to enforce consistent markdown, link validation, and structure (bin/reformat.rb)

• Markdown (README.md) — Human-readable, version-control-friendly format for curated lists; renders natively on GitHub
• Ruby (bin/reformat.rb) — Lightweight scripting language for automated list formatting, TOC generation, and validation without heavy dependencies
• Git + GitHub — Distributed version control enables community contributions, pull request workflows, and transparent change tracking

• Curated list vs. database

  • Why: Simplicity, accessibility, and low maintenance overhead for community curation
  • Consequence: Manual effort for link checking; no queryable API or dynamic filtering at scale

• Ruby script for formatting vs. external linting tool

  • Why: Custom logic tailored to this list's specific structure (TOC, category nesting, link patterns)
  • Consequence: Maintainers must understand Ruby; script must be manually executed before commits

• Plain text contributions via GitHub issues/PRs vs. form-based submission

  • Why: Lower barrier to entry; leverages existing GitHub familiarity and workflow integration
  • Consequence: Requires some git literacy; potential for format inconsistencies if script not run

• Does not provide programmatic API access to the curated list
• Does not host live space data or real-time satellite tracking
• Does not perform resource validation or availability monitoring at runtime
• Does not require authentication or user accounts
• Not intended as a replacement for specialized space industry databases

• Avg cyclomatic complexity: ~2 — Codebase is primarily documentation and a simple formatting script; no complex algorithms or interdependencies
• Largest file: README.md (300 lines)
• Estimated quality issues: ~3 — Main issues: lack of link validation, single point of failure in reformat script, and manual TOC synchronization; otherwise well-structured curation

• Manual TOC maintenance (Medium) — README.md: Table of contents is comment-marked as auto-generated but relies on reformat.rb execution; easy to get out of sync if script not run before commits
• No link validation automation (Medium) — README.md + bin/reformat.rb: Links are not automatically checked for 404s or availability; broken resources can persist in the list
• Single point of failure in reformat script (Medium) — bin/reformat.rb: If script has bugs, it could corrupt README.md structure; no guardrails or tests on the script itself

• bin/reformat.rb (Process/Tooling) — Manual script execution required before each commit; cannot be enforced without pre-commit hook or CI integration
• README.md (Scalability) — Single monolithic file; as list grows, diffs and merge conflicts become harder to manage
• contributing.md (Process) — Quality control relies on human review; no automated checks for relevance, activity, or description quality

No hidden traps typical of code repositories (no env vars, databases, or service dependencies). One gotcha: bin/reformat.rb expects a specific markdown structure with <!-- Start TOC --> and <!-- Start Links --> delimiters; manually editing README.md outside these markers may break the script. Another: external links can rot without notification—no automated link checker is visible, so PRs may add dead resources.

• Two-line element (TLE) format — TLE is the standard compact format for describing satellite orbital parameters; critical for understanding orbit determination tools and tracking software listed under Spacecraft > Tracking & Orbit Determination
• Astrometric calibration — Converting pixel coordinates to celestial coordinates in astronomy images; directly relevant to astrometry.net API and radio astronomy visualization tools listed in the catalog
• Software-defined radio (SDR) — Technique for receiving and transmitting signals using general-purpose hardware and software; foundational for radio astronomy projects and ground station software in awesome-space
• Orbital mechanics (Keplerian elements) — Mathematical framework for describing and predicting satellite orbits; essential knowledge for mission design, orbit determination, and tracking tools featured in the Spacecraft section
• Curation gatekeeping (awesome-list model) — awesome-space enforces quality standards by selective inclusion and PR review; understanding the curation philosophy helps contributors propose resources aligned with project scope
• Spectrometry in radio astronomy — Technique for analyzing radio signals by frequency; directly exemplified by VIRGO project listed under Radio Astronomy, critical for detecting cosmic phenomena

• sindresorhus/awesome — The canonical awesome-list template and governance model; awesome-space follows this structure and philosophy for curated resource lists
• csete/gpredict — Real satellite tracking and orbit prediction software that would be discovered through or featured in awesome-space's Spacecraft > Tracking & Orbit Determination section
• planet-labs/planet-sdk-py — Python SDK for Planet's earth observation satellite imagery; exemplifies the kind of spacecraft data access tool cataloged in awesome-space's Data > Earth section
• python-astropy/astropy — Core Python library for astronomy software development; many projects listed in awesome-space's Astronomy Software section depend on or integrate with Astropy
• GMAT-Community/GMAT — NASA's General Mission Analysis Tool for orbital mechanics and mission design; fits directly into awesome-space's Spacecraft > Mission Design category

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add automated link validation workflow in GitHub Actions

A curated awesome list with hundreds of resources is prone to link rot. Currently there's no CI to validate that all URLs in README.md are accessible. This prevents broken links from accumulating and improves maintainability. A GitHub Action can run periodically to check HTTP status codes.

• [ ] Create .github/workflows/link-check.yml with a link validation action (e.g., lychee or markdown-link-check)
• [ ] Configure the workflow to run on push/PR and scheduled daily
• [ ] Update contributing.md to document the link validation requirement for contributors
• [ ] Add a status badge to README.md showing link health

Create automated README validation and formatting script in bin/

The repo has bin/reformat.rb suggesting a maintenance tooling pattern. The TOC is manually marked with comments (<!-- Start TOC -->), but there's no validation that the TOC stays in sync with actual sections. Create a validation script to ensure TOC accuracy and consistent formatting before merges.

• [ ] Create bin/validate.rb to parse README.md and verify TOC matches actual section headers
• [ ] Add a GitHub Action workflow (.github/workflows/validate.yml) that runs bin/validate.rb on PRs
• [ ] Update contributing.md to explain the validation requirement and how to run it locally
• [ ] Document both bin/reformat.rb and bin/validate.rb usage in a DEVELOPMENT.md file

Add category-specific contribution templates and tracking

The README shows distinct top-level categories (Astronomy, Community, Data, etc.) but contributing.md likely doesn't guide contributors on which categories need updates or how to properly format entries per category. Create a CATEGORIES.md that defines submission standards per section.

• [ ] Create CATEGORIES.md documenting each main section (Astronomy, Community, Data, etc.) with submission guidelines
• [ ] Define standard fields for each resource type (name, URL, description, license, language where applicable)
• [ ] Add validation rules in bin/validate.rb to check that new entries follow category-specific format
• [ ] Update contributing.md with a reference to CATEGORIES.md and a checklist for PRs

• Add validation script: Create a Ruby script (bin/validate_links.rb) that checks all external URLs in README.md return 200/301 status codes; currently no automated link validation exists and dead links accumulate.
• Expand Radio Astronomy section: Only VIRGO is listed under Radio Astronomy subsection; research and add 3–5 other active radio astronomy projects (e.g., gnuradio-based tools, SDR frameworks) with descriptions following the existing format.
• Document reformat.rb script: Create a comment block in bin/reformat.rb explaining the TOC generation algorithm, delimiter requirements, and how to extend it; new contributors cannot currently modify the script safely.

The 'awesome-space' repository appears to be a curated list/documentation project with minimal attack surface. No critical vulnerabilities were identified in the provided analysis. The main security concerns are process-related rather than code-based: lack of dependency information for assessment, no visible security policy, and limited defensive documentation. The project's static nature (primarily markdown documentation) significantly reduces security risk. Recommended improvements include establishing a security policy and performing regular dependency audits if any dependencies exist.

• Low · Ruby Script Without Input Validation — bin/reformat.rb. The bin/reformat.rb script is present but its content was not provided for analysis. Ruby scripts that process user input or file content should validate and sanitize inputs to prevent injection attacks. Fix: Review the script for proper input validation, especially if it processes file content or accepts command-line arguments. Ensure no unsafe eval() or system() calls with unsanitized input.
• Low · Incomplete Dependency Analysis — Root directory. No package/dependency file content was provided (package.json, Gemfile, requirements.txt, etc.). Cannot verify for known vulnerabilities in third-party dependencies. Fix: Run dependency security scanning tools (npm audit, bundle audit, pip audit, etc.) regularly. Maintain an updated SECURITY.md or security policy document.
• Low · Missing Security Documentation — Root directory. No SECURITY.md, security policy, or vulnerability disclosure guidelines are visible in the repository structure. This is a best practice for open-source projects. Fix: Create a SECURITY.md file with vulnerability disclosure guidelines and contact information for reporting security issues.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.