PromptScript: compiling one .prs source into configuration for 49 AI coding platforms

The drift problem PromptScript is built to remove

A modern AI coding setup is not one file. Claude reads CLAUDE.md and discovers agents and skills under .claude/. Cursor reads .cursor/rules and its own agent definitions. GitHub Copilot reads .github/copilot-instructions.md and prompt files under .github/prompts/. Add MCP server declarations, hooks, workflows and platform-specific settings, and the same engineering standard ends up written four or five times in four or five schemas. The README states the consequence plainly: managing these files by hand creates drift between tools, repositories, and teams. The people who feel this are platform and developer-experience engineers in organisations where more than one assistant is approved, and where a change to review policy has to land everywhere at once. A single-developer repository with one tool does not have this problem, and PromptScript is not aimed at it.

How the compiler turns .prs into target-native files

The pipeline is short and worth stating exactly as the README does: source is resolved for inheritance, imports and policies, then validated for language and capabilities, then compiled into deterministic target-native files. There is no runtime proxy and no shared lowest-common-denominator output; each formatter emits the richest native representation its platform supports. The source language is .prs, a block-oriented format with @-prefixed sections such as @meta, @identity, @standards, @shortcuts, @skills, @mcpServers, @agents, @hooks, @workflows and @plugins. A target list in promptscript.yaml decides what gets emitted, and each target can carry a version, for example github with version multifile or claude with version full. The README shows the resulting file set: .github/copilot-instructions.md, .github/prompts/review.prompt.md, CLAUDE.md, .claude/agents/reviewer.md, .claude/skills/security-review/SKILL.md, .cursor/rules/project.mdc, .cursor/agents/reviewer.md and .opencode/agents/reviewer.md. The claim of 49 supported platforms is a formatter count, and the README points to a target matrix on the project site rather than listing every platform inline. Treat that number as coverage breadth, not as a guarantee that every capability maps to every target.

Installing PromptScript and compiling a first project

The README gives a global npm install as the primary path. After installing, prs init inspects the project stack and the AI tools already present, writes a promptscript.yaml and a .promptscript/project.prs, and preselects the targets it detected. Hooks are installed by default; --no-hooks skips that and --dry-run previews every write.

npm install -g @promptscript/cli

prs init
# Edit .promptscript/project.prs
prs validate --strict
prs compile

For unattended setup the README shows prs init --yes --targets claude factory, which skips the interactive target selection and names the targets directly. If you would rather not install anything locally, the same commands run from a container, and the Dockerfile is a multi-stage Node 24 Alpine build that drops npm from the final runtime image.

docker run --rm -v "$(pwd):/workspace" ghcr.io/mrwogu/promptscript:latest validate --strict

The repository also ships a docker-compose.yaml with a prs service for one-off commands and a watch service that runs compile --watch in the foreground, which is the closest thing to a continuous loop the project documents. A browser playground exists for compiling without any local install. A minimal promptscript.yaml, taken from the README, looks like this.

id: checkout-service
syntax: '1.5.0'

input:
  entry: .promptscript/project.prs

targets:
  - github:
      version: multifile
  - claude:
      version: full
  - cursor:
      version: full

After prs compile, expect the generated files to appear at the paths listed above. The source itself is a set of named blocks, so a shortcut, a skill and an agent are declared once and referenced by name.

@agents {
  reviewer: {
    description: "Review changes before merge"
    tools: ["Read", "Grep", "Glob", "Bash"]
    skills: ["security-review"]
    mcpServers: ["issue-tracker"]
    content: "Review changed code, tests, and operational impact."
  }
}

That agent block is the unit that fans out: the formatter decides whether the reviewer agent becomes .claude/agents/reviewer.md, .cursor/agents/reviewer.md or .opencode/agents/reviewer.md.

Where the abstraction leaks and where it is the wrong tool

Capability coverage is uneven by design. The README's own words are that each formatter emits the richest native representation its platform supports, which means a capability you declare in .prs may have no equivalent on a given target and will simply not be emitted there. The README describes validation of language and capabilities, but it does not document, in the portion available, how a silently dropped capability is surfaced to you. That is the failure mode to design around: you edit the source, compile succeeds, and one platform quietly receives less than you expected. The second constraint is the build step itself. Generated files live in the repository and must be regenerated after every source edit, so a developer who edits CLAUDE.md directly will have that change overwritten on the next compile. Teams that treat generated files as hand-editable will fight the tool. Third, the project is a compiler, not a runtime: nothing here intercepts prompts at execution time, so it cannot enforce policy on a tool that ignores its configuration. Finally, if you use exactly one assistant, the source language, the compile step and the generated artifacts are overhead with no offsetting benefit.

PromptScript compared with a shared instructions file

The obvious alternative is a single AGENTS.md or CLAUDE.md checked into the repository root and symlinked or copied to the other tools. That approach is genuinely simpler: no dependency, no compiler, no generated tree, and any engineer can read it without learning a syntax. The difference in approach is where the platform knowledge lives. A shared markdown file puts the burden on each developer to know which tool reads which path and which schema, and it cannot express an agent definition with a tool allowlist, an MCP server declaration or a hook event in a way that survives translation. PromptScript moves that knowledge into formatters maintained in the project, at the cost of a build step and a source language. The honest split: a shared file wins when your configuration is prose and a handful of rules; PromptScript wins when you are declaring agents, skills, MCP servers and hooks that have to exist in native form on more than one platform.

Maintenance, upgrade cost and the MIT licence

The repository is not archived and the last push was on 2026-09-14, so it is under current development. Releases are frequent: v1.18.1 on 2026-08-17, v1.18.0 the day before, and v1.17.1 on 2026-08-12. That cadence is good for fixes and a cost for adopters, because formatter output can shift between minor versions and your generated files are committed. The repository carries a promptscript.lock and a .release-please-manifest.json, which suggests the project tracks its own resolved state and automates versioning, but the README available here does not document an upgrade procedure or a rollback path. Verify that yourself before pinning a version in CI. The licence is MIT, which permits commercial and closed-source use and modification; the repository ships a LICENSE file. This is not legal advice, and if you redistribute the CLI inside a product you should read the licence text and your own obligations rather than relying on this summary.

Editorial conclusion

Adopt PromptScript if several AI coding assistants are already in use across your repositories and the same standards keep diverging between them; the compiler, the strict validator and the lockfile are the parts that carry that weight. Do not adopt it if you use one assistant and one instruction file, because you would take on a source language, a compile step and generated files that must be regenerated after every edit. Before committing, run prs validate --strict on your real source, compile once and inspect the generated CLAUDE.md and .cursor/rules output to confirm the formatters emit what your tools actually read, and check whether the repository's own .promptscript/ directory and promptscript.lock fit how your team reviews changes.

Frequently asked questions

Official sources

1. License: MIT
2. mrwogu/promptscript on GitHub
3. Project website
4. README
5. Releases