@techierathore/techieflow 1.0.1 → 1.0.3

package/scripts/npm-postinstall.mjs

@@ -0,0 +1,49 @@
+#!/usr/bin/env node
+// scripts/npm-postinstall.mjs — the install hook, for when someone runs
+//
+//   npm install @techierathore/techieflow
+//
+// instead of the documented `npx @techierathore/techieflow@latest install`. npm runs this
+// hook after it has put the package under node_modules/. The hook installs the framework
+// into the project (the folder npm was run in), then starts npm-cleanup.mjs detached to
+// remove the package from node_modules/, package.json and package-lock.json once npm has
+// finished writing them. The result is the same as the npx command: the framework's hidden
+// folders, and no npm files that were not there before.
+//
+// npm 12 and newer do not run install hooks unless the project allows them, so on those
+// versions a plain `npm install` only places the package under node_modules/. The fix is
+// to run the documented npx command, which installs the framework and tidies that up.
+//
+// The hook does nothing when the package is not being installed as a dependency of some
+// other folder: `npx`, `npm exec`, `npm pack`, `npm publish` and `npm install` inside
+// this repository all skip it.
+
+import { spawn, spawnSync } from "node:child_process";
+import { existsSync } from "node:fs";
+import { dirname, join, resolve } from "node:path";
+import { fileURLToPath } from "node:url";
+
+const packageRoot = resolve(dirname(fileURLToPath(import.meta.url)), "..");
+const target = process.env.INIT_CWD ? resolve(process.env.INIT_CWD) : null;
+const dependencyInstall = ["install", "ci"].includes(process.env.npm_command)
+  && target !== null
+  && target !== packageRoot
+  && existsSync(join(target, "node_modules", "@techierathore", "techieflow"));
+
+if (!dependencyInstall) process.exit(0);
+
+const installed = spawnSync(process.execPath, [join(packageRoot, "scripts", "install.mjs"), "install", `--target=${target}`], {
+  cwd: target,
+  env: process.env,
+  stdio: "inherit",
+});
+if (installed.status !== 0) process.exit(installed.status ?? 1);
+
+const cleanup = spawn(process.execPath, [join(packageRoot, "scripts", "npm-cleanup.mjs"), target], {
+  cwd: target,
+  detached: true,
+  stdio: "ignore",
+  windowsHide: true,
+});
+cleanup.unref();
+console.log("TechieFlow installed. The temporary npm files (node_modules, package.json, package-lock.json entries) are being removed.");

package/.claude/commands/TechieFlow/tasks/advanced-elicitation.md

@@ -1,117 +0,0 @@
-# Advanced Elicitation Task
-
-## Purpose
-
-- Provide optional reflective and brainstorming actions to enhance content quality
-- Enable deeper exploration of ideas through structured elicitation techniques
-- Support iterative refinement through multiple analytical perspectives
-- Usable during template-driven document creation or any chat conversation
-
-## Usage Scenarios
-
-### Scenario 1: Template Document Creation
-
-After outputting a section during document creation:
-
-1. **Section Review**: Ask user to review the drafted section
-2. **Offer Elicitation**: Present 9 carefully selected elicitation methods
-3. **Simple Selection**: User types a number (0-8) to engage method, or 9 to proceed
-4. **Execute & Loop**: Apply selected method, then re-offer choices until user proceeds
-
-### Scenario 2: General Chat Elicitation
-
-User can request advanced elicitation on any agent output:
-
-- User says "do advanced elicitation" or similar
-- Agent selects 9 relevant methods for the context
-- Same simple 0-9 selection process
-
-## Task Instructions
-
-### 1. Intelligent Method Selection
-
-**Context Analysis**: Before presenting options, analyze:
-
-- **Content Type**: Technical specs, user stories, architecture, requirements, etc.
-- **Complexity Level**: Simple, moderate, or complex content
-- **Stakeholder Needs**: Who will use this information
-- **Risk Level**: High-impact decisions vs routine items
-- **Creative Potential**: Opportunities for innovation or alternatives
-
-**Method Selection Strategy**:
-
-1. **Always Include Core Methods** (choose 3-4):
-   - Expand or Contract for Audience
-   - Critique and Refine
-   - Identify Potential Risks
-   - Assess Alignment with Goals
-
-2. **Context-Specific Methods** (choose 4-5):
-   - **Technical Content**: Tree of Thoughts, ReWOO, Meta-Prompting
-   - **User-Facing Content**: Agile Team Perspective, Stakeholder Roundtable
-   - **Creative Content**: Innovation Tournament, Escape Room Challenge
-   - **Strategic Content**: Red Team vs Blue Team, Hindsight Reflection
-
-3. **Always Include**: "Proceed / No Further Actions" as option 9
-
-### 2. Section Context and Review
-
-When invoked after outputting a section:
-
-1. **Provide Context Summary**: Give a brief 1-2 sentence summary of what the user should look for in the section just presented
-
-2. **Explain Visual Elements**: If the section contains diagrams, explain them briefly before offering elicitation options
-
-3. **Clarify Scope Options**: If the section contains multiple distinct items, inform the user they can apply elicitation actions to:
-   - The entire section as a whole
-   - Individual items within the section (specify which item when selecting an action)
-
-### 3. Present Elicitation Options
-
-**Review Request Process:**
-
-- Ask the user to review the drafted section
-- In the SAME message, inform them they can suggest direct changes OR select an elicitation method
-- Present 9 intelligently selected methods (0-8) plus "Proceed" (9)
-- Keep descriptions short - just the method name
-- Await simple numeric selection
-
-**Action List Presentation Format:**
-
-```text
-**Advanced Elicitation Options**
-Choose a number (0-8) or 9 to proceed:
-
-0. [Method Name]
-1. [Method Name]
-2. [Method Name]
-3. [Method Name]
-4. [Method Name]
-5. [Method Name]
-6. [Method Name]
-7. [Method Name]
-8. [Method Name]
-9. Proceed / No Further Actions
-```
-
-**Response Handling:**
-
-- **Numbers 0-8**: Execute the selected method, then re-offer the choice
-- **Number 9**: Proceed to next section or continue conversation
-- **Direct Feedback**: Apply user's suggested changes and continue
-
-### 4. Method Execution Framework
-
-**Execution Process:**
-
-1. **Retrieve Method**: Access the specific elicitation method from the elicitation-methods data file
-2. **Apply Context**: Execute the method from your current role's perspective
-3. **Provide Results**: Deliver insights, critiques, or alternatives relevant to the content
-4. **Re-offer Choice**: Present the same 9 options again until user selects 9 or gives direct feedback
-
-**Execution Guidelines:**
-
-- **Be Concise**: Focus on actionable insights, not lengthy explanations
-- **Stay Relevant**: Tie all elicitation back to the specific content being analyzed
-- **Identify Personas**: For multi-persona methods, clearly identify which viewpoint is speaking
-- **Maintain Flow**: Keep the process moving efficiently

package/.claude/commands/TechieFlow/tasks/author-brd.md

@@ -1,79 +0,0 @@
-# author-brd
-
-Author or extend a Business Requirements Document (BRD) with stable BRD-N requirement IDs, using interactive elicitation. The analyst NEVER assumes a requirement — each candidate is confirmed by the user before it lands in the BRD.
-
-> **When to use:** this is the INTERACTIVE alternative for extending an existing BRD requirement-by-requirement. For creating a project's BRD, the default path is `*day1-brownfield` / `*day1-greenfield` (bulk draft, no per-item confirmation).
-
-## Purpose
-
-Produce a BRD where every business/functional requirement has a unique, stable, append-only ID (`BRD-1`, `BRD-2`, …) that downstream agents (UI agent, orchestrator, verifier) can declare and verify against. Eliminate the "implicit requirement" problem by forcing per-item user confirmation.
-
-## elicit
-
-elicit=true — this task REQUIRES user interaction. Never skip elicitation for efficiency.
-
-## Inputs
-
-- `{AppName}` argument (required for the canonical filename; ask once if missing).
-- `{topic}` argument (optional) — the product/feature area. If absent, ask once: "What's the topic / product area for this BRD?"
-- Existing BRD path. Resolve in this order: `core-config.yaml → customTechnicalDocuments`, then `docs/{AppName}-BRD.md` (legacy fallbacks: `docs/brd.md`, `docs/BRD.md`). If found, OPEN it and continue from the highest existing BRD-N. If not found, create `docs/{AppName}-BRD.md` from `.tfcore/templates/v4custom/app-brd-tmpl.md` (feature catalog + §10 BRD-N ledger shape — NOT ad-hoc "Phase N" sections).
-
-## SEQUENTIAL Execution
-
-### 1. Read or scaffold the BRD
-
-- If the resolved BRD exists: read it, parse all existing `BRD-{N}` IDs, and record the highest N. New requirements continue from N+1.
-- If absent: scaffold `docs/{AppName}-BRD.md` from `.tfcore/templates/v4custom/app-brd-tmpl.md` (leave unconfirmed sections empty; confirmed requirements land in the §10 ledger).
-- Ask the user which areas they want to scope today.
-
-### 2. Drive elicitation per area, one at a time
-
-For each area the user wants to cover (UI, data, workflow, NFRs, etc.):
-
-1. Generate a numbered list of CANDIDATE requirements for that area — 3 to 7 items, written as one-line "user can X" / "system shall Y" statements. Do NOT assign BRD-N IDs yet.
-2. Present the list and ask the user to (a) accept, (b) reject, (c) refine, or (d) add their own — one item at a time. Use this exact prompt format:
-   ```
-   Candidate requirements for {area}:
-   1. {candidate}
-   2. {candidate}
-   ...
-   For each, reply: keep / drop / refine: <new text>. Or add a new one with: add: <text>.
-   ```
-3. After the user processes each item, assign the next BRD-N to every KEPT or REFINED item, in the order they were confirmed. Show the assignments back:
-   ```
-   Assigned:
-   - BRD-{N}: {final text}
-   - BRD-{N+1}: {final text}
-   ```
-4. Append the assigned requirements to the §10 Functional-requirements ledger of the resolved BRD file (and flesh out / create the owning feature-catalog entry).
-
-Repeat for each area until the user says they're done with this BRD pass.
-
-### 3. NFRs and acceptance criteria (optional pass)
-
-If the user wants NFRs (performance, accessibility, browser support, etc.) or acceptance criteria for any BRD-N, run the same elicitation pattern. NFRs get their own BRD-N IDs (do NOT use a separate `NFR-N` series — keep one ID space so the verifier can grade everything uniformly).
-
-### 4. Final output
-
-Append/refresh the footer block of the BRD:
-```
----
-Last updated: {YYYY-MM-DD}
-Highest BRD ID: BRD-{N}
-```
-
-Print a compact summary to the user:
-```
-BRD updated → docs/{AppName}-BRD.md
-Added: BRD-{a}..BRD-{b} ({count} requirements)
-Phases touched: {list}
-```
-
-HALT.
-
-## Hard rules
-
-- elicit=true — never batch-confirm; one item at a time.
-- BRD-N IDs are append-only — never renumber an existing ID even if the user removes a requirement later (mark it `~~BRD-N~~ (removed)` instead).
-- Requirements are written as observable outcomes, not implementation hints. The verifier needs to be able to test them.
-- The analyst writes the BRD; the analyst does NOT implement anything.

package/.claude/commands/TechieFlow/tasks/document-project.md

@@ -1,343 +0,0 @@
-# Document an Existing Project
-
-## Purpose
-
-Generate comprehensive documentation for existing projects optimized for AI development agents. This task creates structured reference materials that enable AI agents to understand project context, conventions, and patterns for effective contribution to any codebase.
-
-## Task Instructions
-
-### 1. Initial Project Analysis
-
-**CRITICAL:** First, check if a PRD or requirements document exists in context. If yes, use it to focus your documentation efforts on relevant areas only.
-
-**IF PRD EXISTS**:
-
-- Review the PRD to understand what enhancement/feature is planned
-- Identify which modules, services, or areas will be affected
-- Focus documentation ONLY on these relevant areas
-- Skip unrelated parts of the codebase to keep docs lean
-
-**IF NO PRD EXISTS**:
-Ask the user:
-
-"I notice you haven't provided a PRD or requirements document. To create more focused and useful documentation, I recommend one of these options:
-
-1. **Create a PRD first** - Would you like me to help create a brownfield PRD before documenting? This helps focus documentation on relevant areas.
-
-2. **Provide existing requirements** - Do you have a requirements document, epic, or feature description you can share?
-
-3. **Describe the focus** - Can you briefly describe what enhancement or feature you're planning? For example:
-   - 'Adding payment processing to the user service'
-   - 'Refactoring the authentication module'
-   - 'Integrating with a new third-party API'
-
-4. **Document everything** - Or should I proceed with comprehensive documentation of the entire codebase? (Note: This may create excessive documentation for large projects)
-
-Please let me know your preference, or I can proceed with full documentation if you prefer."
-
-Based on their response:
-
-- If they choose option 1-3: Use that context to focus documentation
-- If they choose option 4 or decline: Proceed with comprehensive analysis below
-
-Begin by conducting analysis of the existing project. Use available tools to:
-
-1. **Project Structure Discovery**: Examine the root directory structure, identify main folders, and understand the overall organization
-2. **Technology Stack Identification**: Look for package.json, requirements.txt, Cargo.toml, pom.xml, etc. to identify languages, frameworks, and dependencies
-3. **Build System Analysis**: Find build scripts, CI/CD configurations, and development commands
-4. **Existing Documentation Review**: Check for README files, docs folders, and any existing documentation
-5. **Code Pattern Analysis**: Sample key files to understand coding patterns, naming conventions, and architectural approaches
-
-Ask the user these elicitation questions to better understand their needs:
-
-- What is the primary purpose of this project?
-- Are there any specific areas of the codebase that are particularly complex or important for agents to understand?
-- What types of tasks do you expect AI agents to perform on this project? (e.g., bug fixes, feature additions, refactoring, testing)
-- Are there any existing documentation standards or formats you prefer?
-- What level of technical detail should the documentation target? (junior developers, senior developers, mixed team)
-- Is there a specific feature or enhancement you're planning? (This helps focus documentation)
-
-### 2. Deep Codebase Analysis
-
-CRITICAL: Before generating documentation, conduct extensive analysis of the existing codebase:
-
-1. **Explore Key Areas**:
-   - Entry points (main files, index files, app initializers)
-   - Configuration files and environment setup
-   - Package dependencies and versions
-   - Build and deployment configurations
-   - Test suites and coverage
-
-2. **Ask Clarifying Questions**:
-   - "I see you're using [technology X]. Are there any custom patterns or conventions I should document?"
-   - "What are the most critical/complex parts of this system that developers struggle with?"
-   - "Are there any undocumented 'tribal knowledge' areas I should capture?"
-   - "What technical debt or known issues should I document?"
-   - "Which parts of the codebase change most frequently?"
-
-3. **Map the Reality**:
-   - Identify ACTUAL patterns used (not theoretical best practices)
-   - Find where key business logic lives
-   - Locate integration points and external dependencies
-   - Document workarounds and technical debt
-   - Note areas that differ from standard patterns
-
-**IF PRD PROVIDED**: Also analyze what would need to change for the enhancement
-
-### 3. Core Documentation Generation
-
-[[LLM: Generate a comprehensive BROWNFIELD architecture document that reflects the ACTUAL state of the codebase.
-
-**CRITICAL**: This is NOT an aspirational architecture document. Document what EXISTS, including:
-
-- Technical debt and workarounds
-- Inconsistent patterns between different parts
-- Legacy code that can't be changed
-- Integration constraints
-- Performance bottlenecks
-
-**Document Structure**:
-
-# [Project Name] Brownfield Architecture Document
-
-## Introduction
-
-This document captures the CURRENT STATE of the [Project Name] codebase, including technical debt, workarounds, and real-world patterns. It serves as a reference for AI agents working on enhancements.
-
-### Document Scope
-
-[If PRD provided: "Focused on areas relevant to: {enhancement description}"]
-[If no PRD: "Comprehensive documentation of entire system"]
-
-### Change Log
-
-| Date   | Version | Description                 | Author    |
-| ------ | ------- | --------------------------- | --------- |
-| [Date] | 1.0     | Initial brownfield analysis | [Analyst] |
-
-## Quick Reference - Key Files and Entry Points
-
-### Critical Files for Understanding the System
-
-- **Main Entry**: `src/index.js` (or actual entry point)
-- **Configuration**: `config/app.config.js`, `.env.example`
-- **Core Business Logic**: `src/services/`, `src/domain/`
-- **API Definitions**: `src/routes/` or link to OpenAPI spec
-- **Database Models**: `src/models/` or link to schema files
-- **Key Algorithms**: [List specific files with complex logic]
-
-### If PRD Provided - Enhancement Impact Areas
-
-[Highlight which files/modules will be affected by the planned enhancement]
-
-## High Level Architecture
-
-### Technical Summary
-
-### Actual Tech Stack (from package.json/requirements.txt)
-
-| Category  | Technology | Version | Notes                      |
-| --------- | ---------- | ------- | -------------------------- |
-| Runtime   | Node.js    | 16.x    | [Any constraints]          |
-| Framework | Express    | 4.18.2  | [Custom middleware?]       |
-| Database  | PostgreSQL | 13      | [Connection pooling setup] |
-
-etc...
-
-### Repository Structure Reality Check
-
-- Type: [Monorepo/Polyrepo/Hybrid]
-- Package Manager: [npm/yarn/pnpm]
-- Notable: [Any unusual structure decisions]
-
-## Source Tree and Module Organization
-
-### Project Structure (Actual)
-
-```text
-project-root/
-├── src/
-│   ├── controllers/     # HTTP request handlers
-│   ├── services/        # Business logic (NOTE: inconsistent patterns between user and payment services)
-│   ├── models/          # Database models (Sequelize)
-│   ├── utils/           # Mixed bag - needs refactoring
-│   └── legacy/          # DO NOT MODIFY - old payment system still in use
-├── tests/               # Jest tests (60% coverage)
-├── scripts/             # Build and deployment scripts
-└── config/              # Environment configs
-```
-
-### Key Modules and Their Purpose
-
-- **User Management**: `src/services/userService.js` - Handles all user operations
-- **Authentication**: `src/middleware/auth.js` - JWT-based, custom implementation
-- **Payment Processing**: `src/legacy/payment.js` - CRITICAL: Do not refactor, tightly coupled
-- **[List other key modules with their actual files]**
-
-## Data Models and APIs
-
-### Data Models
-
-Instead of duplicating, reference actual model files:
-
-- **User Model**: See `src/models/User.js`
-- **Order Model**: See `src/models/Order.js`
-- **Related Types**: TypeScript definitions in `src/types/`
-
-### API Specifications
-
-- **OpenAPI Spec**: `docs/api/openapi.yaml` (if exists)
-- **Postman Collection**: `docs/api/postman-collection.json`
-- **Manual Endpoints**: [List any undocumented endpoints discovered]
-
-## Technical Debt and Known Issues
-
-### Critical Technical Debt
-
-1. **Payment Service**: Legacy code in `src/legacy/payment.js` - tightly coupled, no tests
-2. **User Service**: Different pattern than other services, uses callbacks instead of promises
-3. **Database Migrations**: Manually tracked, no proper migration tool
-4. **[Other significant debt]**
-
-### Workarounds and Gotchas
-
-- **Environment Variables**: Must set `NODE_ENV=production` even for staging (historical reason)
-- **Database Connections**: Connection pool hardcoded to 10, changing breaks payment service
-- **[Other workarounds developers need to know]**
-
-## Integration Points and External Dependencies
-
-### External Services
-
-| Service  | Purpose  | Integration Type | Key Files                      |
-| -------- | -------- | ---------------- | ------------------------------ |
-| Stripe   | Payments | REST API         | `src/integrations/stripe/`     |
-| SendGrid | Emails   | SDK              | `src/services/emailService.js` |
-
-etc...
-
-### Internal Integration Points
-
-- **Frontend Communication**: REST API on port 3000, expects specific headers
-- **Background Jobs**: Redis queue, see `src/workers/`
-- **[Other integrations]**
-
-## Development and Deployment
-
-### Local Development Setup
-
-1. Actual steps that work (not ideal steps)
-2. Known issues with setup
-3. Required environment variables (see `.env.example`)
-
-### Build and Deployment Process
-
-- **Build Command**: `npm run build` (webpack config in `webpack.config.js`)
-- **Deployment**: Manual deployment via `scripts/deploy.sh`
-- **Environments**: Dev, Staging, Prod (see `config/environments/`)
-
-## Testing Reality
-
-### Current Test Coverage
-
-- Unit Tests: 60% coverage (Jest)
-- Integration Tests: Minimal, in `tests/integration/`
-- E2E Tests: None
-- Manual Testing: Primary QA method
-
-### Running Tests
-
-```bash
-npm test           # Runs unit tests
-npm run test:integration  # Runs integration tests (requires local DB)
-```
-
-## If Enhancement PRD Provided - Impact Analysis
-
-### Files That Will Need Modification
-
-Based on the enhancement requirements, these files will be affected:
-
-- `src/services/userService.js` - Add new user fields
-- `src/models/User.js` - Update schema
-- `src/routes/userRoutes.js` - New endpoints
-- [etc...]
-
-### New Files/Modules Needed
-
-- `src/services/newFeatureService.js` - New business logic
-- `src/models/NewFeature.js` - New data model
-- [etc...]
-
-### Integration Considerations
-
-- Will need to integrate with existing auth middleware
-- Must follow existing response format in `src/utils/responseFormatter.js`
-- [Other integration points]
-
-## Appendix - Useful Commands and Scripts
-
-### Frequently Used Commands
-
-```bash
-npm run dev         # Start development server
-npm run build       # Production build
-npm run migrate     # Run database migrations
-npm run seed        # Seed test data
-```
-
-### Debugging and Troubleshooting
-
-- **Logs**: Check `logs/app.log` for application logs
-- **Debug Mode**: Set `DEBUG=app:*` for verbose logging
-- **Common Issues**: See `docs/troubleshooting.md`]]
-
-### 4. Document Delivery
-
-1. **In Web UI (Gemini, ChatGPT, Claude)**:
-   - Present the entire document in one response (or multiple if too long)
-   - Tell user to copy and save as `docs/brownfield-architecture.md` or `docs/project-architecture.md`
-   - Mention it can be sharded later in IDE if needed
-
-2. **In IDE Environment**:
-   - Create the document as `docs/brownfield-architecture.md`
-   - Inform user this single document contains all architectural information
-   - Can be sharded later using PO agent if desired
-
-The document should be comprehensive enough that future agents can understand:
-
-- The actual state of the system (not idealized)
-- Where to find key files and logic
-- What technical debt exists
-- What constraints must be respected
-- If PRD provided: What needs to change for the enhancement]]
-
-### 5. Quality Assurance
-
-CRITICAL: Before finalizing the document:
-
-1. **Accuracy Check**: Verify all technical details match the actual codebase
-2. **Completeness Review**: Ensure all major system components are documented
-3. **Focus Validation**: If user provided scope, verify relevant areas are emphasized
-4. **Clarity Assessment**: Check that explanations are clear for AI agents
-5. **Navigation**: Ensure document has clear section structure for easy reference
-
-Apply the advanced elicitation task after major sections to refine based on user feedback.
-
-## Success Criteria
-
-- Single comprehensive brownfield architecture document created
-- Document reflects REALITY including technical debt and workarounds
-- Key files and modules are referenced with actual paths
-- Models/APIs reference source files rather than duplicating content
-- If PRD provided: Clear impact analysis showing what needs to change
-- Document enables AI agents to navigate and understand the actual codebase
-- Technical constraints and "gotchas" are clearly documented
-
-## Notes
-
-- This task creates ONE document that captures the TRUE state of the system
-- References actual files rather than duplicating content when possible
-- Documents technical debt, workarounds, and constraints honestly
-- For brownfield projects with PRD: Provides clear enhancement impact analysis
-- The goal is PRACTICAL documentation for AI agents doing real work

package/.claude/commands/TechieFlow/tasks/execute-checklist.md

@@ -1,86 +0,0 @@
-# Checklist Validation Task
-
-This task provides instructions for validating documentation against checklists. The agent MUST follow these instructions to ensure thorough and systematic validation of documents.
-
-## Available Checklists
-
-If the user asks or does not specify a specific checklist, list the checklists available to the agent persona. If the task is being run not with a specific agent, tell the user to check the .tfcore/checklists folder to select the appropriate one to run.
-
-## Instructions
-
-1. **Initial Assessment**
-   - If user or the task being run provides a checklist name:
-     - Try fuzzy matching (e.g. "architecture checklist" -> "architect-checklist")
-     - If multiple matches found, ask user to clarify
-     - Load the appropriate checklist from .tfcore/checklists/
-   - If no checklist specified:
-     - Ask the user which checklist they want to use
-     - Present the available options from the files in the checklists folder
-   - Confirm if they want to work through the checklist:
-     - Section by section (interactive mode - very time consuming)
-     - All at once (YOLO mode - recommended for checklists, there will be a summary of sections at the end to discuss)
-
-2. **Document and Artifact Gathering**
-   - Each checklist will specify its required documents/artifacts at the beginning
-   - Follow the checklist's specific instructions for what to gather, generally a file can be resolved in the docs folder, if not or unsure, halt and ask or confirm with the user.
-
-3. **Checklist Processing**
-
-   If in interactive mode:
-   - Work through each section of the checklist one at a time
-   - For each section:
-     - Review all items in the section following instructions for that section embedded in the checklist
-     - Check each item against the relevant documentation or artifacts as appropriate
-     - Present summary of findings for that section, highlighting warnings, errors and non applicable items (rationale for non-applicability).
-     - Get user confirmation before proceeding to next section or if any thing major do we need to halt and take corrective action
-
-   If in YOLO mode:
-   - Process all sections at once
-   - Create a comprehensive report of all findings
-   - Present the complete analysis to the user
-
-4. **Validation Approach**
-
-   For each checklist item:
-   - Read and understand the requirement
-   - Look for evidence in the documentation that satisfies the requirement
-   - Consider both explicit mentions and implicit coverage
-   - Aside from this, follow all checklist llm instructions
-   - Mark items as:
-     - ✅ PASS: Requirement clearly met
-     - ❌ FAIL: Requirement not met or insufficient coverage
-     - ⚠️ PARTIAL: Some aspects covered but needs improvement
-     - N/A: Not applicable to this case
-
-5. **Section Analysis**
-
-   For each section:
-   - think step by step to calculate pass rate
-   - Identify common themes in failed items
-   - Provide specific recommendations for improvement
-   - In interactive mode, discuss findings with user
-   - Document any user decisions or explanations
-
-6. **Final Report**
-
-   Prepare a summary that includes:
-   - Overall checklist completion status
-   - Pass rates by section
-   - List of failed items with context
-   - Specific recommendations for improvement
-   - Any sections or items marked as N/A with justification
-
-## Checklist Execution Methodology
-
-Each checklist now contains embedded LLM prompts and instructions that will:
-
-1. **Guide thorough thinking** - Prompts ensure deep analysis of each section
-2. **Request specific artifacts** - Clear instructions on what documents/access is needed
-3. **Provide contextual guidance** - Section-specific prompts for better validation
-4. **Generate comprehensive reports** - Final summary with detailed findings
-
-The LLM will:
-
-- Execute the complete checklist validation
-- Present a final report with pass/fail rates and key findings
-- Offer to provide detailed analysis of any section, especially those with warnings or failures