Skip to content

AGENTS.md

Latest commit

 

History

History
67 lines (51 loc) · 5.89 KB

AGENTS.md

File metadata and controls

67 lines (51 loc) · 5.89 KB
Raw

AGENTS.md

Instructions for AI coding assistants (Cursor, Claude Code, and similar) working in this repository.

Contributing guide vs this file

Purpose
CONTRIBUTING.md Contributing guide for all contributors—humans and agents. Workflow, critical rules, testing, Pascal code style, formatting, build/run reference, documentation index. If it affects what may be merged, it belongs there.
This file (AGENTS.md / CLAUDE.md) Agent-only context: how assistants should operate in this repo, where to read first, and what not to duplicate. It does not replace CONTRIBUTING.

Assistants should treat CONTRIBUTING as authoritative for contribution requirements. Use this file for assistant-specific expectations and navigation, not a second copy of CONTRIBUTING.

Expectations for assistants

  • Read CONTRIBUTING.md before substantive edits—especially Critical rules and Code style.
  • Run verification yourself when the environment allows (tests, format check); do not only tell the human what to run unless execution is impossible.
  • Match the project's workflow: branch from main, focused diffs, tests and docs updated per CONTRIBUTING.
  • Treat project-local skills as external playbooks: files under .agents/skills/ are not normal repo documentation. Do not edit them unless the user explicitly asks to change that skill. Put repo-specific assistant expectations in this file, or create/update a separate skill only when explicitly requested.
  • Infer architecture boundaries during planning: when a change touches website routes, API handlers, generated reports, external services, credentials, artifacts, caches, CI outputs, or deployment/build steps, identify where the work belongs (build time, request time, client time, CI/scheduled time) and compare against existing project patterns before implementing. Do not rely on the user or a skill checklist to spell this out.
  • Search the real source layout: when prompts, automations, or audits search this repo, target source/units, source/shared, source/app, tests, scripts, and website/src explicitly. Do not assume a generic root src/ tree; source/generated is generated data and should only be inspected or regenerated when the task specifically requires it.
  • Do source deep-dives before policy claims: when a question asks how a runtime, standard, engine, or dependency behaves, treat README text, docs, comments, and prior notes as leads—not proof. Check the normative source first when there is one (for ECMAScript, ECMA-262/ECMA-402), then inspect the actual implementation paths in this repo and in any comparison engines or libraries named in the question. Record the specific clauses, files, gates/flags, and code paths that support the conclusion before recommending policy, scope, or architecture. If the answer depends on whether behavior is shim-level, parser-level, runtime-level, or object-model-level, classify each surface by the mechanism it actually needs.
  • Clean first for stale FPC failures: after a merge, branch switch, PR sync, generated resource change, or unexplained compiler/resource error, retry with ./build.pas --clean <target> (or ./build.pas --clean) before diagnosing the reported source line. See Tooling — Stale FPC Build Artifacts.
  • Do not paste large chunks of CONTRIBUTING into this file when CONTRIBUTING changes—edit CONTRIBUTING instead, and keep AGENTS short.

TC39 spec lookup

For ECMAScript or ECMA-402 behavior, use the project TC39 MCP server before falling back to web sources or large spec HTML files. The canonical project MCP config lives under .agents/mcp/, with client-facing links/adapters for supported tools. The shared JSON shape is:

{
  "mcpServers": {
    "tc39": {
      "command": "npx",
      "args": ["-y", "tc39-mcp@0.6.2"]
    }
  }
}

Use spec.search when you do not know the clause id, clause.get when you do, spec.crossrefs to follow abstract-operation dependencies, spec.diff / spec.history for prose drift, test262.search and test262.get to map clauses to conformance tests, and proposal.list / proposal.get for proposal-stage features. When making durable claims in code review, issues, or PR notes, record the spec, edition, clause id, section number, and snapshot SHA when the MCP response provides one. If tc39-mcp is unavailable, fall back to the official TC39 sources (tc39.es/ecma262, tc39.es/ecma402) rather than guessing.

Quick checks

./build.pas testrunner && ./build/GocciaTestRunner tests && ./build/GocciaTestRunner tests --mode=bytecode  # after substantive changes
./build.pas bundler && ./build/GocciaBundler example.js  # build and run the bundler
./format.pas --check # before push / PR

Quick reference

The authoritative command reference lives in Build System. Use that file for build targets, CLI options, configuration-file behavior, GocciaScriptLoader, GocciaTestRunner, GocciaBenchmarkRunner, and GocciaBundler examples. Keep this file agent-only; do not duplicate build or runtime command lists here.

Where to go next