DavidVujic/my-eca-config

planning-style

Produce an implementation plan with a functional-leaning, idiomatic style mindset; prefers lightweight data structures over dataclasses/pydantic unless justified.

coding-style

General coding style policy for generated code: restrictive on comments, concise docstrings for modules and functions.

explaining-code-health

Use when a user asks what Code Health means, how to interpret scores, or why Code Health matters in daily development.

guiding-refactoring-with-code-health

Use when refactoring unhealthy code and needing Code Health findings to choose small safe steps and verify improvement.

making-the-business-case-for-code-health

Use when a user asks for ROI, stakeholder justification, delivery impact, or defect-risk reduction from improving Code Health in a file.

safeguarding-ai-generated-code

Use when AI-generated or AI-modified changes need a Code Health gate before commit, handoff, or pull request.

qa-check

Run linting and unit tests against the current repository, auto-discovering the correct commands from Justfile, Makefile, pyproject.toml, or package.json.

commit

Create a conventional commit from staged changes, with a diff-derived description body.

git-changes-context

Reliably obtain a non-empty unified git diff for the current branch using safe fallbacks (origin/HEAD...HEAD, origin/main...HEAD, origin/master...HEAD) and return structured JSON containing the diff and the command used.

fp-idiomatic-style

Coding style policy for generated code: prefer idiomatic language conventions with a functional-leaning approach (pure-ish functions, composability), and prefer lightweight data structures over heavy schema/class abstractions unless clearly justified.