Skip to content

Latest commit

 

History

History
116 lines (89 loc) · 3.55 KB

File metadata and controls

116 lines (89 loc) · 3.55 KB

Contributing to FinalCode

Development Workflow

  1. Fork the repository and create a feature branch from main
  2. Make changes in skills/finalcode/ only
  3. Verify the skill structure is valid
  4. Open a pull request with a clear description of the change

File Structure

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

Coding Standards

Source Files

  • 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

Terminology

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

Writing Style

  • 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

Documentation Standards

  • 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

Pull Request Expectations

Before submitting a pull request:

  1. Verify skill structure -- ensure all files are in skills/finalcode/ with correct layout
  2. Check cross-references -- ensure all file links point to existing files
  3. Verify terminology -- use the correct terms from the table above
  4. Update CHANGELOG.md -- add a section for your change under the appropriate version
  5. Keep PRs focused -- one logical change per pull request

PR Description

Include:

  • What changed and why
  • Which files were modified
  • Whether behavior changed or only documentation
  • Whether backward compatibility is maintained

Review Checklist

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

Code of Conduct

This project follows the Contributor Covenant Code of Conduct.

Questions

Open a GitHub Discussion or contact dratiux@gmail.com.