parse-community / parse-community/parse-server

Track agent instructions (AGENTS.md) and verification skills in the repo

Open
#10,611 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
JavaScript
Stars
21.4k
Forks
4.8k
Avg merge
7h 45m
Merged PRs (30d)
11

Description

New Feature / Enhancement Checklist
Current Limitation

The repo has no tracked instructions for AI coding agents, and .gitignore actively excludes them:

# AI agents
.claude

So every contributor using an agent rediscovers the same repo specific rules on their own, and usually gets a few of them wrong:

  • tests have to run against both MongoDB and Postgres, an agent that only runs Mongo will report a green suite for a change that breaks Postgres
  • specs run against lib/, so a change to src/ that isn't rebuilt gives a passing run that proves nothing
  • spec conventions (async/await, expectAsync, no done()) that aren't written down anywhere an agent will load

None of this is visible in a diff. A PR arrives saying "tests pass" and the reviewer has no way to tell whether the suite was actually run in a way that means anything.

Feature / Enhancement Description

Track the agent instructions in the repo, the same way we track lint config:

  1. AGENTS.md at the repo root, tool neutral, covering build/test/lint commands, the dual database requirement, the src/ to lib/ build step, spec conventions, and commit/PR conventions.
  2. CLAUDE.md and .github/copilot-instructions.md as symlinks to it, so Claude Code and Copilot pick up the same content without a second copy to drift.
  3. Narrow the .claude ignore rule to .claude/settings.local.json so shared skills (a testing/verification workflow, for example) can be committed while personal settings stay local.

The reason this is worth doing beyond convenience: it's a quality gate we don't currently have. Instructions that state how a change must be verified are what make an agent run the full verification instead of the cheapest thing that turns green, and they give reviewers something concrete to hold a PR against. Combined with the existing CI matrix that raises confidence in what we ship rather than lowering it, which is the usual worry with agent authored PRs.

Example Use Case
  1. A contributor asks an agent to fix a Postgres specific query bug.
  2. The agent reads AGENTS.md, rebuilds lib/, and runs the affected specs against both MongoDB and Postgres.
  3. The PR includes the actual command output for both backends.
  4. The reviewer can see the change was verified the way the project requires, not just that CI went green on a rerun.
Alternatives / Workarounds

Contributors keep private CLAUDE.md files locally, which is the status quo and means the rules are inconsistent and invisible. CONTRIBUTING.md is the other option, but agents don't reliably load it and it's aimed at humans setting up an environment rather than at what has to be true before a change is claimed to work.

3rd Party References
  • AGENTS.md is the emerging cross tool convention: https://agents.md
  • Related: #9467 (parallel unit testing, the test loop speed that makes full verification practical), #7100 (improve contribution guide)

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the existing .gitignore and repository build, test, lint, and CI instructions to capture the commands and conventions that AGENTS.md must describe. Add root AGENTS.md and the requested CLAUDE.md and .github/copilot-instructions.md symlinks, then narrow the .claude rule to local settings. Done means the shared instructions cover both MongoDB and Postgres, the src/ to lib/ build step, spec conventions, and contribution workflow without duplicating content.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript, mongodb, nodejs, postgresql
Domain
developer-experience, documentation, testing, tooling
Issue type
Feature
Difficulty
3/5
Estimated time
1-2 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
68/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.