菜单
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)