freemo
8193545fb5
Adds a comprehensive opencode skill under .opencode/skills/cleverthis-guidelines/
covering every rule, regulation, directive, and guideline governing CleverThis
projects and company operations. Synthesized from CONTRIBUTING.md and the
CleverThis Operations Code (C.O.C. v0.4, 70 pages).
- 12 files, 2,384 lines across 11 reference categories
- 1,059-line SKILL.md with 16 exhaustive decision trees covering every
procedural situation: writing code, committing, submitting PRs, code review,
creating issues, applying labels, ticket state transitions, sprint planning,
triaging, point estimation, definition of done, authoring documents,
confidentiality classification, security/credentials, FOSS, bug fixes (TDD),
architectural decisions, and escalation paths
Reference files cover:
commits/ — Conventional Changelog format, atomic commit rules, pre-commit
pull-requests/ — all 12 PR requirements, review process, merge criteria
testing/ — BDD/Behave (unit), Robot Framework (integration), 97% coverage
threshold (project-specific), TDD bug fix workflow, mocking rules
issue-tracking/ — ticket hierarchy (Issue→Epic→Legendary), all quality criteria,
mandatory issue sections, full label system (State/Type/Priority/
MoSCoW/Special), lifecycle flow, dependency direction rules
sprints/ — DSDM, 6-stage triaging, MoSCoW, poker point estimation,
all 4 sprint ceremonies with complete rule sets
code-style/ — SOLID, design patterns, import rules, error handling, type safety,
LangChain/LangGraph guidelines, v3 vs legacy plan lifecycle
security/ — gopass-only password management, Yubikey rules, encryption policy
information/ — 5 confidentiality stamp levels, document authoring, email conventions
organizational/ — C-level hierarchy, ELB, OCRB, all 12 committees, personnel review
project-tools/ — nox commands, CI/CD, release process, Hatch, Commitizen setup
open-source/ — FOSS governance, open standards mandate, POSIX compliance
Key project-specific facts documented:
- Coverage threshold: 97% (overrides C.O.C. baseline of 85%)
- BDD framework: Behave (not pytest alone)
- Type checker: Pyright (never disabled, no type: ignore)
- Bug fixes: mandatory TDD workflow with @tdd_expected_fail tagging
Open Source and Open Standards Policies
Open Standards Mandate
Company infrastructure and projects MUST use open standards where possible. Proprietary/non-standard options: only when no suitable open standard exists. Products released: must use open standards both internally and at external APIs. When no suitable API standard exists: create new open standards, publish freely.
Open standards definition: publicly available specs, free of patents/fees, published by agency allowing public review, vetted before publication.
Recognized Standards Bodies
- IEEE (Institute of Electrical and Electronics Engineers)
- W3C (World Wide Web Consortium)
- NIST (National Institute of Standards and Technologies)
- IANA (Internet Assigned Numbers Authority)
- IEC (International Electrotechnical Commission)
- ANSI / ISO
- OpenGroup
POSIX Compliance
- All computer systems: run POSIX-compliant OS when possible
- Non-POSIX OS: requires specific justification + COO approval
- Development tools: prefer POSIX-compliant tooling
FOSS (Free and Open Source Software) Governance
Using FOSS Libraries
- Review license for compatibility with CleverThis requirements
- If uncertain → request OOC review before incorporating
- All FOSS usage must comply with relevant licenses
Contributing to External FOSS
- Follow documented approval process
- Verify no conflicts with existing IP or confidentiality agreements
- Comply with TCRC (Technical Community Relations Committee) guidelines
Creating a New FOSS Project
- Register with OOC (document: scope, repositories, license, maintenance plan)
- Include: recognized open source license file (GPL, MIT, Apache, etc.)
- Include: README, contributor guidelines, license files in repository
- Host on BOTH: internal (Forgejo) AND external platform (GitHub/GitLab)
- Mirror: must be synchronized and operational at all times
Releasing Proprietary Code as FOSS
- Requires explicit approval from: EP or EVP AND OOC
- Verify: IP rights, confidentiality obligations, contractual obligations intact
Discovering License Non-Compliance
- Report to OOC immediately
- Submit remediation plan to ELB immediately
Open-Source Community Engagement (TCRC Rules)
- Prioritize education and support over marketing
- Maintain authenticity and professionalism
- Controversial/sensitive topics: pre-approval from ELB required
- All presentations/workshops: align with CleverThis branding
- Confidential information: must not be disclosed during community engagement
- At least 2 external technical events per quarter (for TCRC members)
FOSS Repository Requirements
- Must include: detailed README, contributor guidelines, license files
- Contribution guidelines: include coding standards and documentation requirements
- All external contributions: pass thorough review (automated checks + manual approval)
- Respond to community inquiries and merge requests within defined timeframe
- Major changes to project structure/licensing/governance: OOC majority vote required
- External mirrors: OOC responsible for keeping them synchronized and functional
Bounty Management
OOC manages bounties placed on issues and related policies and procedures.