lukas-ther/prompt-skills

improve-prompt

Offline, no-research prompt improvement for explicitly invoked requests.

ソースを見る

使い方

  1. インストールコマンドをコピーし、自分の環境へ導入する前にソースを確認します。
  2. 必要なツール、認証情報、対応環境を原文で確認します。
  3. 入力と成果物を指定し、出力を資料と照合します。
npx skills add https://github.com/lukas-ther/prompt-skills --skill improve-prompt

開始前の確認

  • 導入にはモデル契約、API枠、ファイルへのアクセス許可は含まれません。
  • スター数や導入数は活動の指標であり、独立した品質・安全性試験ではありません。
リポジトリの原文

見出し、例、コード、表、リンク、参照画像を含む原文を表示しています。

Improve Prompt

Turn the user's existing intent into one focused, portable, copy-ready prompt or instruction set. Use only when explicitly invoked; do not activate this workflow merely because an ordinary request could be phrased better.

Non-negotiable boundary

Do not browse, search, fetch URLs, call retrieval tools, or conduct external research. Work only from:

  • the user's request and current conversation;
  • files the user explicitly names or supplies;
  • governing project instructions already provided by the host.

Do not scan the workspace broadly for extra context. If a claim depends on niche, regulated, disputed, or time-sensitive knowledge that the allowed context does not support, make the best safe structural improvement, avoid inventing facts, and recommend explicitly invoking the deep variant through the current host's skill syntax in a note after the prompt.

Workflow

  1. Read references/improvement-method.md completely before transforming the request.
  2. Recover the user's objective, audience, useful context, accepted constraints, desired output, and success criteria.
  3. Infer whether the artifact should be a one-off runnable prompt or persistent project or agent instructions.
  4. If no usable objective can be recovered, ask exactly one concise clarification question and stop. Otherwise continue without requesting approval of an intermediate interpretation.
  5. Apply the shared method. Add domain terms only when supported by allowed context. Select techniques by task fit instead of inserting a fixed checklist.
  6. Self-review for intent preservation, relevance, support, consistency, proportionality, portability, completeness, and output isolation. Do not execute the generated prompt.
  7. Return the complete improved artifact as the first response content in exactly one nesting-safe Markdown code fence. Put any assumptions or deep-mode recommendation after the fence.

Transformation rules

  • Preserve the user's underlying goal and all still-relevant accepted constraints.
  • Reframe the objective when that makes agreement on the intended result more likely; do not expand the project without evidence.
  • Use precise domain vocabulary, but pair jargon with plain language when comprehension may suffer.
  • Add context, delimiters, workflow stages, examples, schemas, verification, uncertainty handling, tool guidance, or stopping conditions only when the task signals a concrete benefit.
  • Ask for concise rationales or verification when useful; never request hidden reasoning or private chain-of-thought.
  • Keep the generated prompt provider-neutral. Do not depend on private syntax, hidden controls, or proprietary model features.
  • Do not introduce unresolved placeholders unless the user explicitly asks for a reusable template.
  • Keep notes, assumptions, citations, and explanations outside the copy-ready fence.
  • When revising from feedback, return a complete replacement fence, not a patch, while retaining previously accepted intent unless the feedback changes it.

Output contract

When the objective is recoverable, begin immediately with the copy-ready block—no title, preamble, or interpretation summary before it. Make the fence delimiter longer than any backtick run inside the artifact, with a minimum of four backticks.

After the block, add a short Notes section only when the user needs to know a material assumption, unsupported knowledge boundary, or recommendation to explicitly invoke the deep variant. Never place required downstream instructions in Notes.