GO — Healthy across the board

• Last commit today
• 16 active contributors
• Distributed ownership (top contributor 17% of recent commits)
• Other licensed
• CI configured
• Tests present
• ⚠ Non-standard license (Other) — review terms

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests, cross-checked against dependency CVEs from deps.dev and OpenSSF Scorecard}

AutoGPT is an open-source platform for building, deploying, and running persistent AI agents that automate complex multi-step workflows. It provides a visual agent builder (frontend in TypeScript/Next.js), a Python-based execution backend ('autogpt_platform'), and a block-based programming model where reusable action blocks are wired together into agent graphs. The platform handles agent scheduling, credential management, and LLM orchestration so users don't have to. Monorepo with two major subsystems: the legacy Classic agent (likely under autogpts/autogpt/) and the new autogpt_platform/ which contains a Python FastAPI/Prisma backend and a TypeScript Next.js frontend. The .claude/skills/ directory holds AI-agent workflow scripts for repo automation (PR creation, review, orchestration). PLpgSQL files indicate a PostgreSQL database with stored procedures for the platform.

AI engineers, automation developers, and technical hobbyists who want to compose LLM-powered workflows without writing all the orchestration glue code themselves. Also targets product teams evaluating autonomous agent frameworks for internal tooling — anyone who wants to self-host a no-code/low-code agent builder backed by a real execution engine.

The repo has significant traction (large Discord, active Twitter) and is under very active development with a dual structure: a legacy Classic AutoGPT agent and a newer 'Platform' architecture. CI, Docker Compose setup, and a maintained docs site (agpt.co/docs) suggest a serious project. It is best characterized as 'actively developed beta' — the platform side is not yet production-stable, as evidenced by the closed-beta cloud offering and the ongoing architectural migration.

The codebase spans Python, TypeScript, PLpgSQL, and Shell across a large monorepo, creating high coordination overhead and dependency surface. The platform backend relies on Docker Compose orchestration with multiple services (database, broker, backend, frontend) all needing to be healthy simultaneously. The .claude/ directory reveals heavy use of AI-assisted development tooling (Claude agents for PRs, orchestration scripts), which is non-standard and adds process risk. Breaking changes between the Classic and Platform architectures are ongoing.

Active work is focused on the new Platform architecture — the .claude/skills/ orchestration scripts (spawn-agent.sh, poll-cycle.sh, recycle-agent.sh) suggest automated agent-driven development is being used to accelerate feature work. The vercel-react-best-practices skill set under .claude/skills/ indicates ongoing frontend performance improvements. The closed-beta cloud waitlist implies a push toward a public cloud release.

git clone https://github.com/Significant-Gravitas/AutoGPT.git && cd AutoGPT

For the full platform via Docker (recommended):

curl -fsSL https://setup.agpt.co/install.sh -o install.sh && bash install.sh

Or manually with Docker Compose:

cp .env.example .env # fill in API keys docker compose up --build

Frontend only (dev mode):

cd autogpt_platform/frontend && npm install && npm run dev

Daily commands:

Full platform:

docker compose up

Frontend dev server alone:

cd autogpt_platform/frontend && npm run dev

Backend dev server alone:

cd autogpt_platform/backend && poetry install && poetry run uvicorn app.main:app --reload

• .github/workflows/platform-backend-ci.yml — Defines the CI pipeline for the platform backend, gating all PRs with build/test/lint checks.
• .github/CODEOWNERS — Specifies required reviewers per directory, controlling who must approve any change before merge.
• .github/copilot-instructions.md — Documents the repo's AI-assisted development conventions that all contributors and AI tools must follow.
• .claude/skills/orchestrate/scripts/run-loop.sh — Core orchestration loop that drives autonomous Claude agent execution across the repo's multi-agent system.
• .claude/skills/orchestrate/scripts/spawn-agent.sh — Creates new agent instances in the orchestration framework, the entry point for multi-agent parallelism.
• .github/workflows/claude.yml — Top-level workflow that triggers Claude AI agents on GitHub events, the primary automation entry point.
• .branchlet.json — Root configuration for the branchlet multi-repo/branch management system used by agent workflows.

• Claude Workflow (GitHub Actions, YAML) — Receives GitHub events and bootstraps the Claude agent orchestration environment.
  • Failure mode: Workflow fails to trigger if event filters are misconfigured, silently skipping agent tasks.
• Orchestrator (run-loop.sh) (Bash, tmux) — Manages the lifecycle of all concurrent agent processes, polling for completion and spawning new work.
  • Failure mode: Infinite loop or missed completions if poll-cycle.sh logic has race conditions.
• Agent Skills (Markdown, Bash) — Encapsulate reusable task instructions (open PR, review, write tests) consumed by Claude agents.
  • Failure mode: Agent produces incorrect output if SKILL.md instructions are ambiguous or outdated.
• Platform Backend (Python (inferred), Docker) — Serves the core AutoGPT platform API, handling agent creation, execution, and management.
  • Failure mode: Service unavailable if deployment pipeline fails or container health checks don't pass.
• Classic AutoGPT (Python, Docker) — The original standalone AutoGPT agent application, maintained for backward compatibility.
  • Failure mode: Import or dependency errors surface at runtime inside Docker if requirements are not pinned.
• Frontend (Platform UI) (React, Next.js, Vercel) — React/Next.js UI for interacting with the AutoGPT platform, deployed via Vercel.
  • Failure mode: Hydration mismatches or bundle size regressions degrade UX silently in production.

• GitHub Event → Claude Workflow — Issue/PR/push event triggers the workflow via GitHub Actions event subscription.
• Claude Workflow → Orchestrator — Workflow invokes run-loop.sh, passing task context (issue number, repo, branch) as environment variables.
• Orchestrator → Claude Agent — spawn-agent.sh creates a tmux pane with the task prompt; agent reads SKILL.md and begins work.
• Claude Agent → GitHub API — Agent pushes commits, opens PRs, and posts review comments via gh CLI calls within skill scripts.
• GitHub API → CI Workflows — New PR or push event triggers backend/frontend CI workflows to validate agent-produced changes.

Add a new Agent Skill

1. Create a new directory under .claude/skills/ named after your skill (.claude/skills/<your-skill>/SKILL.md)
2. Write a SKILL.md that defines the skill's purpose, inputs, outputs, and step-by-step instructions for the agent (.claude/skills/<your-skill>/SKILL.md)
3. Add any supporting shell scripts the skill needs alongside the SKILL.md (.claude/skills/<your-skill>/scripts/<script>.sh)
4. Reference the new skill in the orchestration workflow so agents can be assigned it (.github/workflows/claude.yml)

Add a new CI Workflow

1. Create a new YAML file in .github/workflows/ following the naming convention <scope>-<purpose>.yml (.github/workflows/<scope>-<purpose>.yml)
2. Add path filters and triggers matching your component's directory to avoid running on unrelated changes (.github/workflows/<scope>-<purpose>.yml)
3. Add the new workflow's job as a required status check in CODEOWNERS or branch protection (update labeler if path-based) (.github/labeler.yml)

Add a new Vercel/React Best-Practice Rule

1. Create a new markdown file in the rules directory following the <category>-<rule-name>.md naming pattern (.claude/skills/vercel-react-best-practices/rules/<category>-<rule-name>.md)
2. Document the anti-pattern, the correct pattern, and a concrete code example in the new rule file (.claude/skills/vercel-react-best-practices/rules/<category>-<rule-name>.md)
3. Register the new rule in the skill's AGENTS.md or SKILL.md so agents know to apply it during reviews (.claude/skills/vercel-react-best-practices/SKILL.md)

Extend Agent Orchestration Capacity

1. Edit capacity.sh to increase the maximum number of concurrent agent slots (.claude/skills/orchestrate/scripts/capacity.sh)
2. Update spawn-agent.sh if new tmux session naming or environment setup is required for extra slots (.claude/skills/orchestrate/scripts/spawn-agent.sh)
3. Adjust poll-cycle.sh timing and slot-selection logic to handle the larger pool efficiently (.claude/skills/orchestrate/scripts/poll-cycle.sh)

• GitHub Actions — Provides event-driven, cloud-hosted CI/CD tightly integrated with the repo, enabling both standard CI and Claude agent triggers without separate infrastructure.
• Shell scripts (Bash) — Lightweight, portable orchestration layer for managing tmux-based agent processes without introducing a heavy runtime dependency.
• Claude AI (Anthropic) — Powers autonomous code generation, review, and PR management via the SKILL.md instruction framework, enabling AI-native development workflows.
• Markdown SKILL.md files — Human- and AI-readable instruction format that lets skills be versioned in Git and consumed directly by Claude without a separate DSL.
• tmux — Enables multiple long-running agent sessions to coexist on a single runner, providing concurrency without containerisation overhead.

• Shell scripts for orchestration instead of a Python/Node framework

  • Why: Minimises dependencies and keeps the orchestration layer universally portable across runner environments.
  • Consequence: Limited error handling, harder to unit-test, and difficult to extend with complex logic.

• SKILL.md markdown files as agent instructions

  • Why: Keeps skills version-controlled, human-readable, and directly ingestible by LLMs without a compilation step.
  • Consequence: No static validation of skill correctness; malformed instructions are only caught at agent runtime.

• Monorepo with separate classic/platform/docs workspaces

  • Why: Allows shared tooling and cross-component CI while keeping each sub-project independently deployable.
  • Consequence: Complex labeler and CODEOWNERS configuration; CI must carefully filter paths to avoid unnecessary runs.

• Claude CI failure auto-fix workflow

  • Why: Reduces manual toil by letting an AI agent attempt fixes on broken builds automatically.
  • Consequence: Risk of auto-merged incorrect fixes if verification gates are insufficient.

• Does not implement a custom LLM model — relies entirely on external providers (Anthropic Claude, OpenAI)
• Does not provide a general-purpose workflow engine; orchestration is specific to GitHub-based agent tasks
• Classic AutoGPT component does not support Windows natively (Docker-first)
• The agent orchestration layer does not support non-tmux environments (e.g., bare CI runners without session management)
• Does not manage secrets rotation — relies on GitHub Actions secrets and repository settings

• Avg cyclomatic complexity: ~3 — The visible files are predominantly shell scripts and markdown; logic is simple sequential/conditional with low cyclomatic complexity, but the full application source (not listed) likely raises the average significantly.
• Largest file: .github/workflows/platform-backend-ci.yml (400 lines)
• Estimated quality issues: ~12 — Estimated issues include unquoted shell variables, missing error handling (set -e/pipefail) in orchestration scripts, and lack of input validation across the skill scripts.

• Unvalidated shell script inputs (High) — .claude/skills/orchestrate/scripts/spawn-agent.sh: Shell scripts that interpolate GitHub event data directly into commands risk injection if event payloads contain special characters.
• No unit tests for orchestration logic (Medium) — .claude/skills/orchestrate/scripts/: All orchestration is implemented in shell scripts with no test harness, making regressions only detectable at runtime.
• Skill instructions as unvalidated prose (Medium) — .claude/skills/: SKILL.md files are free-form markdown with no schema validation, so instruction drift or ambiguity is caught only via agent behaviour.
• Hardcoded capacity limits (Low) — .claude/skills/orchestrate/scripts/capacity.sh: Concurrency limits appear to be hardcoded in the script rather than driven by configuration, making scaling changes require code edits.

• .claude/skills/orchestrate/scripts/poll-cycle.sh (Throughput / Latency) — Synchronous polling loop introduces latency between task completion and new agent spawn, limiting throughput under high load.
• .github/workflows/claude.yml (Single Point of Failure) — All agent tasks funnel through a single workflow entry point; a misconfiguration here blocks the entire AI-assisted development pipeline.
• .github/workflows/platform-backend-ci.yml (CI Performance) — Backend CI is a required gate for all platform PRs; slow test suites here directly increase PR cycle time.

1. Multiple services must be running simultaneously (Postgres, Redis/broker, backend, frontend) — partial startup causes silent failures. 2) The .env setup requires real API keys (OpenAI, etc.) before any agent can execute; missing keys cause runtime errors, not startup errors. 3) The Classic AutoGPT and the new Platform are separate systems in the same repo — mixing up their setup docs will waste hours. 4) The .claude/ AI agent tooling requires tmux and specific shell environments — it won't work on Windows without WSL2. 5) PLpgSQL migrations must be run in order; skipping Prisma migrate steps breaks the schema silently.

• Agent Graph / Dataflow Programming — AutoGPT Platform models agent workflows as directed graphs of blocks — understanding dataflow programming explains why blocks are stateless and how data moves between steps.
• ReAct Prompting Pattern — The autonomous agent loop (Reason + Act) is the core cognitive architecture AutoGPT agents use to decide next actions — understanding ReAct explains the agent's decision loop.
• Tool Use / Function Calling (LLMs) — AutoGPT blocks are exposed as 'tools' the LLM can invoke — OpenAI function calling is the mechanism that lets the model trigger real actions.
• Event-driven Task Queue (Celery/Redis pattern) — Agent execution tasks are queued and dispatched asynchronously — understanding task queue architecture explains how AutoGPT scales agent runs without blocking.
• Prisma ORM with PostgreSQL — The platform backend uses Prisma as the ORM layer over PostgreSQL — schema changes require Prisma migrate commands and understanding the Prisma DSL before touching the database.
• Tmux-based Agent Orchestration — The .claude/skills/orchestrate/ scripts use tmux panes to run parallel AI coding agents — contributors modifying the dev automation tooling must understand tmux session/pane management.
• Server-Sent Events (SSE) for streaming — Agent execution output (LLM token streaming, step results) is likely streamed to the frontend via SSE — relevant when debugging the real-time UI update mechanism.

• langchain-ai/langchain — Primary alternative ecosystem for building LLM-powered agent pipelines in Python — many AutoGPT users evaluate both.
• microsoft/autogen — Direct competitor in the multi-agent orchestration space, also targeting automated AI workflow composition.
• reworkd/AgentGPT — Web-based autonomous agent runner with similar goals to AutoGPT Platform — useful for comparing UX and architecture approaches.
• hwchase17/langchainjs — TypeScript counterpart to LangChain; relevant because AutoGPT's frontend is TypeScript-heavy and may interop with JS agent tooling.
• openai/openai-python — Core upstream dependency — AutoGPT's agent execution relies heavily on OpenAI API patterns and changes here propagate downstream.

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 integration tests for orchestration scripts in .claude/skills/orchestrate/scripts/

The orchestration layer contains 10 shell scripts (capacity.sh, classify-pane.sh, find-spare.sh, notify.sh, poll-cycle.sh, recycle-agent.sh, run-loop.sh, spawn-agent.sh, status.sh, verify-complete.sh) that coordinate AI agent lifecycle management. These scripts have zero visible test coverage, yet they are critical infrastructure. A failure in spawn-agent.sh or recycle-agent.sh could silently break multi-agent workflows. Adding a bats (Bash Automated Testing System) test suite would catch regressions and make the orchestration system more trustworthy for contributors.

• [ ] Install and configure bats-core as a dev dependency (add to package.json or a Makefile target)
• [ ] Create .claude/skills/orchestrate/tests/ directory with a test file per script (e.g., spawn-agent.bats, recycle-agent.bats)
• [ ] Write tests for .claude/skills/orchestrate/scripts/capacity.sh: mock tmux/pane state and assert correct numeric output
• [ ] Write tests for .claude/skills/orchestrate/scripts/find-spare.sh: assert it returns a valid idle pane or exits with expected code when none available
• [ ] Write tests for .claude/skills/orchestrate/scripts/verify-complete.sh: simulate completed vs in-progress agent states and assert correct exit codes
• [ ] Add a GitHub Actions workflow (.github/workflows/test-orchestration.yml) that runs the bats suite on push to any branch touching .claude/skills/orchestrate/

Create a unified SKILL.md documentation standard and fill gaps across all skills

The repo has 8 skill directories under .claude/skills/ (open-pr, orchestrate, pr-address, pr-polish, pr-review, pr-test, setup-repo, vercel-react-best-practices), each with a SKILL.md. However, vercel-react-best-practices also has a separate AGENTS.md and a rules/ subdirectory with 40+ rule files, while other skills like pr-review and pr-test have no equivalent structured rules. This inconsistency means contributors don't know what level of detail is expected. A PR that defines a SKILL.md template and backfills missing structured content for pr-review and pr-test would significantly improve onboarding.

• [ ] Audit existing SKILL.md files in open-pr, pr-address, pr-polish, pr-review, pr-test, setup-repo to identify missing sections compared to the vercel-react-best-practices structure
• [ ] Create a SKILL_TEMPLATE.md at .claude/skills/SKILL_TEMPLATE.md documenting required sections: Purpose, Inputs, Outputs, Steps, Rules/Checklist, Example invocation
• [ ] Create .claude/skills/pr-review/rules/ directory and extract any inline checklist items from .claude/skills/pr-review/SKILL.md into individual markdown rule files (e.g., rules/check-tests-exist.md, rules/check-pr-description.md)
• [ ] Create .claude/skills/pr-test/rules/ directory with rule files covering test naming conventions, coverage thresholds, and CI requirements
• [ ] Update .claude/skills/pr-review/SKILL.md and .claude/skills/pr-test/SKILL.md to reference their new rules/ directories, matching the pattern used in vercel-react-best-practices/SKILL.md
• [ ] Add a CI check (e.g., a simple shell script in a GitHub Action) that validates every SKILL.md contains the required sections from the template

Refactor poll-cycle.sh and run-loop.sh to extract shared agent-state logic into a reusable library script

Based on the file names, poll-cycle.sh and run-loop.sh in .claude/skills/orchestrate/scripts/ almost certainly share logic for reading agent state, checking pane status, and

1. Add missing unit tests for individual agent blocks in autogpt_platform/backend/blocks/ — the block interface is well-defined but test coverage for edge cases (empty inputs, API failures) is likely sparse. 2) Document the .claude/skills/ orchestration system — SKILL.md files exist but the interaction between spawn-agent.sh, poll-cycle.sh, and recycle-agent.sh is not explained end-to-end for new contributors. 3) Add TypeScript types/interfaces for the block graph data structures passed between frontend and backend — the API contract between Next.js frontend and Python backend is a common source of integration bugs.

• High · Shell Script Injection Risk in Orchestration Scripts — .claude/skills/orchestrate/scripts/spawn-agent.sh, recycle-agent.sh, run-loop.sh, notify.sh, poll-cycle.sh. Multiple shell scripts under .claude/skills/orchestrate/scripts/ (e.g., spawn-agent.sh, recycle-agent.sh, run-loop.sh, notify.sh) likely accept external input and pass it to shell commands. Without proper input sanitization and quoting, these scripts are susceptible to command injection attacks, especially if any input originates from untrusted sources such as issue titles, PR descriptions, or external webhooks. Fix: Audit all shell scripts for unquoted variables and unvalidated external input. Use set -euo pipefail at the top of each script. Sanitize and validate all inputs before use in commands. Prefer using arrays for command arguments rather than string interpolation. Consider replacing bash scripts with a safer language (e.g., Python) for complex orchestration logic.
• High · Potential Secret Exposure via Claude Skill Configuration — .claude/skills/open-pr/SKILL.md, .claude/skills/pr-review/SKILL.md, .claude/settings.json. The .claude/ directory contains skill configuration files (SKILL.md, scripts) that may reference environment variables, API keys, or credentials needed for operations like opening PRs, orchestrating agents, or interacting with external services. If any of these files contain hardcoded credentials or tokens (e.g., GitHub tokens, API keys), they would be exposed in the repository. The presence of skills like 'open-pr' and 'pr-review' suggests interaction with authenticated APIs. Fix: Audit .claude/settings.json and all SKILL.md files for hardcoded credentials. Ensure secrets are only passed via environment variables at runtime and never committed to the repository. Add .claude/settings.json to .gitignore if it contains sensitive runtime configuration. Use a secrets scanning tool (e.g., git-secrets, trufflehog, gitleaks) in CI/CD pipelines.
• High · Unvalidated External Input in GitHub Workflow Scripts — .github/scripts/detect_overlaps.py, .github/workflows/classic-autogpt-ci.yml. The .github/scripts/detect_overlaps.py script and .github/workflows/classic-autogpt-ci.yml may process external inputs such as PR titles, branch names, or issue content. If these inputs are not sanitized before being used in shell commands or Python subprocesses, they could lead to command injection or path traversal vulnerabilities. GitHub Actions workflows that use ${{ github.event.pull_request.title }} or similar expressions in run steps are particularly vulnerable. Fix: Avoid interpolating GitHub context variables directly into run: steps. Use environment variables to pass values from GitHub context to scripts (e.g., env: PR_TITLE: ${{ github.event.pull_request.title }}), then reference them as environment variables in the script. Validate and sanitize all inputs in detect_overlaps.py before use in system calls or file operations.
• High · Missing Security Headers Configuration — .claude/skills/vercel-react-best-practices/, Project configuration files. Based on the file structure, there is no evidence of security header configuration (e.g., Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Strict-Transport-Security) in the visible configuration files. The Vercel React best practices skills directory suggests a web frontend is deployed, making this omission significant for XSS and clickjacking protection. Fix: Add security headers via vercel.json headers configuration or a Next.js middleware/next.config.js. At minimum configure: Content-Security-Policy, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, Permissions-Policy. Use securityheaders.com to validate the configuration.
• Medium · XSS Risk via dangerouslySetInnerHTML in React Frontend — undefined. The presence of .claude/skills/vercel-react-best-practices/ rules related to rendering and hydration (rendering-hydration-no-flicker.md, rendering-conditional-render.md) indicates a React frontend. React projects often use dangerouslySetInnerHTML for rendering HTML content (e.g., markdown, user-generated content, AI-generated responses). AutoGPT's core functionality involves rendering AI-generated content, which increases the risk of stored or reflected XSS if output is not properly sanitized Fix: undefined

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

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

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/Significant-Gravitas/AutoGPT 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.

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

What it runs against: a local clone of Significant-Gravitas/AutoGPT — 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 Significant-Gravitas/AutoGPT | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 30 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of Significant-Gravitas/AutoGPT. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/Significant-Gravitas/AutoGPT.git
#   cd AutoGPT
#
# 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 Significant-Gravitas/AutoGPT and re-run."
  exit 2
fi

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

# 2. License matches what RepoPilot saw
(grep -qiE "^(Other)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Other\"" package.json 2>/dev/null) \\
  && ok "license is Other" \\
  || miss "license drift — was Other at generation time"

# 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 ".github/workflows/platform-backend-ci.yml" \\
  && ok ".github/workflows/platform-backend-ci.yml" \\
  || miss "missing critical file: .github/workflows/platform-backend-ci.yml"
test -f ".github/CODEOWNERS" \\
  && ok ".github/CODEOWNERS" \\
  || miss "missing critical file: .github/CODEOWNERS"
test -f ".github/copilot-instructions.md" \\
  && ok ".github/copilot-instructions.md" \\
  || miss "missing critical file: .github/copilot-instructions.md"
test -f ".claude/skills/orchestrate/scripts/run-loop.sh" \\
  && ok ".claude/skills/orchestrate/scripts/run-loop.sh" \\
  || miss "missing critical file: .claude/skills/orchestrate/scripts/run-loop.sh"
test -f ".claude/skills/orchestrate/scripts/spawn-agent.sh" \\
  && ok ".claude/skills/orchestrate/scripts/spawn-agent.sh" \\
  || miss "missing critical file: .claude/skills/orchestrate/scripts/spawn-agent.sh"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 30 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~0d)"
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/Significant-Gravitas/AutoGPT"
  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).

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