parse-community / parse-community/parse-server
Track agent instructions (AGENTS.md) and verification skills in the repo
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
- Report security issues confidentially.
- Any contribution is under this license.
- Before posting search existing issues.
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 tosrc/that isn't rebuilt gives a passing run that proves nothing - spec conventions (async/await,
expectAsync, nodone()) 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:
AGENTS.mdat the repo root, tool neutral, covering build/test/lint commands, the dual database requirement, thesrc/tolib/build step, spec conventions, and commit/PR conventions.CLAUDE.mdand.github/copilot-instructions.mdas symlinks to it, so Claude Code and Copilot pick up the same content without a second copy to drift.- Narrow the
.claudeignore rule to.claude/settings.local.jsonso 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
- A contributor asks an agent to fix a Postgres specific query bug.
- The agent reads
AGENTS.md, rebuildslib/, and runs the affected specs against both MongoDB and Postgres. - The PR includes the actual command output for both backends.
- 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.mdis 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
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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