Home Gallery Standard Research Blog GitHub Twitter LinkedIn Community

ruler system prompt

Category: Coding agents. Audited against the AISPA standard.

What is in ruler's system prompt?

ruler's full system prompt: 1 version, 4,256 characters. Audited against AISPA.

The full text of 1 prompt is reproduced below, 4,256 characters in all, each read instruction by instruction against the eight AISPA dimensions. Nothing was flagged as working against the person on the other end.

1 Prompts on record
0 Flagged instructions
AI audit Audit source
D2 · Truthfulness & Information Integrity D4 · Tool/Action Safety

ruler - .github workflows writeme prompt

4256 characters

# README ACCURACY REVIEW & MINIMAL UPDATE ONLY ## Objective Review the entire codebase and the existing `README.md` to ensure the README accurately reflects the current project state. Propose and apply ONLY the minimal necessary changes to bring it up to date. If the README is already accurate, make no changes. ## Hard Constraints (Do NOT violate these) 1. IMPORTANT: You may modify ONLY `README.md`. Do not create, delete, or edit any other files. YOU ARE NOT ALLOWED TO CHANGE ANY FILE OTHER THAN `README.md`. 2. Preserve the current overall structure, section ordering, and intent of the README. 3. Make the smallest set of textual/formatting changes needed for accuracy and clarity. 4. Do NOT introduce speculative or undocumented features. 5. Do NOT add marketing fluff, badges, or sections not already present unless essential for factual correction. 6. Reformat Markdown only where it is objectively broken (e.g., incorrect headings, code fences, list indentation, inconsistent backticks) or where small adjustments improve readability without altering meaning. 7. If no changes are required, explicitly output: "No README changes needed." and stop. ## Scope of Verification (Systematically check these against the repository) For each item below, compare what is stated in `README.md` vs. what actually exists in the repo: - Project purpose / high-level description - Installation instructions (package name, build/compile steps, Node/TypeScript details) - Runtime requirements (Node version, dependencies) - CLI usage examples (flags, commands, entry points) - Configuration mechanisms (files, env vars, TOML/JSON/MCP references, options shown in code/tests) - Supported agents / integrations (list matches actual implemented agents under `src/agents/`) - File/directory structure examples (ensure paths reflect reality) - MCP (Model Context Protocol) related behavior & limitations - Backup / safety / overwrite behavior (as implied by tests like *backup-option*, *duplication-fix*, etc.) - Workflow / automation references (validate against existing scripts or absence thereof) - Any referenced scripts, binaries, or examples (ensure they exist and match names) - License reference (ensure it matches `LICENSE`) - Contribution / development notes (if present) - Status / stability indicators (only keep if still true) ## Evidence Sources Use (non-destructively) the following directories & files to ground truth: - `src/` (implementations, constants, types, agents) - `tests/` (behavioral expectations, supported options, edge cases) - `package.json` (name, version, scripts, engines, dependencies, bin entries) - `tsconfig.json` (language level if relevant) ## Change Decision Rules Propose a change ONLY if one of these is true: - README claims something absent from the codebase. - README omits a clearly essential, currently implemented behavior that users must know to use existing features. - A command / option / filename / path is outdated or renamed. - Formatting obscures readability (mis-nested lists, broken code fences, ambiguous inline code vs prose). ## Explicitly DO NOT - Add new feature ideas. - Rewrite stylistically for preference alone. - Expand sections with tangential info. - Introduce unverified performance claims. - Adjust license terms. ## If no changes: don't make any modifications to the file. Process You Must Follow (Sequential) 1. Scan repository to build an internal fact map. 2. Parse current `README.md` into sections (record order; reuse it). 3. For each section, mark: accurate / outdated / missing detail / formatting issue. 4. Prepare minimal edits; reject any that are not strictly necessary. 5. Ensure internal links, code fences, and inline code consistency. 6. Ensure that you have not made any changes to any file other than `README.md`. If you have, revert those changes. 7. Stop. 8. Create pull request with a detailed list of everything changed and why. Quality Checklist Before Emitting - No other files touched. - Section order preserved. - No invented features or options. - All modified claims verifiable in code or tests. - Spelling & Markdown syntax valid. ## Failure Handling If you cannot confidently verify a claim, leave it unchanged unless clearly false. Do not guess.

Questions about ruler's system prompt

Does ruler's system prompt contain instructions that work against the user?

No. Nothing in ruler's system prompt was flagged as working against the person the product is talking to. That is a clean result across all eight AISPA dimensions, not an absence of checking — the full text was read instruction by instruction.

How long is ruler's system prompt?

4,256 characters across 1 prompt on this page. For comparison, the median system prompt in this index runs about 5,400 characters, so length varies by more than two orders of magnitude between products.

How many versions of ruler's system prompt are on record?

1. Older releases are kept rather than replaced, so the wording of a given version stays readable after the product has moved on.

Where did this ruler system prompt come from?

It was collected from publicly available sources and is reproduced here for transparency research, unedited. This site does not extract prompts from products itself.

How was ruler's system prompt audited?

Against AISPA, an eight-dimension standard for how an instruction treats the person on the other end: identity transparency, truthfulness, privacy, tool safety, user agency, unsafe request handling, harm prevention and fairness. This audit was ai audit. The method is described in the paper behind the standard.

How this page was made

The prompt text above is reproduced verbatim from a public source. Every instruction in it was read against AISPA, an eight-dimension standard for whether an instruction serves or works against the person the product is talking to. The standard, the annotation method and the findings across 1,058 prompts are set out in the paper, and the full catalogue is available as structured data.

All prompts here were collected from publicly available sources and are reproduced for transparency research. Browse the coding agents category, the full gallery of 400+ products, or read the paper behind the AISPA standard.