prompt-triwizard

Prompt Triwizard

Writes, refines, and evaluates LLM prompts (system prompts, user prompts, few-shot examples, and tool-call schemas) for agent pipeline nodes — producing high-quality, style-correct output every time.

---

Reuse Within a Session

Once this skill has been loaded, its guidance (structural hierarchy, principles, anti-patterns) stays in the conversation context. When the same prompt needs another modification within the same session (e.g. a re-fix request after testing), continue applying this guidance without re-invoking the skill.

---

Step 1 — Read the Context, Deliver in Kind (Common Step)

Prompts usually live as string literals inside code files (most often .py, but it varies — .ts, Jinja templates, etc.). Locate the prompt first; grep for the prompt text if you're unsure which file holds it.

Read only:

• The target prompt file
• Sibling files holding related prompts (other nodes of the same pipeline)
• Schemas, Pydantic models, or tool definitions the prompt feeds into

Don't read a file just because it shares the directory. Skip .md/.json/.yaml/config unless it's the schema or tool definition the prompt feeds.

Goal: understand the project's existing depth, tag conventions, and schema bindings — this shapes how specialized the new prompt should be.

Deliver in kind: match the file/format the original prompt lived in (most often .py, but it varies — .ts, Jinja templates, etc.); if there's no existing file to match (Mode 1), default to .py — use .ts or Jinja instead only if the project already shows that convention elsewhere. When the prompt takes variables, wrap it as a function call (Python/TS) or a render() call (Jinja) rather than a bare string. Name the system and user pieces — whether a constant or a function — so the literal tokens system_prompt and user_prompt appear in the name (e.g. SYSTEM_PROMPT, build_system_prompt, USER_PROMPT, build_user_prompt).

---

Step 2 — Receive the Style and Language