Thanks for contributing. TheWorkshop's quality comes from keeping its boundary small.
In scope:
- clearer
WORKSHOP.mdcontract semantics - safer and more useful
init,check, orstatusbehavior - Codex skill and plugin packaging compatibility
- focused tests, documentation, accessibility, and portability improvements
Out of scope:
- project-management hierarchies, dashboards, or task trackers
- agent orchestration, custom subagent telemetry, or background runners
- reward systems, spend accounting, memory curation, or provider adapters
- domain workflows already owned by another skill or Codex surface
- hosted-product features and private operator workflows
Before proposing a new subsystem, explain why the outcome cannot be achieved through the contract, native Codex behavior, or an existing specialized skill.
Every pull request should include:
- A concrete problem and expected behavior.
- The smallest coherent change.
- Tests for behavior changes.
- Documentation for interface or contract changes.
- Compatibility and rollback notes when relevant.
Requires Python 3.11 or newer. No third-party packages are needed.
python3 -m compileall -q skills/theworkshop/scripts tests
python3 -m unittest discover -s tests -v
git diff --checkFor release preparation, also run the current Codex skill and plugin validators described in RELEASE_CHECKLIST.md.
- I linked an issue or explained why none is needed.
- I kept the change within the lean product boundary.
- I added or updated tests for non-trivial behavior.
- I updated
README.md, the skill reference, or templates when needed. - I described risk and rollback for risky changes.
Maintainers use one type label and one status label:
type:bug,type:enhancement,docsstatus:needs-repro,status:accepted,status:out-of-scope