Install
$ agentstack add skill-hnikoloski-imlazy-imlazy-tdd ✓ scanned · ✓ verified — works with Claude Code, Cursor, and more.
Security review
✓ PassedNo issues found. Passed automated security review. · v0.1.0 How review works →
- ✓ Prompt-injection patterns
- ✓ Secret / credential exfiltration
- ✓ Dangerous shell & filesystem operations
- ✓ Untrusted network calls
- ✓ Known-malicious package signatures
What it can access
- ✓ Network access No
- ✓ Filesystem access No
- ✓ Shell / process execution No
- ✓ Environment & secrets No
- ✓ Dynamic code execution No
From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.
Verified badge
Passed review? Show it. Paste this badge into your README — it links to the public security report.
Reliability & compatibility
Declared compatibility
Compatibility is declared by the source manifest. End-to-end runtime verification is coming — see below.
We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps — measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.
How agent discovery & health will work →About
tdd
Overview
Write the test first. Watch it fail. Write minimal code to pass.
Core principle: If you didn't watch the test fail, you don't know if it tests the right thing.
Violating the letter of the rules is violating the spirit of the rules.
The Iron Law
NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
Write code before the test? Delete it. Start over. No exceptions.
Red-Green-Refactor
Red: Write a failing test. Verify it fails for the right reason (feature missing, not a typo). One behavior, clear name, real code (no mocks unless unavoidable).
Green: Write the simplest code to pass the test. Do not add features, refactor nearby code, or "improve" beyond what the test requires.
Refactor: Clean up after green only. Remove duplication, improve names, extract helpers. Keep tests green. Don't add behavior.
Repeat with the next failing test for the next feature.
Good test vs bad test
Good:
test('retries failed operations 3 times', async () => {
let attempts = 0;
const operation = () => { attempts++; if (attempts {
const mock = jest.fn().mockRejectedValueOnce(new Error()).mockResolvedValueOnce('success');
await retryOperation(mock);
expect(mock).toHaveBeenCalledTimes(3);
});
Vague name, tests mock not code.
Example: Bug Fix
Bug: Empty email accepted
// RED: Write failing test
test('rejects empty email', async () => {
const result = await submitForm({ email: '' });
expect(result.error).toBe('Email required');
});
// Verify RED: run test, confirm FAIL with "expected 'Email required', got undefined"
// GREEN: Minimal implementation
function submitForm(data) {
if (!data.email?.trim()) return { error: 'Email required' };
// ...
}
// Verify GREEN: run test, confirm PASS
Common rationalizations — stop
| Excuse | Reality | |--------|---------| | "Too simple to test" | Simple code breaks. Test takes 30 seconds. | | "I'll test after" | Tests after pass immediately — proves nothing. | | "Tests after achieve same goals" | Tests-first: "what SHOULD this do?" Tests-after: "what DOES this do?" | | "Already manually tested" | Manual is ad-hoc. Can't re-run. No record. | | "Deleting hours of work is wasteful" | Sunk cost. Untested code is technical debt. | | "Test hard = design unclear" | Listen: hard to test = hard to use. Simplify. |
When stuck
| Problem | Solution | |---------|----------| | Don't know how to test | Write the wished-for API first. Assertion first. | | Test too complicated | Design too complicated. Simplify the interface. | | Must mock everything | Code too coupled. Use dependency injection. |
Verification checklist
Before marking work complete:
- [ ] Every new function/method has a test
- [ ] Watched each test fail before implementing
- [ ] Each test failed for the expected reason (feature missing, not typo)
- [ ] Wrote minimal code to pass each test
- [ ] All tests pass, output pristine (no warnings)
- [ ] Tests use real code (mocks only if unavoidable)
Can't check all boxes? You skipped TDD. Start over.
Completion Gate
Before claiming completion or moving to the next task:
- Identify: what command proves the work is done? (test suite, build,
git diff) - Run: execute it now, in this message.
- Read: check full output, count failures, confirm exit code.
- Verify: does output confirm the claim?
- If NO: state actual status with evidence. Do not claim success.
- If YES: state claim WITH the evidence.
| Claim | Requires | |-------|---------| | Tests pass | Test command output: 0 failures | | Build succeeds | Build command: exit 0 | | Bug fixed | Test for original symptom: passes | | Agent completed | Check VCS diff — verify changes exist |
Escalation context: If invoked because a Quick-tier task failed its completion gate, invoke Skill(imlazy-learn) to record the misclassification (predicted=quick, actual=standard, task summary ≤50 chars) before proceeding. Then continue with TDD on the task — do not redo work already done correctly in the Quick attempt.
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: hnikoloski
- Source: hnikoloski/imlazy
- License: MIT
- Homepage: https://hnikoloski.github.io/imlazy/
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet — be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.