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.
npx agentmods add instructions/sap-samples/hana-developer-cli-tool-example/package-json-scriptsgit clone --depth 1 https://github.com/SAP-samples/hana-developer-cli-tool-exampleWhat 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.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.04985 | $0.04985 |
| Opus 5 | $0.02492 | $0.02492 |
| Sonnet 5 | $0.00997 | $0.00997 |
| Haiku 4.5 | $0.00498 | $0.00498 |
Grade C, and why
hana-developer-cli-tool-example package-json-scripts.instructions.md scanned grade C with 1 finding 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.
Recursive force deletehighDestructive command
rm -rf with a variable or a broad path is one typo away from removing the wrong tree.
"clean": "rm -rf dist coverage", // Fails on Windows How it starts
The opening of the file, as written. The whole thing — 703 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Package.json Scripts Management Guidelines
Use this guide when creating or modifying npm scripts in package.json.
Scope and Purpose
This guide applies to npm script management in:
- Root
package.json- Main project scripts - Subproject
package.jsonfiles (e.g.,mcp-server/package.json) - Workspace package.json files in monorepos
Critical Principles
- Naming Convention: Use consistent, predictable script names
- Category Prefixes: Group related scripts with prefixes (
test:*,build:*,docs:*) - Cross-Platform: Write scripts that work on Windows, macOS, and Linux
- Composability: Build complex scripts from simpler ones
- Lifecycle Hooks: Use npm lifecycle scripts appropriately
- Environment Variables: Handle variables safely and consistently
- Documentation: Add comments in package.json for complex scripts
- Exit Codes: Respect exit codes for CI/CD integration
Script Naming Conventions
Pattern: Standard Script Names
{
"scripts": {
// Development
"start": "node index.js", // Primary entry point
"dev": "nodemon index.js", // Development with watch
"serve": "node server.js", // Start server
// Building
"build": "tsc", // Main build
"build:watch": "tsc --watch", // Watch mode
"prebuild": "npm run clean", // Runs before build
"postbuild": "npm run types", // Runs after build
// Testing
"test": "mocha", // Run all tests
"test:unit": "mocha tests/unit", // Unit tests only
"test:integration": "mocha tests/integration",
"test:watch": "mocha --watch", // Watch mode
"pretest": "npm run lint", // Runs before test
// Code Quality
"lint": "eslint .", // Lint all files
"lint:fix": "eslint . --fix", // Auto-fix
"format": "prettier --write .", // Format code
"format:check": "prettier --check .",
// Coverage
"coverage": "nyc npm test", // Generate coverage
"coverage:report": "nyc report --reporter=html",
"coverage:check": "nyc check-coverage",
// Documentation
"docs": "npm run docs:dev", // Alias for main docs task
"docs:dev": "vitepress dev docs",
"docs:build": "vitepress build docs",
"docs:preview": "vitepress preview docs",
// Cleaning
"clean": "rimraf dist coverage .nyc_output types",
"clean:all": "npm run clean && rimraf node_modules",
// Utilities
"validate": "npm run lint && npm run test",
"prepare": "husky install" // Lifecycle hook
}
}
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.
- 2d ago First seen · 703 lines · 4,985 tokens per session scan C f122e58a21df
hana-developer-cli-tool-example package-json-scripts.instructions.md is an instructions file published in the GitHub repository SAP-samples/hana-developer-cli-tool-example (109 stars, last pushed 7d ago), licensed Apache-2.0. It adds 4,985 tokens to every session, about $0.0249 per session on Opus 5. A static security scan graded it C with 1 finding (recursive force delete). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other instructions, from other repositories
rtk CLAUDE.md
Claude Code instructions for rtk-ai/rtk, covering claude.md, project overview, name collision warning, development commands and build & run.
rtk copilot-instructions.md
Copilot instructions for rtk-ai/rtk, covering copilot instructions for rtk, using rtk in this session, instead of: use, build, test & lint and pre-commit gate (must all pass before any pr).
awesome-vscode CLAUDE.md
Instructions for viatsko/awesome-vscode, covering claude.md, what this repo is, adding an entry, themes and linting / ci.
vscode-peacock AGENTS.md
Instructions for johnpapa/vscode-peacock, covering peacock — agent guide, project overview, repository structure, tech stack and build & run.
cs CLAUDE.md
Instructions for boyter/cs, covering claude.md, project overview, build & test commands, architecture and query pipeline (pkg/search/).
docs-mcp-server AGENTS.md
Instructions for arabold/docs-mcp-server, covering agent instructions for docs-mcp-server, repository context, development workflow, key commands and git workflow.