Create Import Module
Always use the skill load-plain-reference to retrieve the ***plain syntax rules — but only if you haven't done so yet.
What an Import Module Is
An import module is a .plain file that lives in the template/ directory and contains only ***definitions***, ***implementation reqs***, and/or ***test reqs***. It must not contain ***functional specs*** and must not use requires in its frontmatter. Other modules pull in its content via the import field in their YAML frontmatter, gaining access to its definitions and reqs.
Use import modules for:
- Sharing concept definitions across multiple modules
- Providing common implementation requirements (e.g., technology stack, coding standards)
- Providing common test requirements
- Creating reusable foundational structure (templates)
If the module needs functional specs (i.e., it describes what software should do), it is not an import module — see the create-requires-module skill.
Workflow
- Determine what shared content this module should provide — which definitions, implementation reqs, or test reqs will other modules need?
- Create the
.plainfile in thetemplate/directory with YAML frontmatter. Userequired_conceptsto declare concepts that importing modules must define. It may optionallyimportother templates for layered reuse, but must not userequires. - Add the shared content — definitions, implementation reqs, and/or test reqs.
- Do not add
***functional specs***— import modules must not contain functional specs. - Verify concept availability — ensure all
:Concepts:referenced are either defined in this module, provided by its own imports, declared asrequired_concepts, or are predefined concepts.
Format
The import field is a list of module paths in the YAML frontmatter:
---
import:
- base_template
required_concepts: [":AppName:"]
description: Shared API definitions and reqs
---
***definitions***
- :ApiClient: is the HTTP client used to communicate with external services.
- :ApiResponse: is the response returned by :ApiClient:.
***implementation reqs***
- :Implementation: should handle HTTP errors by raising appropriate exceptions.
- :ApiClient: should support configurable timeouts.
***test reqs***
- :ConformanceTests: should mock all external HTTP calls made by :ApiClient:.
The default import directory is template/ — the template/ prefix is not needed in import paths. The .plain extension is omitted. Note the absence of ***functional specs*** — import modules must not have them.
Satisfying Required Concepts
If an imported template declares required_concepts, the importing module must define those concepts in its own ***definitions*** section:
---
import:
- auth_template
---
> auth_template declares required_concepts: [":AuthSchema:", ":AuthApiSpec:"]
> So this module must define them:
***definitions***
- :AuthSchema: is the JSON schema describing the authentication data structure.
- :AuthApiSpec: is the OpenAPI specification for the external service's auth endpoint.
Import vs Requires
| Aspect | import |
requires |
|---|---|---|
| Pulls in definitions | Yes | No (only exported_concepts) |
| Pulls in implementation reqs | Yes | No |
| Pulls in test reqs | Yes | No |
| Pulls in functional specs | No | Yes (as previous requirements, transitively) |
| Copies generated code | No | Yes (accumulated ancestor chain) |
| Typical use | Templates, shared definitions | Attaching a module to the build chain |
Validation Checklist
- Module file is in the
template/directory - Module does not contain
***functional specs*** - Module does not use
requiresin its frontmatter - Contains at least one of: definitions, implementation reqs, or test reqs
- All
required_conceptsfrom any imports this module itself uses are satisfied -
required_conceptsdeclared for any concepts referenced but not defined here - No concept name collisions between this module's imports and local definitions
- YAML frontmatter is correctly formatted between
---markers