Loading...
Loading...
Found 12 Skills
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.
Add an implementation requirement to the ***implementation reqs*** section of a ***plain spec file. Use when the user wants to add non-functional requirements like technology choices, architectural constraints, coding standards, data formats, error handling strategies, or any HOW-to-build guidance to a .plain file.
End-to-end feature addition: takes a feature request in plain English and incrementally writes ***plain specs (concepts, implementation reqs, functional specs, acceptance tests) one functionality at a time, asking, authoring, and reviewing per functionality. Use when the user wants to add a new feature to an existing project.
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.
End-to-end ***plain spec authoring workflow: runs a structured QA interview (product, tech stack, behavior) then produces complete .plain specification files with automated review. Use when the user wants to build something new from scratch or asks to start a new project.
Add a test requirement to the ***test reqs*** section of a ***plain spec file. Use when the user wants to specify conformance testing instructions like test frameworks, execution methods, or testing constraints in a .plain file.
Investigate a bug observed in the running application by reading the generated code in plain_modules/, tracing the issue back to the specs, and fixing only the .plain files. Generated code is never modified. Use when the user reports unexpected behavior, visual glitches, crashes, or incorrect logic in the app.
Add a linked resource (external file reference) to a ***plain spec. Use when the user wants to reference a JSON schema, API spec, data file, or other external file from within a functional spec, definition, or implementation requirement.
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.
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.
Analyze two functional specs from a ***plain spec file to determine if they conflict. Use when the user wants to check whether two specific functional requirements are compatible, or when debugging a suspected conflict between two specs.
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.