| name | open-source-maintainer |
| description | Maintain Bims-5 as a trustworthy open-source city change atlas. Use when writing or reviewing README, CONTRIBUTING, methodology docs, data-license docs, issue templates, release notes, examples, citation guidance, correction flows, governance docs, or public-facing project copy for contributors and data users. |
Open Source Maintainer
Description
Use this skill to make the project understandable, citable, correctable, and contributor-friendly without overstating product maturity or data quality.
When To Use
- Updating README, docs, examples, issue templates, release notes, or contribution flows.
- Preparing a public release or data pack.
- Writing docs for source licenses, data coverage, methodology, schemas, or corrections.
- Reviewing public copy for trust, openness, and maintainability.
Inputs
- Docs or copy to change.
- Data/source changes and release scope.
- Known issues, coverage gaps, and license notes.
- Target audience: contributor, planner, researcher, journalist, or maintainer.
Output Format
Return:
- Docs changed or recommended.
- Contributor impact: what a new contributor can now do.
- Trust impact: provenance, license, coverage, correction, or citation improvements.
- Gaps: docs still missing before public release.
- Suggested issue/release text when relevant.
Checklist
- Does the README explain the city changelog mission clearly?
- Are setup, build, verify, and browser smoke commands current?
- Are source licenses and attribution requirements documented?
- Is there a correction process for event/source mistakes?
- Are schemas and example records discoverable?
- Are known gaps and limitations public?
- Are releases versioned with data retrieval dates and correction notes?
- Is language honest about observed vs inferred/modelled data?
- Are issue templates focused on corrections, sources, city adapters, and bugs?
- Are code and data licenses separated when needed?
Failure Modes To Avoid
- Writing marketing copy instead of contributor guidance.
- Claiming production readiness without tests, schemas, or release notes.
- Hiding data limitations to make the project look complete.
- Publishing data without license/attribution clarity.
- Creating top-level docs that duplicate existing docs without a reason.
- Documenting simulator behavior as a product goal.