add-implementation-requirement

Original：🇺🇸 English

Translated

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.

2installs

Sourcecodeplain-ai/plain-forge

Added on2026-05-16

NPX Install

npx skill4agent add codeplain-ai/plain-forge add-implementation-requirement

SKILL.md Content

View Translation Comparison →

Add Implementation Requirement

Always use the skill

load-plain-reference

to retrieve the ***plain syntax rules — but only if you haven't done so yet.

Workflow

Identify the target
.plain
file. If ambiguous, ask the user.
Read the file to understand existing implementation reqs, definitions, and functional specs.
Determine if this belongs in implementation reqs — it must describe HOW to build, not WHAT to build (that goes in
```
***functional specs***
```
).
Draft the requirement following the rules below.
Insert it into the
```
***implementation reqs***
```
section.
Read the file again to confirm correct placement and syntax.

What Belongs Here

Implementation reqs are free-form instructions that steer code generation. Common contents:

Technology choices: language, framework, runtime version
Architectural constraints: patterns, layering, dependency rules
Coding standards: naming conventions, style guidelines
Data formats: serialization, encoding, transformation rules
Error handling: strategies, retry logic, exception hierarchies
Algorithm descriptions: specific approaches when behavior alone is insufficient
Performance guidance: memory constraints, streaming requirements, batching strategies
Language-specific constructs: generics, annotations, framework-specific types and idioms

What Does NOT Belong Here

Behavior and features — those go in
```
***functional specs***
```
Concept definitions — those go in
```
***definitions***
```
Test instructions — those go in
```
***test reqs***
```

Key Principle: HOW vs WHAT

***implementation reqs***

describe HOW the software should be built.

***functional specs***

describe WHAT the software should do.

If the requirement describes observable behavior (endpoints, business rules, user-facing features), it belongs in functional specs. If it describes internal structure, technology, or coding guidance, it belongs here.

Format

Implementation reqs are bullet points in the

***implementation reqs***

section:

plain

***implementation reqs***
- :Implementation: should be in Python 3.12.
- :Implementation: should use pip for dependency management.
- When writing CSV files, :Implementation: should use streaming writes to avoid holding large datasets in memory.

Reference defined

:Concepts:

where they add clarity. Implementation reqs in non-leaf sections apply to all subsections.

Encapsulation Warning

requires

modules only receive functional specs from their dependencies — not implementation reqs. If downstream modules need certain behavior to be visible, that behavior must be expressed in functional specs, not here.

Validation Checklist

Describes HOW to build, not WHAT to build
All referenced
```
:Concepts:
```
are defined in
```
***definitions***
```
Does not duplicate guidance already present in the file or its imports
Placed inside a
```
***implementation reqs***
```
section
No behavioral requirements that should be in
```
***functional specs***
```