CtrlK
BlogDocsLog inGet started
Tessl Logo

spec-driven-devlopment/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.

73

Quality

92%

Does it follow best practices?

Impact

No eval scenarios have been run

SecuritybySnyk

Advisory

Suggest reviewing before use

Overview
Quality
Evals
Security
Files

prompt-loop.mdrules/

prompt-loop

The prompt-loop skill (skills/prompt-loop/SKILL.md) refines an incoming prompt through a bounded score → interview → lock → rewrite cycle until it is mechanically good enough (rubric score ≥ 9/10) to feed the SDD workflow. This rule defines when agents must run it.

Automatic trigger — the SDD threshold

Run the prompt-loop automatically, without the user asking for it, whenever the incoming request is non-trivial development work — a new feature, a new module, a new project, a significant refactor, or any complex or multi-file work. This is the same threshold that mandates spec-driven development itself: if the request is big enough to require a spec, its prompt is big enough to require refinement first.

The loop runs before openspec-propose: no proposal, spec, or implementation work starts until the loop has produced a confirmed output contract (REFINED_PROMPT.md).

Explicit-request trigger — everywhere else

Outside the SDD threshold, run the prompt-loop only on explicit request — when the user says things like "refine this prompt", "prompt loop", "score my prompt", or "is this prompt ready".

Trivial-work exclusions

The prompt-loop does NOT trigger automatically for:

  • trivial bugfixes;
  • one-line tweaks;
  • isolated CSS changes;
  • throwaway scripts;
  • questions or explanations without code.

These are the same exclusions that exempt work from spec-driven development; they are restated here so there is exactly one threshold, not two subtly different ones.

Subsumption of requirement-gathering

When the prompt-loop runs, it subsumes the standalone requirement-gathering step of the SDD workflow: the interview happens inside the loop (one question at a time, wait for the answer), so do not run a separate requirement-gathering interview on top of it. The requirement-gathering skill itself is untouched and remains available outside the loop.

Anti-invention invariant (always on)

At every phase of the loop — and in any intake work around it — information the agent needs but does not have MUST be marked n/a or turned into a question to the user. It must never be invented, assumed, or filled with plausible defaults. This invariant is always active, not merely a property of the skill's phases.

README.md

tile.json