Orchestrates component scaffolding by delegating to component-specific scaffolding skills.
The English summary is being prepared. Showing the original description.
See how to installReview the instructions the agent will receive before you install.
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.
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.
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. |
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.
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.
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:
name, type, and type-specific settings to add to sdd-settings.yaml.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.
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
This skill defines no input parameters or structured output. It is consumed as orchestration guidance by the planning and change-orchestration skills.
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Standards for authoring SDD plugin agents — frontmatter, self-containment, skill references, and no-user-interaction rules.
The English summary is being prepared. Showing the original description.
Scaffolds Node.js/TypeScript backend components with CMDO architecture, driven by component settings.
The English summary is being prepared. Showing the original description.
CMDO architecture standards for Node.js/TypeScript backends with strict layer separation.
The English summary is being prepared. Showing the original description.
Intent-to-command mappings for fullstack-typescript tech pack features.
The English summary is being prepared. Showing the original description.
Create change specification and implementation plan with dynamic phase generation. Supports feature, bugfix, refactor, and epic types.
The English summary is being prepared. Showing the original description.
Orchestrates the full change lifecycle — routes actions to phase-specific sub-files.
The English summary is being prepared. Showing the original description.