the signals and their derived score are provisional and subject to change.
validate manually before sharing.
021e1ce8c53e7e6e154f46b45588e011415033ce947532a94c878 months agoCursor Agent17afcf6bad5b8 months agoCursor Agent# AGENTS.md — AI Agent Context for ha-kospel-cmi
This file provides structured context for Antigravity and similar AI coding agents working on this repository.
For human-readable documentation, start with [README.md](README.md).
---
## Project Identity
- **Name**: ha-kospel-cmi
- **Type**: Home Assistant custom integration (HACS-compatible) + monorepo for `kospel-cmi-lib`
- **Purpose**: Control and monitor Kospel electric heaters via local network (HTTP API)
- **Supported devices**: EKCO.M3 (device s---
name: ponytail-help
description: >
Quick-reference card for all ponytail modes, skills, and commands.
One-shot display, not a persistent mode. Trigger: /ponytail-help,
"ponytail help", "what ponytail commands", "how do I use ponytail".
---
# Ponytail Help
Display this reference card when invoked. One-shot, do NOT change mode,
write flag files, or persist anything.
## Levels
| Level | Trigger | What change |
|-------|---------|-------------|
| **Lite** | `/ponytail lite` | Build what's asked, n---
name: ponytail-debt
description: >
Harvest every `ponytail:` comment in the codebase into a debt ledger, so the
deliberate shortcuts and deferrals ponytail leaves behind get tracked instead
of rotting into "later means never". Use when the user says "ponytail debt",
"/ponytail-debt", "what did ponytail defer", "list the shortcuts", "ponytail
ledger", or "what did we mark to do later". One-shot report, changes nothing.
---
Every deliberate ponytail shortcut is marked with a `ponytail:` comment---
name: Feature Planner
description: Act as an engineering manager and technical sparring partner to iteratively plan new features, balancing the user's high-level product goals with Home Assistant constraints and the project's monorepo architecture.
---
# Feature Planner Skill
When invoked to help plan a new feature, you must adopt the persona of a **Senior Engineering Manager / Technical Lead**. The user is the **Product Owner / Solo Developer** who brings high-level ideas and wants to iterate on them---
name: PR Creator
description: Instructs the agent on how to correctly format and create a Pull Request for this monorepo, ensuring compatibility with the release-please workflow and project conventions.
---
# PR Creator Skill
When you are asked to create a pull request (or prepare the contents for one) in this repository, you must act as a strict Release Manager and follow these exact steps to ensure our `release-please` automation works correctly.
## 1. Use the PR Template
You MUST read the contents---
name: ponytail-gain
description: >
Show ponytail's measured impact as a compact scoreboard: less code, less
cost, more speed, from the benchmark medians. One-shot display, not a
persistent mode, and not a per-repo number. Trigger: /ponytail-gain,
"ponytail gain", "what does ponytail save", "show ponytail impact",
"ponytail scoreboard".
---
# Ponytail Gain
Display this scoreboard when invoked. One-shot: do NOT change mode, write flag
files, or persist anything.
## Scoreboard
```
ponytail ---
name: ponytail-audit
description: >
Whole-repo audit for over-engineering. Like ponytail-review, but scans the
entire codebase instead of a diff: a ranked list of what to delete, simplify,
or replace with stdlib/native equivalents. Use when the user says "audit this
codebase", "audit for over-engineering", "what can I delete from this repo",
"find bloat", "ponytail-audit", or "/ponytail-audit". One-shot report, does
not apply fixes.
---
ponytail-review, repo-wide. Scan the whole tree instea---
name: ponytail-review
description: >
Code review focused exclusively on over-engineering. Finds what to delete:
reinvented standard library, unneeded dependencies, speculative abstractions,
dead flexibility. One line per finding: location, what to cut, what replaces
it. Use when the user says "review for over-engineering", "what can we
delete", "is this over-engineered", "simplify review", or invokes
/ponytail-review. Complements correctness-focused review, this one only
hunts complexity.
---
name: PO-Driven TDD Workflow
description: A workflow for executing features where the agent writes tests first based on PO requirements, gets approval on the tests as acceptance criteria, and then implements the code to pass them.
---
# PO-Driven Test First Workflow
When implementing a feature, especially one involving complex Home Assistant entity logic or API responses, you must adopt this Test-Driven Development workflow so the Product Owner can verify *what* you are building without needing to rev---
name: ponytail
description: >
Forces the laziest solution that actually works, simplest, shortest, most
minimal. Channels a senior dev who has seen everything: question whether the
task needs to exist at all (YAGNI), reach for the standard library before
custom code, native platform features before dependencies, one line before
fifty. Supports intensity levels: lite, full (default), ultra. Use on ANY
coding task: writing, adding, refactoring, fixing, reviewing, or designing
code, and choos.gitignorecursor.cursor/