GO — Healthy across the board

• Last commit 2d ago
• 33+ active contributors
• Distributed ownership (top contributor 38% of recent commits)
• MIT licensed
• CI configured
• Tests present

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests, cross-checked against dependency CVEs from deps.dev and OpenSSF Scorecard}

ECC (Engineer Command Center) is an agent harness operating system that installs structured skills, memory, security layers, and behavioral instincts into AI coding agents like Claude Code, OpenCode, Codex, and Cursor. It works by injecting SKILL.md files and openai.yaml agent definitions into the .agents/ directory of a project, giving the AI agent a persistent, composable set of capabilities (e.g., api-design, benchmark-methodology, brand-voice) that persist across sessions. It ships as two npm packages — ecc-universal (the OpenCode plugin) and ecc-agentshield (security layer) — plus a GitHub App. The repo is structured as a skill library under .agents/skills/ where each skill (e.g., api-design, bun-runtime, brand-voice) is a self-contained directory containing a SKILL.md (the human-readable spec) and an agents/openai.yaml (the machine-readable agent definition). The ecc-universal npm package at the root contains src/, dist/, commands/, prompts/, and instructions/ directories that form the OpenCode plugin, compiled via tsc from TypeScript.

AI-augmented software engineers who use Claude Code, OpenCode, Cursor, or Codex daily and want their agent to carry consistent coding standards, architectural patterns, and domain skills across every project without re-prompting from scratch each session.

The npm package is at v2.0.0 with active weekly download tracking on ecc-universal and ecc-agentshield, suggesting real adoption. The repo has a GitHub App, a Discord, a dedicated website (ecc.tools), and multilingual docs (11 languages), indicating deliberate productization. It appears actively developed and approaching production-ready for daily AI-agent workflows, though the v2.0.0 version bump suggests recent breaking changes.

Single-maintainer risk is high — affaan-m appears to be the sole author with no visible co-maintainers in the contributor list. The peerDependency on @opencode-ai/plugin >=1.0.0 ties this tightly to OpenCode's plugin API, meaning breaking changes upstream in @opencode-ai/plugin (currently pinned at ^1.4.3 in devDependencies) could break the entire harness. No test files are visible in the top-60 file list, which is a significant quality signal for a system that modifies AI agent behavior.

The v2.0.0 release of ecc-universal is the most visible recent milestone, including a redesigned export map with separate entry points for ./plugins and ./tools. The .agents/plugins/marketplace.json file suggests active development of a skill marketplace feature. Multilingual README expansion (11 languages) indicates recent community growth work.

git clone https://github.com/affaan-m/ECC.git && cd ECC && npm install && npm run build

To install as a plugin into an existing project: npm install ecc-universal

or for security layer:

npm install ecc-agentshield

Daily commands: npm run build # compiles TypeScript src/ → dist/ npm run clean # rm -rf dist/ npm run prepublishOnly # runs build before publish

For development against a local OpenCode install, symlink the package: npm link && cd /your-project && npm link ecc-universal

• .agents/plugins/marketplace.json — Central registry of all available plugins/skills in the ECC marketplace — the source of truth for what can be installed and loaded.
• .agents/skills/deep-research/SKILL.md — Defines the deep-research skill contract and behavior, the most foundational research-first capability in the harness.
• .agents/skills/coding-standards/SKILL.md — Establishes coding conventions enforced across all agent-generated code, making it load-bearing for code quality.
• .agents/skills/eval-harness/SKILL.md — Describes the evaluation harness skill that benchmarks and scores agent performance — core to the optimization system.
• .agents/skills/everything-claude-code/SKILL.md — Master skill definition for Claude Code integration, the primary supported agent target for this harness.
• .agents/skills/backend-patterns/SKILL.md — Defines reusable backend architectural patterns injected into agents, affecting all server-side code generation.
• .agents/skills/agent-introspection-debugging/SKILL.md — Provides the introspection and debugging skill that lets agents self-diagnose — critical for harness reliability.

• Plugin Marketplace (JSON) — Central index for discovering, listing, and resolving installable skills and plugins.
  • Failure mode: Stale or missing entries cause skills to be undiscoverable by agent harness consumers.
• Skill Definition (SKILL.md) (Markdown) — Declares the behavioral contract, triggers, and output format for a single agent capability.
  • Failure mode: Ambiguous or incomplete SKILL.md leads to inconsistent or hallucinated agent behavior.
• Agent Adapter (openai.yaml) (YAML) — Maps skill parameters to a specific LLM platform's expected configuration schema.
  • Failure mode: Misconfigured YAML causes skill to be ignored or misapplied by the target agent platform.
• Reference Documents (Markdown) — Supplementary grounding documents loaded as additional context for complex skills like brand-discovery.
  • Failure mode: Missing or outdated references degrade output quality without surfacing an explicit error.
• OpenCode Plugin Package (TypeScript, ESM, Bun) — Compiled TypeScript plugin exposing tools, commands, and hooks for OpenCode agent integration.
  • Failure mode: Build failures prevent the plugin from loading, silently disabling all harness features in OpenCode.
• Eval Harness Skill (Markdown + YAML) — Orchestrates benchmarking and scoring of agent performance across skill executions.
  • Failure mode: Poorly defined metrics in SKILL.md yield misleading benchmark scores.

• Developer → Plugin Marketplace — Developer queries marketplace.json to discover available skills
• Plugin Marketplace → Skill Loader — Returns skill path and metadata for the requested capability
• Skill Loader → SKILL.md + references/ — Reads skill contract and optional reference documents to build system prompt context
• Skill Loader → agents/openai.yaml — Reads platform adapter to translate skill params into LLM-specific configuration
• Skill Loader → LLM Agent — Injects composed context and configuration into the active agent session

Add a New Skill

1. Create a new directory under .agents/skills/ with the skill name (.agents/skills/<new-skill>/SKILL.md)
2. Write the SKILL.md defining behavior, triggers, and output contracts following existing skill conventions (.agents/skills/coding-standards/SKILL.md)
3. Create an agents subdirectory and add an openai.yaml adapter config mapping skill params to the OpenAI agent format (.agents/skills/<new-skill>/agents/openai.yaml)
4. Register the new skill in the marketplace plugin registry so it is discoverable (.agents/plugins/marketplace.json)

Add Reference Documents to a Skill

1. Create a references/ subdirectory inside the target skill folder (.agents/skills/brand-discovery/references/)
2. Add numbered Markdown reference files following the NN_topic.md naming convention (.agents/skills/brand-discovery/references/10_purpose-why.md)
3. Update SKILL.md to reference the new documents in its instruction context (.agents/skills/brand-discovery/SKILL.md)

Add Support for a New Agent Platform

1. Identify which skills need platform support and navigate to their agents/ subdirectory (.agents/skills/deep-research/agents/)
2. Create a new YAML config (e.g. claude.yaml or codex.yaml) following the structure of the existing openai.yaml (.agents/skills/deep-research/agents/openai.yaml)
3. Update marketplace.json to advertise the new platform adapter for relevant skills (.agents/plugins/marketplace.json)

Add a New Content/Media Skill

1. Create the skill directory and SKILL.md describing the content generation behavior (.agents/skills/fal-ai-media/SKILL.md)
2. Add style preset or schema reference files if the skill has structured output formats (.agents/skills/frontend-slides/STYLE_PRESETS.md)
3. Add the OpenAI agent adapter YAML for the new media skill (.agents/skills/fal-ai-media/agents/openai.yaml)
4. Register in marketplace.json under the appropriate category tag (.agents/plugins/marketplace.json)

• Markdown (SKILL.md) — Human-readable, version-controllable skill definitions that are both agent-ingestible and developer-friendly without requiring a build step.
• YAML (agent adapters) — Lightweight declarative format for mapping skill parameters to platform-specific agent configurations across OpenAI, Claude, Codex, etc.
• JSON (marketplace.json) — Structured, machine-readable plugin registry enabling programmatic discovery and installation of skills.
• TypeScript/ESM (package) — Typed, tree-shakeable plugin distribution for OpenCode integration with clean import/export boundaries.
• Bun runtime — Fast JavaScript runtime used for build and execution, reflected by the dedicated bun-runtime skill in the harness.

• Markdown-first skill definitions over code-first

  • Why: Keeps skills readable and editable by non-engineers and easily diffable in PRs.
  • Consequence: Skills cannot express complex conditional logic natively; adapter YAMLs must handle platform-specific translation.

• Per-platform YAML adapters instead of a universal format

  • Why: Different LLM platforms have incompatible parameter schemas requiring bespoke mapping.
  • Consequence: Adding a new platform requires creating adapter files for every skill, increasing maintenance surface.

• Flat file-system skill registry over a database

  • Why: Zero infrastructure dependency; skills are portable and work offline with any git clone.
  • Consequence: Querying, versioning, and dependency resolution between skills requires custom tooling.

• Numbered reference document naming (10_, 20_, etc.)

  • Why: Provides deterministic load order for reference context without a manifest file.
  • Consequence: Inserting new references between existing ones requires renaming files.

• Does not provide a hosted API or server — purely a local/CLI harness
• Does not handle LLM authentication or API key management
• Does not implement a real-time agent execution runtime
• Does not support non-text modalities natively (image/audio generation is delegated to fal-ai-media skill)
• Does not enforce skill execution ordering or DAG-based workflow orchestration

• Avg cyclomatic complexity: ~2 — The codebase is predominantly Markdown and YAML with minimal TypeScript logic; cyclomatic complexity is near 1 for most files.
• Largest file: .agents/skills/brand-discovery/references/90_SYNTHESIS.md (300 lines)
• Estimated quality issues: ~4 — Primary issues are structural (manual registry sync, missing adapters for non-OpenAI platforms, no schema validation) rather than logic bugs.

• Manual Registry Synchronization (High) — .agents/plugins/marketplace.json: marketplace.json must be manually kept in sync with the 60+ skill directories — no automated generation or validation script exists.
• Duplicated Adapter Boilerplate (Medium) — .agents/skills/*/agents/openai.yaml: Every skill has its own openai.yaml with likely repeated structure and no shared base template, creating high copy-paste maintenance burden.
• Implicit Load Order via Filename Convention (Low) — .agents/skills/brand-discovery/references/: Reference document ordering depends on filename numeric prefixes (10_, 20_) with no enforced schema or validation.
• Single Platform Adapter Coverage (Medium) — .agents/skills/*/agents/: Only openai.yaml adapters exist despite the README claiming support for Claude Code, Codex, Cursor and beyond — other platforms are not yet implemented.

• .agents/plugins/marketplace.json (Single point of failure) — All skill discovery routes through a single manually-maintained JSON file; any corruption or omission blocks harness functionality.
• .agents/skills/*/SKILL.md (60+ files) (Quality consistency) — No automated validation of SKILL.md format means quality and completeness varies widely across the skill library.
• .agents/skills/brand-discovery/references/ (Context window scalability) — Reference documents are loaded as full text into context; large reference sets can exhaust LLM context windows.

The peerDependencies requires @opencode-ai/plugin >=1.0.0 but the project only devDependency-pins ^1.4.3 — if your OpenCode version ships a plugin API below 1.4.3 you may hit subtle incompatibilities. Node.js >=18.0.0 is required (enforced in engines), and the ESM-only (type: module) build means you cannot require() this package from CommonJS without a dynamic import(). The .agents/ directory must be placed at the project root for agent harnesses to discover skills; placing it in a subdirectory will silently break skill loading.

• Agent Harness — ECC's core abstraction — a harness wraps an AI agent to inject capabilities, constraints, and memory without modifying the base model.
• Skill Injection (Prompt Engineering Pattern) — Each SKILL.md is a structured prompt artifact injected into agent context at session start — understanding this pattern explains why the .agents/ directory structure is the entire product.
• OpenAI Function/Tool YAML Schema — Every agents/openai.yaml file defines an agent using OpenAI's tool/function calling schema — you need to understand this format to author new skills.
• ESM-only npm Package — ecc-universal uses type: module and ESM exports exclusively, which creates real incompatibility traps when consumed from CommonJS hosts.
• Agent Memory / Persistent Context — ECC's value proposition is giving stateless AI agents persistent behavioral memory across sessions via file-based skill manifests — understanding why LLMs are stateless makes this architecture legible.
• Marketplace Plugin Registry Pattern — .agents/plugins/marketplace.json implements a plugin registry pattern similar to VS Code's extension marketplace — skills are discoverable, versioned, composable units.

• anthropics/claude-code — Claude Code is one of the primary agent runtimes ECC is designed to augment with its skill and memory system.
• opencode-ai/opencode — ECC's ecc-universal package is explicitly an OpenCode plugin, making this the direct host runtime.
• continuedev/continue — Close alternative — also provides persistent context, custom prompts, and skills for AI coding agents in VS Code/JetBrains.
• paul-gauthier/aider — Alternative AI coding harness that solves the same 'persistent agent conventions' problem via a different .aider conventions file approach.
• BuilderIO/micro-agent — Inspiration-class repo exploring structured agent task decomposition and skill-like prompt modularity for coding agents.

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 a marketplace.json schema validator and CI workflow to prevent malformed plugin entries

The repo has .agents/plugins/marketplace.json which is likely the source of truth for installable skills/plugins. There is no visible JSON schema file or CI step that validates it on every PR. A malformed entry (missing required fields, bad URLs, wrong types) would silently break the marketplace for all users. Adding a JSON Schema + a GitHub Actions workflow that runs ajv or zod validation on every push would catch regressions before merge.

• [ ] Audit .agents/plugins/marketplace.json to enumerate every field used across entries (name, version, description, entrypoint, tags, etc.)
• [ ] Create .agents/plugins/marketplace.schema.json using JSON Schema Draft-07 that marks required vs optional fields and validates types/formats
• [ ] Add scripts/validate-marketplace.ts (or .mjs) that imports the schema and runs ajv against marketplace.json, exiting non-zero on failure
• [ ] Create .github/workflows/validate-marketplace.yml that triggers on push and pull_request paths matching .agents/plugins/**, installs deps with npm ci, and runs npm run validate:marketplace
• [ ] Add a validate:marketplace entry to scripts in package.json
• [ ] Document the schema and validation step in a new CONTRIBUTING.md section titled 'Adding a plugin to the marketplace'

Add per-skill SKILL.md conformance tests to ensure every skill directory has all required files

The repo has 20+ skill directories under .agents/skills/ (e.g., agent-sort, api-design, brand-discovery). Each should contain at minimum SKILL.md and agents/openai.yaml, but some skills like brand-discovery and brand-voice also have a references/ subdirectory. There is no automated check that enforces this structure. A new contributor adding a skill could accidentally omit SKILL.md or the OpenAI agent spec, silently breaking agent loading. A Node.js/Bun test script and matching CI job would enforce the contract.

• [ ] Inspect all existing skill directories to define the minimum required structure: SKILL.md (non-empty), agents/openai.yaml (valid YAML)
• [ ] Create scripts/validate-skills.ts that reads all directories under .agents/skills/, checks for SKILL.md and agents/openai.yaml, parses each YAML with js-yaml, and reports any violations
• [ ] Optionally define a lightweight JSON Schema for agents/openai.yaml fields (name, description, model, instructions) and validate each file against it
• [ ] Add a validate:skills npm script and a .github/workflows/validate-skills.yml triggered on changes to .agents/skills/**
• [ ] Add a test for the known references/ pattern: skills that have a references/ dir should have at least one .md file inside (catching the documentation-lookup skill that appears potentially empty in the partial listing)
• [ ] Update CONTRIBUTING.md with a 'Creating a new skill' section that references the required file structure and points to an existing skill like api-design as a template

Add TypeScript build and type-check CI for the ecc-universal npm package (src/ → dist/)

The package.json declares main: dist/index.js, exports for ./plugins and ./tools, and a build: tsc script, but there is no visible .github/workflows/ CI that runs tsc --noEmit or npm run build on PRs. This means a contributor could merge a change that breaks the TypeScript compilation of the published npm package without any automated gate. Since this package is consumed as a plugin by OpenCode, Cursor, Claude Code, etc., a broken dist/ would be a high-impact regression

1. Add a tests/ directory with at minimum a schema validation test for agents/openai.yaml files across all skills in .agents/skills/ — currently zero test files are visible. 2. Add TypeScript type definitions for the openai.yaml skill schema so contributors get autocomplete and validation when authoring new skill YAML files. 3. Write a CONTRIBUTING.md that documents the exact SKILL.md + openai.yaml contract with field-by-field documentation, since newcomers must infer the schema from examples like .agents/skills/brand-voice/references/voice-profile-schema.md.

• High · API Keys Exposed via Environment Variable Misconfiguration Risk — .env.example. The .env.example file documents several sensitive API keys including ANTHROPIC_API_KEY, GITHUB_TOKEN, and ASTRAFLOW_API_KEY. While .env.example itself is safe to commit, the pattern of storing multiple high-privilege tokens (GitHub PAT, Anthropic API key) in a single flat .env file creates a high-blast-radius exposure risk if the .env file is accidentally committed or leaked. The ASTRAFLOW_API_KEY entry also appears truncated (comment cut off: '# ASTRAFLOW_MO'), suggesting possible copy-paste errors in documentation that could lead to misconfiguration. Fix: 1. Ensure .env is in .gitignore and verify it has never been committed. 2. Use a secrets manager (e.g., HashiCorp Vault, AWS Secrets Manager) instead of flat .env files in production. 3. Apply least-privilege scoping to all tokens (e.g., GitHub token should only have required scopes). 4. Fix the truncated ASTRAFLOW_MO comment to avoid user confusion. 5. Add a pre-commit hook (e.g., git-secrets or trufflehog) to prevent accidental secret commits.
• High · GitHub Personal Access Token with Potentially Broad Scope — .env.example. The GITHUB_TOKEN documented in .env.example is described as a 'GitHub personal access token (for MCP GitHub server)'. Personal Access Tokens (PATs) in GitHub can carry very broad permissions (repo, admin:org, etc.). If this token is over-scoped and gets leaked, an attacker could gain full read/write access to repositories, secrets, workflows, and organizational resources. The MCP (Model Context Protocol) GitHub server integration also means this token is likely passed to an AI agent, further increasing the attack surface. Fix: 1. Use a fine-grained GitHub PAT with only the minimum required permissions (e.g., contents:read if only reading repos). 2. Consider using GitHub App tokens instead of PATs for better auditability and scope control. 3. Rotate tokens regularly. 4. Ensure the MCP server does not log or expose the token in any output or telemetry.
• High · Unvalidated Plugin Marketplace JSON — Supply Chain Risk — .agents/plugins/marketplace.json. The file .agents/plugins/marketplace.json suggests a plugin marketplace system where agents can install or load plugins. If this JSON is fetched remotely or contains plugin URLs/references without integrity verification (e.g., subresource integrity hashes, signature checks), a compromised or malicious plugin entry could lead to arbitrary code execution within the agent harness. This is a classic supply chain attack vector. Fix: 1. Implement cryptographic signature verification for all plugins in the marketplace (e.g., using cosign or similar). 2. Pin plugin versions and validate checksums/hashes before installation. 3. Run plugins in sandboxed environments with restricted permissions. 4. Audit marketplace.json entries for third-party sources and establish a vetting process. 5. Do not auto-install plugins without explicit user consent and verification.
• High · Agent YAML Configuration Files — Prompt Injection Risk — .agents/skills/*/agents/openai.yaml. Multiple agent configuration files exist as YAML (e.g., .agents/skills/*/agents/openai.yaml). These files likely define system prompts, instructions, or model parameters for OpenAI-compatible agents. If any of these YAML files incorporate user-supplied input or external data into agent prompts without sanitization, they are vulnerable to prompt injection attacks. An attacker could craft malicious input that overrides agent instructions, exfiltrates context, or causes the agent to take unauthorized actions (e.g., deleting files, exfiltrating API keys from the environment). Fix: 1. Treat all external/user input as untrusted and sanitize before inclusion in prompts. 2. Use structured output formats and strict system prompt boundaries to limit injection surface. 3. Implement input validation and output filtering layers. 4. Apply the principle of least privilege to agent tool access — agents should only have access to tools they explicitly need. 5. Log and monitor agent actions for anomalous behavior.
• Medium · Third-Party AI API Integration Without Input/Output Sanitization Guarantees — undefined. The system integrates with multiple AI provider APIs (Anthropic, OpenAI-compatible via ASTRAFLOW_API_KEY). Data sent to and received from these APIs may contain sensitive information from the user's codebase, environment, or project context. There is no visible evidence of Fix: undefined

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

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

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/affaan-m/ECC 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.

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

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

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

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

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

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

# 4. Critical files exist
test -f ".agents/plugins/marketplace.json" \\
  && ok ".agents/plugins/marketplace.json" \\
  || miss "missing critical file: .agents/plugins/marketplace.json"
test -f ".agents/skills/deep-research/SKILL.md" \\
  && ok ".agents/skills/deep-research/SKILL.md" \\
  || miss "missing critical file: .agents/skills/deep-research/SKILL.md"
test -f ".agents/skills/coding-standards/SKILL.md" \\
  && ok ".agents/skills/coding-standards/SKILL.md" \\
  || miss "missing critical file: .agents/skills/coding-standards/SKILL.md"
test -f ".agents/skills/eval-harness/SKILL.md" \\
  && ok ".agents/skills/eval-harness/SKILL.md" \\
  || miss "missing critical file: .agents/skills/eval-harness/SKILL.md"
test -f ".agents/skills/everything-claude-code/SKILL.md" \\
  && ok ".agents/skills/everything-claude-code/SKILL.md" \\
  || miss "missing critical file: .agents/skills/everything-claude-code/SKILL.md"

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

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