Create CONTRIBUTING.md

[not2pixel]

No description provided.

[qodo-code-review]

Review Summary by Qodo

Add comprehensive CONTRIBUTING.md guidelines

📝 Documentation

Walkthroughs

Description

• Add comprehensive contributing guidelines for DuoHacker project
• Include setup instructions, PR guidelines, and code style standards
• Provide examples of good vs bad code practices
• Document testing requirements and review process

Diagram

flowchart LR
  A["New CONTRIBUTING.md"] --> B["Getting Started Guide"]
  A --> C["PR Guidelines"]
  A --> D["Code Style Examples"]
  A --> E["Testing Requirements"]
  A --> F["Review Process"]

Loading

File Changes

1. CONTRIBUTING.md 📝 Documentation +134/-0

New comprehensive contributing guidelines document

• Created new contributing guide with 134 lines of documentation
• Includes step-by-step setup instructions for forking and cloning
• Defines PR guidelines covering focus, testing, and commit message format
• Provides code style guidelines with JavaScript examples showing good vs bad practices
• Documents testing procedures including manual testing and edge cases
• Outlines review process and contribution areas

CONTRIBUTING.md

---

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (2) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX Issues (0)

1. Unclear edit entrypoints 🐞 Bug ⚙ Maintainability

Description

CONTRIBUTING.md instructs contributors to “Make Changes” without identifying which userscript file
is the source of truth (the repo contains both v1 and v2 scripts, while README points installers to
a different root filename). This ambiguity will cause contributors to modify the wrong file and
produce PRs that don’t affect the distributed/installed script.

Code

CONTRIBUTING.md[R20-24]

+3. **Make Changes**
+   - Write clean, readable JavaScript/Tampermonkey script code
+   - Follow existing code style and patterns
+   - Add comments for complex logic or API calls
+   - Test thoroughly before submitting

Evidence

The contribution steps do not mention the actual versioned script locations, even though the repo
includes separate v1 and v2 userscripts, and the README directs users to install from a root-level
DuoHacker.user.js URL (different from the versioned filenames).

CONTRIBUTING.md[20-31]
v1/duohacker-v1.user.js[1-5]
v2/duohacker-v2.user.js[1-5]
README.md[6-40]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
CONTRIBUTING.md doesn't tell contributors which userscript file is the canonical source (v1 vs v2) and how changes map to the install/distribution artifact referenced by README.

### Issue Context
The repo contains versioned userscripts under `v1/` and `v2/`, while README links to `DuoHacker.user.js`. Without guidance, contributors may edit the wrong file and/or be unable to validate that their change affects what users install.

### Fix Focus Areas
- CONTRIBUTING.md[20-38]

### Suggested change
Add a short section under “Make Changes” that explicitly states:
- Which file is the primary target for new work (e.g., `v2/duohacker-v2.user.js`)
- Whether `v1` is legacy/maintenance-only
- If there is a release/build/copy step to produce the install script (and where it lives), document the exact command/process; if not, update contributor expectations accordingly.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Example uses wrong identifiers 🐞 Bug ≡ Correctness

Description

The CONTRIBUTING.md code example references DUOLINGO_API (not present in the repo) and uses
delay() even though the v2 script uses a different helper name (_sleep). Contributors copying
this example will start from patterns that don’t match the codebase.

Code

CONTRIBUTING.md[R67-75]

+const probeSlugWithRetry = async (slug, maxRetries = 3) => {
+  // Implement exponential backoff for rate limiting
+  for (let i = 0; i < maxRetries; i++) {
+    try {
+      const response = await fetch(`${DUOLINGO_API}/${slug}`);
+      if (response.ok) return response.json();
+    } catch (error) {
+      if (i < maxRetries - 1) await delay(Math.pow(2, i) * 1000);
+    }

Evidence

The example fetches from ${DUOLINGO_API} and calls delay(...), but the v2 userscript defines
GOALS_API and _sleep(...) instead; only v1 defines delay, and neither script defines
DUOLINGO_API. This makes the example non-copy-pastable and inconsistent with the repo’s current
naming.

CONTRIBUTING.md[65-86]
v2/duohacker-v2.user.js[1094-1099]
v1/duohacker-v1.user.js[352-354]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The CONTRIBUTING.md example uses identifiers that don't match the repository (`DUOLINGO_API`, `delay`). This is misleading for contributors.

### Issue Context
In v2, the codebase uses `_sleep` and `GOALS_API` (and does not define `DUOLINGO_API`). In v1, `delay` exists but `DUOLINGO_API` still does not.

### Fix Focus Areas
- CONTRIBUTING.md[64-86]

### Suggested change
Update the snippet to either:
- Use real identifiers from the canonical version (once defined in the doc), or
- Explicitly label the snippet as pseudocode and define placeholder constants/functions inline (e.g., `const API_BASE = ...; const sleep = ...`).
Also consider showing the same naming conventions used in the current script (e.g., `_sleep` vs `delay`).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

ⓘ The new review experience is currently in Beta. Learn more