create-requires-module

Create Requires Module

Always use the skill load-plain-reference to retrieve the ***plain syntax rules — but only if you haven't done so yet.

What Requires Does

requires attaches the current module to the project's build chain. The required module is built before the current one, and its generated code — the accumulated output of that module and all its ancestors — is copied as the starting point. The current module does not need to functionally extend the required module, but their outputs are never independent: the current module's code physically contains the required module's.

When this module is rendered:

• The required module's generated code (plain_modules/<required_module>/code) is copied as the starting point.
• The ***functional specs*** of the required module and all its ancestors become visible as previous functional specs.
• Of the required module's definitions, only the concepts in its exported_concepts are visible, each with its full definition text. Export visibility is not transitive — to see an ancestor's exports, list that ancestor in requires too.

All modules connected by requires form a single tree with a common root. Diamond joins are prohibited: multiple requires entries must lie on one root-to-tip ancestor path. The deepest entry is the attachment point; the other entries exist only to make those ancestors' exports visible.

Use requires for:

• Building on top of an existing module's functionality
• Attaching a module at the right point in the build chain, even when it addresses a different concern

If you only need shared definitions and reqs (no functional specs, no generated code), use import instead — see the create-import-module skill.

Workflow

1. Identify the attachment point. Determine which existing module this new module attaches after in the build chain. That module must already exist and be renderable. If listing additional modules, verify each is an ancestor of the attachment point — no diamond joins.
2. Create the .plain file at the repository root with YAML frontmatter containing the requires field. Modules with functional specs live at the root, not in template/.
3. Review the functional specs of the whole ancestor chain — they will be treated as previous requirements. Your new functional specs must not conflict with any of them.
4. Review each listed module's exported_concepts — only those concepts are available to reference; an ancestor's exports require listing that ancestor.
5. Add module-specific content — definitions, implementation reqs, test reqs, and functional specs unique to this module.
6. Check for conflicts between your new functional specs and any spec in the ancestor chain.