AI Policy
The use of AI in software engineering is an evolving practice. For the NEXUS Framework it has been genuinely helpful — for research, bug investigation, initial test generation, and building out narrowly scoped methods. We treat it as an accelerant and force amplifier, not as a replacement for good old human thought.
Contributor Responsibility
Any AI-assisted contribution — whether code, tests, or documentation — must be reviewed, understood, and tested by a human developer before it is committed. Contributors are fully responsible for everything they submit, regardless of how it was produced. "The AI wrote it" is not a defense for a regression, an unsafe pattern, or a licensing issue.
You should understand every line you submit well enough to defend it in review and maintain it later.
Disclosure
There is no requirement to disclose minor use of AI assistance (autocomplete, rubber-ducking, asking for an explanation of unfamiliar code) in a PR. For more substantial AI-assisted changes, a one-line note in the PR description (e.g. "initial draft generated with <tool>, reviewed and adapted") is appreciated. It helps reviewers calibrate the kind of feedback they give.
The examples below were drafted on May 7, 2026. Just in case this page hasn't been updated and you're using some super-AI that's 1000x better — rendering the framing pointless — apply judgment, not a literal reading.
Acceptable Use-Cases
| Use | Reason | |
|---|---|---|
| ✅ | Implementing a narrowly scoped method. | Small, well-defined implementations are a great fit. The context is limited, and correctness can be verified and tested. |
| ✅ | Drafting unit or performance tests. | There is enough context in the project to generate useful tests. They still need to be confirmed correct and complete by a developer. |
| ✅ | Drafting Doxygen comments for an existing code. | Project skills can produce a reasonable first pass of in-source documentation directly from the code. A developer still needs to confirm each comment matches actual behavior. |
| ✅ | Drafting a documentation page (this site) from an existing class. | Type pages can be generated by the doc-new-type skill from a real source header. The output is a starting point, not a final draft. |
| ✅ | Explaining unfamiliar code, APIs, or engine internals. | Accelerates onboarding and review. The risk surface is your own understanding, not the codebase. |
| ✅ | Mechanical refactors (renames, signature updates, formatting passes). | The diff is small and reviewable; the model is doing tedious work, not making design decisions. |
Not Acceptable Use-Cases
| Use | Reason | |
|---|---|---|
| ❌ | Prompting AI to plan and code a new feature. | You are giving the wheel to the AI. Architecture, scope, and trade-offs are decisions a maintainer must own. |
| ❌ | Fully agentic work. | Expanding on the above, you need to understand the code you are submitting. Without a hand-on-the-wheel while writing it that won't happen. |
Repository Configuration
The framework is configured for Claude Code out of the box, but the guidelines above apply equally to any AI tool.
| Repository | What's Provided |
|---|---|
| NEXUS | A CLAUDE.md at TestProject/ describing the framework layout, plus skills under TestProject/.claude/skills/ for build, coding-style, running-tests, and writing-tests. |
| NEXUS.Docs | A repository-level CLAUDE.md describing this documentation site, plus the doc-new-plugin and doc-new-type skills for scaffolding new pages. |
These exist to lower the floor on AI-assisted contributions. A model with the right context produces better starting points and asks fewer wrong questions. They are not a substitute for review.