# Prompting > Design, write, review, audit, debug, revise, compress, or test AI-facing instructions, including prompts, repository instructions (AGENTS.md/CLAUDE.md), skills, agent/tool definitions, plans, memory/state/handoffs, and evaluators. Not for reader-facing prose or code comments. - **Type:** Skill - **Install:** `agentstack add skill-anbeeld-prompting-md-prompting` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [Anbeeld](https://agentstack.voostack.com/s/anbeeld) - **Installs:** 0 - **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [Anbeeld](https://github.com/Anbeeld) - **Source:** https://github.com/Anbeeld/PROMPTING.md/tree/main/skills/prompting ## Install ```sh agentstack add skill-anbeeld-prompting-md-prompting ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # PROMPTING.md ruleset Instructions for designing, writing, reviewing, and testing documents whose operational reader is an AI model. Apply this standard to system and developer prompts, task prompts, repository instructions, skills, agent profiles, tool descriptions, plans, specifications, memory and state documents, evaluators, and other AI-facing control text. Select the rules relevant to the artifact and deployment, using the surface overlays in section 20. Do not apply this standard mechanically to ordinary reader-facing prose. Follow the current specification of the target product for syntax, loading, precedence, tools, and runtime behavior. Evaluate each deployed artifact in its target configuration. ## Priorities When requirements conflict, lower-numbered priorities win: 1. Correct authority, authorization, safety, privacy, and truth boundaries 2. Correct target behavior and factual grounding 3. Observable success and valid evaluation 4. Complete coverage of material routes, exceptions, and failure paths 5. Minimum sufficient control and context 6. Human reviewability, portability, cost, and style Do not average a critical boundary failure into an otherwise good score. A prompt that is cheaper or more accurate on common cases is not better if it introduces a false permission for a high-impact action. ## Normative vocabulary Use these semantic classes: - Invariant: cannot be waived at this layer. Use `Invariant:` when this class is not already explicit from an authoritative interface. Wording intensity, including `must`, `must not`, and `never`, does not by itself establish non-waivability. Enforce the invariant outside prose where the runtime allows. - Requirement: binding within its stated scope. An unqualified direct imperative, `do not`, `must`, `must not`, or `never` expresses a requirement unless an explicit semantic label assigns another class. A requirement yields only to a higher priority, higher authority, or a named exception. Evidence can justify authorized revision or retirement; it does not waive the active requirement during execution. - Ask-first boundary: requires approval from a named actor before a named action. Use `Ask first:` or `Approval required from before ` when the class is not already explicit. State the action, impact, approving actor, and allowed fallback when approval is unavailable. - Default: applies unless its named exception or an authorized higher-priority instruction overrides it. Use `Default:`, `by default`, `default to`, or `prefer`, and state the escape condition. - Guideline: informs judgment without binding every case. Use `Guideline:`, `should`, `consider`, `may`, or `can`, and keep the relevant tradeoff visible. - Runtime fact: records a verified mechanism from which policy follows. Use `Runtime fact:` when the statement could be mistaken for policy, and keep its product, harness, scope, or version next to it. - Exposition: supplies rationale or an example without creating an action. Use `Rationale:` or `Example:` when the role is not clear from structure. `When`, `if`, `unless`, and equivalent conditions limit whichever class follows. If two reasonable readers could assign different force to a statement, add the semantic label instead of relying on tone or emphasis. Invariant: Do not present a hypothesis as an established result until evidence meets its explicit promotion criterion. These classes also govern this standard's own statements: its directives are requirements unless labeled otherwise, and the Priorities section resolves conflicts among them. ## Core rule Treat prompting as configuration engineering, not wordsmithing. Behavior belongs to a configured system: ```text behavior = f(model, harness, authority, rendered messages, placement, selected context, tools, permissions, state, task, parameters) ``` Do not call an instruction effective because it sounds clear, follows a template, contains emphatic language, matches a product guide, or worked once. Preserve the executing configuration and test the behavior the instruction is meant to cause. Distinguish the authored artifact from the input the model receives: ```text representation: source artifact -> templates/imports/parser -> rendered role-tagged messages lifecycle: available -> selected -> loaded -> executed -> checked -> retained ``` The source and rendered input may be identical, but do not assume they are. Evidence for one state does not establish the next. A skill can exist but never be selected. A rule can be loaded but skipped. A tool call can occur without its result being used correctly. A self-audit can report no issue while a later run exposes one. ## Load references The sections not reproduced below live in `references/`. Numbering is the standard's own, so a cross-reference to a section number resolves whether or not that section is loaded. - Read `references/authority-and-trust.md` (section 3) when instructions can conflict, when untrusted content reaches the model, or when deciding who may override, approve, or waive a rule. - Read `references/task-routing.md` (section 4) when one artifact serves neighboring jobs, modes, or branches. - Read `references/state-and-lifecycle.md` (section 5) for long, multi-stage, compacted, or handed-off work. - Read `references/calibration.md` (sections 9 and 14) when choosing degrees of freedom and altitude, or when deciding whether a reason, example, prohibition, emphasis, or checklist earns its place. - Read `references/context-and-density.md` (sections 10 and 11) when selecting what to load, or when added rules coincide with omissions or false activation. - Read `references/input-representation.md` (section 12) when the artifact's markup, formatting, roles, or rendered messages are in question. - Read `references/compression.md` (section 13) before shortening a durable instruction, context packet, handoff, or state record. - Read `references/tools-and-security.md` (sections 15 and 16) when defining tool interfaces, permissions, secrets, privacy, or untrusted-content defenses. - Read `references/evaluation.md` (section 17) when designing behavioral tests, baselines, graders, or comparisons. - Read `references/revision.md` (sections 18 and 19) when running an audit and repair pipeline or revising from an observed failure. - Read `references/anti-rules.md` (section 22) before adopting any prompting convention as a universal law. ## 1. Establish the target configuration Before drafting or materially revising an instruction, identify: 1. Artifact: the prompt, file, description, schema, profile, plan, state packet, or evaluator. 2. Operational reader: the target model, model tier, or supported model range. 3. Harness: the product, message roles, loading and discovery rules, templates, imports, parsing, rendering, precedence, context lifecycle, compaction behavior, tool semantics, and output channels. 4. Representation: the authored source, required interface syntax, exact rendered messages, role placement, answer contract, output parser, and constrained-decoding settings. 5. Authority: who may set, override, waive, approve, or delete each class of instruction. 6. Task population: representative tasks, neighboring non-tasks, edge cases, and adversarial cases. 7. Outcome: observable success, acceptable failure, and prohibited side effects. 8. Runtime resources: selected context, tools, permissions, schemas, storage, and external dependencies. 9. Evaluation: baseline, graders, trials, thresholds, protected slices, instruction density, placement, and regressions. Verify non-inferable runtime facts. Do not invent discovery behavior, precedence, context limits, tool capabilities, persistence, permissions, model settings, or local conventions. If the artifact must work in more than one harness, separate: - a portable semantic core; - harness-specific adapters for syntax, loading, scope, precedence, permissions, and lifecycle. Do not force one file format or local runtime policy into every deployment. A rule derived from a blocking tool call, automatic skill loader, path-scoped file, or particular permission model remains bound to that premise. Ask for missing information only when it would materially change behavior, compatibility, authority, persistence, security, or evaluation. Otherwise state a low-risk assumption and produce the smallest reversible draft. ## 2. Define the behavioral contract before the prose State the governed behavior in operational terms: ```text goal + scope + authority + inputs + routes + actions + outputs + success + failure + stopping ``` For each material requirement, determine: - what event makes it applicable; - which actor must or may act; - which prerequisites must already hold; - which action or decision is required; - which result makes compliance observable; - which exceptions apply; - what happens when information, permission, or capability is missing; - what ends the procedure. Do not start from preferred phrasing. Start from the decision the model must make differently. Separate outcome requirements from process requirements. Specify a process only when order affects correctness, safety, compatibility, auditability, or an external interface. When several safe paths exist, specify the outcome and boundaries and leave the method open. Treat a high-cost safety hazard as sufficient reason for a proactive control. Ordinary behavior rules should respond to an observed failure, a required capability, or a credible pre-mortem hazard. Every rule still needs an observable consequence or a clearly labeled role as rationale, default, or guideline. ## 6. Diagnose the failure before choosing the form Classify the need before adding text. For each observed failure, consider the listed mechanism first. The groups below aid retrieval; they do not make the failure classes mutually exclusive. Knowledge, selection, and judgment: - Missing fact or domain knowledge: use context, a reference, retrieval, or another data source. - Wrong source selected: adjust the trigger, routing description, selection policy, or taxonomy. - Genuine scope overlap: change the architecture rather than rewriting the instruction again. - Ambiguous applicability: define the partition, precedence, non-trigger, and fallback. - Wrong default judgment: use a principle, decision criterion, short rationale, or example. Execution and state: - Skipped action: use an event-bound prerequisite, state transition, hook, or gate. - Wrong-time action: add a state lock, phase transition, or capability boundary. - Repeated question or forgotten choice: record explicit state, source, lock, and reopening rule. Output and authorization: - Generic filler under missing information: define a null path that permits inspection, asking, marking unknown, omission, deferral, or stopping. - Wrong abstraction level: name the audience and target altitude. - Invalid machine structure: use a strict schema, constrained output, parser, and validator. - Semantically invalid output: use a domain validator, test, rubric, or independent evaluator. - Unsafe or unauthorized action: use least privilege, a sandbox, confirmation, or a transaction boundary. Lifecycle, activation, and load: - Late-session omission: use lifecycle hydration, a compact state record, or harness reinjection. - Excessive activation: narrow the trigger, define an explicit non-trigger, or use a softer default. - Context overload: use selection, deduplication, progressive disclosure, or loss-aware compression. - Instruction-density failure: measure the density curve, reconcile rules, or redesign routing and controls. Representation, validation, and maintenance: - Source/render mismatch: inspect templates, imports, parsing, role splitting, and exact rendered messages. - Parse success mistaken for task success: score loader, parser, schema, and semantic outcomes separately. - Presentation syntax with no operational job: remove it or run a matched rendered-input ablation. - Stale local policy: recheck the runtime premise, then narrow or remove the policy. - Repeated attempted fix: require new evidence and a root-cause diagnosis, or stop. Do not repair a routing failure by expanding the skill body, a permission failure by adding a warning paragraph, a state failure by rewriting one sentence, or a schema failure by asking the model to be more careful. Group related symptoms before editing. A patch per symptom creates duplicate rules, stale branches, and unclear ownership. Change the smallest coherent mechanism that covers the diagnosed failure. When dependent changes must ship together, label them as one bundle and do not attribute the result to an individual feature without an ablation. ## 7. Match control strength to failure cost Match each requirement to a suitable control: - Goal, judgment, tone, or tradeoff: natural-language guidance. - Auditable action or result: a named operation, artifact, decision, or state transition. - Exact structure or typed input: a schema, constrained output, parser, or typed tool. - Required order: a state machine, wrapper, transaction, or precondition gate. - Access or side-effect boundary: a permission, sandbox, allowlist, or scoped credential. - Irreversible or external action: action-specific human approval and a transaction boundary. - Mandatory validation: a hook, CI rule, validator, or application gate. Choose the weakest control that safely meets the cost of failure. Stronger control adds latency, false refusals, and user friction. Harmless reversible work should not inherit approval rituals designed for destructive or external actions. Do not leave secrets, payments, destructive changes, permission expansion, external messages, production changes, or public publication to prose alone. Remember each mechanism's boundary: - a schema can enforce supported syntax, not truth, authorization, or good judgment; - a valid tool call can still be the wrong tool call; - a hook only guarantees what its trigger, exit behavior, and override rules actually enforce; - a tool trace proves an action occurred, not that its output was interpreted correctly; - a final statement that checks ran is not the check result. Observable prose is useful because it creates a denominator. It is not enforcement. ## 8. Write decidable semantic units Write one canonical statement per requirement. For an action rule, use the fields that matter: ```text actor + trigger + modality + action + object + scope + prerequisite + result + exception/fallback ``` Not every rule needs every field. Every material field in the intended behavior must remain recoverable. Prefer: Before editing a generated file, identify its generator, edit the source, regenerate the output, and compare the generated diff. If the generator is unavailable, stop and report the gap. Avoid: Be careful with generated files. Use one stable term per concept. Name concrete actors, objects, files, fields, operations, states, and owners. Replace vague quality words with criteria that can be assessed. Preserve control operators deliberately: - actor and authority; - `must`, `may`, `must not`, and priority; - negation and quantity; - `if`, `when`, `unless`, `except`, and non-trigger scope; - `before`, `after`, `only once`, and dependency; - exact identifiers, values, units, and thresholds; - observable success; - fallback and stopping behavior. Do not convert `may` to `will`, `some` to `all`, `prefer` to `must`, `after` to `and`, or `not retrieved` to `nonexistent` for cleaner prose. Do not invent numeric thresholds solely to make a rule measurable. Use numbers when they represent a real interface, limit, budget, quorum, or acceptance threshold. A countable proxy can be easier to score while becoming a worse requirement. Put a required action before the event it governs. A late reminder to validate before completion is weaker than validation that must produce a result before … ## Source & license This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [Anbeeld](https://github.com/Anbeeld) - **Source:** [Anbeeld/PROMPTING.md](https://github.com/Anbeeld/PROMPTING.md) - **License:** MIT Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-anbeeld-prompting-md-prompting - Seller: https://agentstack.voostack.com/s/anbeeld - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.