alejandro-cedeno-10/agentic-sdd-kit

sdd-context-intake

Ingest raw context the user pastes or points at — a ticket, a design doc, meeting notes, a spec, a URL, referenced files/paths — and have an agent READ and UNDERSTAND all of it, then synthesize a well-formed feature brief (goal, scope, constraints, and load…

Ver código-fonte
Documento original do Skill

Renderizado do repositório de origem, preservando títulos, exemplos, código, tabelas, links e imagens.

Context intake for Spec-Driven Development

The user rarely starts with a clean one-line goal — they have a ticket, a doc, a thread, some files. This skill turns that raw material into the structured brief the SDD flow needs, WITHOUT guessing past what the sources actually say.

When to use

  • The user pastes a ticket / requirements / design doc / notes and says "do this".
  • The user names files, paths, or URLs as the source of truth.
  • Before sdd-clarify and before launching sdd-feature-flow, when the goal is buried in

material rather than stated.

Procedure

  1. Collect every source the user gave, verbatim: pasted text, plus anything referenced —

Read the named files, WebFetch the URLs, pull the ticket via its MCP/CLI if available. Do NOT stop at the pasted blurb if it points elsewhere.

  1. Delegate the reading when it's large or multi-source. Spawn a read-only agent (the

Explore or general-purpose agent) to ingest the sources and return a compact digest — this keeps the bulky material out of the main context. For a single short paste, read inline.

  1. Synthesize a brief with exactly these sections, grounded ONLY in the sources (mark

anything you inferred):

  • Goal — one or two lines: what to build and why (the "what/why", not the "how").
  • In scope / Out of scope — bullet lists drawn from the sources.
  • Constraints — data model, contracts, integrations, naming, limits the sources state.
  • Load-bearing unknowns — decisions the sources do NOT settle that would change code,

contract, or template structure. These become the questions for sdd-clarify.

  • Sources — the files/URLs/tickets you actually read.
  1. Hand off. Feed the unknowns to sdd-clarify (ask the user), then pass the resolved

brief as the goal (and any confirmed params) to the sdd-feature-flow workflow.

Rules

  • Ground everything in the sources. If the source doesn't say it, it's an unknown, not an

assumption — surface it, don't invent it. (This is the same discipline the harness's clarity gate enforces later; catching it here is cheaper.)

  • Never begin writing a spec or code from this skill — its only output is the brief.
  • Keep the digest tight; the point is to compress source material into decisions and unknowns.
do mesmo repositório

Mais Skills

Todos os Skills
alejandro-cedeno-10
Comunidade

sdd-checklist

Generate a requirements-quality checklist for an OpenSpec change and run it against the proposal/design/tasks/delta — validating completeness, clarity, consistency, and testability BEFORE you approve the spec. Modeled on GitHub Spec-Kit's /checklist. Use when reviewing a spec at the human approval gate, or before launching implementation, to catch under-specified requirements early.

instalações
2
GitHub Stars
0
Atualizado
7 de jul.
alejandro-cedeno-10
Comunidade

sdd-clarify

Front door of the SDD flow. When the user asks for a feature or bug fix ("implementa…", "agrega…", "arregla…", "add…", "build…", "fix…"), FIRST scan the request + codebase context for load-bearing ambiguity and ask a few targeted clarifying questions (selectable options, recommended first) BEFORE writing any spec or code — then hand a well-formed goal to /opsx:propose (small) or the sdd-feature-flow workflow (large). Skip the questions when the request is already unambiguous. Modeled on GitHub Spec-Kit's /clarify.

instalações
2
GitHub Stars
0
Atualizado
7 de jul.
alejandro-cedeno-10
Comunidade

sdd-verify

Surface-aware end-to-end verification of a change — determine whether it touches a FRONTEND surface (rendered UI) or an API/backend surface, then validate the right way. Frontend → chrome-devtools MCP (open the affected page, screenshot, confirm it renders, check console/network/accessibility). API → a Playwright request script that hits the affected endpoints and asserts status + response shape. Use after implementing a change, or in the harness Validate step, to confirm it actually works in the running app — not just that unit tests pass. Requires the chrome-devtools-mcp plugin (frontend) and/or Playwright (API); both are wired up by the kit installer.

instalações
2
GitHub Stars
0
Atualizado
7 de jul.