GocciaScript AGENTS.md

Repository instructions for GocciaScript, a programming language project, aimed at AI coding assistants. They explain which contribution guide to read, how to follow project conventions, and which checks to run.

In plain words
What is it for?
They are for navigating the project, reading its contribution requirements, following its code style, and verifying edits with tests or formatting checks.
Why use it?
They help an assistant make changes that match the repository’s rules instead of relying on generic coding habits.

Instructions file for CodexOpenCode

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add instructions/frostney/gocciascript/agents-md
Clone the repo
git clone --depth 1 https://github.com/frostney/GocciaScript

Made for: Codex, OpenCode.

Per session 1,341 This file is loaded in full into every session.
When invoked 1,341 The same file — it is already loaded in full.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.01341 $0.01341
Opus 5 $0.00671 $0.00671
Sonnet 5 $0.00268 $0.00268
Haiku 4.5 $0.00134 $0.00134

Measured 2d ago against content hash 528ba8375535, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

GocciaScript AGENTS.md scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

AGENTS.md · 67 lines

How it starts

The opening of the file, as written. The whole thing — 67 lines — stays where its author put it; the contents beside it link to each section on GitHub.

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.

Read the full file on GitHub · 67 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. 2d ago First seen · 67 lines · 1,341 tokens per session scan A 528ba8375535

Subscribe to this mod's changes

GocciaScript AGENTS.md is an instructions file published in the GitHub repository frostney/GocciaScript (20 stars, last pushed 6d ago), licensed MIT. It adds 1,341 tokens to every session, about $0.0067 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.