- Fork the repository and create a feature branch from
main - Make changes in
skills/finalcode/only - Verify the skill structure is valid
- Open a pull request with a clear description of the change
skills/finalcode/
├── SKILL.md # Main skill specification
├── core/ # Core engine layer
│ ├── decision-engine.md
│ ├── policy-engine.md
│ ├── rule-registry.md
│ ├── report-engine.md
│ └── certification-engine.md
├── plugins/ # Plugin layer
│ ├── sdk.md
│ ├── profiles.md
│ └── marketplace.md
└── references/ # Reference documentation
├── examples.md
├── gates.md
├── security-gate.md
├── configuration.md
├── plugins.md
├── health-score.md
├── confidence-model.md
├── finding-classification.md
├── explainability.md
├── release-engine.md
└── architecture.md
- Use Markdown with consistent heading levels
- Use tables for structured data
- Use code blocks for commands and configuration examples
- Keep lines under 120 characters where practical
Use consistent terms throughout all documentation:
| Use | Do Not Use |
|---|---|
| FinalCode | Final Gate |
| Skills ecosystem | OpenCode-only |
| Inspect, Repair, Refactor, Certify | Inspect Mode, Repair Mode, etc. (use bare names) |
| Policy Engine | Engineering Policy Engine |
| Plugin SDK | plugin SDK |
| Explainability Engine | Explainability |
- Write in technical English
- Prefer concise explanations over long feature lists
- Do not use marketing language or superlatives
- Do not use emojis
- Do not use artificial verbosity
- Every paragraph must provide actionable information
- Each document must have a unique responsibility
- Avoid duplicating explanations across files
- Link to other documents instead of repeating content
- Reference specific files when linking:
[skills/finalcode/references/gates.md](skills/finalcode/references/gates.md)not "the gates documentation" - Update the changelog when adding or changing features
Before submitting a pull request:
- Verify skill structure -- ensure all files are in
skills/finalcode/with correct layout - Check cross-references -- ensure all file links point to existing files
- Verify terminology -- use the correct terms from the table above
- Update CHANGELOG.md -- add a section for your change under the appropriate version
- Keep PRs focused -- one logical change per pull request
Include:
- What changed and why
- Which files were modified
- Whether behavior changed or only documentation
- Whether backward compatibility is maintained
When reviewing a pull request:
- Changes are in
skills/finalcode/only - Skill structure is valid
- No broken cross-references between documents
- Terminology is consistent
- No marketing language or filler text
- No duplicated content across files
- CHANGELOG.md updated
- Backward compatibility maintained
This project follows the Contributor Covenant Code of Conduct.
Open a GitHub Discussion or contact dratiux@gmail.com.