Develop, compile, build, test, and publish applications using the Prose-Lang methodology. Use this skill when the user wants to work with .prose files, generate source code from design specs, or manage the lifecycle of a Prose application.
This skill empowers the Agent to act as the Prose Compiler. You will interpret high-level .prose specifications and manually generate the corresponding source code, build artifacts, and documentation.
The specification is usually in the .prose/specification.md refer and cache that to remember the format and syntax of the langague.
.prose file MUST have five sections: # Context, # Memory, # Behaviors, # Interface, and # Tests. If one of these sections is missing, THROW AN ERROR and stop compilation. You may ask the user if they'd like you to auto-add the missing sections.generate, build, or , check the section. Each behavior in the file MUST have corresponding tests. If absent, you MUST ask the user for explicit permission to bypass the check before proceeding.test# Tests@prose_strict_block): If you see @prose_strict_block surrounding a block of code or pseudo-code, you MUST exactly match that logic or drop-in replace it. Do not interpret or paraphrase. Generating these blocks during reverse-engineering requires explicit user approval.prose.reverse-engineer, ALWAYS auto-populate the # Tests section with the original test suites to ensure parity..prose file (e.g., choosing a specific PRNG algorithm for cross-language parity, selecting a hashing strategy, picking a data serialization format), you MUST PAUSE and disclose the assumption to the user. Present the assumption clearly, explain why it is needed, and ask the user to update the .prose specification with the decision before you proceed to generate code. The .prose file must always be the single source of truth — not the compiler agent's judgment..prose file.prose.generate)Use this workflow when the user creates/updates a .prose file or asks to "sync" the design to code. You are the compiler.
.prose/scripts/check_sync.py BEFORE reading the source file.
python3 .prose/scripts/check_sync.py [source_file] [metadata_file]./generated/[app-name]/[app-name].prose.md5needsGeneration is false: STOP HERE. Skip read_file. Inform the user that the code is up to date.needsGeneration is true: Proceed to the next step.read_file on the target .prose file ONLY if the sync check confirms it is out of date. DO NOT rely on your conversation history..prose file (e.g., choice of random number generator, serialization format, concurrency model), STOP. Disclose the assumption to the user and ask them to update the .prose spec before proceeding../generated/[app-name] directory../generated/[app-name]/[app-name].prose.md5 metadata file.prose.build)Use this workflow to transform the generated code into a deployable artifact using standard system tools.
./generated folder to determine the build tool needed.go build -o ./dist/app ./generated/...npm install and npm run build.requirements.txt and ensure pip install -r requirements.txt passes.Dockerfile relative to the stack and run docker build -t [app-name] .prose.test)Use this workflow to validate that the implementation matches the "Behaviors" defined in the Prose file.
main_test.go) that asserts these specific logic rules.go test ./..., npm test, pytest)..prose spec needs to be updated.prose.document)Use this workflow to create user guides or API references based on the readable Prose spec.
.prose file.README.md: Create a Markdown file in the project root containing:
prose.publish)Use this workflow to release the project.
.prose file..prose file text with the new version.git add ., git commit -m "Release v[Version]", and git tag v[Version].git push --tags.docker push [tag].prose.reverse-engineer)Use this workflow to analyze an existing codebase and construct an accurate .prose specification.
@prose_strict_block if explicitly approved by the user, even if it is very difficult to represent the code as pseudo-code..prose file for large projects. Break the problem into multiple .prose files inside an organized directory structure (e.g., src/core.prose, src/api.prose)..prose files to ensure they can be compiled together smoothly..prose files MUST be able to be tested with the exactly same tests to guarantee true functional parity. Document these testing mechanisms directly in the .prose specifications.