mcpField
S
scartill-sdd-lite

scartill-sdd-lite

github.com/neurowitchersAgent workflows239 installsUpdated 2d ago
Repository

About scartill-sdd-lite

A specification-driven development skill with commands for brainstorming, writing specs, splitting tasks, implementation, review, and finalization. It is for teams or developers who want a staged path from an initial idea to reviewed implementation, with some handoff commands requiring Orca.

Key features

  1. 01Creates seed and full specifications
  2. 02Splits specifications into tasks
  3. 03Supports implementation and code review
  4. 04Includes brainstorming and input cleanup
  5. 05Archives project documentation

Use cases

  1. 01Turn an idea into an actionable specification
  2. 02Break a specification into implementation tasks
  3. 03Review code and finalize project documentation

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/neurowitchers/scartill-sdd-lite --skill scartill-sdd-lite

After installing, type/scartill-sdd-litein Claude Code to confirm it loaded.

Bundled files

References and scripts installed along with SKILL.md.

prompts/
sc.archive.md
sc.autoflow.md
sc.brainstorm.md
sc.brainstorm.to.seed.md
sc.code.review.md
sc.critique.spec.md
sc.finalize.md
sc.gate.input.md
sc.handoff.code.review.md
sc.handoff.critique.md
sc.implement.tasks.md
sc.save.spec.md
sc.split.tasks.md

Details

From the project README

Commands

  • Save Spec - save persistent specification (prompt: sc.save.spec.md)
  • Split Tasks - create standalone tasks (prompt: sc.split.tasks.md)
  • Implement - run implementation (prompt: sc.implement.tasks.md)
  • Finalize - post-implementation actions: update docs, capture deferred items to docs/feedback/, and post product-manager guidance to the PR if available (prompt: sc.finalize.md)
  • Critique - critique specification (prompt: sc.critique.spec.md, to file to critique as a parameter)
  • Code Review - review implementation (prompt: sc.code.review.md)
  • Archive - archive older project documentation (prompt: sc.archive.md)
  • Brainstorm - Extended brainstorming (prompt: sc.brainstorm.md, the problem to consider is a parameter)
  • Seed - convert final brainstorming results to a seed (prompt: sc.brainstorm.to.seed.md)
  • Gate Input - sanitize raw input, extract clean seed specs, and generate a PM feedback report (prompt: sc.gate.input.md, input document path as parameter)

Advanced Commands (Orca-dependent)

These commands require the /orchestration skill and an available adversarial agent.

  • Handoff Critique - hand off the critique to an adversarial agent (Antigravity) running in a new Orca terminal, then apply the resulting critique (prompt: sc.handoff.critique.md, allowed argument: --auto)
  • Handoff Code Review - hand off the code review to an adversarial agent (Antigravity) running in a new Orca terminal, then act on the resulting review (prompt: sc.handoff.code.review.md, allowed argument: --auto)
  • Autoflow - polymorphically drive the full pipeline end-to-end and autonomously: starting from the earliest available artifact — a filled-in brainstorm awaiting Phase 3–4, a completed brainstorm with no seed, seed(s), or a full spec — finalize the brainstorm and/or derive a seed if needed, plan a full spec, then handoff-critique (--auto), split tasks, implement, handoff-code-review (--auto), and finalize, committing at each stage (prompt: sc.autoflow.md, arguments: free-form user refining notes)

All prompts reside in <skill-dir>/prompts/.

Upon activation, remember these commands, but do not run until an explicit user request.

Guidance

Specification Workflow: Seed vs Full Specs

This project uses a two-stage specification process. Both live under docs/.

Seed Specs (docs/seed/)

A seed spec is a concise, human-written intent document. It captures:

  • What the user wants (feature intent, desired behavior)
  • Key examples and expected output formats
  • High-level CLI interface or config shape
  • Follow-up tasks (amend README, add examples, etc.)

Seed specs are informal, written in the user's voice, and may contain typos or shorthand. They do not include:

  • Detailed implementation guidance
  • Internal data models or code structure
  • Explicit task breakdowns with test requirements
  • Mermaid diagrams or architecture decisions
  • Background on existing codebase internals

A seed spec is the input to the design phase.

Full Specs (docs/specs/)

A full spec is a detailed implementation blueprint derived from a seed spec. It includes:

  • Problem Statement: Precise restatement of the requirement
  • Requirements: Exhaustive list of acceptance criteria
  • Background: Relevant codebase internals (existing patterns, modules, data structures)
  • Proposed Solution: Architecture with Mermaid diagrams, data models, and code sketches
  • Task Breakdown: Numbered implementation tasks, each with:
    • Objective
    • Implementation guidance (which files, which patterns to follow)
    • Test requirements (what to assert, which fixtures to use)
    • Demo command to verify

Full specs are written for an implementer (human or AI) to execute without further clarification.

Workflow
  1. User writes a seed spec in docs/seed/ to capture intent.
  2. A full spec is produced in docs/specs/ (either by the user or with AI assistance) that expands the seed into an actionable plan.
  3. Implementation follows the full spec's task breakdown.

When asked to implement a feature, look for both the seed (for intent) and the full spec (for implementation details). If only a seed exists, offer to produce a full spec first.

Comments

Markdown supported