mirror of
https://github.com/l0ng-ai/openidea.git
synced 2026-11-06 16:08:05 +00:00
l0ng-ai
e4b8b76452
Adds a PR template (linked issue, what and why, how it was verified, review focus), a minimal reproduction field on the bug form and required acceptance criteria on the feature form, and CONTRIBUTING.md with the issue and PR rules. A PR check labels needs-info and leaves one comment when the issue link or the verification section is missing; it only reads the title and description. AGENTS.md is now tracked, with CLAUDE.md linking to it, and covers layout, rules, commands, the checks CI runs, pitfalls and parallel worktrees. The verify and issue-fix skills are shared under .agents/skills and linked from .claude/skills; the rest of .claude/ stays local.
1.7 KiB
1.7 KiB
Contributing to OpenIDEA
These rules apply to everyone, and to any coding agent working on their behalf. Project layout, coding rules, commands and checks are in AGENTS.md.
Issues
- One problem or request per issue. Use the issue forms.
- Bugs: steps that reproduce the problem from a fresh start. A minimal sample project is the fastest way to get a fix.
- Features: state the problem and the acceptance criteria. A feature is ready to
build once a maintainer labels it
planned. - Labels track status:
needs-infowaits on the reporter,needs-decisionwaits on a maintainer,plannedis accepted,needs-acceptancehas a fix waiting to be checked.
Pull requests
- One issue per PR, linked with
Closes #123. Feature PRs need aplannedissue. Docs, CI and pure refactors may skip the issue. - Reproduce the problem first, or write a test that fails before the fix.
- Fix the cause, and check whether the same cause breaks anything nearby.
- Keep the diff focused. Unrelated refactors go in their own PR.
- Title: Conventional Commits, e.g.
fix(editor): keep the caret visible after folding. - Fill in the template. Keep the description short and in plain words. If it doesn't fit in a few sentences, the PR is probably too big.
- How it was verified is required: the commands you ran and their results, and what else the change could affect. UI changes need before/after screenshots; multi-step interactions need a recording.
- If a change needs a product decision you can't make, ask in the issue and stop rather than guessing.
A check on each PR adds needs-info when the issue link or the verification
section is missing, and removes it once they're filled in.