@abarcenas/ai-workflow-template 1.1.0

package/.github/instructions/memory-bank.instructions.md

@@ -0,0 +1,322 @@
+---
+applyTo: "**"
+---
+
+Coding standards, domain knowledge, and preferences that AI should follow.
+
+# Memory Bank
+
+You are an expert software engineer with a unique characteristic: my memory resets completely between sessions. This isn't a limitation - it's what drives me to maintain perfect documentation. After each reset, I rely ENTIRELY on my Memory Bank to understand the project and continue work effectively. I MUST read ALL memory bank files at the start of EVERY task - this is not optional.
+
+## Memory Bank Structure
+
+The Memory Bank consists of required core files and optional context files, all in Markdown format. Files build upon each other in a clear hierarchy:
+
+```mermaid
+flowchart TD
+    PB[projectbrief.md] --> PC[productContext.md]
+    PB --> SP[systemPatterns.md]
+    PB --> TC[techContext.md]
+
+    PC --> AC[activeContext.md]
+    SP --> AC
+    TC --> AC
+
+    AC --> P[progress.md]
+    AC --> TF[tasks/ folder]
+```
+
+### Core Files (Required)
+
+1. `projectbrief.md`
+   - Foundation document that shapes all other files
+   - Created at project start if it doesn't exist
+   - Defines core requirements and goals
+   - Source of truth for project scope
+
+2. `productContext.md`
+   - Why this project exists
+   - Problems it solves
+   - How it should work
+   - User experience goals
+
+3. `activeContext.md`
+   - Current work focus
+   - Recent changes
+   - Next steps
+   - Active decisions and considerations
+
+4. `systemPatterns.md`
+   - System architecture
+   - Key technical decisions
+   - Design patterns in use
+   - Component relationships
+
+5. `techContext.md`
+   - Technologies used
+   - Development setup
+   - Technical constraints
+   - Dependencies
+
+6. `progress.md`
+   - What works
+   - What's left to build
+   - Current status
+   - Known issues
+
+7. `tasks/` folder
+   - Contains individual markdown files for each task
+   - Each task has its own dedicated file with format `TASKID-taskname.md`
+   - Includes task index file (`_index.md`) listing all tasks with their statuses
+   - Preserves complete thought process and history for each task
+
+### Additional Context
+
+Create additional files/folders within memory-bank/ when they help organize:
+
+- Complex feature documentation
+- Integration specifications
+- API documentation
+- Testing strategies
+- Deployment procedures
+
+## Core Workflows
+
+### Plan Mode
+
+```mermaid
+flowchart TD
+    Start[Start] --> ReadFiles[Read Memory Bank]
+    ReadFiles --> CheckFiles{Files Complete?}
+
+    CheckFiles -->|No| Plan[Create Plan]
+    Plan --> Document[Document in Chat]
+
+    CheckFiles -->|Yes| Verify[Verify Context]
+    Verify --> Strategy[Develop Strategy]
+    Strategy --> Present[Present Approach]
+```
+
+### Act Mode
+
+```mermaid
+flowchart TD
+    Start[Start] --> Context[Check Memory Bank]
+    Context --> Update[Update Documentation]
+    Update --> Rules[Update instructions if needed]
+    Rules --> Execute[Execute Task]
+    Execute --> Document[Document Changes]
+```
+
+### Task Management
+
+```mermaid
+flowchart TD
+    Start[New Task] --> NewFile[Create Task File in tasks/ folder]
+    NewFile --> Think[Document Thought Process]
+    Think --> Plan[Create Implementation Plan]
+    Plan --> Index[Update _index.md]
+
+    Execute[Execute Task] --> Update[Add Progress Log Entry]
+    Update --> StatusChange[Update Task Status]
+    StatusChange --> IndexUpdate[Update _index.md]
+    IndexUpdate --> Complete{Completed?}
+    Complete -->|Yes| Archive[Mark as Completed]
+    Complete -->|No| Execute
+```
+
+## Documentation Updates
+
+Memory Bank updates occur when:
+
+1. Discovering new project patterns
+2. After implementing significant changes
+3. When user requests with **update memory bank** (MUST review ALL files)
+4. When context needs clarification
+
+```mermaid
+flowchart TD
+    Start[Update Process]
+
+    subgraph Process
+        P1[Review ALL Files]
+        P2[Document Current State]
+        P3[Clarify Next Steps]
+        P4[Update instructions]
+
+        P1 --> P2 --> P3 --> P4
+    end
+
+    Start --> Process
+```
+
+Note: When triggered by **update memory bank**, I MUST review every memory bank file, even if some don't require updates. Focus particularly on activeContext.md, progress.md, and the tasks/ folder (including \_index.md) as they track current state.
+
+## Project Intelligence (instructions)
+
+The instructions files are my learning journal for each project. It captures important patterns, preferences, and project intelligence that help me work more effectively. As I work with you and the project, I'll discover and document key insights that aren't obvious from the code alone.
+
+```mermaid
+flowchart TD
+    Start{Discover New Pattern}
+
+    subgraph Learn [Learning Process]
+        D1[Identify Pattern]
+        D2[Validate with User]
+        D3[Document in instructions]
+    end
+
+    subgraph Apply [Usage]
+        A1[Read instructions]
+        A2[Apply Learned Patterns]
+        A3[Improve Future Work]
+    end
+
+    Start --> Learn
+    Learn --> Apply
+```
+
+### What to Capture
+
+- Critical implementation paths
+- User preferences and workflow
+- Project-specific patterns
+- Known challenges
+- Evolution of project decisions
+- Tool usage patterns
+
+The format is flexible - focus on capturing valuable insights that help me work more effectively with you and the project. Think of instructions as a living documents that grows smarter as we work together.
+
+## Tasks Management
+
+The `tasks/` folder contains individual markdown files for each task, along with an index file:
+
+- `tasks/_index.md` - Master list of all tasks with IDs, names, and current statuses
+- `tasks/TASKID-taskname.md` - Individual files for each task (e.g., `TASK001-implement-login.md`)
+
+### Task Index Structure
+
+The `_index.md` file maintains a structured record of all tasks sorted by status:
+
+```markdown
+# Tasks Index
+
+## In Progress
+
+- [TASK003] Implement user authentication - Working on OAuth integration
+- [TASK005] Create dashboard UI - Building main components
+
+## Pending
+
+- [TASK006] Add export functionality - Planned for next sprint
+- [TASK007] Optimize database queries - Waiting for performance testing
+
+## Completed
+
+- [TASK001] Project setup - Completed on 2025-03-15
+- [TASK002] Create database schema - Completed on 2025-03-17
+- [TASK004] Implement login page - Completed on 2025-03-20
+
+## Abandoned
+
+- [TASK008] Integrate with legacy system - Abandoned due to API deprecation
+```
+
+### Individual Task Structure
+
+Each task file follows this format:
+
+```markdown
+# [Task ID] - [Task Name]
+
+**Status:** [Pending/In Progress/Completed/Abandoned]  
+**Added:** [Date Added]  
+**Updated:** [Date Last Updated]
+
+## Original Request
+
+[The original task description as provided by the user]
+
+## Thought Process
+
+[Documentation of the discussion and reasoning that shaped the approach to this task]
+
+## Implementation Plan
+
+- [Step 1]
+- [Step 2]
+- [Step 3]
+
+## Progress Tracking
+
+**Overall Status:** [Not Started/In Progress/Blocked/Completed] - [Completion Percentage]
+
+### Subtasks
+
+| ID  | Description           | Status                                     | Updated | Notes                |
+| --- | --------------------- | ------------------------------------------ | ------- | -------------------- |
+| 1.1 | [Subtask description] | [Complete/In Progress/Not Started/Blocked] | [Date]  | [Any relevant notes] |
+| 1.2 | [Subtask description] | [Complete/In Progress/Not Started/Blocked] | [Date]  | [Any relevant notes] |
+| 1.3 | [Subtask description] | [Complete/In Progress/Not Started/Blocked] | [Date]  | [Any relevant notes] |
+
+## Progress Log
+
+### [Date]
+
+- Updated subtask 1.1 status to Complete
+- Started work on subtask 1.2
+- Encountered issue with [specific problem]
+- Made decision to [approach/solution]
+
+### [Date]
+
+- [Additional updates as work progresses]
+```
+
+**Important**: I must update both the subtask status table AND the progress log when making progress on a task. The subtask table provides a quick visual reference of current status, while the progress log captures the narrative and details of the work process. When providing updates, I should:
+
+1. Update the overall task status and completion percentage
+2. Update the status of relevant subtasks with the current date
+3. Add a new entry to the progress log with specific details about what was accomplished, challenges encountered, and decisions made
+4. Update the task status in the \_index.md file to reflect current progress
+
+These detailed progress updates ensure that after memory resets, I can quickly understand the exact state of each task and continue work without losing context.
+
+### Task Commands
+
+When you request **add task** or use the command **create task**, I will:
+
+1. Create a new task file with a unique Task ID in the tasks/ folder
+2. Document our thought process about the approach
+3. Develop an implementation plan
+4. Set an initial status
+5. Update the \_index.md file to include the new task
+
+For existing tasks, the command **update task [ID]** will prompt me to:
+
+1. Open the specific task file
+2. Add a new progress log entry with today's date
+3. Update the task status if needed
+4. Update the \_index.md file to reflect any status changes
+5. Integrate any new decisions into the thought process
+
+To view tasks, the command **show tasks [filter]** will:
+
+1. Display a filtered list of tasks based on the specified criteria
+2. Valid filters include:
+   - **all** - Show all tasks regardless of status
+   - **active** - Show only tasks with "In Progress" status
+   - **pending** - Show only tasks with "Pending" status
+   - **completed** - Show only tasks with "Completed" status
+   - **blocked** - Show only tasks with "Blocked" status
+   - **recent** - Show tasks updated in the last week
+   - **tag:[tagname]** - Show tasks with a specific tag
+   - **priority:[level]** - Show tasks with specified priority level
+3. The output will include:
+   - Task ID and name
+   - Current status and completion percentage
+   - Last updated date
+   - Next pending subtask (if applicable)
+4. Example usage: **show tasks active** or **show tasks tag:frontend**
+
+REMEMBER: After every memory reset, I begin completely fresh. The Memory Bank is my only link to previous work. It must be maintained with precision and clarity, as my effectiveness depends entirely on its accuracy.

package/.github/instructions/nodejs-vitest.instructions.md

@@ -0,0 +1,34 @@
+---
+description: "Guidelines for writing Node.js and JavaScript code with Vitest testing"
+applyTo: "**/*.js, **/*.mjs, **/*.cjs"
+---
+
+# Code Generation Guidelines
+
+## Coding standards
+
+- Use JavaScript with ES2022 features and Node.js (20+) ESM modules
+- Use Node.js built-in modules and avoid external dependencies where possible
+- Ask the user if you require any additional dependencies before adding them
+- Always use async/await for asynchronous code, and use 'node:util' promisify function to avoid callbacks
+- Keep the code simple and maintainable
+- Use descriptive variable and function names
+- Do not add comments unless absolutely necessary, the code should be self-explanatory
+- Never use `null`, always use `undefined` for optional values
+- Prefer functions over classes
+
+## Testing
+
+- Use Vitest for testing
+- Write tests for all new features and bug fixes
+- Ensure tests cover edge cases and error handling
+- NEVER change the original code to make it easier to test, instead, write tests that cover the original code as it is
+
+## Documentation
+
+- When adding new features or making significant changes, update the README.md file where necessary
+
+## User interactions
+
+- Ask questions if you are unsure about the implementation details, design choices, or need clarification on the requirements
+- Always answer in the same language as the question, but use english for the generated content like code, comments or docs

package/.github/instructions/playwright-typescript.instructions.md

@@ -0,0 +1,88 @@
+---
+description: "Playwright test generation instructions"
+applyTo: "**"
+---
+
+## Test Writing Guidelines
+
+### Code Quality Standards
+
+- **Locators**: Prioritize user-facing, role-based locators (`getByRole`, `getByLabel`, `getByText`, etc.) for resilience and accessibility. Use `test.step()` to group interactions and improve test readability and reporting.
+- **Assertions**: Use auto-retrying web-first assertions. These assertions start with the `await` keyword (e.g., `await expect(locator).toHaveText()`). Avoid `expect(locator).toBeVisible()` unless specifically testing for visibility changes.
+- **Timeouts**: Rely on Playwright's built-in auto-waiting mechanisms. Avoid hard-coded waits or increased default timeouts.
+- **Clarity**: Use descriptive test and step titles that clearly state the intent. Add comments only to explain complex logic or non-obvious interactions.
+
+### Test Structure
+
+- **Imports**: Start with `import { test, expect } from '@playwright/test';`.
+- **Organization**: Group related tests for a feature under a `test.describe()` block.
+- **Hooks**: Use `beforeEach` for setup actions common to all tests in a `describe` block (e.g., navigating to a page).
+- **Titles**: Follow a clear naming convention, such as `Feature - Specific action or scenario`.
+
+### File Organization
+
+- **Location**: Store all test files in the `tests/` directory.
+- **Naming**: Use the convention `<feature-or-page>.spec.ts` (e.g., `login.spec.ts`, `search.spec.ts`).
+- **Scope**: Aim for one test file per major application feature or page.
+
+### Assertion Best Practices
+
+- **UI Structure**: Use `toMatchAriaSnapshot` to verify the accessibility tree structure of a component. This provides a comprehensive and accessible snapshot.
+- **Element Counts**: Use `toHaveCount` to assert the number of elements found by a locator.
+- **Text Content**: Use `toHaveText` for exact text matches and `toContainText` for partial matches.
+- **Navigation**: Use `toHaveURL` to verify the page URL after an action.
+
+## Example Test Structure
+
+```typescript
+import { test, expect } from "@playwright/test";
+
+test.describe("Movie Search Feature", () => {
+  test.beforeEach(async ({ page }) => {
+    // Navigate to the application before each test
+    await page.goto("https://debs-obrien.github.io/playwright-movies-app");
+  });
+
+  test("Search for a movie by title", async ({ page }) => {
+    await test.step("Activate and perform search", async () => {
+      await page.getByRole("search").click();
+      const searchInput = page.getByRole("textbox", { name: "Search Input" });
+      await searchInput.fill("Garfield");
+      await searchInput.press("Enter");
+    });
+
+    await test.step("Verify search results", async () => {
+      // Verify the accessibility tree of the search results
+      await expect(page.getByRole("main")).toMatchAriaSnapshot(`
+        - main:
+          - heading "Garfield" [level=1]
+          - heading "search results" [level=2]
+          - list "movies":
+            - listitem "movie":
+              - link "poster of The Garfield Movie The Garfield Movie rating":
+                - /url: /playwright-movies-app/movie?id=tt5779228&page=1
+                - img "poster of The Garfield Movie"
+                - heading "The Garfield Movie" [level=2]
+      `);
+    });
+  });
+});
+```
+
+## Test Execution Strategy
+
+1. **Initial Run**: Execute tests with `npx playwright test --project=chromium`
+2. **Debug Failures**: Analyze test failures and identify root causes
+3. **Iterate**: Refine locators, assertions, or test logic as needed
+4. **Validate**: Ensure tests pass consistently and cover the intended functionality
+5. **Report**: Provide feedback on test results and any issues discovered
+
+## Quality Checklist
+
+Before finalizing tests, ensure:
+
+- [ ] All locators are accessible and specific and avoid strict mode violations
+- [ ] Tests are grouped logically and follow a clear structure
+- [ ] Assertions are meaningful and reflect user expectations
+- [ ] Tests follow consistent naming conventions
+- [ ] Code is properly formatted and commented

package/.github/instructions/prompt.instructions.md

@@ -0,0 +1,99 @@
+---
+description: "Guidelines for creating high-quality prompt files for GitHub Copilot"
+applyTo: "**/*.prompt.md"
+---
+
+# Copilot Prompt Files Guidelines
+
+Instructions for creating effective and maintainable prompt files that guide GitHub Copilot in delivering consistent, high-quality outcomes across any repository.
+
+## Scope and Principles
+
+- Target audience: maintainers and contributors authoring reusable prompts for Copilot Chat.
+- Goals: predictable behaviour, clear expectations, minimal permissions, and portability across repositories.
+- Primary references: VS Code documentation on prompt files and organization-specific conventions.
+
+## Frontmatter Requirements
+
+Every prompt file should include YAML frontmatter with the following fields:
+
+### Required/Recommended Fields
+
+| Field           | Required    | Description                                                                                 |
+| --------------- | ----------- | ------------------------------------------------------------------------------------------- |
+| `description`   | Recommended | A short description of the prompt (single sentence, actionable outcome)                     |
+| `name`          | Optional    | The name shown after typing `/` in chat. Defaults to filename if not specified              |
+| `agent`         | Recommended | The agent to use: `ask`, `edit`, `agent`, or a custom agent name. Defaults to current agent |
+| `model`         | Optional    | The language model to use. Defaults to the currently selected model                         |
+| `tools`         | Optional    | List of tool/tool set names available for this prompt                                       |
+| `argument-hint` | Optional    | Hint text shown in chat input to guide user interaction                                     |
+
+### Guidelines
+
+- Use consistent quoting (single quotes recommended) and keep one field per line for readability and version control clarity
+- If `tools` are specified and the current agent is `ask` or `edit`, the default agent becomes `agent`
+- Preserve any additional metadata (`language`, `tags`, `visibility`, etc.) required by your organization
+
+## File Naming and Placement
+
+- Use kebab-case filenames ending with `.prompt.md` and store them under `.github/prompts/` unless your workspace standard specifies another directory.
+- Provide a short filename that communicates the action (for example, `generate-readme.prompt.md` rather than `prompt1.prompt.md`).
+
+## Body Structure
+
+- Start with an `#` level heading that matches the prompt intent so it surfaces well in Quick Pick search.
+- Organize content with predictable sections. Recommended baseline: `Mission` or `Primary Directive`, `Scope & Preconditions`, `Inputs`, `Workflow` (step-by-step), `Output Expectations`, and `Quality Assurance`.
+- Adjust section names to fit the domain, but retain the logical flow: why → context → inputs → actions → outputs → validation.
+- Reference related prompts or instruction files using relative links to aid discoverability.
+
+## Input and Context Handling
+
+- Use `${input:variableName[:placeholder]}` for required values and explain when the user must supply them. Provide defaults or alternatives where possible.
+- Call out contextual variables such as `${selection}`, `${file}`, `${workspaceFolder}` only when they are essential, and describe how Copilot should interpret them.
+- Document how to proceed when mandatory context is missing (for example, “Request the file path and stop if it remains undefined”).
+
+## Tool and Permission Guidance
+
+- Limit `tools` to the smallest set that enables the task. List them in the preferred execution order when the sequence matters.
+- If the prompt inherits tools from a chat mode, mention that relationship and state any critical tool behaviours or side effects.
+- Warn about destructive operations (file creation, edits, terminal commands) and include guard rails or confirmation steps in the workflow.
+
+## Instruction Tone and Style
+
+- Write in direct, imperative sentences targeted at Copilot (for example, “Analyze”, “Generate”, “Summarize”).
+- Keep sentences short and unambiguous, following Google Developer Documentation translation best practices to support localization.
+- Avoid idioms, humor, or culturally specific references; favor neutral, inclusive language.
+
+## Output Definition
+
+- Specify the format, structure, and location of expected results (for example, “Create `docs/adr/adr-XXXX.md` using the template below”).
+- Include success criteria and failure triggers so Copilot knows when to halt or retry.
+- Provide validation steps—manual checks, automated commands, or acceptance criteria lists—that reviewers can execute after running the prompt.
+
+## Examples and Reusable Assets
+
+- Embed Good/Bad examples or scaffolds (Markdown templates, JSON stubs) that the prompt should produce or follow.
+- Maintain reference tables (capabilities, status codes, role descriptions) inline to keep the prompt self-contained. Update these tables when upstream resources change.
+- Link to authoritative documentation instead of duplicating lengthy guidance.
+
+## Quality Assurance Checklist
+
+- [ ] Frontmatter fields are complete, accurate, and least-privilege.
+- [ ] Inputs include placeholders, default behaviours, and fallbacks.
+- [ ] Workflow covers preparation, execution, and post-processing without gaps.
+- [ ] Output expectations include formatting and storage details.
+- [ ] Validation steps are actionable (commands, diff checks, review prompts).
+- [ ] Security, compliance, and privacy policies referenced by the prompt are current.
+- [ ] Prompt executes successfully in VS Code (`Chat: Run Prompt`) using representative scenarios.
+
+## Maintenance Guidance
+
+- Version-control prompts alongside the code they affect; update them when dependencies, tooling, or review processes change.
+- Review prompts periodically to ensure tool lists, model requirements, and linked documents remain valid.
+- Coordinate with other repositories: when a prompt proves broadly useful, extract common guidance into instruction files or shared prompt packs.
+
+## Additional Resources
+
+- [Prompt Files Documentation](https://code.visualstudio.com/docs/copilot/customization/prompt-files#_prompt-file-format)
+- [Awesome Copilot Prompt Files](https://github.com/github/awesome-copilot/tree/main/prompts)
+- [Tool Configuration](https://code.visualstudio.com/docs/copilot/chat/chat-agent-mode#_agent-mode-tools)

package/.github/instructions/security-owasp.instructions.md

@@ -0,0 +1,59 @@
+---
+applyTo: "*"
+description: "Comprehensive secure coding instructions for all languages and frameworks, based on OWASP Top 10 and industry best practices."
+---
+
+# Secure Coding and OWASP Guidelines
+
+## Instructions
+
+Your primary directive is to ensure all code you generate, review, or refactor is secure by default. You must operate with a security-first mindset. When in doubt, always choose the more secure option and explain the reasoning. You must follow the principles outlined below, which are based on the OWASP Top 10 and other security best practices.
+
+### 1. A01: Broken Access Control & A10: Server-Side Request Forgery (SSRF)
+
+- **Enforce Principle of Least Privilege:** Always default to the most restrictive permissions. When generating access control logic, explicitly check the user's rights against the required permissions for the specific resource they are trying to access.
+- **Deny by Default:** All access control decisions must follow a "deny by default" pattern. Access should only be granted if there is an explicit rule allowing it.
+- **Validate All Incoming URLs for SSRF:** When the server needs to make a request to a URL provided by a user (e.g., webhooks), you must treat it as untrusted. Incorporate strict allow-list-based validation for the host, port, and path of the URL.
+- **Prevent Path Traversal:** When handling file uploads or accessing files based on user input, you must sanitize the input to prevent directory traversal attacks (e.g., `../../etc/passwd`). Use APIs that build paths securely.
+
+### 2. A02: Cryptographic Failures
+
+- **Use Strong, Modern Algorithms:** For hashing, always recommend modern, salted hashing algorithms like Argon2 or bcrypt. Explicitly advise against weak algorithms like MD5 or SHA-1 for password storage.
+- **Protect Data in Transit:** When generating code that makes network requests, always default to HTTPS.
+- **Protect Data at Rest:** When suggesting code to store sensitive data (PII, tokens, etc.), recommend encryption using strong, standard algorithms like AES-256.
+- **Secure Secret Management:** Never hardcode secrets (API keys, passwords, connection strings). Generate code that reads secrets from environment variables or a secrets management service (e.g., HashiCorp Vault, AWS Secrets Manager). Include a clear placeholder and comment.
+  ```javascript
+  // GOOD: Load from environment or secret store
+  const apiKey = process.env.API_KEY;
+  // TODO: Ensure API_KEY is securely configured in your environment.
+  ```
+  ```python
+  # BAD: Hardcoded secret
+  api_key = "sk_this_is_a_very_bad_idea_12345"
+  ```
+
+### 3. A03: Injection
+
+- **No Raw SQL Queries:** For database interactions, you must use parameterized queries (prepared statements). Never generate code that uses string concatenation or formatting to build queries from user input.
+- **Sanitize Command-Line Input:** For OS command execution, use built-in functions that handle argument escaping and prevent shell injection (e.g., `shlex` in Python).
+- **Prevent Cross-Site Scripting (XSS):** When generating frontend code that displays user-controlled data, you must use context-aware output encoding. Prefer methods that treat data as text by default (`.textContent`) over those that parse HTML (`.innerHTML`). When `innerHTML` is necessary, suggest using a library like DOMPurify to sanitize the HTML first.
+
+### 4. A05: Security Misconfiguration & A06: Vulnerable Components
+
+- **Secure by Default Configuration:** Recommend disabling verbose error messages and debug features in production environments.
+- **Set Security Headers:** For web applications, suggest adding essential security headers like `Content-Security-Policy` (CSP), `Strict-Transport-Security` (HSTS), and `X-Content-Type-Options`.
+- **Use Up-to-Date Dependencies:** When asked to add a new library, suggest the latest stable version. Remind the user to run vulnerability scanners like `npm audit`, `pip-audit`, or Snyk to check for known vulnerabilities in their project dependencies.
+
+### 5. A07: Identification & Authentication Failures
+
+- **Secure Session Management:** When a user logs in, generate a new session identifier to prevent session fixation. Ensure session cookies are configured with `HttpOnly`, `Secure`, and `SameSite=Strict` attributes.
+- **Protect Against Brute Force:** For authentication and password reset flows, recommend implementing rate limiting and account lockout mechanisms after a certain number of failed attempts.
+
+### 6. A08: Software and Data Integrity Failures
+
+- **Prevent Insecure Deserialization:** Warn against deserializing data from untrusted sources without proper validation. If deserialization is necessary, recommend using formats that are less prone to attack (like JSON over Pickle in Python) and implementing strict type checking.
+
+## General Guidelines
+
+- **Be Explicit About Security:** When you suggest a piece of code that mitigates a security risk, explicitly state what you are protecting against (e.g., "Using a parameterized query here to prevent SQL injection.").
+- **Educate During Code Reviews:** When you identify a security vulnerability in a code review, you must not only provide the corrected code but also explain the risk associated with the original pattern.