Requirements Engineering
- 68 installs
- 7 repo stars
- Updated January 15, 2026
- eyadsibai/ltk
Helps with ai & agent building tasks.
About
requirements-engineering is a Claude Code skill for ai & agent building. It helps solo builders move faster with AI-assisted development.
- requirements-engineering
- AI & Agent Building
- AI-coding skill
Requirements Engineering by the numbers
- 68 all-time installs (skills.sh)
- Ranked #5,828 of 16,546 AI & Agent Building skills by installs in the Skillselion catalog
- Data as of Jul 30, 2026 (Skillselion catalog sync)
npx skills add https://github.com/eyadsibai/ltk --skill requirements-engineeringAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 68 |
|---|---|
| repo stars | ★ 7 |
| Last updated | January 15, 2026 |
| Repository | eyadsibai/ltk ↗ |
What it does
Helps with ai & agent building tasks.
Files
Requirements Engineering
Structured approaches for capturing what to build before how to build it.
---
Core Principle
Specify WHAT, not HOW. Requirements describe outcomes and behaviors, not implementation details.
---
EARS Format
Easy Approach to Requirements Syntax - structured acceptance criteria.
| Pattern | Template | Use Case |
|---|---|---|
| Event-driven | WHEN [event] THEN [system] SHALL [response] | User actions, triggers |
| Conditional | IF [condition] THEN [system] SHALL [response] | Business rules |
| State-driven | WHILE [state] [system] SHALL [response] | Ongoing behaviors |
| Ubiquitous | WHERE [feature] [system] SHALL [response] | Always-true rules |
| Unconditional | [system] SHALL [response] | Basic capabilities |
Examples
| Type | Example |
|---|---|
| Event | WHEN user clicks "Submit" THEN system SHALL validate all required fields |
| Conditional | IF user is not authenticated THEN system SHALL redirect to login |
| State | WHILE file is uploading system SHALL display progress indicator |
| Ubiquitous | WHERE data is displayed system SHALL use consistent date format |
---
User Story Format
As a [role]
I want [capability]
So that [benefit]Good vs Bad
| Bad | Good |
|---|---|
| As a user I want to login | As a returning customer I want to login with my email so that I can access my order history |
| As a user I want a button | As a content creator I want a publish button so that I can share my work publicly |
Key concept: The "so that" clause reveals the actual need - often the stated "want" isn't what's really needed.
---
Requirements Document Structure
| Section | Content |
|---|---|
| Problem Statement | What problem are we solving? |
| User Stories | Who wants what and why? |
| Acceptance Criteria | How do we know it's done? (EARS) |
| Non-Functional | Performance, security, accessibility |
| Out of Scope | What we're NOT building |
| Success Metrics | How do we measure success? |
---
Constitution (Governing Principles)
For complex projects, establish guiding principles before features:
| Element | Purpose |
|---|---|
| Core Values | What matters most (simplicity > cleverness) |
| Technical Principles | Architecture standards |
| Decision Framework | How to make trade-offs |
| Quality Standards | Testing, review requirements |
Key concept: Constitution prevents scope creep and ensures consistency across features.
---
Clarification Techniques
Before implementation, resolve ambiguities:
| Technique | When to Use |
|---|---|
| Ask "what if" | Edge cases, error scenarios |
| Present options | Multiple valid approaches |
| Challenge assumptions | "Is this actually required?" |
| Define boundaries | What's in/out of scope |
Questions to Ask
- What happens when [edge case]?
- What does success look like?
- What's the minimum viable version?
- What can we defer to later?
---
Non-Functional Requirements
| Category | Questions to Answer |
|---|---|
| Performance | Response time? Throughput? Concurrent users? |
| Security | Authentication? Authorization? Data protection? |
| Accessibility | WCAG level? Screen reader support? |
| Scalability | Expected growth? Peak load? |
| Reliability | Uptime requirements? Recovery time? |
---
Anti-Patterns
| Don't | Why |
|---|---|
| Specify implementation | "Use React" locks in decisions |
| Assume requirements | Validate with stakeholders |
| Skip edge cases | They become bugs later |
| Mix requirements with design | Conflates what with how |
| Write vague criteria | "System should be fast" is untestable |
---
Testable vs Untestable
| Untestable | Testable |
|---|---|
| "Fast response" | "Response under 200ms" |
| "User-friendly" | "Task completable in <3 clicks" |
| "Secure" | "Passwords hashed with bcrypt" |
| "Scalable" | "Handles 10K concurrent users" |
Key concept: If you can't write a test for it, it's not a requirement - it's a wish.
Related skills
Setup Matt Pocock SkillsScaffold the per-repo configuration that Matt Pocock’s engineering agent skills rely on so they understand the issue tracker, triage labels, and domain documentation la495k196k
Lark AppsConnect Claude, Cursor or custom agents directly to Lark (Feishu) for messaging, document automation, approval workflows and enterprise data access.402k
CavemanSlash token usage by roughly 75% while keeping every technical detail intact when working with Claude Code, Cursor or similar agents.391k94.7k
Lark Skill MakerQuickly turn any Lark/Feishu OpenAPI call or multi-step workflow into a reusable agent skill with its own SKILL.md.386k16k
Running Claude Code Via Litellm CopilotRun Claude Code at a fraction of the cost by routing requests through LiteLLM to the GitHub Copilot Chat API.270k72
Codex PetGenerate a complete Codex Pet spritesheet and metadata from one reference image without needing an OpenAI key or Codex Pro.246k10AI & Agent Buildingagents