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

SCORING_RUBRIC.mdskills/prompt-loop/templates/

Prompt Scoring Rubric

Score every prompt revision against exactly these five dimensions. Each dimension is scored 0, 1, or 2 using the written anchors below; the total ranges 0–10. The rubric exists so two scoring runs over the same prompt land in the same neighborhood — score against the anchors, not against intuition.

Evidence requirement: any dimension scored above 0 MUST cite quoted evidence — a verbatim excerpt from the prompt revision that justifies the score. No quote, no points: if you cannot quote the prompt to support a 1 or a 2, the dimension scores 0.

Dimensions

1. Objective clarity

What the user wants to exist or happen, stated unambiguously.

  • 0 — No identifiable objective, or several conflicting ones; a reader could not say what "done" produces.
  • 1 — An objective is present but vague, compound, or open to more than one reasonable interpretation.
  • 2 — A single, concrete objective a reader can restate in one sentence without guessing.

2. Scope boundaries

What is in and what is out.

  • 0 — No boundaries at all; the request could absorb any amount of adjacent work.
  • 1 — Some boundaries stated, but the edges are fuzzy: it is unclear whether obvious neighboring concerns are included.
  • 2 — Explicit in/out boundaries; for the obvious adjacent concerns the prompt says whether they are included or excluded.

3. Verifiability of outcomes

Whether success can be checked mechanically or by observation.

  • 0 — Success is entirely subjective ("make it better", "clean it up") with no observable acceptance signal.
  • 1 — Some outcomes are checkable, but key ones rest on unstated expectations.
  • 2 — Every stated outcome maps to something checkable: a behavior to observe, a test to pass, an artifact to inspect.

4. Completeness of constraints and edge cases

The limits the solution must respect and the awkward inputs it must survive.

  • 0 — No constraints or edge cases mentioned where the domain plainly has them.
  • 1 — The main constraints are present but known edge cases, failure modes, or environmental limits are unaddressed.
  • 2 — Constraints and the domain's foreseeable edge cases are stated, or explicitly delegated ("agent's choice") by the user.

5. Absence of invented or assumed facts

Whether acting on the prompt requires making things up.

  • 0 — Acting on the prompt requires inventing multiple material facts (names, formats, integrations, data shapes) the user never gave.
  • 1 — Mostly grounded, but at least one material detail would have to be assumed or defaulted without user confirmation.
  • 2 — Everything needed is either stated by the user, marked n/a, or already captured as an open question — nothing must be invented.

Decision tree

Total the five dimensions and act on the band:

  • 9–10 — proceed: exit refinement and produce the output contract (REFINED_PROMPT.md). If this is the first round, skip the interview and rewrite phases entirely.
  • 6–8 — targeted questions: run the interview phase with questions derived only from the dimensions that scored below 2; then lock, rewrite, and re-score.
  • 0–5 — broad re-elicitation: the prompt is not a workable starting point; re-elicit the request broadly (objective first, then scope), one question at a time, before attempting another rewrite.

The loop stops mechanically at total ≥ 9 or when the round cap (default 5) is reached; on cap-out, report the dimensions still below 2 and why, and ask the user whether to proceed anyway or abort.

skills

README.md

tile.json