Document factory pattern for model reuse in skills

Summary

The factory pattern — using a single model definition with inputs to create multiple resource instances — is the recommended approach when you need multiple resources of the same type. However, this pattern is almost entirely undocumented in the swamp skills.

What's Missing

The following gaps were identified while building a production VPC workflow (10 factory models creating 21 AWS resources):

1. When to use the factory pattern

No decision framework exists. When someone needs 4 subnets, there's no guidance saying "create 1 factory model with inputs" rather than "create 4 separate models". The factory pattern reduces model count significantly (21 → 10 in our case) and keeps definitions DRY.

2. Factory pattern definition and example

The concept of using inputs + globalArguments with name: ${{ inputs.instanceName }} to create multiple instances from a single model is never shown end-to-end. A complete example should show:

• The model definition with inputs schema
• How globalArguments.name becomes the instance name / data name
• How to call the model multiple times with different inputs

3. globalArguments evaluation lifecycle

The critical fact that globalArguments are always evaluated before ANY method (create, get, update, delete) is never documented. This means ALL inputs referenced in globalArguments must be provided for every method invocation — including delete. This is the #1 gotcha when building delete workflows for factory models.

4. Delete workflows with factory models

No documentation covers how to write delete steps for factory models. Specifically:

• All factory inputs must be passed (not just identifier)
• The identifier must be constructed from stored data via CEL expressions
• Example of a correct delete step with all required inputs

5. Data naming with factory models

The relationship between name: ${{ inputs.instanceName }} in globalArguments and how that becomes the data name used in data.latest("model-name", "instance-name") is never connected. This is essential for cross-model references in workflows.

6. Workflow patterns for factory models

How to structure workflows that:

• Call the same model multiple times with different inputs in parallel steps
• Reference each instance's output data downstream via data.latest()
• Handle the reverse order for delete workflows

Context

This was discovered building a production AWS VPC with:

• prod-subnet factory model creating 4 instances (public-a, public-b, private-a, private-b)
• prod-eip factory model creating 2 instances (eip-a, eip-b)
• prod-nat-gateway factory model creating 2 instances (nat-a, nat-b)
• prod-route-table factory model creating 3 instances (public-rt, private-rt-a, private-rt-b)
• And more...

The create workflow worked first try. The delete workflow took 3 iterations to get right, entirely because the factory pattern behavior (especially around globalArguments evaluation and input requirements for delete) was undocumented.

Suggested Location

The swamp-model skill should cover the pattern definition and when-to-use guidance. The swamp-workflow skill's data-chaining.md reference should cover workflow patterns for factory models including delete ordering.