From sdd
Manages sdd/sdd-settings.yaml for project metadata, component settings, tech pack configs, and validation rules that drive scaffolding.
npx claudepluginhub liorcohen/sdd --plugin sddThis skill uses the workspace's default tool permissions.
Single source of truth for the `sdd/sdd-settings.yaml` schema, component settings, validation rules, and directory mappings. Component types and their settings schemas are defined by the active tech pack — invoke `techpacks.listComponents` and `techpacks.routeSkills` rather than hardcoding type-specific knowledge.
Scaffolds SDD project structure with root files (package.json, README.md, CLAUDE.md, .gitignore), sdd/, specs/, and optional changes/ in minimal or full modes. Non-destructive.
Generates project-specific SDD steering documents (product.md, tech.md, structure.md) by analyzing manifests like package.json/Cargo.toml, directories, and code patterns. Use for project context setup and conventions.
Wires backend and frontend scaffold outputs into a runnable project with directory tree, configs, and entry points. Use after generating scaffolds via upstream tools.
Share bugs, ideas, or general feedback.
Single source of truth for the sdd/sdd-settings.yaml schema, component settings, validation rules, and directory mappings. Component types and their settings schemas are defined by the active tech pack — invoke techpacks.listComponents and techpacks.routeSkills rather than hardcoding type-specific knowledge.
Schema: schemas/input.schema.json
Accepts operation type and operation-specific parameters for managing sdd-settings.yaml.
Schema: schemas/output.schema.json
Returns success status, file path, and current component configurations.
Manage the sdd/sdd-settings.yaml file that stores project configuration and component settings. Component settings are structural decisions that drive scaffolding, config initialization, and deployment.
Settings file: sdd/sdd-settings.yaml (git-tracked)
The sdd/ directory contains all SDD metadata. Create this directory if it doesn't exist.
If sdd-settings.yaml exists at project root (legacy location):
sdd/ directorysdd-settings.yaml to sdd/sdd-settings.yamlQuick migration command:
mkdir -p sdd && mv sdd-settings.yaml sdd/ && git add -A && git commit -m "Migrate sdd-settings.yaml to sdd/"
Formal definition: schemas/sdd-settings.schema.json (JSON Schema Draft 2020-12)
The schema defines three top-level sections: sdd (plugin metadata), project (project metadata), and components (list of typed components with settings). Component types and their settings schemas are defined by the active tech pack.
sdd:
initialized_by_plugin_version: "7.0.0"
updated_by_plugin_version: "7.1.0"
initialized_at: "2026-02-07 00:00:00Z"
updated_at: "2026-02-09 14:30:00Z"
project:
name: "my-app"
description: "A task management SaaS application"
techpacks:
<namespace>:
name: <tech-pack-name>
namespace: <namespace>
version: "1.0.0"
mode: internal # or external, git
path: <tech-pack-directory>
components:
my-component:
type: <type-from-tech-pack>
techpack: <namespace>
directory: <directory-from-tech-pack-pattern>
other-component:
type: <type-from-tech-pack>
techpack: <namespace>
directory: <directory-from-tech-pack-pattern>
| Aspect | Settings | Config |
|---|---|---|
| What | Structural capabilities | Runtime values |
| When set | At component creation, changeable | Per-environment |
| Examples | depends_on, component-type-specific fields | port: 3000, replicas: 3 |
| Affects | What gets scaffolded | Values in scaffolded files |
| Stored in | sdd/sdd-settings.yaml | Config component envs/ directory |
Component types and their settings schemas are defined by the active tech pack. Core does not hardcode component type definitions.
To discover available component types and their settings schemas:
Invoke techpacks.listComponents for the active tech pack namespace.
To load type-specific settings schemas during validation:
Invoke techpacks.routeSkills with:
namespace: <active-namespace>
phase: implementation
The tech pack's techpack-settings skill contains the full component type definitions, settings tables per type, directory patterns, and validation rules.
Component directory patterns are defined in the tech pack manifest under components.<type>.directory_pattern. Invoke techpacks.listComponents to get the directory pattern for each component type. Do NOT hardcode type→directory mappings.
config component type)depends_on) must reference existing component instancestechpacks.routeSkills(phase: implementation) for component-type-specific settings schemas.createInitialize a new settings file.
Input:
| Parameter | Required | Description |
|---|---|---|
initialized_by_plugin_version | Yes | Current SDD plugin version |
project_name | Yes | Project name |
project_description | No | Project description |
components | Yes | List of components with settings |
readLoad and return current settings.
updateMerge partial updates into existing settings. Triggers automatic sync of affected artifacts.
get_component_dirsGet the actual directory names for all components.
┌─────────────────┐
│ /sdd (init) │ Settings defined during project creation
└────────┬────────┘
│
▼
┌─────────────────┐
│ Scaffolding │ Settings drive what files/templates are created
│ (initial) │ Settings drive initial config values
└────────┬────────┘
│
▼
┌─────────────────┐
│ Development │ Settings changes come from:
│ │ - Specs (new components, capability changes)
│ │ - Plans (implementation decisions)
│ │ - /sdd with natural language about settings (manual adjustments)
└────────┬────────┘
│
▼
┌─────────────────┐
│ Settings Sync │ Changes propagate to affected artifacts
│ (incremental) │ Only adds/updates, never deletes user content
└─────────────────┘
order-service, analytics-db, customer-portal, task-apiapi, public, primary, main, serverconfig (singleton)Template for initializing a new sdd/sdd-settings.yaml:
# ============================================================================
# SDD PROJECT SETTINGS - DO NOT EDIT MANUALLY
# ============================================================================
# This file is generated and maintained by SDD commands.
# To modify settings, use: /sdd with natural language about settings
# ============================================================================
sdd:
initialized_by_plugin_version: "{{PLUGIN_VERSION}}"
updated_by_plugin_version: "{{PLUGIN_VERSION}}"
initialized_at: "{{CURRENT_UTC_DATETIME}}"
updated_at: "{{CURRENT_UTC_DATETIME}}"
project:
name: "{{PROJECT_NAME}}"
# Tech packs and components are added here during init and implementation.
techpacks:
<namespace>:
name: <tech-pack-name>
namespace: <namespace>
version: "1.0.0"
mode: internal
path: <tech-pack-directory>
components:
my-component:
type: <type-from-tech-pack>
techpack: <namespace>
directory: <directory-from-tech-pack-pattern>