Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.
---code:SPEC-001title:AddUserAuthenticationwithJWTstatus:draftcreated_at:2025-11-13updated_at:2025-11-13priority:higheffort:8version:1.0.0epic:AUTH-01domains:-backend-security-database---
# SPEC-001: Add User Authentication with JWT## OverviewImplementsecureJWT-baseduserauthenticationwithpasswordhashingand
[ ]
[ ]
[ ]
[ ]
token
validation.
## Requirements
### REQ-001 (Universal)
SPEC:
The
authentication
service
SHALL
validate
JWT
tokens
using
RS256
algorithm
against
the
public
key.
### REQ-002 (Conditional)
SPEC:
If
a
JWT
token
has
expired,
then
the
authentication
service
SHALL
reject
the
request
and
return
HTTP
401
.
### REQ-003 (Unwanted Behavior)
SPEC:
The
authentication
service
SHALL
NOT
accept
JWT
tokens
signed
with
symmetric
algorithms
(HS256,
HS384,
HS512).
### REQ-004 (Stakeholder)
As
an
API
consumer,
I
want
to
pass
JWT
tokens
in
the
Authorization
header
so
that
my
requests
are
authenticated.
### REQ-005 (Boundary Condition)
SPEC:
The
authentication
service
SHALL
return
HTTP
429
when
a
single
IP
attempts
more
than
10
failed
authentications
in
5
minutes.
## Unwanted Behaviors
### Security Constraints
-
The
system
SHALL
NOT
store
JWT
secrets
in
source
code
-
The
system
SHALL
NOT
log
JWT
tokens
or
sensitive
claims
### Performance Constraints
-
The
system
SHALL
NOT
block
on
token
validation
(async
pattern)
-
The
system
SHALL
NOT
cache
tokens
indefinitely
## Acceptance Criteria
-
All
5
REQ
patterns
implemented
and
tested
-
Code
coverage
≥85%
-
Security
scan
passed
(OWASP
Top
10
)
-
Performance:
JWT
validation
p99
latency
≤200ms
EARS Pattern Summary
Pattern
Syntax
Use Case
Universal
The [System] SHALL [Action]
Core system behavior
Conditional
If [Condition], then [System] SHALL [Action]
Conditional logic
Unwanted Behavior
The [System] SHALL NOT [Action]
Security constraints
Stakeholder
As a [Role], I want [Feature] so that [Benefit]
User stories
Boundary Condition
[System] SHALL [Action] when [Condition]
Edge cases
Level 2: Core Implementation
YAML Metadata Structure
7 Required Fields
---# SPEC identifier (auto-generated)code:SPEC-001# SPEC title (descriptive, 50-80 chars)title:AddUserAuthenticationwithJWT# SPEC status (draft | active | deprecated | archived)status:draft# Creation timestamp (ISO 8601: YYYY-MM-DD)created_at:2025-11-13# Last updated timestamp (ISO 8601: YYYY-MM-DD)updated_at:2025-11-13# Business priority (critical | high | medium | low)priority:high# Estimated effort in story points (1-13 scale)effort:8---
9 Optional Fields
# Version tracking (semantic versioning: major.minor.patch)version:1.0.0# Deadline target date (ISO 8601: YYYY-MM-DD)deadline:2025-12-15# Epic this SPEC belongs to (e.g., AUTH-01, ONBOARDING-02)epic:AUTH-01# Related SPEC codes (dependencies or conflicts)depends_on:-SPEC-002-SPEC-003# Affected domains (for routing to specialists)domains:-backend-security-database# Acceptance criteria complexity ratingacceptance_difficulty:high# Rollback complexity rating (critical | high | medium | low)rollback_risk:medium# Risk assessment notesrisks:|
- Security: JWT key rotation must be tested
- Performance: Token validation on every request
# Custom tags for filtering/searchingtags:-authentication-security-jwt-users
EARS Requirement Syntax
Pattern 1: Universal (Always True)
Syntax:
SPEC: The [System] SHALL [Action]
Example:
SPEC-001-REQ-001: The authentication service SHALL validate
all JWT tokens using RS256 algorithm against the public key.
Related TEST:
- test_valid_jwt_with_rs256_signature
- test_invalid_jwt_with_wrong_algorithm
Pattern 2: Conditional (If-Then)
Syntax:
SPEC: If [Condition], then the [System] SHALL [Action]
Example:
SPEC-001-REQ-002: If a JWT token has expired,
then the authentication service SHALL reject the request
and return HTTP 401 Unauthorized with error code TOKEN_EXPIRED.
Related TEST:
- test_expired_token_returns_401
- test_expired_token_error_message
SPEC-001-REQ-003: The authentication service SHALL NOT
accept JWT tokens signed with symmetric algorithms (HS256, HS384, HS512)
in a production environment.
Related TEST:
- test_reject_hs256_signed_token
- test_reject_hs384_signed_token
- test_reject_hs512_signed_token
Pattern 4: Stakeholder (User Role-Specific)
Syntax:
SPEC: As a [User Role], I want [Feature] so that [Benefit]
Example:
SPEC-001-REQ-004: As an API consumer,
I want to pass JWT tokens in the Authorization header
so that my requests are authenticated without exposing tokens.
Related TEST:
- test_jwt_from_authorization_header
- test_jwt_in_query_param_rejected
- test_malformed_authorization_header
Pattern 5: Boundary Condition (Edge Cases)
Syntax:
SPEC: [System] SHALL [Action] when [Boundary Condition]
Example:
SPEC-001-REQ-005: The authentication service SHALL return
HTTP 429 Too Many Requests when a single IP address
attempts more than 10 failed authentication attempts within 5 minutes.
Related TEST:
- test_rate_limit_after_10_failures
- test_rate_limit_window_5_minutes
- test_rate_limit_by_ip_address
Level 3: Advanced Features
Version Lifecycle Management
Lifecycle States
DRAFT → ACTIVE → DEPRECATED → ARCHIVED
↓ ↓
Under Review Stable, In Use
↓ ↓
Changes Expected Changes Require
Feedback Pending Major Version Bump
State Transitions
DRAFT → ACTIVE:
All acceptance criteria defined
At least 2 reviewers approved
No critical open issues
version bumped to 1.0.0
Status change commit created
ACTIVE → DEPRECATED:
Marked with deprecation reason
Migration path documented
Replacement SPEC linked
30-day notice period
Status change commit created
DEPRECATED → ARCHIVED:
No active code references
All dependent SPECs archived
Historical record maintained
No further changes allowed
Archive commit created
Unwanted Behaviors Section
Critical security and quality constraints that MUST be tested:
defauthenticate_user(token: str) -> bool:
"""Validate JWT token per SPEC-001."""pass
Documentation:
## Authentication Flow
Per SPEC-001, the system SHALL validate all JWT tokens...
Level 4: Reference & Integration
Pre-Submission Validation Checklist
Metadata Validation
code field filled (SPEC-XXX format)
title is descriptive (50-80 characters)
status is one of: draft | active | deprecated | archived
created_at is ISO 8601 format (YYYY-MM-DD)
updated_at matches actual update date
priority is one of: critical | high | medium | low
effort is between 1-13 (story points)
Requirement Syntax
At least 3 REQ patterns used (Universal, Conditional, Unwanted)
Each REQ follows EARS syntax strictly
Requirements are specific and testable
No ambiguous language ("should", "may", "might")
All REQs are actionable (have test cases)
Unwanted Behaviors
Security constraints listed (if applicable)
Performance constraints listed (if applicable)
Reliability constraints listed (if applicable)
Data integrity constraints listed (if applicable)
Each Unwanted Behavior has a test approach
Acceptance Criteria
All 5 EARS patterns implemented
All Unwanted Behaviors testable
Code coverage target ≥85% specified
Security scan type specified
Performance baseline defined (if applicable)
Final Review
No TODO or placeholder text
All links are valid (internal and external)
Formatting is consistent (markdown syntax)
No confidential information exposed
Ready for team review
Common Pitfalls & Anti-Patterns
Anti-Pattern 1: Ambiguous Requirements
Bad:
SPEC-001-REQ-001: The system should authenticate users quickly.
Good:
SPEC-001-REQ-001: The authentication service SHALL validate JWT tokens
and return a response within 50ms on average,
with p99 latency not exceeding 200ms.
Anti-Pattern 2: Vague Acceptance Criteria
Bad:
- The feature should work
- Tests should pass
- No obvious bugs
moai-foundation-trust - Security and compliance principles
moai-alfred-workflow - SPEC creation workflows
TRUST Principles Applied
Test First: All requirements include test cases and validation criteria
Readable: Clear EARS syntax with unambiguous language
Unified: Consistent structure across all SPEC documents
Secured: Unwanted Behaviors section with security constraints
Traceable: TAG integration for complete requirement traceability
Enterprise v4.0 Compliance: Progressive disclosure with comprehensive EARS syntax, validation checklists, and lifecycle management.
Last Updated: 2025-11-13 Dependencies: YAML metadata format, EARS specification, TAG system
See Also: examples.md for detailed SPEC examples
