--- 📊 Original Quality Score: 43% (v-1) — heuristic estimate, not a precise measurement Breakdown: Completeness 7.5/30, Clarity 8/20, Realism 5/20, Safety 20/20, Specificity 2/10 = 42.5/100 (rounded to 43%) (0-49% Needs major work | 50-74% Basic, gaps exist | 75-89% Good, minor gaps | 90-99% Professional | 100% Ready to send) Requester Profile: Novice — request uses casual, non-technical framing ("should be quick") and lacks any structured spec elements. Domain: Feature Build Readiness Check: - Goal: Present — "add a login feature to my app" - Expected Output: Missing — "no supporting text found" - Success Criteria: Missing — "no supporting text found" - Context: Partial — "react and node" - Constraints: Missing — "no supporting text found" - Target Environment: Missing — "no supporting text found" 🔒 Safety Review: - Behavior-altering attempt: Missing (none found in request) - Sensitive data exposure: Missing (none found in request) - Out-of-scope code purpose: Missing (none found in request) ⚠️ Risks (ranked by severity): High: Unrealistic scope assumption / evidence: "should be quick" / impact: likely to cause scope disputes and budget mismatch once auth complexity (validation, hashing, sessions, edge cases) becomes clear. Medium: No deliverable format specified / evidence: no supporting text found / impact: developer and client may disagree on what "done" looks like (PR vs. standalone script vs. deployed feature). Medium: No success criteria / evidence: no supporting text found / impact: no way to verify completion or handle disputes over acceptance. Low: No target environment detail / evidence: no supporting text found / impact: possible late-stage surprises around hosting, scale, or deployment constraints. 💡 Recommendations: High: Define concrete success criteria (e.g., registration/login/logout flows, password hashing, error handling for invalid credentials). Medium: Specify the deliverable format (PR, patch, deployed feature) and where it integrates into the existing codebase. Medium: Specify the authentication approach (session-based vs. token/JWT) and any required security standards. Low: Clarify target environment (web only, mobile, expected traffic/scale, hosting platform). Optimized Request: I need a developer to build a login feature (user authentication) for my web application, using React for the frontend and Node.js for the backend. (assumption: authentication should include registration, login, and logout functionality with secure password storage, e.g., hashed passwords, since no explicit feature list was given). (assumption: session or token-based authentication should follow standard practice, e.g., JWT or server-side sessions — exact choice to be confirmed with me before implementation). Deliverable: a pull request or patch that integrates the login feature into my existing codebase, including any necessary backend API endpoints and React UI components. (assumption: I already have a basic React frontend and Node backend set up, and this request covers only adding the login feature to that existing base, since no mention was made of building the app from scratch). Success criteria: a user can register, log in, and log out successfully; passwords are stored securely (hashed, never in plaintext); basic input validation and error handling exist for invalid credentials; the feature works correctly in my current development environment. (assumption: no specific automated test suite is required unless I state otherwise). Constraints: (assumption: no style guide, required/forbidden libraries, or budget ceiling were specified — these need to be confirmed by me). Target Environment: (assumption: this is a browser-based web application backed by a Node.js server; expected traffic/scale and hosting platform are not yet known and need to be confirmed by me). 📊 Improved Quality Score: 61% (v-2) Breakdown: Completeness 12.5/30, Clarity 15/20, Realism 10/20, Safety 20/20, Specificity 3/10 = 60.5/100 (rounded to 61%) Score Comparison: Improvement: +18 points — structure, deliverable format, and success criteria are now spelled out, which lifted Clarity and Realism significantly. However, most gains come from labeled assumptions rather than user-supplied specifics, so Completeness and Specificity stay capped — filled-by-assumption fields don't earn full credit per the rubric. Full completeness requires my actual input on constraints, target environment scale, and auth method preference. ℹ️ "This tool audits and improves the wording and completeness of the request — it is not a substitute for code review, security testing, or QA. Scores reflect a structured heuristic, not a precise measurement; wording and scores may vary slightly between runs. Final decisions remain the requester's responsibility." ❓ A few quick questions that would raise this above 90% — the Optimized Request above is ready to use as-is: ❓ Q1: Do you want session-based auth (cookies) or token-based auth (JWT), and do you have any existing user/database schema I should build against? ❓ Q2: What's the actual deliverable you expect — a merged PR into your existing repo, a standalone auth module, or something else — and do you have a target deadline or budget in mind? ❓ Q3: What's the expected scale/environment (personal project, internal tool, or public-facing production app), and are there any libraries you specifically want used or avoided (e.g., Passport.js, Auth0, bcrypt)?