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 skills add nonlinear-xyz/factory-kit --skill factory-promptinggit clone --depth 1 https://github.com/nonlinear-xyz/factory-kitWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/nonlinear-xyz/factory-kit/factory-prompting)<a href="https://agentmods.dev/skills/nonlinear-xyz/factory-kit/factory-prompting"><img src="https://agentmods.dev/badge/skills/nonlinear-xyz/factory-kit/factory-prompting.svg" alt="Measured on agentmods" height="20"></a>What 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.1 | $0.00093 | $0.02847 |
| Opus 5 | $0.00046 | $0.01424 |
| Sonnet 5 | $0.00019 | $0.00569 |
| Haiku 4.5 | $0.00009 | $0.00285 |
Grade A, and why
factory-prompting scanned grade A with 0 findings 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 8d 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.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 207 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Factory prompting
Each section leads with Principle (one sentence, model-agnostic), then Why (the constraint and the tradeoff), then Recipe (the canonical shape), and Failure mode when there's one to name. This skill governs how to author prompts; it doesn't tell you what to ask for.
Why tags at all
Principle. XML tags are unambiguous delimiters. They tell the model what role each chunk plays without relying on prose cues.
Why. A bare prompt mixes roles: "Summarize these meeting notes (the meeting was with our vendor about Q3) — bullet points, max 150 words. Notes: …" The model has to infer which sentence is the ask, which is background, which is the material to operate on, and which is the output shape. It usually guesses right; under load, with long inputs, or with conflicting cues, it sometimes guesses wrong. Tags collapse the guess. <instructions> is the ask. <input> is the material. <output_format> is the shape. Each chunk has a labelled role, parseable independently.
The deeper reason: tags are positional-independent. You can reorder context and input without rewriting transition prose. Templates compose. Variable substitution stays clean.
Tradeoff. Tags add visual noise on short prompts. A one-line ask wrapped in five tags is worse, not better — that's decoration, not structure (see failure modes). Reach for tags when ambiguity is real, not as ritual.
The vocabulary — small, named by role
Principle. A canonical set of ~8 tag names, each mapping to a role that genuinely differs in kind. Reuse the vocabulary across prompts; don't invent new tags per task.
Why. The same discipline that keeps a design token system legible (see factory-design.md) keeps a prompt template system legible. Ten roles you know cold beats fifty roles you have to read each time. Every prompt in the system should feel like the same product.
The set.
| Tag | Role | Use when |
|---|---|---|
<instructions> |
The literal ask — what the model should do | Always, unless the ask is the only thing in the prompt |
<context> |
Background that informs the task but isn't the material to operate on | The model needs to know why or for whom |
<input> |
The literal material to operate on (notes, email, transcript, code, query) | There's a thing to read/transform/answer |
<output_format> |
Shape and constraints of the response | The output needs structure (length, schema, tone, format) |
<examples> (nests <example>) |
Few-shot demonstrations of input → output | The task is fuzzy and one good example beats a paragraph of description |
<constraints> |
Hard rules (length caps, exclusions, must-include, forbidden phrasings) | A rule is binary, not advisory |
<role> |
Persona / domain stance | The voice or expertise frame genuinely changes the answer |
<thinking> |
Steer explicit reasoning before the answer | You want the model to lay out steps before committing to output |
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.
- 8d ago First seen · 207 lines · 93 tokens per session scan A 5b86ae54501f
factory-prompting is a skill published in the GitHub repository nonlinear-xyz/factory-kit (9 stars, last pushed 1mo ago), licensed MIT. It adds 93 tokens to every session and 2,847 once invoked, about $0.0005 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
prompt-sensei
Stage-aware prompt coaching, prompt improvement, lookback analysis, prompting habit feedback, and local reports about prompt quality for AI coding agents such as Claude Code or Codex.
kanso-prompting
Use when rewriting, sharpening, or producing a prompt for Claude or another current frontier model. Sets standing rules for getting better LLM output through better prompts. Loaded by /kanso-task; not directly invoked by the user.
cost-aware-llm-pipeline
A planning guide for choosing language models and managing the amount of conversation context used by an AI coding workflow. It groups tasks by complexity and gives rules for avoiding context overflow during long sessions.
llm-patterns
AI-first application patterns, LLM testing, prompt management.
813-regulations-iso-42001
Use when reviewing, designing, or modifying Java enterprise systems that use GenAI, LLMs, AI-assisted coding, RAG, AI agents, generated code, generated dependencies, prompt workflows, external model providers, or AI-enabled business logic and need ISO/IEC 42001 AI management system-aware engineering guidance. Part of…
prompt-engineering
Universal prompt engineering techniques for any LLM. Use when crafting, optimizing, or reviewing prompts for AI models. Triggers on requests like "improve this prompt", "write a system prompt", "optimize my instructions", "help me prompt engineer", "audit this prompt", "review my prompt", or when building agentic…