Install
$ agentstack add skill-legendtkl-agentic-skill-router-skill-007 ✓ 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
Feature Specification Generator
Create structured feature specifications from natural language descriptions.
SpecKit Workflow
This skill is Step 1 of 6 in the Relentless workflow:
specify → plan → tasks → analyze → implement (task by task) or relentless run --feature [FEATURE NAME] --tui
What flows to next step:
- User requirements → plan will create technical approach
- Routing preference → carried through all artifacts
- Acceptance criteria → basis for TDD in implementation
TDD is MANDATORY
The specification MUST include testable acceptance criteria:
- Every user requirement should be verifiable with tests
- Test scenarios should be part of each story
- Edge cases should be documented for test coverage
All acceptance criteria must be written in Given/When/Then format to enable direct test implementation.
The Job
- Receive feature description from user
- Confirm routing preference (Step 0)
- Generate short name and feature number
- Create branch and feature directory in
relentless/features/NNN-feature-name/ - Generate specification using template
- Validate specification quality (including TDD readiness)
- Save to
spec.md
Step 0: Confirm Routing Preference (BEFORE generating spec)
Ask the user these specific questions:
- "Which routing mode?" (free/cheap/good/genius) - Default:
good - "Allow free models in fallback?" - Default:
yes - "Specific harness/model preference?" - Default:
auto
Record the answer in spec.md metadata:
**Routing Preference**: auto: good | allow free: yes
Step 1: Create Feature Structure
Run the create-new-feature script to set up the branch and directory:
.claude/skills/specify/scripts/bash/create-new-feature.sh --json "FEATURE_DESCRIPTION"
This will output JSON with:
BRANCH_NAME: e.g., "003-user-auth"SPEC_FILE: Full path to spec.mdFEATURE_DIR: Full path to feature directoryFEATURE_NUM: e.g., "003"
Important: Parse this JSON and use these paths for all subsequent operations.
Step 2: Load Constitution & Context
- Read
relentless/constitution.mdfor project governance - Note any MUST/SHOULD rules that apply to specifications
- Keep these principles in mind while generating the spec
- Pay special attention to TDD requirements - all features must be testable
Step 3: Generate Specification
Using the template at templates/spec.md, create a specification with:
Required Sections:
1. Feature Overview
- One-paragraph summary
- User value proposition
- Problem being solved
2. User Scenarios & Testing
- Concrete user stories with priorities (P1, P2, P3...)
- Step-by-step flows
- Expected outcomes
- Given/When/Then acceptance scenarios (MANDATORY)
- Independent testability explanation for each story
3. Functional Requirements
- What the system must do
- Testable requirements (no implementation details)
- Clear success criteria
4. Test Strategy (MANDATORY)
- Unit test approach
- Integration test scenarios
- Edge case tests
- Test data requirements
5. Success Criteria
- Measurable, technology-agnostic outcomes
- Quantitative metrics (time, performance, volume)
- Qualitative measures (user satisfaction, task completion)
6. Key Entities (if applicable)
- Data models and relationships
- Fields and types (logical, not implementation)
7. Dependencies & Assumptions
- External systems required
- Prerequisites
- Assumptions made
8. Out of Scope
- What this feature explicitly does NOT include
- Future considerations
Step 4: Handle Ambiguities
If aspects are unclear:
- Interview the user first with questions to clarify any doubts, concerns or about his opinion on eventual ideas to improve the feature.
- Only mark
[NEEDS CLARIFICATION: specific question]if: - Choice significantly impacts scope or UX
- Multiple reasonable interpretations exist
- No reasonable default exists
- Question not already solved by interview
- LIMIT: Maximum 3 clarifications
If clarifications needed, present to user:
## Clarification Needed
**Q1: [Topic]**
Context: [Quote spec section]
Question: [Specific question]
Options:
A. [Option 1] - [Implications]
B. [Option 2] - [Implications]
C. Custom - [Your answer]
Your choice: _
Step 5: Validate Quality
Check the specification against:
General Quality
- [ ] No implementation details (languages, frameworks, APIs)
- [ ] Focused on user value and business needs
- [ ] All requirements are testable
- [ ] Success criteria are measurable
- [ ] User scenarios cover primary flows
- [ ] Dependencies identified
- [ ] Scope clearly bounded
- [ ] No more than 3
[NEEDS CLARIFICATION]markers
TDD Readiness (MANDATORY)
- [ ] Every user story has Given/When/Then acceptance criteria
- [ ] Acceptance criteria are specific enough to write tests against
- [ ] Edge cases are documented for test coverage
- [ ] Test strategy section is complete
Routing Compliance
- [ ] Routing preference is recorded in metadata
- [ ] Routing choice is reasonable for feature complexity
If validation fails, revise and re-check (max 3 iterations).
Step 6: Save & Report
- Write complete specification to
SPEC_FILEfrom JSON output - Create progress.txt if it doesn't exist:
```markdown --- feature: FEATURENAME started: DATE lastupdated: DATE storiescompleted: 0 routingpreference: [auto: mode | allow free: yes/no] ---
# Progress Log: FEATURE_NAME ```
- Report to user:
- Branch created:
BRANCH_NAME - Spec saved:
SPEC_FILE - Quality validation: PASSED/FAILED
- TDD readiness: PASSED/FAILED
- Routing preference: [recorded value]
- Next step:
/relentless.planor/relentless.clarify
Example Output
# Feature: User Authentication
**Routing Preference**: auto: good | allow free: yes
## Overview
Enable users to create accounts and log in securely using email/password.
## User Scenarios
### User Story 1: New User Registration (Priority: P1)
User visits signup page, enters email and password, and creates an account.
**Why this priority**: Core functionality, blocks all other auth features.
**Independent Test**: Can be fully tested by registering a new account and verifying the account exists.
**Acceptance Scenarios**:
1. **Given** a visitor on the signup page, **When** they submit valid email and password, **Then** the account is created and confirmation email sent
2. **Given** an email already in use, **When** visitor tries to register, **Then** error message shown without revealing account exists
## Functional Requirements
**REQ-1:** System must validate email format
**REQ-2:** System must require passwords ≥ 8 characters
**REQ-3:** System must send confirmation email within 1 minute
**REQ-4:** System must hash passwords before storage
## Test Strategy (MANDATORY)
### Unit Test Approach
- Email validation logic
- Password strength validation
- Password hashing utility
### Integration Test Scenarios
- Full registration flow (submit form → create account → send email)
- Duplicate email rejection
### Edge Case Tests
- Invalid email formats (missing @, invalid domain)
- Password too short
- Unicode in email/password
### Test Data Requirements
- Valid test email addresses
- Various invalid email formats
- Password examples at boundary conditions
## Success Criteria
1. 95% of signups complete within 60 seconds
2. Zero plaintext passwords in database
3. Email confirmation rate > 80%
## Key Entities
**User**
- email: string (unique)
- password_hash: string
- confirmed: boolean
- created_at: timestamp
## Dependencies
- Email service provider (e.g., SendGrid, Mailgun)
- Session management system
## Out of Scope
- Social login (OAuth)
- Two-factor authentication
- Password reset (separate feature)
Notes
- Always run the script first to get proper paths
- Use absolute paths from JSON output
- Validate before marking complete
- Keep specification technology-agnostic
- Focus on WHAT, not HOW
- TDD readiness is non-negotiable - all acceptance criteria must be testable
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: legendtkl
- Source: legendtkl/agentic-skill-router
- License: MIT
- Homepage: https://legendtkl.github.io/agentic-skill-router/
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.