SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillssdd-prompt-builder

sdd-prompt-builder

Writing & research

View repository

Updated 10-16 01:08

About this skill

Prompt Builder

In the first response of this skill, start with this line, once only: sdd-prompt-builder v1.0.0 · out/2026 · versão atual: https://github.com/robertodiasduarte/sdd-starter/releases/latest

Produce a single operational prompt ready for runtime use. Prioritize the smallest prompt that preserves clarity, output control, recoverability and fidelity to the provided context.

Quick start

  1. Identify the real task and the artifact that the target model must produce.
  2. Read references/prompt-building-rules.md and apply only the sections justified by the task.
  3. If the call comes from SDD, also read references/sdd-integration.md before generating any prompt.
  4. Use references/output-template.md as a flexible skeleton; omit empty or unnecessary sections.
  5. Return only a TXT BLOCK containing the final prompt. Do not wrap the result in TypeScript code, an exported constant or a destination file.

When to use / When not to use

Positive triggers are defined in the frontmatter and must be the source of discovery for the skill.

After the skill is triggered:

  • Do not apply to narrative documentation, READMEs, BRAINSTORM/DEFINE/DESIGN or other texts intended for humans.
  • Do not apply to internal prompts of the orchestration agents of the SDD flow itself.
  • Do not apply to emails, notifications or transactional UI copy.
  • In /build, if drift is detected without a registered LLM Prompts inventory, interrupt direct generation and require the DESIGN to be updated according to references/sdd-integration.md.

Required data

For manual use, receive:

  • prompt objective;
  • context or reference material, when available;
  • desired output contract or sufficient information to infer it;
  • decisions already closed that must not be reopened, when available.

For use via SDD, receive the compiled contract described in references/sdd-integration.md. Do not read DEFINE, DESIGN or BUILD_REPORT on your own when the caller is already responsible for compiling the context.

Step-by-step procedure

  1. Identify the real objective, the consumer of the output and the expected level of autonomy.
  2. Define the exact output contract first: type, structure, mandatory content, limits and permitted fallback.
  3. Convert cautions and restrictions into short operational rules, without repetitions.
  4. Include <formulas> whenever there is a calculation, metric, indicator, ratio or score; declare operands and operations explicitly.
  5. Define behavior for missing, ambiguous or unverifiable context. Never invent data.
  6. Include a short internal verification when structure, transformation, extraction or criticality justify it.
  7. Include a completeness contract for required batches, slots, lists, inventories, or sections.
  8. Include empty-result recovery when partial, noisy, or extraction-failure inputs are plausible.
  9. Isolate schemas, templates, policies, examples, and canonical material in <reference_material> instead of scattering rules.
  10. Remove decorative, redundant, or non-operational text.
  11. Validate the prompt against the quality checklist below.
  12. Emit a single TXT BLOCK with the finished prompt.

Validations and quality checklist

Before responding, verify internally:

  • The objective is clear and operational.
  • The output contract is explicit.
  • The behavior for missing data is defined when necessary.
  • No important rule appears duplicated across different sections.
  • <formulas> exists whenever the task depends on calculation.
  • Optional sections appear only when they add reliability or control.
  • Reference material is isolated from operational instructions.
  • The prompt does not contain labels such as Reasoning Effort, Verbosity or Mode, unless explicitly requested by the user.
  • The final response contains exactly one TXT BLOCK and no competing artifact.

If any item fails, fix it before emitting the response.

Exception handling

  • If context is missing in autonomous execution, use the approved fallback and record unavailability in the expected format itself; do not ask for clarification.
  • If the task allows interaction and essential information is missing without a safe fallback, ask only for the minimum necessary.
  • If there is a conflict between already-closed decisions and new material, preserve the closed decisions and flag the conflict at the level allowed by the contract.
  • If an SDD prompt is being changed without a valid inventory, do not improvise the contract; follow the drift flow in references/sdd-integration.md.
  • Never estimate numbers or fill in missing facts as if they were supplied data.

Examples

Simple request: Crie um system prompt que classifique tickets em billing, bug ou feature e devolva JSON válido.

Expected result:

  • Lean structure, usually <goal>, <output_contract>, <workflow_rules> and <verification>.
  • No decorative sections.

Request with calculation: Crie um prompt que calcule margem bruta por período a partir de receita e custo.

Expected result:

  • Include <formulas> with margem bruta = (receita - custo) ÷ receita.
  • Define fallback for missing or zero revenue.

Part of SDD Open by RDD — https://github.com/robertodiasduarte/sdd-open