If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/QianMo/Unity-Design-Pattern shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

AVOID — Stale and unlicensed — last commit 6y ago

• 3 active contributors
• Tests present
• ⚠ Stale — last commit 6y ago
• ⚠ Small team — 3 contributors active in recent commits
• ⚠ Single-maintainer risk — top contributor 98% of recent commits
• ⚠ No license — legally unclear to depend on
• ⚠ No CI workflows detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live QianMo/Unity-Design-Pattern repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/QianMo/Unity-Design-Pattern.

What it runs against: a local clone of QianMo/Unity-Design-Pattern — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in QianMo/Unity-Design-Pattern | Confirms the artifact applies here, not a fork | | 2 | Default branch master exists | Catches branch renames | | 3 | Last commit ≤ 2315 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of QianMo/Unity-Design-Pattern. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/QianMo/Unity-Design-Pattern.git
#   cd Unity-Design-Pattern
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of QianMo/Unity-Design-Pattern and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "QianMo/Unity-Design-Pattern(\\.git)?\\b" \\
  && ok "origin remote is QianMo/Unity-Design-Pattern" \\
  || miss "origin remote is not QianMo/Unity-Design-Pattern (artifact may be from a fork)"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 2315 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~2285d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/QianMo/Unity-Design-Pattern"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

A comprehensive Unity C# implementation of all 23 Gang of Four design patterns plus game-specific patterns from Game Programming Patterns, organized into Behavioral, Structural, and Creational categories. Each pattern includes both a structural blueprint (in Assets/.../Structure/) and 1-3 real-world Unity examples (in Assets/.../Example*/) with accompanying test scenes. Monolithic Asset structure: Assets/Behavioral Patterns/, Assets/Structural Patterns/, Assets/Creational Patterns/ folders each containing pattern-specific subdirectories. Within each pattern (e.g., Assets/Behavioral Patterns/Command Pattern/): a Structure/ folder with base classes/interfaces + test scene, and Example1/, Example2/ folders with concrete implementations + .unity scenes. Each pattern may include a README.md.

Unity game developers and C# programmers learning design patterns in a game context; educators teaching software architecture through interactive Unity scenes; game engineers refactoring codebases to adopt proven architectural patterns like Command, Observer, and Strategy.

Actively maintained educational resource with all 23 GoF patterns implemented and runnable in Unity. No visible CI/CD pipeline, automated tests, or recent commit metadata provided, but the systematic Structure/Example organization and complete pattern coverage suggest stable, intentional development. More suitable as a reference guide than production framework.

Single-maintainer educational project with no apparent automated testing, CI/CD, or dependency management visible; patterns are isolated implementations rather than a cohesive library, so no breaking changes across patterns. Risk is low for reference/learning use but high if attempting to integrate this as a production library—patterns lack version pinning, test coverage, and unified API contracts.

No active commit history or PR data visible in provided metadata. Repository appears complete (23 GoF patterns finished per README), but state of ongoing development, bug fixes, or documentation updates is unknown from the file snapshot.

1. Clone: git clone https://github.com/QianMo/Unity-Design-Pattern.git
2. Open in Unity (compatible version not specified in metadata—check README for requirements)
3. Navigate to Assets/Behavioral Patterns/Command Pattern/Example2/ and open TestCommandExample2.unity scene to see a working example
4. Inspect CommandExample1.cs, TVRemove.cs, ICommand.cs to understand Command pattern structure

Daily commands: Open any .unity scene file in the Unity Editor (e.g., Assets/Behavioral Patterns/Command Pattern/Example2/TestCommandPattern.cs references a scene). No build pipeline or CLI; interaction is through Unity Editor scene playback or C# script inspection. Press Play in Editor to execute scene logic.

• [Assets/Behavioral Patterns/Command Pattern/Example2/ICommand.cs](https://github.com/QianMo/Unity-Design-Pattern/blob/master/Assets/Behavioral Patterns/Command Pattern/Example2/ICommand.cs): Defines the Command interface contract—core abstraction all command examples must implement; starting point for understanding encapsulated requests as objects.
• [Assets/Behavioral Patterns/Command Pattern/Example2/TestCommandPattern.cs](https://github.com/QianMo/Unity-Design-Pattern/blob/master/Assets/Behavioral Patterns/Command Pattern/Example2/TestCommandPattern.cs): Demonstrates real-world Command usage: RemoteControl, Television, Radio, Button binding—shows how to queue and execute commands polymorphically.
• [Assets/Behavioral Patterns/Chain of Responsibility Pattern/Structure/ChainOfResponsibilityStructure.cs](https://github.com/QianMo/Unity-Design-Pattern/blob/master/Assets/Behavioral Patterns/Chain of Responsibility Pattern/Structure/ChainOfResponsibilityStructure.cs): Blueprint for Chain of Responsibility: shows handler interface, successor linking, and request forwarding—essential for understanding dynamic responsibility delegation.
• [Assets/Behavioral Patterns/Chain of Responsibility Pattern/Example1/ChainOfResponsibilityExample1.cs](https://github.com/QianMo/Unity-Design-Pattern/blob/master/Assets/Behavioral Patterns/Chain of Responsibility Pattern/Example1/ChainOfResponsibilityExample1.cs): Concrete chain example (likely HTTP request handling or approval workflow); illustrates how requests flow through a chain until handled or dropped.
• README.md: Complete index of all 23 GoF patterns + Game Programming Patterns with links and references; essential navigation and context for the entire repo.

To add a new pattern: 1. Create Assets/[Category Patterns]/[Pattern Name]/Structure/ with abstract base classes and a test scene. 2. Create Assets/[Category Patterns]/[Pattern Name]/Example1/ with concrete implementations and a gameplay scene. 3. Follow naming convention seen in existing patterns (e.g., ChainOfResponsibilityStructure.cs, CommandExample1.cs). 4. Add interfaces in separate files (e.g., ICommand.cs, IElectronicDevice.cs). 5. Optionally add README.md explaining the pattern.

No explicit Unity version specified; patterns use MonoBehaviour but may not be compatible with recent Unity 2022+/2023+ if they rely on deprecated APIs. No .gitignore visible (provided as .gitignore file but not detailed), so local build artifacts may pollute repo. Test scenes (*.unity files) are binary and not easily version-diffable. Patterns are isolated—no shared base class hierarchy, so copy-pasting logic between patterns is necessary. Example code is not unit-testable in isolation; validation happens only in Editor play mode on scenes.

• Gang of Four Design Patterns (23 patterns) — This repo implements the canonical taxonomy of object-oriented design; understanding all 23 is essential for writing maintainable, scalable game and application code.
• Command Pattern / Command Queue — Central to game input handling, undo/redo systems, and action queueing shown in Example2; critical for decoupling UI from game logic in multiplayer games.
• Chain of Responsibility — Used in event propagation, request filtering, and hierarchical decision-making (e.g., damage reduction through armor → shields → health); essential for flexible conditional logic.
• Observer Pattern / Event System — Decouples publishers from subscribers in game events (health changes, UI updates, audio triggers); foundational to reactive gameplay systems.
• Object Pool Pattern — Critical game optimization: reusing bullet/particle objects instead of allocating/deallocating reduces GC spikes and improves frame rate in performance-sensitive games.
• Strategy Pattern — Enables runtime swapping of algorithms (AI behaviors, movement controllers, combat strategies) without modifying client code; flexible and testable.
• Component Pattern (ECS-adjacent) — Alternative to inheritance hierarchies for game entities; allows composing behaviors dynamically (e.g., Health + Armor + AI components on an enemy).

• Naphier/unity-design-patterns — Direct predecessor and inspiration for this repo's Structure/Example organization; lighter reference implementation for core GoF patterns in Unity.
• robertpanvip/csharp-design-patterns — Parallel pure C# implementation of design patterns without Unity coupling; useful for understanding patterns as language-agnostic concepts.
• refactoring-guru/design-patterns-csharp — Refactoring Guru's official C# design patterns examples; canonical reference with diagrams and detailed explanations for cross-validation.
• game-programming-patterns/game-programming-patterns — Official repository of 'Game Programming Patterns' book; source material for the game-specific patterns partially implemented in this repo.
• Unity-Technologies/EntityComponentSystemSamples — Official Unity ECS examples; modern complement to traditional OOP patterns, showing how newer Unity architecture patterns differ from Gang of Four.

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive README.md files for each Behavioral Pattern folder

The repo shows Chain of Responsibility has a README.md, but most other Behavioral Patterns (Command Pattern, etc.) appear to lack top-level documentation explaining the pattern's purpose, when to use it, and how the examples differ. This is a high-value gap since the repo explicitly states 'Each pattern contains the corresponding structure implementations, application examples and diagrams.' Adding these READMEs would match the stated repo promise and improve discoverability.

• [ ] Create Assets/Behavioral Patterns/Command Pattern/README.md with pattern explanation, use cases, and example descriptions
• [ ] Create similar READMEs for all other Behavioral Pattern folders missing them
• [ ] Include links to Gang of Four pattern definitions and brief explanation of when each example applies
• [ ] Reference the structure vs. example folders in each README for clarity

Create a master index/navigation document at repo root

With 23+ Gang of Four patterns and Game Programming Patterns organized across multiple nested folders, contributors and users cannot easily discover all available patterns or understand the repo structure at a glance. A root-level index (INDEX.md or PATTERNS.md) would dramatically improve navigation and serve as the single source of truth for pattern coverage.

• [ ] Create Assets/PATTERNS_INDEX.md or INDEX.md at repo root listing all 23 GoF patterns with checkmarks for completion status
• [ ] Organize by category (Creational, Structural, Behavioral) matching the Assets folder structure
• [ ] Include links to each pattern's Structure and Examples folders
• [ ] Add a separate section for Game Programming Patterns with implementation status
• [ ] Document which patterns have multiple examples and highlight the most complex/useful ones

Add a test runner script or testing documentation for validating all example scenes

The repo contains many .unity scene files (TestChainOfRespExample1.unity, command pattern example 1.unity, etc.) but there is no documented way to validate that all examples work correctly. This is critical for a reference repo where users learn from working examples. Creating an automated test approach or clear testing guide would ensure quality.

• [ ] Document in CONTRIBUTING.md the manual testing steps: which scenes to load, what to expect in Inspector/Console output
• [ ] Create a Unity test assembly (Assets/Tests/) with EditorTests that validates key class interfaces exist (ICommand, IChainHandler, etc.)
• [ ] Add a script or workflow document listing all example scenes and their expected outputs when run
• [ ] Optionally add a CI workflow (.github/workflows/) that loads and validates scene integrity using Unity Test Framework

• Add C# unit tests (NUnit/xUnit) for pattern correctness: Currently all validation is manual/scene-based. Create Tests/Behavioral Patterns/CommandPatternTests.cs to verify ICommand implementations can be queued, executed, and undone without Unity Editor.
• Document missing pattern examples: Some patterns (e.g., Mediator, Interpreter, Visitor in Behavioral) have Structure but may lack Example2 or Example3; implement a game scenario (e.g., Mediator for UI controller, Visitor for game object traversal) and add it to corresponding Example folder.
• Write implementation checklists in README.md for each pattern: Add a table showing which patterns have Structure implementation ✓, Example1 ✓, Example2 ✓, Example3 ✓, Documentation ✓, and Tests ✗ to highlight gaps and guide new contributors.

This is an educational repository focused on implementing design patterns in Unity C#. No critical or high-severity vulnerabilities were identified. The codebase does not appear to handle sensitive data, make external requests, or execute user input in dangerous ways typical of security-critical applications. Primary concerns are: (1) lack of visible dependency management documentation, (2) typical characteristics of educational code without production-level security hardening, and (3) absence of security governance documentation. For an educational project, the security posture is acceptable. However, if patterns from this repository are used in production applications, developers should add appropriate input validation, error handling, and security-specific considerations.

• Low · No visible dependency management or package lock files — Root directory / Assets folder. The repository does not show any package.json, packages.config, or similar dependency management files. This makes it difficult to track dependencies and their versions, potentially leading to the use of outdated or vulnerable packages. Fix: Implement proper dependency management using Unity's package manager (UPM) or maintain a documented list of all external dependencies with version pinning.
• Low · Educational codebase without security hardening — All C# script files across Behavioral Patterns and other examples. This is an educational repository focused on design pattern implementation in Unity. Educational examples often lack production-level security considerations such as input validation, error handling, and secure coding practices. Fix: Add security-focused comments and validation examples in code. Create documentation on how to implement these patterns securely in production environments.
• Low · Missing .gitignore security configurations — .gitignore file. While a .gitignore file is present, there is no visibility into its contents. It may not properly exclude sensitive files that could be accidentally committed (e.g., API keys, local configuration files, build artifacts). Fix: Ensure .gitignore includes exclusions for: local configuration files, API keys, credentials, local build directories, and IDE-specific files. Consider using a standard template for Unity projects.
• Informational · No security policy or vulnerability disclosure process — Root directory. The repository lacks a SECURITY.md file or similar documentation describing how security vulnerabilities should be reported, which is important even for educational projects. Fix: Create a SECURITY.md file with guidance on responsible vulnerability disclosure and security best practices for contributors.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.