Tessl SDD Tile — Prompt Files
Excerpt 1: requirement-gathering SKILL.md — Interview Protocol
## Steps
1. **Review existing specs.** Scan the `specs/` directory for any specs related to the request.
Note what's already documented and what's missing.
2. **Identify gaps.** List the ambiguous or underspecified areas:
- Unclear scope boundaries (what's in vs. out)
- Missing edge cases or error handling expectations
- Unspecified behavior for boundary conditions
3. **Interview the stakeholder.** Ask ONE question at a time. Wait for the answer before asking
the next question. Prioritize questions by impact — ask about scope and core behavior first,
edge cases second.
Good questions are specific and bounded:
- "Should the API return a 404 or an empty list when no results match?"
- "Is this endpoint authenticated, and if so, which roles have access?"
Bad questions are open-ended or bundled:
- "What should the API do?" (too vague)
- "What about errors, pagination, auth, and rate limits?" (too many at once)
Technique: Structured elicitation with anti-pattern examples — the skill includes explicit examples of good and bad questions, teaching the agent both what to do and what to avoid. The "bad questions" examples prevent common AI failure modes (open-ended fishing, question bundling).
Excerpt 2: spec-before-code Rule (verbatim)
---
alwaysApply: true
---
# Spec Before Code
Never begin implementation without an approved spec.
## What counts as approval
- Stakeholder says the spec is accurate (e.g., "looks good", "yes", "approved")
- Stakeholder makes corrections and then confirms the updated version
## What does NOT count as approval
- Silence or no response
- "Just do it" without reviewing the spec
- Your own judgment that the spec is probably fine
## Exceptions
- Trivial changes (typo fixes, formatting) that don't alter behavior
- Emergency hotfixes — but a spec must be written retroactively
Technique: Negative definition — the rule explicitly defines what does NOT count as approval, preventing the common agent failure mode of interpreting silence or "just do it" as permission to proceed.
Excerpt 3: spec-verification SKILL.md — Drift Detection Steps
4. **Spot-check targets for drift.** Read the files listed in `targets:` and compare against spec requirements:
- For each requirement in the spec, confirm the target file implements it
- Look for logic in target files that contradicts the spec
- Look for new behavior in target files not mentioned in any spec
5. **Check for drift signals:**
- Behavioral changes in code not mentioned in the spec
- Newly added tests without matching requirements
- Deleted or renamed files that still appear in `targets:` or `[@test]` links
Technique: Drift signal taxonomy — defines specific categories of drift to look for, transforming a vague "check if code matches spec" into a structured checklist of observable signals.
Prompting Techniques Summary
- Structured elicitation with anti-patterns — good/bad question examples in requirement-gathering
- Negative definition — "what does NOT count" in approval gate
- Drift signal taxonomy — specific observable signals for spec drift
alwaysApply: true — frontmatter rule that fires on every interaction[@test] link syntax — inline spec-to-test traceability in .spec.md format