CtrlK
BlogDocsLog inGet started
Tessl Logo

spec-driven-development/spec-as-source

Spec-driven development on OpenSpec, with mechanical spec-as-source enforcement: a custom 'spec-as-source' OpenSpec schema adds file-ownership (targets) and test-verification ([@test]) metadata to every capability spec, three scripts (link check, ownership check, manifest build) keep code and specs from drifting apart, plus requirement-gathering, spec-writer, work-review, and a session-handoff skill with a proactive context-warning hook.

68

Quality

85%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Low

Low-risk findings worth noting

Overview
Quality
Evals
Security
Files

SKILL.mdskills/prompt-engineer/

name:
prompt-engineer
description:
Rewrites a confirmed REFINED_PROMPT.md from prompt-loop into an ENGINEERED_PROMPT.md ready to execute: cleaned of reasoning-scripting and shouting, structured into the task contract (objective, context, scope, tools, action boundaries, verification, output, stop condition), every change traced to a numbered prompting rule, the lock register carried byte-identical, and an effort level recommended. Runs in a fresh-context subagent and never asks the user anything. Trigger — automatically after prompt-loop's output contract is confirmed and before openspec-propose, for non-trivial development work; explicitly on: engineer this prompt, ottimizza il prompt, prompt engineering, ingegnerizza il prompt, make this prompt executable. Do not use it on a prompt that has not been through prompt-loop: without a confirmed REFINED_PROMPT.md there is nothing to engineer.

Prompt Engineer

prompt-loop settles what the user wants: it interviews them until every block of the task contract has an answer, and hands back a confirmed REFINED_PROMPT.md. That document is a contract of requirements, written for the user to confirm — not a prompt written for a model to execute. This skill closes the gap: it turns the confirmed contract into a prompt that the complex work downstream (openspec-propose, then implementation) can start from.

It does that by applying a cited rule corpus, references/PROMPTING_RULES.md (R1–R38, gathered from the 2026 Anthropic guidance and converging third-party sources), and nothing else. Its guiding principle comes from that corpus: the prompt defines the contract of the work, not the way to think.

How it runs

  • Only input: the absolute filesystem path of a REFINED_PROMPT.md that prompt-loop produced and the user confirmed. Nothing else is an input — not a summary, not your memory of a discussion.
  • Execution: a fresh-context subagent, launched by the router with that path. The subagent cannot see the parent conversation, and that is the point: the engineering does not need the user, and running it apart keeps the main thread clean. It also means everything you write must come from the file, because the file is all you have.
  • Output: ENGINEERED_PROMPT.md, written in the same directory as the input, instantiated from templates/ENGINEERED_PROMPT.md.

No questions, no invention

This skill MUST NOT ask the user anything and never runs an interview. Every question belongs to prompt-loop, whose coverage gate guarantees that each of the eight blocks — objective, context and source priority, scope, tools policy, action boundaries, verification, output, stop condition — has either the user's answer or the user's own statement that it does not apply. The interview happens once, upstream, with the user present; a subagent that asked would be talking to no one.

So the engineered prompt draws every block from the input only:

  • a block the user declared not applicable is omitted from the prompt — never filled with a plausible default (R3, R18);
  • a block with no covering lock is not yours to repair: the only party who can answer it is on the other side of prompt-loop. Stop, and send the document back to prompt-loop (see Procedure, step 2);
  • Open questions holds only residual tensions found inside covered blocks — two locks that pull in different directions, a verification criterion that the stop condition makes unreachable. Keep both locks verbatim, name the tension, and leave it to the user. Never use Open questions to paper over a block that was never answered.

The lock register is the user's

Every entry of the input's lock register goes into the output's ## Lock register byte-identical — superseded entries included, still struck-through. The engineered prompt may restate a locked decision in the words the block needs, but it must never contradict one. A lock rewritten "for clarity" is a decision overridden without the user, and only a mechanical comparison makes that visible — which is why the checker compares bytes, not meaning.

Procedure

  1. Read the input. Read the file at the path you were given, and only that file (plus this skill's own references/ and templates/). If no path was given, or it is unreadable, stop with a declared error naming the missing input, and write no output file.
  2. Validate it. Run python3 scripts/check_engineered.py --input <REFINED_PROMPT.md>.
    • No lock register → stop with a declared error saying the input lacks its lock register; write nothing.
    • Uncovered blocks → stop with a declared error that names each uncovered block and states that the document must go back to prompt-loop for the user to answer it; write nothing. Only a clean exit lets you continue.
  3. Clean against the checklist. Walk the anti-pattern checklist in references/PROMPTING_RULES.md over the refined prompt. Remove reasoning-scripting (R9), requests to reproduce internal reasoning (R10), and capitalised pressure (R12); replace "be careful / double-check" with observable verification (R11, R25); say a repeated constraint once (R13).
  4. Structure into contract blocks. Lay the content into OBJECTIVE, CONTEXT, SCOPE, TOOLS, ACTION BOUNDARIES, VERIFICATION, OUTPUT, STOP CONDITION (R2), outcome before method (R1), context kept apart from scope (R4), keeping only the blocks the input gives content for (R3). Write it so a colleague who never saw the conversation could act on it (R7, R34).
  5. Log every change with its rule. Each entry of ## Change log says what changed and cites at least one R<n> that exists in the corpus. A change you cannot justify by a numbered rule is taste, and taste is not this skill's job — undo it.
  6. Carry the locks. Copy the input's lock register verbatim into ## Lock register.
  7. Record open questions. Only tensions inside covered blocks; n/a when there is none.
  8. Recommend an effort. Exactly one of low, medium, high, xhigh, max, under ## Recommended effort. Depth of reasoning is a runtime setting, so it is recommended beside the prompt and never written into it (R37).
  9. Run the checker before returning. Run python3 scripts/check_engineered.py <REFINED_PROMPT.md> <ENGINEERED_PROMPT.md>. If it exits non-zero, fix what it names and run it again. An output the checker rejects is never returned.
  10. Return. Report the absolute path of ENGINEERED_PROMPT.md, the checker's result, the recommended effort and any open questions. That document — not the refined prompt — is the input of openspec-propose (or openspec-explore).

What the checker guarantees, and what it does not

scripts/check_engineered.py (stdlib only) enforces what would otherwise be only words: required sections present, locks byte-identical, no listed reasoning-scripting phrase in the prompt section, every change-log entry citing an existing R<n>, effort in the allowed set; with --input, a readable file with a lock register and full coverage. It is a net, not the judge: a paraphrase of a banned formula slips through it, and staying clear of those remains your job under R9–R11.

README.md

tile.json