i‑have‑adhd Contribution Workflow: Complete Guide to Pull Request Requirements

Contributors must declare authorship category, apply three required label groups, and provide a four‑section PR description to have a pull request accepted in the i‑have‑adhd repository.

The ayghri/i-have-adhd repository enforces a strict, safety‑first contribution workflow designed to maintain code quality and transparency around AI‑generated changes. This guide walks through the exact requirements defined in CONTRIBUTING.md so you can submit compliant pull requests without friction.

Select an Authorship Category

Every pull request must disclose who performed the substantive work. Per CONTRIBUTING.md lines 7‑12, choose one of three categories:

• Human‑authored – You wrote the code yourself.
• Autonomous agent‑authored – An AI agent generated the substantive change with minimal human direction.
• Hybrid – Substantial collaboration between human and AI agent.

This disclosure requirement ensures reviewers understand the provenance of every line of code and can calibrate their review accordingly.

Apply the Required Label Groups

Once you select an authorship category, you must attach exactly one label from each of three groups (CONTRIBUTING.md lines 19‑25):

Label Group	Valid Options	Purpose
Target	Target:Integrations, Target:Evals, Target:Rules, Target:Docs	Identifies the system area affected
Author	Author:Human, Author:Hybrid, Author:AI	Matches your chosen authorship category
Workflow	bug, enhancement, issue, question, duplicate	Describes the nature of the change

Missing any of these labels, or applying multiple labels from the same group, will block PR acceptance.

Example Label Declaration

<!-- Include this comment in your PR description -->
Target:Rules
Author:Human
Workflow:enhancement

Write a Complete PR Description

The description must contain four mandatory sections (CONTRIBUTING.md lines 31‑36). Each section serves a specific review purpose:

1. What changed and why – Concise technical summary with rationale.

2. Observable behavior before and after – Evidence such as test output, screenshots, or metrics demonstrating impact.

3. Safety, compatibility, and side‑effect considerations – Analysis of breaking changes, dependency risks, hook behavior modifications, and cost implications.

4. Verification performed – Exact commands executed and their complete results.

Full PR Description Template

### What changed and why

Implemented a new response brevity rule in `skills/i-have-adhd/SKILL.md` to reduce cognitive load for users with ADHD.

### Observable behavior before and after

- **Before:** Average response length 247 characters (see baseline in `tests/response_length_test.py`).  
- **After:** Average response length 152 characters, 38% reduction.

### Safety, compatibility, and side‑effects

- No new external dependencies added.  
- No modifications to hook behavior in `.cursor/rules`.  
- Backward compatible: existing integrations continue to function.

### Verification performed

```sh
python3 -m unittest discover -s tests -v
python3 scripts/run_evals.py validate

Results: 156 tests passed, 0 failed. Evaluation suite completed with no regressions.

## PR Readiness Checklist

A pull request is considered **ready for review** only when all following conditions are satisfied ([`CONTRIBUTING.md`](https://github.com/ayghri/i-have-adhd/blob/main/CONTRIBUTING.md) lines 92‑98):

- **Single authorship category** selected and any agent involvement fully disclosed.
- **Human submitter review** – You have personally reviewed the complete diff and removed any unrelated generated edits.
- **Focused change scope** – No drive‑by formatting changes, whitespace adjustments, or unrelated dependency updates.
- **Complete documentation** – All side‑effects, compatibility impacts, cost considerations, and verification steps are explicitly stated.

If any check fails, maintainers may close the PR without further review.

## Key Files for Contributors

Understanding these file roles helps you craft accurate PR descriptions and verification steps:

- **[`CONTRIBUTING.md`](https://github.com/ayghri/i-have-adhd/blob/main/CONTRIBUTING.md)** – Source of truth for all workflow requirements and label conventions.

- **[`skills/i-have-adhd/SKILL.md`](https://github.com/ayghri/i-have-adhd/blob/main/skills/i-have-adhd/SKILL.md)** – Canonical skill definition; changes here must remain synchronized with the Cursor rules copy.

- **`tests/`** – Unit test suite referenced in verification sections.

- **[`scripts/run_evals.py`](https://github.com/ayghri/i-have-adhd/blob/main/scripts/run_evals.py)** – Evaluation harness for behavioral validation; include its output in your PR description.

## Summary

- **Label requirement**: Exactly one label from each of Target, Author, and Workflow groups.
- **Authorship transparency**: Human, Hybrid, or Autonomous agent must be declared.
- **Description structure**: Four mandatory sections covering change rationale, behavioral evidence, safety analysis, and verification commands.
- **Review criterion**: Human‑reviewed diffs with focused scope and complete documentation.
- **Consequence**: Non‑compliant PRs face closure without maintainer negotiation.

## Frequently Asked Questions

### What happens if I forget to include the authorship category?

The PR will be considered incomplete and may be closed by maintainers. The authorship disclosure at [`CONTRIBUTING.md`](https://github.com/ayghri/i-have-adhd/blob/main/CONTRIBUTING.md) lines 7‑12 is mandatory for all submissions regardless of change size.

### Can I use multiple Target labels if my change affects several areas?

No. You must select exactly one Target label that best represents the primary purpose of your change. If your PR genuinely spans multiple areas, consider splitting it into focused, separate pull requests.

### Is there a specific format for verification command output?

No rigid format is required, but your verification section must include the exact commands run and their complete results—whether passing test counts, evaluation metrics, or error messages. Paste raw terminal output inside fenced code blocks for readability.

### Who needs to review the diff when using AI assistance?

The human submitting the PR must personally review the entire diff and remove any unrelated generated edits. This requirement at [`CONTRIBUTING.md`](https://github.com/ayghri/i-have-adhd/blob/main/CONTRIBUTING.md) lines 92‑98 applies even when the authorship category is Hybrid or Autonomous agent‑authored.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}