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/inancgumus/learngo 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 — Slowing — last commit 11mo ago

• Last commit 11mo ago
• 31+ active contributors
• Distributed ownership (top contributor 28% of recent commits)
• Other licensed
• ⚠ Slowing — last commit 11mo ago
• ⚠ Non-standard license (Other) — review terms
• ⚠ No CI workflows detected
• ⚠ 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 inancgumus/learngo repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/inancgumus/learngo.

What it runs against: a local clone of inancgumus/learngo — 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 inancgumus/learngo | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | Last commit ≤ 349 days ago | Catches sudden abandonment since generation |

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "inancgumus/learngo(\\.git)?\\b" \\
  && ok "origin remote is inancgumus/learngo" \\
  || miss "origin remote is not inancgumus/learngo (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 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 349 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~319d)"
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/inancgumus/learngo"
  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).

learngo is a hands-on Go learning repository containing 1000+ executable examples, exercises, and quizzes organized from basics (printing, variables) through advanced topics (packages, scopes, imports). It teaches Go through the 'learn by fixing code' paradigm, where each exercise presents broken code that learners must repair to understand language fundamentals. Flat, topic-driven directory structure: numbered chapters (01-get-started, 02-write-your-first-program, 03-packages-and-scopes) each containing README.md, .pdf variants, standalone main.go examples, an exercises/ subdirectory with broken code and solution/ subdirectories showing correct implementations, and questions/ subdirectories with conceptual quiz prompts. Each exercise mirrors the parent structure (e.g., exercises/01-packages has main.go + solution/main.go).

Beginner and intermediate programmers learning Go who prefer learning-by-doing over passive reading; students enrolled in or following along with the author's Udemy 'Go: Bootcamp Course'; developers transitioning from other languages who need practical, bite-sized examples rather than lengthy tutorials.

Actively maintained and educationally proven—the repo was created to support a successful Udemy course (Go: Bootcamp Course) and later expanded for free access, suggesting substantial real-world usage. With 1000+ hand-crafted examples across clearly structured directories (01-get-started through 03-packages-and-scopes visible), organized solutions directories, and README/PDF documentation at each level, it demonstrates mature educational design. Appears to prioritize breadth of content over CI/test infrastructure (no visible Makefile testing pipeline in the excerpt), typical for a learning-focused rather than production library.

Single-maintainer risk is moderate—repository is community-supported (Spanish and Chinese translations listed as WIP, requiring contributor help) but core content authored by @inancgumus. No dependency management files visible (no go.mod excerpt provided), which is actually low-risk for a examples-only repo, but lack of CI/automated testing means code snippets aren't verified against Go version updates. Translation work noted as 'WIP: Please Contribute' suggests maintainer bandwidth constraints.

Repository actively documents Go bootcamp course curriculum; the file structure suggests chapters 01-03 are fully developed with examples, exercises, and solutions. A companion book project 'Go by Example: Programmer's guide to idiomatic and testable code' is linked in the README, indicating the maintainer is extending content ecosystem. Translation efforts (Spanish, Chinese) are explicitly open for community contributions.

Clone the repository: git clone https://github.com/inancgumus/learngo.git && cd learngo. No external installation required—navigate directly to any exercise directory (e.g., cd 02-write-your-first-program/exercises/01-print-names) and run go run main.go to see the broken code, then edit main.go to match the solution in the solution/ subdirectory.

Daily commands: Navigate to any exercise directory and execute go run main.go to see the current (broken) behavior. Compare with go run solution/main.go to see the correct output. For example: cd 02-write-your-first-program/exercises/01-print-names && go run main.go (will error), then go run solution/main.go (will print names correctly).

• 02-write-your-first-program/exercises/01-print-names/main.go: First hands-on exercise teaching how to run and fix Go programs; entry point for understanding the exercise structure and fixing pattern
• 02-write-your-first-program/exercises/01-print-names/solution/main.go: Model solution showing the correct approach; learners compare their fix against this reference implementation
• 03-packages-and-scopes/01-packages/main.go: Demonstrates Go package fundamentals with concrete multi-file example (main.go + bye.go + hey.go); essential for understanding Go's module organization
• 03-packages-and-scopes/02-scopes/02-block-scope/main.go: Introduces Go's scoping rules (block, package, file scope) with live code; critical concept for learners transitioning from other languages
• 02-write-your-first-program/README.md: Chapter-level guide explaining the pedagogical approach; sets expectations for how to use exercises and solutions
• README.md: Root documentation directing learners to the Udemy course, social channels, and license; critical for understanding repo purpose and contribution guidelines

To add exercises: create a new numbered subdirectory under the relevant chapter (e.g., 02-write-your-first-program/exercises/02-your-exercise/), place broken code in main.go, and provide the corrected version in solution/main.go. To add questions: create a questions/XX-your-question/README.md file with the quiz prompt. To improve docs: edit chapter README.md files or their .pdf counterparts. To fix existing code: PR against the corresponding main.go or solution/main.go files.

No external dependencies or environment variables required, which is intentional simplicity for a learning repo. However: (1) Solutions are in solution/subdirectories—naive learners might peek before attempting the exercise; (2) Go version assumptions not explicitly documented (exercises assume Go 1.11+ given module-style structure, but no go.mod visible); (3) PDF versions (.pdf files) may become stale if main .md files are updated without corresponding regeneration; (4) File-level scope imports (03-importing/01-file-scope) require understanding Go's strict import semantics, which can trip up beginners unfamiliar with how Go resolves package-private vs. exported identifiers.

• Package scope and visibility (exported vs. unexported identifiers) — Go's capitalization-based export convention (Name vs. name) is unique among mainstream languages; understanding this is essential to reading and writing idiomatic Go that respects encapsulation
• Block scope and variable shadowing — Go's explicit block scoping (if, for, switch blocks) differs from C-style scoping; the exercises in 03-packages-and-scopes/02-scopes teach how shadowing can hide outer variables and lead to bugs
• Import aliasing and renaming — Go allows renaming imports (e.g., import foo 'original/path') to avoid naming conflicts; 03-importing/02-renaming teaches this non-obvious feature crucial for managing large dependency graphs
• Go's GOPATH and module-based project structure — Understanding Go's workspace layout (GOPATH, go.mod, package organization) is prerequisite to building and running any non-trivial Go program; 01-get-started covers platform-specific setup (OSX, Ubuntu, Windows)
• Multi-file packages and compilation units — Unlike Python or JavaScript, Go doesn't rely on explicit import statements for same-package files; 03-packages-and-scopes/01-packages teaches how hey.go and bye.go share package main without imports, a source of confusion for beginners
• Function and variable declaration order independence — Go allows calling a function defined later in the same file (unlike C), enabling clearer top-down code organization; this flexibility is taught implicitly through multi-file package examples

• golang/go — Official Go repository; canonical source for language specification, stdlib docs, and issue tracker for verifying Go version compatibility of exercises
• inancgumus/gobyexample — Companion book repository by the same author; extends learngo content into idiomatic patterns and testable code for post-bootcamp learners
• adonovan/gopl.io — The Go Programming Language book's examples and exercises; complementary in-depth coverage of Go fundamentals with solutions
• exercism/go — Community-driven Go exercises with automated mentoring; similar learn-by-fixing approach but with peer feedback and progression tracking
• golang/example — Official Go examples repository; canonical reference implementations that learngo examples should align with for idiomatic Go practices

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.

Create automated solution checker script for exercises

The repo has 1000+ exercises with solutions in */exercises/*/solution/ directories, but no automated way to verify student work. A Go script that compares exercise output against expected solutions would help learners self-validate and reduce maintainer burden. This is critical for a learning-focused repo.

• [ ] Create scripts/check-solution.go that compiles and runs exercise code
• [ ] Compare stdout output against corresponding solution in solution/main.go
• [ ] Add usage documentation in scripts/README.md with examples from 02-write-your-first-program/exercises/ and 03-packages-and-scopes/exercises/
• [ ] Test against at least 3 exercises from different sections to ensure robustness

Add missing README files with learning outcomes for each exercise folder

The repo has structured exercise directories (02-write-your-first-program/exercises/, 03-packages-and-scopes/exercises/) but most lack README.md files explaining what learners should accomplish. Adding these with clear learning objectives and difficulty indicators would significantly improve UX.

• [ ] Create 02-write-your-first-program/exercises/01-print-names/README.md with learning goals and hints
• [ ] Create 03-packages-and-scopes/exercises/01-packages/README.md, 02-scopes/README.md, and 03-importing/README.md following the same template
• [ ] Include difficulty level, estimated time, and key concepts tested in each
• [ ] Reference the corresponding question file (e.g., ../questions/02-packages-B/README.md) where relevant

Create GitHub Actions workflow to validate all Go code compiles and runs

With 1000+ code examples across */main.go and */solution/main.go files, there's risk of bitrot and syntax errors. A CI workflow ensuring all Go programs compile and run successfully would catch breaking changes early and maintain repo quality.

• [ ] Create .github/workflows/go-validate.yml that finds all main.go files recursively
• [ ] Run go build and go run on each file in appropriate directories (respecting package structure in 03-packages-and-scopes/)
• [ ] Add workflow to run on pull requests and pushes to main branch
• [ ] Document the CI process in .github/CONTRIBUTING.md for new contributors

• Add a Makefile test target that runs all exercises with go run and validates they produce expected output (e.g., exercises//solution/main.go should succeed, exercises//main.go should initially fail). This would automate verification that solutions are correct and exercise templates are broken as intended.
• Create missing exercises for chapters 04+ (visible from README structure beyond chapter 03). Specifically, add numbered directories for topics like functions, interfaces, concurrency, and error handling with the same template structure: main.go (broken), solution/main.go (fixed), and questions/ directory.
• Document the exact Go version(s) tested in a go.version.txt or CONTRIBUTING.md file, and add a GitHub Actions workflow (no CI visible) that runs each exercise/solution/main.go against that version to prevent bitrot as Go evolves.

This is a Go learning repository containing educational examples and exercises. The codebase presents a very low security risk profile. It is a collection of hand-crafted Go examples, exercises, and quizzes designed for learning purposes. No production code, dependencies, configuration files, or infrastructure components were identified that would introduce security vulnerabilities. The repository follows a clean, organized structure with educational content only. No secrets, credentials, dangerous patterns, or misconfigurations were detected in the provided file structure.

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.