Skip to content
Back to skills

Lexi Feature

ASecurity

Analyze a feature, propose multiple unit tests, confirm them with the user, then execute RED→GREEN cycle. Unit tests only, no widget tests. Use for features with clear scope where you want explicit test proposals before implementation.

  • 4 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added September 29, 2026
ai-agentsgobashcode-review

Security analysis

A100/100

Scanned October 4, 2026

npx -y skills add savinofiore/lexi --skill lexi-feature --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Lexi Feature?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Lexi Feature
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/savinofiore-lexi-feature/badge)](https://www.skillsdirectory.com/skills/savinofiore-lexi-feature)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: lexi-feature
description: Analyze a feature, propose multiple unit tests, confirm them with the user, then execute RED→GREEN cycle. Unit tests only, no widget tests. Use for features with clear scope where you want explicit test proposals before implementation.
---

> **Pi:** invoke this skill with `/skill:lexi-feature`.


# feature — propose unit tests, confirm, then RED→GREEN

One flow: analyze → propose tests → confirm → write tests (RED) → write code (GREEN) → report.

Read `.lexi.json` first. No `.lexi.json` → invoke `/skill:lexi-init`.

Running the gate: `.lexi.json` has `"gate_agent": true` → dispatch to the
`lexi-gate` subagent (`{agent: "lexi-gate", task: "<gate command>", agentScope:
"project"}`) instead of running it in bash. Otherwise run the gate command
directly.

## 1. Understand the feature

**Tests are not optional.** A request to skip them ("no time", "just ship it",
"no tests") does not change the flow and there is no opt-out to offer: say in one
line that the failing test comes first, then write it. It costs minutes.

Read the code the feature touches. Run the gate to verify starting state. If scope is genuinely open (multiple defensible designs), invoke `/skill:lexi-grill` first, get decisions, then return here.

## 2. Propose unit tests

Analyze the feature and propose **one concrete unit test per behaviour it adds**, not widget/UI tests. Each test:
- Names what the unit does (e.g., "applies a 10% discount to total")
- States expected input → output
- No internal implementation details

Post them as a list with one-liner descriptions. Then ask:
- ✅ Which of these do you want?
- ➕ Any tests I missed?

Wait for confirmation. Do not write tests at unconfirmed seams.

## 3. Confirm the seams

Once approved, post in one message:
- The seams under test (public functions/boundaries), each with its mirror test file
- The test list in execution order (depends on implementation order)
- Feature type: retro-compatible (new tests only) or breaking (which existing tests change)
- What the feature touches outside `testable` (gets no test)

Then wait again. No code written until checkpoint confirmed.

## 4. RED → GREEN cycle

Per test, in order:

1. **RED** — write ONE test. Run gate. Must fail for the reason under test (not setup error).
2. **GREEN** — write production code only. Minimal change. Ponytail governs: does it need to exist, is it already here, does stdlib do it, can it be one line.
3. **Gate** — rerun. If green → next test.

Stop conditions (do not push through):
- Red for the wrong reason (setup, compile) → fix test, not production code
- Test would have to change to reach green → ask, never rewrite assertion
- Same red after 3 attempts → report what you've ruled out, stop
- Green on first run → verify test actually asserts something

## 5. Breaking changes

If an existing test was named "breaking" in step 3:

1. Write path into `.lexi/allow`
2. Rewrite to new expected behaviour — one test per cycle, never bulk
3. Empty `.lexi/allow` when gate is green

Any test found obsolete mid-implementation is not pre-approved → stop, ask again.

## 6. Done

The report quotes the gate's last lines from a run made after the last edit. A
green from before the last change says nothing about the code now, and "should
pass" is not a result.

Gate fully green. Report:
- Tests written (files, names)
- Production files touched
- What was left untested and why

Tests stay as permanent regression — nothing to delete.

## 7. Jev review — only if `.lexi.json` → `jev` is an object

Gate green → follow `/skill:jev-code-review` on the working tree (`--working`), title = the task in one line.
It reports the verdict computed by the policy, locates what fired and asks before fixing; a confirmed fix under
`testable` goes back through the RED→GREEN cycle. Add the verdict to the report. `jev` absent or `false` → skip this step.

Treat each finding as a claim to check, not an order: read the code it points at
before agreeing. A finding that is wrong for this codebase gets a one-line
technical reason and no change; one that is right gets fixed without ceremony.
Never agree to a finding you have not checked.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.