From aeon-loop
Generate a Product Requirements Document (PRD) for planning. Use when starting a new feature, project, or complex task. Triggers on: create a prd, write prd for, plan this feature, requirements for, spec out, prd for.
npx claudepluginhub theglitchking/aeon-loop --plugin aeon-loopThis skill uses the workspace's default tool permissions.
Create detailed Product Requirements Documents that integrate with Aeon Loop's planning system.
Generates design tokens/docs from CSS/Tailwind/styled-components codebases, audits visual consistency across 10 dimensions, detects AI slop in UI.
Records polished WebM UI demo videos of web apps using Playwright with cursor overlay, natural pacing, and three-phase scripting. Activates for demo, walkthrough, screen recording, or tutorial requests.
Delivers idiomatic Kotlin patterns for null safety, immutability, sealed classes, coroutines, Flows, extensions, DSL builders, and Gradle DSL. Use when writing, reviewing, refactoring, or designing Kotlin code.
Create detailed Product Requirements Documents that integrate with Aeon Loop's planning system.
For a complete guided experience (PRD → Planning → Approval → Execution), use:
/aeon-flux
This skill (/prd) creates just the PRD. Use /aeon-flux for the full workflow.
.planning/[task-slug]/prd.md/aeon-flux to continue the workflow/loop laterImportant: Do NOT start implementing. Just create the PRD.
Ask only critical questions where the initial prompt is ambiguous. Focus on:
1. What is the primary goal of this feature?
1.1. Improve user experience
1.2. Add new functionality
1.3. Fix existing issues
1.4. Other: [please specify]
2. What is the scope?
2.1. Minimal viable version
2.2. Full-featured implementation
2.3. Just the backend/API
2.4. Just the UI
3. What are the key constraints?
3.1. Must integrate with existing code
3.2. Greenfield implementation
3.3. Performance critical
3.4. Security critical
This lets users respond with "1.1, 2.2, 3.1" for quick iteration.
Generate the PRD with these sections:
Brief description of the feature and the problem it solves.
Specific, measurable objectives (bullet list).
Each story needs:
Each story should be small enough to implement in one focused session.
Format:
### US-001: [Title]
**Description:** As a [user], I want [feature] so that [benefit].
**Acceptance Criteria:**
- [ ] Specific verifiable criterion
- [ ] Another criterion
- [ ] Tests pass
Important:
Numbered list of specific functionalities:
Be explicit and unambiguous.
What this feature will NOT include. Critical for managing scope.
How will success be measured? What does "done" look like?
Remaining questions or areas needing clarification.
Critical Rule: Each user story must be completable in the first 60% of a context window (one loop iteration).
Stories should complete using roughly 60% of a subagent's context window:
This ensures stories never hit context limits and have room for error recovery.
If you cannot describe the change in 2-3 sentences, it is too big.
This is a quick heuristic. If you need a paragraph to explain it, split it.
For Sonnet 4.5 (~200K context window):
If a story would require:
→ It's too big. Split it.
Every story MUST include at minimum:
The PRD reader may be an AI agent executing via /loop. Therefore:
.md).planning/[task-slug]/prd.mdAfter creating the PRD, also create/update task_plan.md in the same directory with phases derived from the user stories.
After the user stories section, add a state block for progress tracking:
<!-- STATE
stories:
- id: US-001
title: "User Registration"
passes: false
notes: ""
- id: US-002
title: "User Login"
passes: false
notes: ""
/STATE -->
This block:
prd.md (no separate JSON file needed)passes: false → passes: true)Update protocol: After completing a story, update its passes field:
sed -i '/id: US-001/,/notes:/{s/passes: false/passes: true/}' .planning/*/prd.md
After generating the PRD:
.planning/[task-slug]/prd.md with the full PRD.planning/[task-slug]/task_plan.md with phases based on user stories/loop "[task]" --done "COMPLETE" to executeThe /loop command will use the PRD and task_plan.md to guide implementation.
# PRD: User Authentication System
## Overview
Implement user authentication with login, logout, and session management. Users should be able to securely access their accounts and have their sessions persist across browser restarts.
## Goals
- Secure user authentication with password hashing
- Session persistence using secure cookies
- Clear login/logout user flow
- Protection against common auth vulnerabilities
## User Stories
### US-001: User Registration
**Description:** As a new user, I want to create an account so that I can access the application.
**Acceptance Criteria:**
- [ ] Registration form with email and password fields
- [ ] Password minimum 8 characters with complexity requirements
- [ ] Email uniqueness validation
- [ ] Success redirects to login page
- [ ] Tests pass
### US-002: User Login
**Description:** As a registered user, I want to log in so that I can access my data.
**Acceptance Criteria:**
- [ ] Login form with email and password fields
- [ ] Invalid credentials show error message (no info leak)
- [ ] Successful login redirects to dashboard
- [ ] Session cookie set with secure flags
- [ ] Tests pass
### US-003: User Logout
**Description:** As a logged-in user, I want to log out so that I can secure my session.
**Acceptance Criteria:**
- [ ] Logout button visible when authenticated
- [ ] Clicking logout clears session
- [ ] Redirects to login page
- [ ] Tests pass
### US-004: Session Persistence
**Description:** As a user, I want my session to persist so I don't have to log in every time.
**Acceptance Criteria:**
- [ ] Session survives browser restart
- [ ] Session expires after 7 days of inactivity
- [ ] Remember me option for 30-day sessions
- [ ] Tests pass
## Functional Requirements
- FR-1: Hash passwords using bcrypt with cost factor 12
- FR-2: Store sessions in database with expiration timestamp
- FR-3: Set HttpOnly, Secure, SameSite=Strict on session cookies
- FR-4: Rate limit login attempts (5 per minute per IP)
- FR-5: Log authentication events for audit trail
## Non-Goals
- Social login (OAuth) - future enhancement
- Two-factor authentication - future enhancement
- Password reset via email - separate PRD
- User profile management - separate PRD
## Technical Considerations
- Use existing database connection pool
- Session table needs index on token and user_id
- Consider Redis for session storage if scale requires
## Success Criteria
- Users can register, login, and logout without errors
- Sessions persist correctly across browser restarts
- No security vulnerabilities in OWASP top 10
- All tests pass
## Open Questions
- What should session timeout be? (defaulting to 7 days)
- Should we support "remember me" from launch?
<!-- STATE
stories:
- id: US-001
title: "User Registration"
passes: false
notes: ""
- id: US-002
title: "User Login"
passes: false
notes: ""
- id: US-003
title: "User Logout"
passes: false
notes: ""
- id: US-004
title: "Session Persistence"
passes: false
notes: ""
/STATE -->
Before saving the PRD:
.planning/[task-slug]/prd.mdtask_plan.md with phases