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/Creators-of-Create/Create 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.

WAIT — Mixed signals — read the receipts

• Last commit 1w ago
• 22+ active contributors
• Other licensed
• CI configured
• ⚠ Concentrated ownership — top contributor handles 54% of recent commits
• ⚠ Non-standard license (Other) — review terms
• ⚠ No test directory 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 Creators-of-Create/Create repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/Creators-of-Create/Create.

What it runs against: a local clone of Creators-of-Create/Create — 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 Creators-of-Create/Create | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch mc1.21.1/dev exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 40 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of Creators-of-Create/Create. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/Creators-of-Create/Create.git
#   cd Create
#
# 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 Creators-of-Create/Create and re-run."
  exit 2
fi

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

# 2. License matches what RepoPilot saw
(grep -qiE "^(Other)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Other\"" package.json 2>/dev/null) \\
  && ok "license is Other" \\
  || miss "license drift — was Other at generation time"

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

# 4. Critical files exist
test -f "build.gradle" \\
  && ok "build.gradle" \\
  || miss "missing critical file: build.gradle"
test -f "gradle.properties" \\
  && ok "gradle.properties" \\
  || miss "missing critical file: gradle.properties"
test -f "settings.gradle" \\
  && ok "settings.gradle" \\
  || miss "missing critical file: settings.gradle"
test -f "Jenkinsfile" \\
  && ok "Jenkinsfile" \\
  || miss "missing critical file: Jenkinsfile"
test -f ".github/workflows/build.yml" \\
  && ok ".github/workflows/build.yml" \\
  || miss "missing critical file: .github/workflows/build.yml"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 40 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~10d)"
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/Creators-of-Create/Create"
  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).

Create is a NeoForge mod for Minecraft that adds animated building blocks and mechanical contraptions designed for aesthetic automation. It provides decorative tech components (gearboxes, conveyors, rotating shafts) that players arrange visually in-world rather than through UIs, with an in-game interactive documentation system called 'Ponder' that teaches each mechanic through guided demonstrations. Monolithic Gradle-based mod project: src/main contains the core mod code organized by feature (likely under com.simibubi.create package structure); src/generated contains auto-generated blockstates, models, and textures (acacia_window.json, adjustable_chain_gearshift.json, etc.). Build configuration uses NeoForge ModDevGradle, Parchment mappings for deobfuscation, and Silk for annotation processing; resources include accesstransformers for reflection access.

Minecraft players and modders who want creative mechanical building challenges; mod developers contributing to the NeoForge ecosystem. They value visual automation gameplay and aesthetic customization over traditional tech mod UIs.

Actively maintained and production-ready. The mod has substantial community support (CurseForge + Modrinth distribution), a Discord with 620k+ members, and CI/CD via GitHub Actions (build.yml, label-actions.yml, localization.yml). The codebase is large (~9.6MB Java) with generated asset pipelines and organized Gradle structure, indicating mature tooling.

Risk is moderate: single lead maintainer (simibubi) creates potential continuity risk, but strong community and Patreon support mitigate this. NeoForge version pinning (neo_version in gradle.properties) ties updates to Minecraft releases. The mod uses Java 21+ toolchain, which may create compatibility friction for older contributor environments. No visible test directory in top 60 files suggests limited automated testing coverage.

Active development visible through: GitHub Actions workflows for CI (build.yml), community localization via Crowdin (crowdin.yml, localization.yml), automated label management (label-actions.yml). The changelog.md and version tracking in gradle.properties indicate regular release cycles. No specific PR/issue data in file list, but issue templates (bug.yml, crash.yml, config.yml) suggest active issue management.

git clone https://github.com/Creators-of-Create/Create.git
cd Create
./gradlew build
./gradlew runClient  # Launch the mod in dev environment

Use gradlew (not Gradle directly) to respect the wrapper version.

Daily commands:

./gradlew runClient      # Start Minecraft client with mod loaded
./gradlew build          # Compile mod JAR
./gradlew genSourcesMaps # Generate Parchment deobfuscated sources

• build.gradle — Primary Gradle build configuration for the NeoForge mod; defines dependencies, version management, and all build plugins including ModDevGradle and Silk data generation.
• gradle.properties — Mod metadata and version constants (mod_version, game_version) referenced throughout the build pipeline and changelog generation.
• settings.gradle — Gradle project structure and repository configuration; essential for dependency resolution and workspace setup.
• Jenkinsfile — CI/CD pipeline definition for automated builds, testing, and artifact publishing across multiple Minecraft versions.
• .github/workflows/build.yml — GitHub Actions workflow for building, testing, and publishing releases; defines the automated deployment process.
• crowdin.yml — Localization (i18n) configuration for crowdsourced translation management across multiple languages.
• log4j.xml — Logging configuration for development and runtime diagnostics; critical for troubleshooting mod behavior.

Add a new decorative or mechanical block

1. Define the block class in src/main/java/com/simibubi/create/content/... with properties (hardness, sound, material) (src/main/java (assumed; not in file list but inferred from package structure))
2. Register the block in the mod's block registry (likely BlockRegistry.java or similar) (src/main/java (registry class; exact path not shown))
3. Create or regenerate blockstate JSON via Silk data generator (build.gradle triggers silk task) (src/generated/resources/assets/create/blockstates/{block_name}.json)
4. Add textures to src/main/resources/assets/create/textures/block/ (src/main/resources (assumed; texture path not in list))
5. Register language strings in src/main/resources/assets/create/lang/en_us.json (src/main/resources (assumed; lang file not in list))
6. Update changelog.md with feature description (changelog.md)

Add a new feature in a different Minecraft version

1. Update mod_version in gradle.properties with new version string (gradle.properties)
2. Update minecraft_version in gradle.properties to target version (e.g., 1.21.1) (gradle.properties)
3. Run Gradle build task; ModDevGradle and Silk will regenerate blockstate JSONs and mappings (build.gradle)
4. Tag git commit; Jenkinsfile detects tag and triggers multi-version build matrix (Jenkinsfile)
5. Update crowdin.yml with new locale sources if translation keys changed (crowdin.yml)

Publish a new release

1. Update changelog.md with release notes and new version number (changelog.md)
2. Update version in gradle.properties (remove -dev suffix) (gradle.properties)
3. Create git tag matching version (e.g., v0.5.1) (Jenkinsfile (triggers on tag))
4. Jenkinsfile and build.yml automatically build, test, and publish to CurseForge/Modrinth via mod-publish-plugin (build.gradle (defines publishing config))
5. GitHub release created automatically with artifacts attached (.github/workflows/build.yml)

Improve translations / add new language

1. Source English translation keys are defined in src/main/resources/assets/create/lang/en_us.json (src/main/resources (lang directory, not in list))
2. Submit translations via Crowdin web interface (external tool, but config points to it) (crowdin.yml)
3. Crowdin syncs translated strings back; localization.yml workflow automatically commits new language files (.github/workflows/localization.yml)
4. New language JSON files appear in src/main/resources/assets/create/lang/ after workflow runs (src/main/resources (lang files auto-created))

• NeoForge ModDevGradle — Provides out-of-the-box Minecraft development environment setup, MCP mappings, and automatic resource reobfuscation for the latest Minecraft versions (1.21.1 target).
• Silk Data Generation (Ithundxr) — Eliminates manual JSON blockstate boilerplate by code-generating blockstate definitions, models, and asset metadata from Java class annotations and code structure.
• Gradle with Blossom — Enables string substitution at build time (git hash, build number) for automatic version injection into mod metadata and crash logs.
• GitHub Actions + Jenkinsfile dual CI — GitHub Actions handles PR validation and artifact hosting; Jenkinsfile coordinates multi-version release builds across Minecraft versions with Jenkins infrastructure.
• Crowdin for Localization — Decouples translation management from code; enables community crowdsourcing of translations without requiring code commits, with automated sync back to repository.
• mod-publish-plugin — Single Gradle plugin abstracts publishing to multiple platforms (CurseForge, Modrinth) with standardized metadata, reducing maintenance burden for multi-platform releases.

• Dual CI/CD: GitHub Actions + Jenkinsfile

  • Why: GitHub Actions is free and integrated; Jenkinsfile offloads heavy compilation to dedicated build server.
  • Consequence: Requires maintaining two separate build configurations; GitHub Actions used for fast PR feedback while Jenkinsfile handles official releases.

• Auto-generate blockstate JSONs via Silk instead of manual definition

  • Why: Reduces boilerplate and sync bugs; block definitions are source-of-truth in Java code.
  • Consequence: Harder to hand-tune individual blockstate variants; less flexibility for non-standard block state logic, though most use cases are covered.

• Crowdin for translations vs. in-repo translation files

  • Why: Enables non-programmer community contributors to translate; reduces review burden on maintainers.
  • Consequence: Translation workflow is external; risk of desync if crowdin.yml config is stale; requires webhook automation to stay in sync.

• Single gradle.properties for version + minecraft_version

  • Why: undefined
  • Consequence: undefined

Java 21 toolchain requirement: Must have JDK 21+ installed; older environments will fail. NeoForge version lock: gradle.properties pins neo_version—upgrading requires rebuilding against new Minecraft/NeoForge, not just updating a version number. Generated sources: src/generated/ is gitignored but required at runtime; run ./gradlew build first or IDE won't find generated blockstates. Parchment mapping fallback: If parchment_version='none', mapping step is skipped; may cause obfuscated method names. No test framework visible: Rely on runClient for validation; no pytest/JUnit setup apparent.

• Access Transformers (AccessTransformer) — Create uses accesstransformer.cfg to make Minecraft's private methods/fields public; essential for understanding how mods interact with closed-source game code
• Block State JSON and Model Baking — Create auto-generates blockstate JSONs for 50+ variants of blocks; understanding this pipeline is critical for adding new decorative blocks
• Capability System (ICapabilityProvider) — NeoForge mods use capabilities to attach data (rotational speed, stress, etc.) to blocks and items; Create's mechanical contraptions rely on this for component communication
• Parchment Mappings (Deobfuscation) — Parchment provides human-readable names for Minecraft internals (e.g., 'getBlockState' instead of 'a()'); Create uses this via gradle.properties for developer-friendly code
• Mechanical Rotation and Stress Simulation — Create's core mechanic: simulating rotational force between connected gears and shafts; understanding the stress/speed propagation algorithm is key to adding new kinetic components
• Network Packet Synchronization (Server↔Client) — Create must sync block rotation states between server and client; NeoForge's networking layer handles this, but improper sync causes desync bugs
• GLSL Shaders in Minecraft — Create uses ~4.3KB of GLSL for custom rendering (decorative block effects); understanding Minecraft's shader integration is needed for visual features

• Fabricators-of-Create/Create — Fabric port of the same mod; directly comparable codebase showing how to adapt Create to a different modding framework
• NeoForged/NeoForge — Core modding framework Create depends on; understanding NeoForge internals is essential for advanced mod hacking
• MinecraftForge/MinecraftForge — Legacy predecessor to NeoForge; some architectural patterns and access transformer conventions derive from Forge
• Creators-of-Create/CreateAdditions — Official companion mod extending Create with extra features; shows integration patterns and code organization conventions
• ParchmentMC/Parchment — Provides human-readable Minecraft method/field names used in Create's build process; critical for development readability

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 unit tests for Create's core block state generation and model loading

The repo has extensive generated blockstate JSON files (src/generated/resources/assets/create/blockstates/) but no visible test coverage for the data generation logic. This is critical because blockstate misconfigurations can cause rendering issues across dozens of blocks. Adding tests would validate that block properties (rotation, connection states, etc.) generate correct JSON before deployment.

• [ ] Create src/test/java/com/simibubi/create/foundation/data/BlockStateGeneratorTest.java to test blockstate JSON output
• [ ] Add integration tests in src/test/java/com/simibubi/create/content/*/BlockStateTest.java for each major block category (casing, gears, funnels, etc.)
• [ ] Update build.gradle to include test dependencies (JUnit 5, Mockito) and add 'test' task to CI workflow in .github/workflows/build.yml

Implement GitHub Actions workflow for data generation validation and cache invalidation

The .cache folder (src/generated/resources/.cache/) contains 14+ hash files that track data generation state, but there's no automated validation that generated resources stay in sync with source code changes. A new workflow should detect when generated files become stale and warn contributors, reducing integration delays and merge conflicts.

• [ ] Create .github/workflows/validate-datagen.yml that runs 'gradlew build --refresh-dependencies' and compares generated file checksums against tracked hashes
• [ ] Add step to verify all blockstate JSONs in src/generated/resources/assets/create/blockstates/ are valid JSON using a JSON linter
• [ ] Update build.gradle to expose a 'validateDataGen' task that the workflow can invoke, and document the expected behavior in CONTRIBUTING.md (if it exists)

Add Parchment mappings fallback handling and documentation for offline builds

The build.gradle conditionally loads Parchment mappings (parchment_version != 'none'), but there's no fallback mechanism or documentation for CI/offline environments where mapping downloads may fail. This causes build failures in restricted network environments and makes the build.gradle configuration opaque to new contributors.

• [ ] Update gradle.properties to document the purpose of parchment_version, parchment_minecraft_version, and add a new 'parchment_fallback_enabled' property with default 'true'
• [ ] Modify neoForge.parchment block in build.gradle to wrap in a try-catch and log warnings when mappings fail to download, allowing builds to proceed with default mappings
• [ ] Add a troubleshooting section to README.md or create BUILDING.md with explicit instructions for offline builds and how to set parchment_version = 'none'

• Add unit tests for core block rotation/state logic: Create lacks visible test files; add JUnit 5 tests under src/test/java for BlockStateUtils or similar utility classes that handle mechanical rotations.
• Document Ponder system architecture: The in-game tutorial system is mentioned but no source-level docs exist in top 60 files; write a developer guide explaining how Ponder entries map to Java code and asset JSONs.
• Expand blockstate JSON generation: Inspect why only ~4 blockstate files are shown in src/generated; add missing blockstates for new blocks added since last build, or fix the generator to cover all blocks.

The Create mod project demonstrates a generally solid security posture with a documented security policy and vulnerability reporting mechanism. The primary concern is the committed Gradle wrapper JAR file, which should be removed from version control. Secondary concerns include the lack of explicit dependency verification mechanisms and potential reproducibility issues with the build system. The project would benefit from implementing checksum verification for Gradle plugins and stricter CI/CD controls to prevent building from uncommitted code. No evidence of hardcoded secrets, SQL injection risks, XSS vulnerabilities, or unsafe Docker configurations was identified in the provided files.

• Medium · Gradle Wrapper JAR in Repository — gradle/wrapper/gradle-wrapper.jar. The Gradle wrapper JAR file (gradle/wrapper/gradle-wrapper.jar) is committed to the repository. This is a security risk as JAR files are binary and difficult to audit. If compromised, it could inject malicious code into the build process affecting all developers. Fix: Remove the gradle-wrapper.jar from version control and add it to .gitignore. Developers should regenerate it using './gradlew wrapper' command. Consider using gradle-wrapper-validation action in CI/CD to verify wrapper integrity.
• Low · Missing Build Process Integrity Verification — build.gradle - plugin declarations. The build.gradle file uses external plugins from repositories (KyoriPowered/blossom, ithundxr/silk, NeoForged/ModDevGradle, modmuss50/mod-publish-plugin) without explicit version pinning or checksum verification mentioned in the configuration. Fix: Verify plugin versions are explicitly pinned. Consider implementing gradle dependency verification plugin to ensure reproducible builds and detect tampering of dependencies.
• Low · Git Hash Modification Detection Not Enforced — build.gradle - version calculation. While the build system detects unstaged changes (hasUnstaged()), there is no mechanism to prevent building with uncommitted changes in CI/CD, which could lead to unreproducible builds. Fix: Implement CI/CD checks to ensure all code is committed before building releases. Use pre-commit hooks locally to prevent accidental commits of sensitive data.
• Low · Java 21 Language Version Requirement — build.gradle - java.toolchain.languageVersion. The project requires Java 21, which may have a shorter support window. Future security patches could become unavailable if support ends. Fix: Document the Java 21 LTS timeline and create a migration plan for future Java versions. Consider periodic security updates to the build configuration.
• Low · Build System Verbose Logging — build.gradle - println statement. The build system outputs Java version, JVM version, vendor, and architecture information which could aid in targeted attacks on developers. Fix: Consider conditionally logging this information only in development mode or removing it from normal builds. Do not expose detailed system information in CI/CD logs publicly.

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.