• Outcome fits in one sentence.
• Success is checkable without judgment words.
• No time-relative phrases; versions pinned.
• Exactly one goal.
• Hard bounds stated (what not to do).
• Output format is explicit.

Context (inputs):

• Domain, data, versions, prior artifacts

Task (one goal):

• Imperative verb + object; ≤ 20 words

Constraints (bounds):

• Limits: libs, length, time, style bans, forbidden actions

Format (output spec):

• Target schema / sections / filenames

Verify (hooks):

• Tiny test input; counts/schema; what to run/compare

Before (bad): “Help me write a script to process some data files and make them more efficient.”

After (KERNEL):

Context: CSV folder with identical columns
Task: Write Python to merge all CSVs into one
Constraints: Pandas only; ≤ 50 lines; no external I/O libs
Format: single file merge.py that writes merged.csv; print row count
Verify: run on ./test_data to produce merged.csv with N rows

• Multi-goal prompts (code+docs+tests in one).
• Vague quality targets (“engaging”, “solid”).
• “Latest/best practices” without version pins.

Does KERNEL reduce creativity? No; it constrains the contract, not the solution space.
Model-specific? No; it’s a spec discipline.

Source:
Team examples:
Related molecules: Prompt evaluation, Prompt chaining