메뉴
Common rules for code development that apply across all project types (libraries, CLI tools, services, etc.). Covers development workflow, requirements clarity, bug-fix workflow, logging, coding style, testing discipline, version management, and commit conventions.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | common-development |
| description | Common rules for code development that apply across all project types (libraries, CLI tools, services, etc.). Covers development workflow, requirements clarity, bug-fix workflow, logging, coding style, testing discipline, version management, and commit conventions. |
| metadata | {"author":"vsirotin","version":"1.4"} |
These rules apply to all code development activities in this project, regardless of whether the target is a library, CLI tool, or service.
Every new feature or bug-fix must follow these steps in order:
Understand requirements and plan tests. Before writing any code, understand the requirements and propose which tests are needed at which stages (see the staging pipeline in docs/common-architecture.md). Test planning must be pragmatic — avoid overtesting. Unit tests are needed in most cases. Instructions for manual testing should only be written for very important features.
Develop tests. Write the tests before or alongside the implementation (TDD for bugs — see Rule 2 below).
Develop code. Implement the feature or fix.
Run local automatic tests. First run the tests that are directly relevant to the changes. Then run all unit tests in the project — they must all pass before proceeding.
Think about documentation. Ask: "Do any sections in the sub-project's DEVELOPMENT.md need updating? Does README.md or docs/common-architecture.md need updating?" Be pragmatic — do not over-document.
Update documentation. Apply the documentation skill if updates are needed.
Post-task checklist. Apply the post-task skill (version bump, release notes, commit text proposal).
Functional and technical requirements must be provided in an understandable and feasible form before implementation begins. If requirements are ambiguous, ask the user for clarification.
When fixing a bug, always follow this order:
All functions must include logging. If the specification does not describe logging, use best practices for the language (e.g. a @logged decorator for entry/exit, structured log fields for errors).
Use best practices of the programming language, but maintain a common, consistent style across the entire project. Do not mix conventions within one codebase.
If a function uses data from environment variables or files, this must be mentioned in the function's documentation.
If technically possible, unit tests should contain test cases for:
if, switch, match, etc.).await on internal calls.Use the following naming pattern for test functions:
test_<subject_under_test>_<aspect>
<subject_under_test> — what is being tested (for unit tests of a single function, use the function name).<aspect> — short abbreviation for the tested aspect (up to 10 characters), e.g. timeout, no_conn, bad_env.When a project has many unit tests (more than 5), try to group them into sub-directories by topic or module.
After completing development, all unit tests in the project must be processed with success.
After running tests, delete any temporary directories or files created during the test run (e.g. output or download directories produced in dist/ by integration tests). Leave the project tree in the same state it was before the tests ran.
If you see suddenly that you cannot solve some problem, stop the development and ask me.
If you try to fix the same bug too long (more than 20 iterations), stop the development and ask me.
After completing a task that makes essential changes, apply the post-task skill (version bump, release notes, commit text proposal).
Compare an SFSM FA definition JSON file against a draw.io UML state diagram and report every discrepancy. Use when validating that a diagram matches its source JSON, or vice versa. Combines drawio-to-json and compare-compact-jsons for round-trip verification.
Convert an SFSM FA definition JSON file (compact or extended format) to a professional draw.io UML state diagram with hierarchical ELK.js layout. Use when asked to visualize or diagram an SFSM JSON definition. The generated diagram may require small manual repositioning for visual perfection.
Extract an SFSM FA definition JSON file in compact format from a draw.io UML state diagram. Use when asked to convert, export, or reverse-engineer a diagram back into SFSM/StOP JSON.
Post-task checklist that runs after every agent task that makes essential changes to code, documentation, scripts, or configuration. Covers version bumping, release-notes update, and commit-text proposal. Applied automatically — the agent does not need to be asked.
Documentation rules for the Aiavivo project. Covers README.md structure, per-sub-project DEVELOPMENT.md template, when/how to update documentation after code changes, and handling of sub-projects with no code yet.