メニュー
Create or include a Liquid template in a ***plain spec file using {% include %} syntax. Use when the same spec content needs to be reused across multiple .plain files with different parameters.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Authors and structures professional-grade agent skills following the agentskills.io spec. Use when creating new skill directories, drafting procedural instructions, or optimizing metadata for discoverability. Don't use for general documentation, non-agentic library code, or README files.
Add acceptance tests under a functional spec in a ***plain spec file. Use when the user wants to add verification criteria for a specific functional spec, or after adding a functional spec that needs testable success criteria.
Add a concept to the ***definitions*** section of a ***plain spec file. Use when the user wants to define a new concept, entity, or domain term in a .plain file.
End-to-end feature addition on an existing ***plain project: runs a short feature-intent interview, then takes the confirmed request and, one question at a time, incrementally writes ***plain specs (concepts, implementation reqs, functional specs, test reqs, acceptance tests) to disk — asking, authoring, and reviewing per functionality — then closes with a plain-healthcheck gate. Use when the user wants to add a feature to an existing project. Not for bootstrapping a new project from scratch (use forge-plain) or for editing generated code (the .plain specs are the source of truth).
Add a single functional spec to the ***functional specs*** section of a ***plain spec file. Use whenever exactly one new functional spec is being added — whether the user explicitly asks, or another skill/workflow (e.g. forge-plain, add-feature) needs to author a new functional spec. Every new entry under ***functional specs*** must go through either this skill or `add-functional-specs` (the bulk variant for adding multiple specs in one pass); hand-authoring functional specs without invoking one of these skills is forbidden.
Add multiple functional specs to the ***functional specs*** section of a ***plain spec file in a single batch. Use whenever more than one new functional spec is being added — whether the user explicitly asks, or another skill/workflow (e.g. forge-plain, add-feature) needs to author several specs in one pass. Bulk-writing or hand-authoring functional specs without invoking this skill is forbidden; for adding a single spec, use add-functional-spec instead.
| name | add-template |
| description | Create or include a Liquid template in a ***plain spec file using {% include %} syntax. Use when the same spec content needs to be reused across multiple .plain files with different parameters. |
Always use the skill load-plain-reference to retrieve the ***plain syntax rules — but only if you haven't done so yet.
Templates use Liquid syntax ({% include %}) to reuse the same spec content across multiple .plain files. Each inclusion can pass different parameters, producing tailored output from a single source. This is distinct from import and requires — templates are about textual reuse with parameterization, not module dependencies.
.plain file.Use {% include %} with the template path and parameters:
{% include "console_app_template.plain", main_file_name: "app.py", app_name: "MyApp" %}
Parameters are passed as key-value pairs after the template path. Inside the template, parameters are accessed using Liquid variable syntax ({{ main_file_name }}).
Templates live in the template/ directory. Only variables ({{ variable_name }}) are supported — conditionals, loops, and other Liquid features are not available:
***definitions***
- :{{ app_name }}MainFile: is the entry point file for :{{ app_name }}:.
***implementation reqs***
- :{{ app_name }}MainFile: should be called "{{ main_file_name }}".
template/ directory to see what templates are available.{% include %} statement to the target .plain file with the correct parameters..plain files..plain file in the template/ directory.{% include %} instead of the duplicated content.template/ directory{% include %} call site.plain file (otherwise, inline the content)