Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
69 lines (45 loc) · 2.5 KB

CONTRIBUTING.md

File metadata and controls

69 lines (45 loc) · 2.5 KB

Contributing

Thanks for contributing to Repo Canvas.

This project is intended to be collaborative, practical, and clear about its boundaries. We want contributions that make the tool more useful without blurring what it is for.

License

Repo Canvas is released under the MIT License. That license covers use, modification, and distribution of the code.

Our collaboration norms and product guardrails are documented here and in the README. They describe how we want to work together on the project. They are not an additional software license.

Good Contributions

We especially welcome contributions that improve:

  • repo inspection and product understanding
  • capture planning and Playwright capture reliability
  • template quality and layout flexibility
  • export workflows and manifest quality
  • agent integrations for Claude Code, Codex, and Gemini
  • guardrails that keep copy and imagery grounded in real product behavior

Before Opening A PR

Please include:

  • the repo or product context you tested against
  • the asset type or workflow you were working on
  • the expected behavior
  • the actual behavior
  • screenshots, manifests, or logs when they help explain the issue

If a change is conceptual or high-risk, open an issue first and discuss the direction before implementation.

Project Boundaries

Repo Canvas is for static assets. It is not a video-rendering tool and it should not replace Remotion.

Please keep these boundaries intact:

  • Do not add workflows that fabricate product UI.
  • Do not add copy-generation behavior that invents features absent from the repo.
  • Treat Playwright capture as the source of truth for product screens.
  • Use OpenAI or Gemini only for supporting visuals such as textures, backgrounds, or abstract brand elements.
  • Prefer deterministic rendering and reproducible outputs over opaque or non-repeatable behavior.
  • Make assumptions explicit when changing repo understanding or copy logic.

Documentation Expectations

If you change the public workflow, update the corresponding docs in the same change when appropriate:

  • README.md
  • HOWTO.md
  • manifests or config defaults
  • integration templates under integrations/

Collaboration Style

Be direct, specific, and practical.

Helpful reviews and proposals usually explain:

  • what problem is being solved
  • why the current behavior is insufficient
  • what tradeoff the change introduces
  • how the change was validated

If you are unsure whether a change crosses a product or safety boundary, raise the question before implementing it.