| name | create-import-module |
| description | Create a ***plain import module that provides shared definitions, implementation reqs, and test reqs for other modules to import. Use when the user wants to create a new .plain file that contains only definitions, implementation reqs, and/or test reqs — no functional specs. |
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
.plain file in the template/ directory with YAML frontmatter. Use required_concepts to declare concepts that importing modules must define. It may optionally import other templates for layered reuse, but must not use requires.
- 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 as required_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) |
| Copies generated code | No | Yes |
| Typical use | Templates, shared definitions | Build dependency chain |
Validation Checklist
