Contributing

This project uses Claude Code with a multi-agent workflow for development. Agent teams are an experimental feature — this repo includes the required .claude/settings.json that enables it. When you ask Claude to implement a feature or fix a bug, it coordinates a team of specialized agents that each handle a distinct phase.

Prerequisites

• .NET 10 SDK or later
• Git
• Claude Code CLI — requires Node.js 18+
• Claude Max plan (or Team/Enterprise) — agent teams run multiple sessions concurrently and consume significantly more tokens than single-agent usage
• WSL on Windows — Claude Code requires a Unix-like shell
• tmux (optional) — enables split-pane view of each teammate; without it, teammates run in-process in the same terminal
• Ruby (optional) — only needed to preview docs locally

The experimental agent teams feature is already enabled in this repo via .claude/settings.json.

Agent Roles

Role	Responsibility
Lead (Architect)	Plans the approach, spawns teammates, coordinates, delivers the PR
Implementer	Writes production code in src/
Tester	Writes unit tests in tests/
Reviewer	Reviews all changes for quality, security, and patterns
Documenter	Updates Jekyll docs and XML doc comments

Development Lifecycle

Every feature or fix progresses through six phases:

1. Plan

The Lead analyzes the requirement, researches existing NuGet packages that might already solve the problem, and designs the approach. It creates a task list with dependencies and spawns the Implementer and Tester agents.

2. Implement

The Implementer writes production code in src/ following the plan and the rules in .claude/rules/architecture.md. It ensures dotnet build produces zero warnings before marking tasks complete.

3. Test

The Tester writes unit tests in tests/ using FluentAssertions (.Should() syntax), the Arrange-Act-Assert pattern, and Method_Scenario_ExpectedResult naming. This phase can run in parallel with implementation once interfaces are defined.

4. Review

The Reviewer checks all changes for:

• Code style and .editorconfig compliance
• Security issues (OWASP top 10)
• Correct use of central package management (no versions in .csproj)
• Test coverage for every new public API

5. Document

Only required when the public API surface changes. The Documenter updates XML doc comments on new/changed public members and refreshes the Jekyll docs as needed.

6. Deliver

The Lead verifies all tasks are complete, runs dotnet build, dotnet test, and dotnet pack, then creates a PR against main.

Getting Started

To add a feature or fix a bug, describe what you need in Claude Code:

Add a Result<T> type that wraps success/failure outcomes

Fix the null reference in SampleTool when input is empty

When prompted, Claude follows the workflow defined in CLAUDE.md — creating a feature branch, planning the approach, spawning agents, and delivering a PR.

Quality Gate

Every PR must pass before merging:

• dotnet build --configuration Release — zero warnings
• dotnet test --configuration Release — all tests pass
• dotnet pack — packages build successfully
• Every new public type/member has XML doc comments
• Every new public type/member has corresponding unit tests
• No secrets, credentials, or sensitive data in committed files

Manual Development

You can also develop without Claude Code. Follow the same conventions:

1. Create a feature branch from main (e.g., feat/my-feature).
2. Write production code in src/ following .claude/rules/architecture.md.
3. Write tests in tests/ following .claude/rules/testing.md.
4. Ensure the quality gate passes.
5. Open a PR against main.