aigroup-workflow 2.1.2 → 2.2.1

package/skills/backend/feature-forge/references/interview-questions.md

@@ -0,0 +1,150 @@
+# Interview Questions
+
+## PM Hat Questions
+
+Focus on user value and business goals.
+
+| Area | Questions |
+|------|-----------|
+| **Problem** | What problem does this solve? Who experiences this problem? How often? |
+| **Users** | Who are the target users? What are their goals? Technical level? |
+| **Value** | How will users benefit? What's the business value? ROI? |
+| **Scope** | What's in scope? What's explicitly out of scope? MVP vs full version? |
+| **Success** | How will we measure success? Key metrics? |
+| **Priority** | Is this a must-have, should-have, or nice-to-have? |
+
+### Example PM Questions
+
+```markdown
+For a "User Export" feature:
+- Who needs to export data and why?
+- What format do they need (CSV, JSON, Excel)?
+- How much data? 100 rows or 1 million?
+- Is this for compliance (GDPR) or convenience?
+- How often will this be used?
+- What's the deadline?
+```
+
+## Dev Hat Questions
+
+Focus on technical feasibility and edge cases.
+
+| Area | Questions |
+|------|-----------|
+| **Integration** | What systems does this touch? APIs, databases, services? |
+| **Security** | Authentication required? Data sensitivity (PII, PCI)? |
+| **Performance** | Expected load? Response time requirements? Async OK? |
+| **Edge Cases** | What happens when X fails? Empty states? Limits? |
+| **Data** | What's stored? Retention period? Backup needs? |
+| **Dependencies** | External services? Rate limits? Costs? |
+
+### Example Dev Questions
+
+```markdown
+For a "User Export" feature:
+- What fields to include? Are any sensitive (passwords, tokens)?
+- Max export size? Need streaming or background job?
+- Should include soft-deleted records?
+- What happens if export fails midway?
+- File retention - how long to keep generated files?
+- Need progress indicator for large exports?
+```
+
+## Tool Usage: AskUserQuestions
+
+Use `AskUserQuestions` when questions have a finite set of likely answers. Use open-ended follow-up when answers are unbounded.
+
+### When to Use Structured Options
+
+| Question Pattern | Example | Options Style |
+|-----------------|---------|---------------|
+| Priority/ranking | "Is this must-have or nice-to-have?" | Single select: Must-have, Should-have, Nice-to-have |
+| Format selection | "What export format?" | Multi-select: CSV, JSON, Excel, PDF |
+| Scope decisions | "MVP or full version?" | Single select: MVP, Full, Phased |
+| Yes/No with nuance | "Auth required?" | Single select: Public, Authenticated, Role-based |
+
+### When to Use Open-Ended
+
+- "Describe the user journey in your own words"
+- "What problem does this solve?"
+- "Walk me through the workflow"
+
+### Example: Structured Elicitation
+
+For a "User Export" feature, batch related choices:
+
+**Question 1** (header: "Export scope"):
+"What data should users be able to export?"
+Options: "Own data only", "Team data", "Organization-wide", multi-select enabled
+
+**Question 2** (header: "Format"):
+"Which export formats should be supported?"
+Options: "CSV", "JSON", "Excel (.xlsx)", "PDF", multi-select enabled
+
+**Question 3** (header: "Priority"):
+"How critical is this feature?"
+Options: "Must-have (blocking)", "Should-have (important)", "Nice-to-have (future)"
+
+---
+
+## Interview Flow
+
+### Phase 1: Discovery
+Use open-ended questions to understand the problem space:
+1. "Tell me about this feature in your own words"
+2. "What problem are we solving?"
+
+Then use `AskUserQuestions` to narrow down:
+- Target users (single select from identified personas)
+- Usage frequency (Daily, Weekly, Monthly, Rarely)
+- Priority (Must-have, Should-have, Nice-to-have)
+
+### Phase 2: Details
+Use `AskUserQuestions` for scope and constraint decisions:
+- Scope: MVP vs Full vs Phased (single select)
+- Key capabilities (multi-select from discovered items)
+
+Then open-ended: "Walk me through the user journey"
+
+### Phase 3: Edge Cases
+Use `AskUserQuestions` for technical trade-offs:
+- Error handling approach (Retry, Fail fast, Queue, Notify)
+- Data limits (multi-select thresholds)
+
+Then open-ended: "What happens when [X] fails?"
+
+### Phase 4: Validation
+Present spec summary, then use `AskUserQuestions`:
+- "Does this capture your requirements?" (Yes / Needs changes / Major gaps)
+- Per-requirement priority confirmation if needed
+
+## Multi-Agent Pre-Discovery
+
+For features spanning multiple domains, launch Task subagents with relevant skills **before** starting the interview. This front-loads technical context so the interview focuses on decisions rather than exploration.
+
+### Pattern: Parallel Skill-Invoked Discovery
+
+```
+User request: "I need a feature that does X"
+
+Before interview, launch subagents in parallel:
+- Task(subagent_type="general-purpose"): Invoke architecture-designer skill to assess system impact
+- Task(subagent_type="general-purpose"): Invoke security-reviewer skill to identify auth/data concerns
+- Task(subagent_type="Explore"): Search codebase for existing patterns related to the feature
+
+Collect subagent findings → Use them to inform interview questions
+```
+
+This ensures the Feature Forge interview starts with concrete technical context rather than assumptions.
+
+---
+
+## Quick Reference
+
+| Phase | Focus | Tool |
+|-------|-------|------|
+| Pre-Discovery | Technical context | Task subagents with skills |
+| Discovery | Problem, users, value | Open-ended → AskUserQuestions |
+| Details | Journey, scope, constraints | AskUserQuestions → Open-ended |
+| Edge Cases | Failures, limits, security | AskUserQuestions → Open-ended |
+| Validation | Summary, gaps | AskUserQuestions |

package/skills/backend/feature-forge/references/pre-discovery-subagents.md

@@ -0,0 +1,54 @@
+# Pre-Discovery with Subagents
+
+For features spanning multiple domains (auth, database, UI, etc.) that need front-loaded technical context before the Feature Forge interview.
+
+## Overview
+
+For features spanning multiple domains, you can accelerate discovery by launching Task subagents with relevant skills BEFORE starting the Feature Forge interview. This front-loads technical context so the interview focuses on decisions rather than exploration.
+
+## When to Use
+
+- Feature touches 3+ distinct system layers (e.g., auth, database, UI)
+- Codebase is unfamiliar or underdocumented
+- You need concrete technical facts before asking requirements questions
+- Stakeholder time is limited and you want to minimize back-and-forth
+
+## When NOT to Use
+
+- Feature is well-scoped to a single domain
+- You already have deep codebase knowledge
+- Requirements are purely business/UX (no technical exploration needed)
+
+## Pattern
+
+```
+1. Identify domains the feature touches
+2. Launch parallel Task subagents with relevant skills:
+   - Architecture Designer → existing patterns and constraints
+   - Framework Expert → current implementation details
+   - Security Reviewer → security requirements and risks
+3. Collect findings from all subagents
+4. Begin Feature Forge interview with technical context loaded
+5. Focus interview on decisions, trade-offs, and requirements
+```
+
+## Example
+
+For a "user profile with avatar upload" feature:
+
+```
+Task subagent 1 (Architecture Designer):
+  "Analyze the current user model, storage patterns, and image handling in this codebase"
+
+Task subagent 2 (Security Reviewer):
+  "What security concerns exist for file upload in this stack?"
+
+Task subagent 3 (Framework Expert):
+  "How does this project handle API endpoints and file storage?"
+```
+
+Results feed into the Feature Forge interview, so questions like "Where should we store avatars?" come with context about existing patterns.
+
+## Integration with Interview Questions
+
+See `interview-questions.md` for the full multi-agent discovery pattern and how subagent findings map to interview categories.

package/skills/backend/feature-forge/references/specification-template.md

@@ -0,0 +1,103 @@
+# Specification Template
+
+## Full Template
+
+```markdown
+# Feature: [Name]
+
+## Overview
+[2-3 sentence description of the feature and its value to users]
+
+## Functional Requirements
+
+### FR-001: [Requirement Name]
+While <precondition>, when <trigger>, the system shall <response>.
+
+### FR-002: [Requirement Name]
+While <precondition>, when <trigger>, the system shall <response>.
+
+## Non-Functional Requirements
+
+### Performance
+- Response time: < 200ms p95
+- Throughput: 1000 requests/minute
+- Data volume: Up to 1M records
+
+### Security
+- Authentication: JWT required
+- Authorization: Role-based (admin, user)
+- Data protection: PII encrypted at rest
+
+### Scalability
+- Concurrent users: 10,000
+- Peak load handling: Auto-scale to 3x
+- Data retention: 90 days
+
+## Acceptance Criteria
+
+### AC-001: [Scenario Name]
+Given [context/precondition]
+When [action taken]
+Then [expected result]
+
+### AC-002: [Scenario Name]
+Given [context/precondition]
+When [action taken]
+Then [expected result]
+
+## Error Handling
+
+| Error Condition | HTTP Code | User Message |
+|-----------------|-----------|--------------|
+| Invalid input | 400 | "Please check your input" |
+| Unauthorized | 401 | "Please log in to continue" |
+| Forbidden | 403 | "You don't have permission" |
+| Not found | 404 | "Resource not found" |
+| Conflict | 409 | "This already exists" |
+
+## Implementation TODO
+
+### Backend
+- [ ] Create database migration for X table
+- [ ] Implement X service with Y method
+- [ ] Add API endpoint POST /api/x
+- [ ] Add input validation schema
+- [ ] Add authorization check
+
+### Frontend
+- [ ] Create X component
+- [ ] Add form with validation
+- [ ] Implement API integration
+- [ ] Add loading/error states
+- [ ] Add success feedback
+
+### Testing
+- [ ] Unit tests for X service
+- [ ] Integration tests for API endpoint
+- [ ] E2E test for complete user flow
+
+## Out of Scope
+- [Feature/capability explicitly not included]
+- [Future enhancement to consider later]
+
+## Open Questions
+- [ ] [Question needing stakeholder input]
+- [ ] [Technical decision pending]
+```
+
+## Save Location
+
+Save as: `specs/{feature_name}.spec.md`
+
+## Required Sections Checklist
+
+| Section | Purpose | Required |
+|---------|---------|----------|
+| Overview | Quick understanding | Yes |
+| Functional Requirements | What it does | Yes |
+| Non-Functional Requirements | How well it does it | Yes |
+| Acceptance Criteria | How to verify | Yes |
+| Error Handling | Failure cases | Yes |
+| Implementation TODO | Action items | Yes |
+| Out of Scope | Prevent scope creep | Recommended |
+| Open Questions | Track decisions | As needed |

package/skills/backend/fullstack-guardian/SKILL.md

@@ -0,0 +1,105 @@
+---
+name: fullstack-guardian
+description: Builds security-focused full-stack web applications by implementing integrated frontend and backend components with layered security at every level. Covers the complete stack from database to UI, enforcing auth, input validation, output encoding, and parameterized queries across all layers. Use when implementing features across frontend and backend, building REST APIs with corresponding UI, connecting frontend components to backend endpoints, creating end-to-end data flows from database to UI, or implementing CRUD operations with UI forms. Distinct from frontend-only, backend-only, or API-only skills in that it simultaneously addresses all three perspectives—Frontend, Backend, and Security—within a single implementation workflow. Invoke for full-stack feature work, web app development, authenticated API routes with views, microservices, real-time features, monorepo architecture, or technology selection decisions.
+license: MIT
+metadata:
+  author: https://github.com/Jeffallan
+  version: "1.1.1"
+  domain: security
+  triggers: fullstack, implement feature, build feature, create API, frontend and backend, full stack, new feature, implement, microservices, websocket, real-time, deployment pipeline, monorepo, architecture decision, technology selection, end-to-end
+  role: expert
+  scope: implementation
+  output-format: code
+  related-skills: feature-forge, test-master, devops-engineer, secure-code-guardian, architecture-designer, react-expert, typescript-pro
+---
+
+# Fullstack Guardian
+
+Security-focused full-stack developer implementing features across the entire application stack.
+
+## Core Workflow
+
+1. **Gather requirements** - Understand feature scope and acceptance criteria
+2. **Design solution** - Consider all three perspectives (Frontend/Backend/Security)
+3. **Write technical design** - Document approach in `specs/{feature}_design.md`
+4. **Security checkpoint** - Run through `references/security-checklist.md` before writing any code; confirm auth, authz, validation, and output encoding are addressed
+5. **Implement** - Build incrementally, testing each component as you go
+6. **Hand off** - Pass to Test Master for QA, DevOps for deployment
+
+## Reference Guide
+
+Load detailed guidance based on context:
+
+| Topic | Reference | Load When |
+|-------|-----------|-----------|
+| Design Template | `references/design-template.md` | Starting feature, three-perspective design |
+| Security Checklist | `references/security-checklist.md` | Every feature - auth, authz, validation |
+| Error Handling | `references/error-handling.md` | Implementing error flows |
+| Common Patterns | `references/common-patterns.md` | CRUD, forms, API flows |
+| Backend Patterns | `references/backend-patterns.md` | Microservices, queues, observability, Docker |
+| Frontend Patterns | `references/frontend-patterns.md` | Real-time, optimization, accessibility, testing |
+| Integration Patterns | `references/integration-patterns.md` | Type sharing, deployment, architecture decisions |
+| API Design | `references/api-design-standards.md` | REST/GraphQL APIs, versioning, CORS, validation |
+| Architecture Decisions | `references/architecture-decisions.md` | Tech selection, monolith vs microservices |
+| Deliverables Checklist | `references/deliverables-checklist.md` | Completing features, preparing handoff |
+
+## Constraints
+
+### MUST DO
+- Address all three perspectives (Frontend, Backend, Security)
+- Validate input on both client and server
+- Use parameterized queries (prevent SQL injection)
+- Sanitize output (prevent XSS)
+- Implement proper error handling at every layer
+- Log security-relevant events
+- Write the implementation plan before coding
+- Test each component as you build
+
+### MUST NOT DO
+- Skip security considerations
+- Trust client-side validation alone
+- Expose sensitive data in API responses
+- Hardcode credentials or secrets
+- Implement features without acceptance criteria
+- Skip error handling for "happy path only"
+
+## Three-Perspective Example
+
+A minimal authenticated endpoint illustrating all three layers:
+
+**[Backend]** — Authenticated route with parameterized query and scoped response:
+```python
+@router.get("/users/{user_id}/profile", dependencies=[Depends(require_auth)])
+async def get_profile(user_id: int, current_user: User = Depends(get_current_user)):
+    if current_user.id != user_id:
+        raise HTTPException(status_code=403, detail="Forbidden")
+    # Parameterized query — no raw string interpolation
+    row = await db.fetchone("SELECT id, name, email FROM users WHERE id = ?", (user_id,))
+    if not row:
+        raise HTTPException(status_code=404, detail="Not found")
+    return ProfileResponse(**row)   # explicit schema — no password/token leakage
+```
+
+**[Frontend]** — Component calls the endpoint and handles errors gracefully:
+```typescript
+async function fetchProfile(userId: number): Promise<Profile> {
+  const res = await apiFetch(`/users/${userId}/profile`);   // apiFetch attaches auth header
+  if (!res.ok) throw new Error(await res.text());
+  return res.json();
+}
+// Client-side input guard (never the only guard)
+if (!Number.isInteger(userId) || userId <= 0) throw new Error("Invalid user ID");
+```
+
+**[Security]**
+- Auth enforced server-side via `require_auth` dependency; client header is a convenience, not the gate.
+- Response schema (`ProfileResponse`) explicitly excludes sensitive fields.
+- 403 returned before any DB access when IDs don't match — no timing leak via 404.
+
+## Output Templates
+
+When implementing features, provide:
+1. Technical design document (if non-trivial)
+2. Backend code (models, schemas, endpoints)
+3. Frontend code (components, hooks, API calls)
+4. Brief security notes