Scaffolding Skill

Orchestrates component scaffolding for the fullstack-typescript tech pack. When a plan phase requires scaffolding new components, this skill determines the correct scaffolding order and delegates to the appropriate component-specific scaffolding skill.

---

Purpose

During plan execution, the scaffolding phase creates new component directories and boilerplate. This skill ensures components are scaffolded in dependency order -- a server cannot be scaffolded before its contract exists, and Helm charts cannot be created before the services they deploy.

---

Orchestration Order

Components must be scaffolded in this order. Skip any component type that is not being scaffolded in the current change.

Order	Component Type	Rationale
1	config	Singleton, always first. All other components read from config.
2	contract	API-first -- contracts define interfaces before implementations.
3	database	Data layer before services that read/write data.
4	server	Backend services depend on contracts and databases.
5	webapp	Frontend applications consume contracts for type-safe API calls.
6	helm	Deployment charts -- created after deployable components exist.
7	integration-testing	Requires server and database to be scaffolded.
8	e2e-testing	Requires server and webapp to be scaffolded.
9	cicd	CI/CD pipeline -- last, after all components it builds/deploys exist.

---

Delegation Table

Each component type delegates to its specific scaffolding skill. Paths are relative to the tech pack's skills/ directory.

Component Type	Scaffolding Skill Path
config	components/config/config-scaffolding
contract	components/contract/contract-scaffolding
database	components/database/database-scaffolding
server	components/backend/backend-scaffolding
webapp	components/frontend/frontend-scaffolding
helm	components/helm/helm-scaffolding
integration-testing	components/integration-testing/integration-testing-scaffolding
e2e-testing	components/e2e-testing/e2e-testing-scaffolding
cicd	components/cicd/cicd-scaffolding

Each delegated skill handles its own template rendering, directory creation, and file generation. See the individual SKILL.md files for component-specific details.

---

Directory Naming Patterns

Component directories follow the patterns defined in techpack.yaml under components.<type>.directory_pattern. These patterns are the authoritative source for where scaffolded components are placed.

Component Type	Directory Pattern
config	components/config/
contract	components/contracts/{name}/
database	components/databases/{name}/
server	components/servers/{name}/
webapp	components/webapps/{name}/
helm	components/helm_charts/{name}/
integration-testing	components/testing/integration/{name}/
e2e-testing	components/testing/e2e/{name}/
cicd	components/cicds/{name}/

The {name} placeholder is replaced with the component's name from sdd-settings.yaml. Delegate to the techpack-settings skill for the authoritative directory patterns and naming conventions.

---

Settings Update

After scaffolding a component, the project's sdd-settings.yaml must be updated with the new component entry. This is handled via a declared actions response returned to the orchestrating skill.

The scaffolding skill returns a declared actions response that includes:

1. Component entry -- the new component's name, type, and type-specific settings to add to sdd-settings.yaml.
2. Dependencies -- any depends_on relationships the new component declares.

The calling orchestrator (typically the change-orchestration skill) is responsible for applying the settings update by delegating to the techpack-settings skill.

---

Orchestration Flow

1. Read SPEC.md Components section for new components
2. Read sdd-settings.yaml for existing components
3. Identify components that need scaffolding (new - existing)
4. Sort by orchestration order (above)
5. For each component to scaffold:
   a. Resolve scaffolding skill from delegation table
   b. Invoke component scaffolding skill with component settings
   c. Collect declared actions response (settings update)
   d. Apply settings update to sdd-settings.yaml
6. Return aggregated results

---

Input / Output

This skill defines no input parameters or structured output. It is consumed as orchestration guidance by the planning and change-orchestration skills.