System Prompts
Author or tighten system prompts, tool docs, and agent definitions using project tag conventions and RFC 2119 normative language.
Overview
system-prompts is a journey-wide agent skill that writes and refines system prompts, tool docs, and agent definitions using authoritative tags and RFC 2119 normative keywords—usable whenever a solo builder needs to lock
Install
npx skills add https://github.com/can1357/oh-my-pi --skill system-promptsWhat is this skill?
- Defines a fixed tag vocabulary (e.g. system-conventions, stakes, critical, workflow) and forbids ornamental tags
- Maps RFC 2119 MUST/NEVER/SHOULD/AVOID to replace vague wording like "always" or "prefer"
- Places <critical> rules at start and end; uses numbered workflow phases from scope through verify
- Anti-shrink completeness and pre-yield checklists so agents do not truncate authoritative instructions
- Dense, imperative house style for any prompt the model reads (system, tools, sub-agents)
- Documented structural tag vocabulary including system-conventions, stakes, critical, completeness, yielding, and workflo
- RFC 2119 normative keyword set (MUST, NEVER, SHOULD, AVOID) with explicit replacements for vague phrasing
Adoption & trust: 1 installs on skills.sh; 11.3k GitHub stars; 3/3 security scanners passed (skills.sh audits); trending (+100% hot-view momentum).
What problem does it solve?
Your agent instructions read like friendly chat guidance, so the model invents tags, softens requirements, and ships incomplete work.
Who is it for?
Solo builders standardizing prompts across skills, tools, and sub-agents in a repo that already uses structural XML-style tags.
Skip if: Teams that only need one-off marketing copy or casual chat personas with no normative agent contract or tool definitions.
When should I use this skill?
Authoring or editing any prompt the model reads, including system prompts, tool docs, and agent definitions.
What do I get? / Deliverables
You get dense, RFC-keyed prompt artifacts with a consistent tag contract and workflow sections that agents treat as literal requirements.
- Revised system prompt with authoritative tags and RFC 2119 keywords
- Tool or agent definition docs matching project house style
Recommended Skills
Journey fit
Useful at every journey phase - explore requirements and options before committing to a direction.
Where it fits
Draft a stakes-and-workflow system prompt before approving an MVP agent scope.
Rewrite tool docs with MUST/NEVER language so the agent stops inventing decorative tags.
Align MCP or API tool descriptions with the same tag contract as the main system prompt.
Add completeness and critical blocks at start and end before launch-review of agent behavior.
Tighten yielding and verify phases after production drift without rewriting the whole stack.
How it compares
Use as a style-and-contract skill for prompt files, not as an MCP server or runtime integration.
Common Questions / FAQ
Who is system-prompts for?
Indie and solo builders who author agent system prompts, tool documentation, or multi-agent definitions and want one enforceable house style.
When should I use system-prompts?
During build agent-tooling when defining agents; during validate scope when drafting spec prompts; during ship review when hardening instructions; and anytime you edit any prompt the model reads.
Is system-prompts safe to install?
It is documentation and authoring guidance only; review the Security Audits panel on this skill page before installing from any third-party repo.
SKILL.md
READMESKILL.md - System Prompts
# System Prompts Project house style. Dense, imperative, RFC-keyed. ## Tags Tags are structural markers — the agent treats them as authoritative and literal. Each tag means exactly what its name says. NEVER invent ornamental tags (`<north-star>`, `<stance>`, `<protocol>`, `<directives>`, `<strengths>`) — they're noise. The vocabulary actually in use: | Tag | Purpose | | --- | --- | | `<system-conventions>` | How to interpret tags + RFC keywords themselves. Defines the contract. | | `<stakes>` | Why correctness matters here. Domain framing. | | `<communication>` | Voice, tone, response shape. | | `<critical>` | Inviolable rules. Place at START and END. | | `<completeness>` | What "done" means. Anti-shrink rules. | | `<yielding>` | Pre-yield checklist. Block conditions. | | `<workflow>` | Numbered phases (scope → edit → decompose → work → verify). | ## Normative Language RFC 2119 in full caps, no bold. The all-caps form IS the marker. | Keyword | Meaning | Replaces | | --- | --- | --- | | MUST / REQUIRED | Absolute requirement | "always", "make sure", "ensure" | | NEVER (= MUST NOT) | Absolute prohibition | "do not", "don't" | | SHOULD / RECOMMENDED | Strong preference; deviation allowed with known tradeoffs | "prefer", "it's best to" | | AVOID (= SHOULD NOT) | Strong discouragement | "try not to" | | MAY / OPTIONAL | Truly optional | "can", "you could" | **Project aliases**: prefer `NEVER` over `MUST NOT` and `AVOID` over `SHOULD NOT`. Both are single-token in cl100k/o200k tokenizers and carry identical authority. State the alias contract once, near the top, inside `<system-conventions>`: > RFC 2119 applies to MUST, REQUIRED, SHOULD, RECOMMENDED, MAY, OPTIONAL. `NEVER` and `AVOID` MUST be interpreted as aliases for `MUST NOT` and `SHOULD NOT` respectively. NEVER convert: factual descriptions (what a tool returns, what a parameter does), code blocks, examples, schema, Handlebars template syntax. ## Density Strip prose to load-bearing tokens. A bullet earns its words by saying something the prior bullet didn't. - One claim per bullet. Sub-clauses that don't change behavior get cut. - Replace "If X, then Y" with `X? Y.` when X is a quick check. - Inline reasoning ("otherwise it duplicates") only when it changes the call; otherwise drop. - The bolded lead names the rule — NEVER restate it in the body. - Symbols beat words: `→`, `=`, `+`/`<`/`-`, `B+1`, `A..B`. - Collapse parallel enumerations: `add → +/<; delete → -; = ONLY when modifying inside.` ``` Bad: - **Never fabricate anchor hashes.** Hashes are 2-letter content fingerprints, not arbitrary suffixes. You cannot increment them, guess the "next" one, or compute them locally. If a needed anchor is not in your last `read` output, issue another `read`. Good: - **NEVER fabricate anchor hashes.** Missing? Re-`read`. Bad: - **Do not replay the line past your range.** For `= A..B`, never end the payload with content that already exists at B+1. Stop the payload at the last line you are actually changing; if you need that next line gone, extend B. Good: - **NEVER replay past your range.** Stop before B+1; extend B if it must go. ``` Target: **5–12 words per tactical bullet.** Reserve longer bullets for genuinely multi-part contracts (parameter semantics, edge enumerations) where each clause carries a distinct constraint. AVOID compressing: factual reference (operator definitions, return formats, schema), worked examples (the example IS the explanation), the first occurrence of a non-obvious term. ## Voice Direct, imperative, second-person. "You MUST", "You NEVER", "You SHOULD". No hedging, no apology, no ceremony. ``` Bad: "You might want to consider using X..." Good: "You SHOULD use X." Bad: "Please note that this is important..." Good: "Cri