Menu
Orchestrates component scaffolding by delegating to component-specific scaffolding skills.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
Orchestrates SDD project initialization — version detection, environment verification, scaffolding, and git setup.
Manage project settings in sdd/sdd-settings.yaml including component settings that drive scaffolding.
Single gateway for all core↔tech-pack interactions. Reads manifests, resolves paths, loads skills/agents, routes commands.
Manage tasks and plans using the .tasks/ directory.
Standards for authoring SDD plugin agents — frontmatter, self-containment, skill references, and no-user-interaction rules.
Standards for authoring SDD plugin commands — frontmatter, user interaction, skill/agent invocation, CLI integration, and output formatting.
| name | scaffolding |
| description | Orchestrates component scaffolding by delegating to component-specific scaffolding skills. |
| user-invocable | false |
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.