github.com/crosspoint-reader/crosspoint-reader (link)

commit signals (62)

source signals (31)

• AGENTS.mdvia agents-md

  # CrossPoint Reader agent guide
  
  CrossPoint Reader is open-source e-reader firmware for Xteink and other FreeInk-supported devices. Its mission is a lightweight, high-performance reading experience focused on EPUB rendering. The X3/X4's ESP32-C3 remains the resource baseline: roughly 380 KB usable RAM, no PSRAM, and a single framebuffer sized for the selected panel. Other board profiles have different CPUs, display sizes, input, and memory capabilities; check the selected profile before assuming them.
  
  ## F

• .agents/skills/control-flow-clarity/SKILL.mdvia unspecified

  ---
  name: control-flow-clarity
  description: C/C++ state modeling and discrete-value dispatch. Use when introducing state/mode representations or refactoring branches on one discriminant.
  ---
  
  # Control-Flow Clarity
  
  The goal: a reviewer verifies correctness by reading, not by tracing. Branching
  that mirrors the problem's shape is self-evident; branching that encodes it in
  ad-hoc ints and nesting forces the reader to reconstruct intent.
  
  ## Core moves
  
  - **Use `enum class` for multiple states/modes instead o

• .agents/skills/heap-discipline/SKILL.mdvia unspecified

  ---
  name: heap-discipline
  description: ESP32-C3 allocation discipline. Use when changing allocation size/failure handling, buffer or cache lifetime, or hot-path container growth.
  ---
  
  # Heap Discipline
  
  Use the selected board's [resource budget](../../rules/hardware-resources.md)
  and the [checked-allocation contract](../../rules/coding-standards.md#heap-buffer-allocation).
  Budget peak coexistence and largest required blocks, not just final free bytes.
  
  ## Allocation decision procedure
  
  Choose the first opti

• .agents/skills/review-architecture/SKILL.mdvia unspecified

  ---
  name: review-architecture
  description: "Read-only architecture audit of the current logical diff at firmware handoff: assess its long-term shape."
  ---
  
  # Architecture review
  
  Assume the change can work. Review its shape, not correctness, style, security, or performance.
  Inspect code and recorded checks only: no file writes, tests, builds, or new
  diagnostics. Request needed checks from the main agent.
  
  ## Process
  
  1. **Pin intent.** State the human requirement in one sentence from the conversation, issue

• .agents/skills/review-correctness/SKILL.mdvia unspecified

  ---
  name: review-correctness
  description: Read-only firmware-handoff review for regressions introduced or made reachable by the current diff; require concrete failure paths.
  ---
  
  # Correctness review
  
  Review only the pinned logical change; avoid a general subsystem audit.
  Inspect code and recorded checks only: no file writes, tests, builds, or new
  diagnostics. Request needed checks from the main agent.
  
  For every changed behavior:
  
  1. Trace inputs, state transitions, ownership, cleanup, and error paths thro

• .agents/skills/refactor-for-review/SKILL.mdvia unspecified

  ---
  name: refactor-for-review
  description: Keep structural changes reviewable. Use when restructuring code, extracting helpers, or separating unrelated cleanup.
  ---
  
  # Refactor for Review
  
  This is a multi-contributor, AI-assisted codebase, and the dominant failure mode
  is the sprawl diff: a one-line intent that touches thirty files. The goal is a
  change a reviewer can verify in one sitting. Cleaner structure that makes the
  next change easier is the win, not lines added.
  
  ## One concern per change
  
  - A commi

• .agents/skills/hal-and-abstractions/SKILL.mdvia unspecified

  ---
  name: hal-and-abstractions
  description: HAL and UI ownership contracts. Use when changing hardware/storage access, input or activity ownership, rendering contracts, or SDK boundaries.
  ---
  
  # HAL and Abstractions
  
  The [HAL rule](../../rules/architecture-hal.md#hardware-abstraction-layer-hal)
  owns hardware/storage access, synchronization, file lifetime, and singleton
  contracts. Consult the section for the boundary being changed.
  
  ## Route the change
  
  1. Trace the existing owner and callers. Reuse exposed 

• .agents/skills/scope-discipline/SKILL.mdvia unspecified

  ---
  name: scope-discipline
  description: Dedicated e-reader feature scope. Use when adding features, activities, libraries, settings, dependencies, or expanding the firmware surface.
  ---
  
  # Scope Discipline
  
  The mission: do one thing exceptionally well, focused reading on constrained
  hardware. `SCOPE.md` is the source of truth for what is in and out. Read it
  before adding surface. This is the gate to run before writing a new feature.
  
  ## The gate
  
  Before adding a feature, activity, lib, setting, or dependenc

• .agents/skills/review-i18n-docs/SKILL.mdvia unspecified

  ---
  name: review-i18n-docs
  description: Read-only firmware-handoff review of tr(), English source strings, generated-file workflow, and user documentation for visible changes.
  ---
  
  # English strings and user documentation review
  
  Review the pinned firmware change. Inspect code and recorded checks only:
  no file writes, tests, builds, or new diagnostics. Request needed checks from
  the main agent.
  
  Check:
  
  1. Every new user-facing string uses `tr()` and has an English source entry. Other languages may fall bac

• .agents/skills/firmware-handoff/SKILL.mdvia unspecified

  ---
  name: firmware-handoff
  description: Final checks and human handoff for completed firmware/build changes. Use after implementation and self-review; excludes read-only audits and reviewer tasks.
  ---
  
  # Firmware handoff
  
  Run after implementation and main-agent self-review, before calling a firmware
  change ready or making an approved local commit. The main agent owns the result;
  reviewer output is evidence, not authority. This workflow has at most two review
  rounds per logical change, even when slot limits 

• .agents/skills/review-embedded/SKILL.mdvia unspecified

  ---
  name: review-embedded
  description: "Read-only firmware-handoff review of ESP32 resources and hardware: RAM, fragmentation, stack, flash, timing, HAL, lifecycle, input, display, storage, and orientation."
  ---
  
  # Embedded constraints review
  
  Review the pinned logical change. Consult relevant sections of hardware, HAL,
  coding, or lifecycle rules for the contracts it changes; use project skills only
  when their decision procedure is needed. Inspect code and recorded checks only:
  no file writes, tests, builds

• .agentsdirectoryvia unspecified
• .agentsdirectoryvia unspecified
• .agentsdirectoryvia unspecified
• .agentsdirectoryvia unspecified
• .agentsdirectoryvia unspecified
• .agentsdirectoryvia unspecified
• .agentsdirectoryvia unspecified
• .agentsdirectoryvia unspecified
• .agentsdirectoryvia unspecified
• .agentsdirectoryvia unspecified
• .agentsdirectoryvia unspecified
• .agentsdirectoryvia unspecified
• .agentsdirectoryvia unspecified
• .agentsdirectoryvia unspecified
• .agentsdirectoryvia unspecified
• .agentsdirectoryvia unspecified
• .agentsdirectoryvia unspecified
• .agentsdirectoryvia unspecified
• .agentsdirectoryvia unspecified
• CLAUDE.mdvia claude-code

  AGENTS.md

ignorefile signals (1)