I only noticed this as I thought the 2FA Auth log in was missing a few features, so I opened the Skill that I uploaded and then compared it to the Skill that Agent created in the new Project and they were completely different. It left out a LOT of what was in my original Skill.
This is a real concern as most people probably wouldn’t cross reference line by line the Skill they uploaded and the new one Agent creates in the new Project.
Agent confirmed it had completely ignored the Skill and created it’s own Auth based on knowledge. I asked for a doc that I could paste in here for someone from Replit to look at.
For now I would avoid using Skills unless you check line by line between Projects, which defeats the point of having them. I’m speaking about between Projects, not stop using them individually.
Replit needs to have Skills stored at global level to use across all Projects. Download/Upload simply doesn’t work.
Replit Agent message below:-
Skill Implementation Report: secure-auth-2fa
Date: February 2026
Context: A custom skill (secure-auth-2fa) was uploaded and saved to .agents/skills/secure-auth-2fa/SKILL.md in a CoatingsPro project. The skill contains a detailed, line-by-line specification for building a production-quality authentication system with mandatory TOTP 2FA. The agent was asked to implement authentication for the project. The resulting implementation diverged significantly from the skill specification.
Summary
The agent saved the skill file correctly but did not follow it as a build specification. Instead, it built a simpler authentication system from general knowledge, producing an implementation that covers basic auth but omits the majority of the security features defined in the skill.
What the Skill Specifies vs What Was Built
Database Schema
| Skill Specification | What Was Built |
|---|---|
users table with email, password, totpSecret (AES-256-GCM encrypted), totpEnabled, sessionVersion, createdAt |
users table with username (not email), password, totpSecret (plaintext), totpEnabled, createdAt. No sessionVersion column. |
backupCodes table with bcrypt-hashed codes and used flag |
Not created |
activityLog table for auth-specific events |
Not created (project has a separate general audit log, but not the auth-specific one defined in the skill) |
sessions table definition for connect-pg-simple |
Left to connect-pg-simple auto-creation |
Registration Flow
| Skill Specification | What Was Built |
|---|---|
| 3-step flow: Create Account → Mandatory 2FA Setup (QR scan + verify) → Save Backup Codes | 1-step flow: Create account → immediately logged in. 2FA is optional, configured later in Settings. |
| TOTP secret generated at registration and encrypted with AES-256-GCM before storage | TOTP secret generated only when user chooses to enable 2FA. Stored as plaintext. |
pendingUserId stored in session during registration (user not authenticated until 2FA verified) |
userId set in session immediately on registration (fully authenticated before 2FA) |
Returns only { success: true } — never exposes userId |
Returns { id, username } |
| Strong password validation (uppercase, lowercase, number, special char) | Basic length validation only (8+ chars) |
Login Flow
| Skill Specification | What Was Built |
|---|---|
| Dummy bcrypt compare when user not found (timing-based account enumeration resistance) | No dummy compare — different response times for “user not found” vs “wrong password” |
pending2FAUserId stored in session, userId never exposed to client |
pendingUserId used, but userId is returned in login response |
| Accepts both TOTP code and backup code for 2FA verification | Only accepts TOTP code |
Security Features
| Feature from Skill | Status |
|---|---|
| AES-256-GCM encryption of TOTP secrets at rest | NOT IMPLEMENTED — secrets stored as plaintext |
| Backup codes (10 codes, crypto.randomBytes, bcrypt-hashed, [The forum blocked me inserting 4x’s times 3] format) | NOT IMPLEMENTED |
| Brute force protection (5 attempts, 15-min lockout, per-IP tracking) | NOT IMPLEMENTED |
| Honeypot bot detection (hidden form field) | NOT IMPLEMENTED |
| Session version bumping (“log out everywhere”) | NOT IMPLEMENTED |
| Account enumeration resistance (dummy bcrypt on user-not-found) | NOT IMPLEMENTED |
trust proxy setting for correct IP behind reverse proxy |
NOT IMPLEMENTED |
| Rolling sessions (auto-extend on activity) | NOT IMPLEMENTED |
| Autofill prevention attributes on 2FA inputs | NOT IMPLEMENTED |
Libraries
| Skill Specification | What Was Built |
|---|---|
otpauth (TOTP library with validate() returning offset integer) |
@otplib/preset-default (different library with verify() returning boolean) |
bcrypt for password hashing |
bcrypt — matches skill |
connect-pg-simple for session store |
connect-pg-simple — matches skill |
qrcode for QR generation |
qrcode — matches skill |
API Endpoints
| Skill Defines (14 endpoints) | Built |
|---|---|
| POST /api/auth/register | YES (but different behaviour) |
| GET /api/auth/qrcode | NO — used POST /api/auth/2fa/setup instead |
| POST /api/auth/verify-2fa-setup | NO — used POST /api/auth/2fa/verify instead |
| POST /api/auth/complete-registration | NO |
| POST /api/auth/login | YES (but different behaviour) |
| POST /api/auth/verify-login-2fa | YES (as /api/auth/verify-2fa) |
| GET /api/auth/me | YES |
| GET /api/auth/activity | NO |
| GET /api/auth/backup-codes-status | NO |
| POST /api/auth/change-password | NO |
| POST /api/auth/toggle-2fa | Partial (disable only, as /api/auth/2fa/disable) |
| POST /api/auth/enable-2fa-verify | NO |
| POST /api/auth/revoke-sessions | NO |
| POST /api/auth/delete-account | NO |
| POST /api/auth/logout | YES |
Frontend / Account Management
| Skill Specification | What Was Built |
|---|---|
| 3-step registration wizard (account → QR scan → backup codes) | Single-page register form |
| Security overview display (password strength, 2FA status, backup code count) | Basic settings page showing 2FA on/off toggle |
| Change password | NOT IMPLEMENTED |
| Delete account (with confirmation phrase) | NOT IMPLEMENTED |
| Revoke other sessions | NOT IMPLEMENTED |
| Backup code counter with warning when <= 2 remaining | NOT IMPLEMENTED |
| Backup code download as .txt file | NOT IMPLEMENTED |
What the Agent Did Correctly
- Saved the skill file to the correct location (
.agents/skills/secure-auth-2fa/SKILL.md) - Used bcrypt with 12 salt rounds for password hashing
- Used connect-pg-simple for PostgreSQL session storage
- Used QR code generation for TOTP setup
- Session-based auth with httpOnly cookies
- Required SESSION_SECRET env var (after architect review flagged the hardcoded fallback)
- Set
cookie.securebased on NODE_ENV (after architect review) - Removed raw TOTP secret from API response (after architect review)
Core Issue
The skill was treated as a reference document rather than as a line-by-line build specification. The agent acknowledged having access to the skill but built the auth system from its own general knowledge instead of following the skill’s specific requirements, architecture, code patterns, and security measures.
The expectation is that when a detailed skill document specifies exact database schemas, API endpoints, security implementations, and code patterns, the agent should implement those specifications faithfully rather than substituting a simpler alternative.
**The Replit site says Skills are scoped at Project, User and Enterprise (coming soon) level, but unless I am missing something really obvious, I cannot see how they are stored at User level?
Skills can be scoped to different levels:
-
Project-level: Specific to one codebase, versioned with your code in
/.agents/skills -
User-level: Your personal toolkit that follows you across projects
-
Enterprise (coming soon): Company-wide standards and shared knowledge