Install
$ agentstack add skill-hnikoloski-imlazy-imlazy-brainstorm ✓ 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
brainstorming
When to use
The router invokes this skill ONLY for Heavy-tier tasks (multi-component, unclear scope, new subsystem, or user explicitly requests design/plan/architecture).
For Standard or Quick tier, skip brainstorming entirely — go straight to Skill(imlazy-planning) in light mode or inline execution.
This skill's job: produce a spec doc that Skill(imlazy-planning) can turn into an implementation plan.
Process
- Explore project context — read existing files, check recent commits before asking any questions.
- Ask clarifying questions one at a time. Prefer multiple-choice. One question per message. Focus on: purpose, constraints, success criteria.
- Assess scope first. If the request describes multiple independent subsystems, flag this and help the user decompose into sub-projects before proceeding. Each sub-project gets its own spec → plan → implementation cycle.
- Propose 2-3 approaches with tradeoffs and your recommendation. Lead with the recommended option.
- Present the design in sections. Get user approval section by section. Cover: architecture, components, data flow, error handling, testing.
- Write the spec to
docs/imlazy/specs/YYYY-MM-DD--design.md. Self-review for placeholders, contradictions, scope, and ambiguity. Fix inline. - Ask the user to review the spec before proceeding.
- Hand off to
Skill(imlazy-planning)in full mode. Do not invoke any other skill.
Key principles
- One question at a time. Multiple-choice preferred over open-ended.
- YAGNI ruthlessly — cut unrequested features from the design.
- Always propose 2-3 approaches before settling.
- Explore the existing codebase before proposing changes. Follow existing patterns. Targeted improvements to broken code you are touching are fine; unrelated refactoring is not.
- Be flexible — go back and clarify when something does not make sense.
Spec self-review checklist
Before asking the user to review, check:
- Placeholder scan — any TBD/TODO/incomplete sections?
- Internal consistency — do sections contradict each other?
- Scope check — focused enough for one implementation plan?
- Ambiguity check — can any requirement be interpreted two ways?
Fix issues inline. No need to re-review.
Hand-off
After the user approves the spec, invoke Skill(imlazy-planning) in full mode. Do not invoke any other skill — imlazy-planning is the terminal state for this skill.
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.