5-phase-workflow 1.8.6 → 1.8.8

package/src/skills/configure-project/SKILL.md

@@ -1,465 +0,0 @@
----
-name: configure-project
-description: Analyzes codebase for CLAUDE.md and generates project-specific skills. Used during /5:implement-feature CONFIGURE.
-allowed-tools: Read, Write, Bash, Glob, Grep
-model: sonnet
-context: fork
-user-invocable: false
----
-
-# Configure Project Skill
-
-## Overview
-
-This skill does the heavy lifting during Phase 3 (implement-feature) for the CONFIGURE feature. It is called by step-executor to create the actual configuration files.
-
-It handles two distinct tasks, invoked with different parameters per component:
-
-- **A. Analyze Codebase and Create/Update CLAUDE.md** - Maps codebase and documents conventions
-- **B. Generate Project-Specific Skills** - Creates SKILL.md files for common project patterns
-
-Note: config.json is written directly by `/5:configure` during the Q&A phase.
-
----
-
-## Modes
-
-This skill supports two modes. The analysis (A1), template filling (A2-A3), CLAUDE.md update (A4-A5), and skill generation (B) logic is the same in both modes — only the **input source** changes.
-
-### Full Mode (default)
-
-Used by `/5:configure` → `/5:implement-feature CONFIGURE` flow.
-
-- **Input:** Pattern/command selections from feature spec (`.5/features/CONFIGURE/feature.md`)
-- **Behavior:** Creates everything from scratch based on feature spec requirements
-
-### Refresh Mode
-
-Used by `/5:reconfigure` for lightweight refresh.
-
-- **Input:** The Task prompt lists which skills to refresh, create, and remove (determined by `/5:reconfigure` after scanning `.claude/skills/` and comparing with detected codebase patterns)
-- **Behavior:** Re-analyzes codebase, overwrites docs and refreshes/creates/removes skills as specified
-- **Trigger:** Task prompt includes "REFRESH MODE"
-
-In both modes, the analysis and generation logic is identical — only where the skill list comes from differs.
-
----
-
-## A. Analyze Codebase and Create/Update CLAUDE.md
-
-**Process:**
-
-### A1. Unified Codebase Analysis
-
-Perform comprehensive analysis once to gather data for ALL templates:
-
-**Structure Analysis** (for STRUCTURE.md):
-- Use Glob to map directory tree: `**/*` (with depth limits to avoid overwhelming results)
-- Identify source directories (`src/`, `lib/`, `app/`, etc.)
-- Identify test directories and their organization
-- Identify configuration directories
-- Determine file naming conventions (camelCase, kebab-case, PascalCase)
-- Locate key files (entry points, configurations)
-
-**Stack Analysis** (for STACK.md):
-- Read package manifests: `package.json`, `Cargo.toml`, `go.mod`, `pom.xml`, `requirements.txt`, `Gemfile`
-- Extract: language, version, runtime, package manager
-- Identify frameworks in dependencies (React, Express, Django, Rails, etc.)
-- List critical dependencies and their versions
-- Find config files: `tsconfig.json`, `.eslintrc`, etc.
-
-**Architecture Analysis** (for ARCHITECTURE.md):
-- Identify architectural pattern (MVC, layered, modular, microservices) from directory structure
-- Map layers by directory structure (controllers/, services/, models/, routes/, etc.)
-- Trace data flow patterns (read 2-3 example files from different layers)
-- Identify key abstractions (interfaces, base classes, common patterns)
-- Find entry points (`index.ts`, `main.go`, `app.py`, `server.js`)
-- Analyze error handling strategy (try/catch, Result types, middleware, error boundaries)
-
-**Conventions Analysis** (for CONVENTIONS.md):
-- Sample 5-10 files from main source directory
-- Extract naming patterns: files, functions, variables, types/classes
-- Find formatters/linters: `.prettierrc`, `.eslintrc`, `black.toml`, `.rubocop.yml`
-- Identify import organization patterns (order, grouping, aliases)
-- Determine logging approach (console, winston, log4j, etc.)
-- Check comment/documentation patterns (JSDoc, Javadoc, etc.)
-
-**Testing Analysis** (for TESTING.md):
-- Find test files: `**/*.test.{ts,js}`, `**/*.spec.{ts,js}`, `**/*_test.go`, `test_*.py`, `*_spec.rb`
-- Read test config: `jest.config.js`, `vitest.config.ts`, `pytest.ini`, `spec/spec_helper.rb`
-- Determine test organization (co-located vs separate `test/` or `spec/`)
-- Extract test naming patterns
-- Identify mocking framework (jest.mock, sinon, pytest-mock, etc.)
-- Find fixture/factory patterns
-- Extract test run commands from package.json, Makefile, or similar
-
-**Integration Analysis** (for INTEGRATIONS.md):
-- Scan dependencies for SDK packages (axios, @aws-sdk, stripe, @google-cloud, etc.)
-- Identify database clients/ORMs (prisma, mongoose, sqlalchemy, activerecord, etc.)
-- Find auth providers (passport, next-auth, devise, etc.)
-- Detect monitoring/logging services (datadog, sentry, newrelic)
-- Read CI/CD config: `.github/workflows/`, `.gitlab-ci.yml`, `.circleci/config.yml`
-- Grep for environment variables: `process.env`, `os.getenv`, `ENV[`, etc.
-
-**Concerns Analysis** (for CONCERNS.md):
-- Grep for TODO/FIXME/HACK/XXX/DEPRECATED comments across all code
-- Check for common security issues (SQL injection patterns, XSS vulnerabilities)
-- Identify deprecated dependencies (check for warnings in package manifests)
-- Look for complex code sections (deeply nested conditionals, long functions)
-
-### A2. Fill Templates
-
-For each template in `src/templates/`:
-
-1. Read template content with Read tool
-2. Replace placeholders with analyzed data:
-   - Date placeholders: `{YYYY-MM-DD}`, `{date}` → current date (format: YYYY-MM-DD)
-   - Template-specific placeholders → actual project data from B1 analysis
-3. Handle missing data gracefully: mark sections as "Not detected" or "None found" rather than omitting
-
-**Placeholder mapping examples**:
-
-ARCHITECTURE.md:
-- `{Pattern name}` → "Layered Architecture" or "MVC" or "Modular Monolith"
-- `{Layer Name}` → "Controllers", "Services", "Repositories"
-- `{path}` → "src/controllers/", "src/services/"
-
-STACK.md:
-- `{Language} {Version}` → "TypeScript 5.3.3", "Python 3.11"
-- `{Framework} {Version}` → "Express 4.18.2", "Django 4.2"
-- `{Package} {Version}` → "axios 1.6.0"
-
-CONVENTIONS.md:
-- `{Pattern observed}` → "PascalCase for classes, camelCase for functions"
-- `{Tool used}` → "Prettier with 2-space indent"
-
-TESTING.md:
-- `{Framework} {Version}` → "Jest 29.5.0"
-- `{command}` → "npm test", "pytest"
-
-INTEGRATIONS.md:
-- `{Service}` → "PostgreSQL", "Stripe API"
-- `{package}` → "@stripe/stripe-js"
-
-CONCERNS.md:
-- `{file paths}` → Actual file paths from grep results
-
-### A3. Write Documentation Files
-
-Write filled templates to `.5/` folder:
-
-1. Ensure `.5/` directory exists: `mkdir -p .5`
-2. Write each filled template:
-   - `.5/ARCHITECTURE.md`
-   - `.5/STACK.md`
-   - `.5/STRUCTURE.md`
-   - `.5/CONVENTIONS.md`
-   - `.5/TESTING.md`
-   - `.5/INTEGRATIONS.md`
-   - `.5/CONCERNS.md`
-
-### A4. Create Master CLAUDE.md
-
-Generate CLAUDE.md as a navigation hub:
-
-CLAUDE.md structure:
-- **Quick Reference:** Links to all 7 `.5/*.md` files (STACK, STRUCTURE, ARCHITECTURE, CONVENTIONS, TESTING, INTEGRATIONS, CONCERNS)
-- **Project Overview:** 1-2 paragraphs from README/package.json
-- **Build & Run Commands:** Build, test, and other detected commands
-- **Workflow Rules:** Include this section verbatim:
-  ```
-  ## Workflow Rules
-  When running `/5:` workflow commands, follow the command instructions exactly as written.
-  Do not skip steps, combine phases, or proceed to actions not specified in the current command.
-  Each phase produces a specific artifact — do not create artifacts belonging to other phases.
-  ```
-- **Coding Guidelines:** The 6 mandatory principles (types, concise docs, short files, extract methods, SRP/DRY, maintainable/modular)
-- **Getting Started:** Links to relevant `.5/` files for new devs and specific tasks
-
-### A5. Preserve Existing Content
-
-If CLAUDE.md already exists:
-- Read current content
-- Identify user-written custom sections (not matching template structure)
-- Preserve under "Custom Documentation" section in new CLAUDE.md
-- Ensure 6 mandatory coding guidelines are retained
-
----
-
-## B. Generate Project-Specific Skills
-
-### Using skill-creator plugin
-
-If `tools.skillCreator.available` is `true` in `.5/config.json`, use the skill-creator plugin's tools (e.g., `create-skill`, `scaffold-skill`) to generate each SKILL.md instead of the template-based approach below. Pass the extracted patterns, conventions, and example file paths as context to the skill-creator tool so it can produce structured, high-quality skill files.
-
-If skill-creator is not available, use the existing template-based generation below — no degradation in workflow behavior.
-
-**Reads:** Pattern selections from feature spec (`.5/CONFIGURE/feature.md`)
-
-**Creates:** SKILL.md files in `.claude/skills/{name}/SKILL.md`
-
-### Pattern-Based Skill Generation
-
-Skills are determined by what patterns exist in the codebase (detected during `/5:configure`) and what the user selected—NOT by project type.
-
-For EACH pattern selected by the user in the feature spec:
-
-1. **Find examples** - Read 2-3 files from the pattern's location
-2. **Extract conventions:**
-   - File naming (PascalCase, kebab-case, suffix patterns)
-   - Directory structure (flat, nested, co-located tests)
-   - Import patterns (absolute, relative, aliases)
-   - Export patterns (default, named, barrel files)
-   - Common boilerplate (decorators, annotations, base classes)
-3. **Generate SKILL.md** with:
-   - Detected conventions as instructions
-   - Template derived from actual code
-   - Checklist based on common elements found
-
-### Skill Template Structure
-
-For each skill, create `.claude/skills/create-{pattern}/SKILL.md`:
-
-```yaml
----
-name: create-{pattern}
-description: Creates a {Pattern} following project conventions at {location}.
-allowed-tools: Read, Write, Glob, Grep
-model: haiku
-context: fork
-user-invocable: true
----
-```
-
-```markdown
-# Create {Pattern}
-
-## What This Skill Creates
-A {pattern} following this project's conventions.
-
-## Detected Conventions
-- **Location:** {detected-location}
-- **Naming:** {detected-naming-pattern}
-- **Structure:** {detected-structure}
-- **Imports:** {detected-import-pattern}
-
-## Template
-Based on {example-file}, new {patterns} should follow:
-
-\`\`\`{language}
-{template-derived-from-analysis}
-\`\`\`
-
-## Checklist
-- [ ] File created at correct location
-- [ ] Naming convention followed
-- [ ] Required imports added
-- [ ] {pattern-specific-items}
-```
-
-### Pattern to Skill Name Mapping
-
-**Rule:** Skill name is `create-{pattern}` (e.g., `controller` → `create-controller`, `component` → `create-component`, `dto` → `create-dto`). For compound patterns, use the short form: `model/entity` → `create-model`, `api-route` → `create-api-route`.
-
----
-
-## B2. Generate Command Skills (run-*)
-
-**Reads:** Command selections from feature spec (`.5/CONFIGURE/feature.md`)
-
-**Creates:** SKILL.md files in `.claude/skills/run-{command}/SKILL.md`
-
-### Command-Based Skill Generation
-
-For EACH command selected by the user in the feature spec:
-
-1. **Read the source** - Check package.json scripts, Makefile, etc.
-2. **Document the command:**
-   - Exact command syntax
-   - Available variants (e.g., test:unit, test:e2e)
-   - Common flags and options
-   - Expected output format
-3. **Generate SKILL.md** with:
-   - Command execution instructions
-   - Output parsing guidance
-   - Error handling patterns
-
-### Command Skill Template Structure
-
-For each skill, create `.claude/skills/run-{command}/SKILL.md`:
-
-```yaml
----
-name: run-{command}
-description: Runs {command} for this project using {source}.
-allowed-tools: Bash
-model: haiku
-context: fork
-user-invocable: true
----
-```
-
-```markdown
-# Run {Command}
-
-## What This Skill Does
-Executes the project's {command} command.
-
-## Command
-\`\`\`bash
-{exact-command}
-\`\`\`
-
-## Variants
-{if variants exist}
-- `{variant1}` - {description}
-- `{variant2}` - {description}
-
-## Common Options
-- `--watch` - Run in watch mode (if available)
-- `--coverage` - Generate coverage report (for tests)
-- `--fix` - Auto-fix issues (for lint/format)
-
-## Expected Output
-{describe what success/failure looks like}
-
-## Error Handling
-- If command fails, report the error output
-- Common issues: {list common problems and solutions}
-```
-
-### Command to Skill Name Mapping
-
-**Rule:** Skill name is `run-{category}` (e.g., `build` → `run-build`, `test`/`spec` → `run-tests`, `lint` → `run-lint`). Group variants under the primary category name.
-
----
-
-## C. Generate Scoped Rules
-
-If `rules.generate` is `true` in `.5/config.json`, generate `.claude/rules/` files with project-specific conventions scoped to relevant file types.
-
-Rules are **concise directives** (15-40 lines each), NOT documentation. Documentation lives in `.5/*.md` files. Rules tell Claude what to do when working with specific file types.
-
-### C1. Determine Which Rules to Generate
-
-Based on the A1 analysis results, determine which rules apply:
-
-| Rule File | Generate When | Source Analysis |
-|-----------|---------------|-----------------|
-| `code-style.md` | Always (if source files exist) | Conventions Analysis |
-| `testing.md` | Test files detected | Testing Analysis |
-| `api-patterns.md` | Controller/route/handler patterns detected | Architecture Analysis |
-| `dependencies.md` | External integrations detected | Integration Analysis |
-
-**Skip** any rule whose prerequisite patterns were not detected. Do NOT generate empty or placeholder rule files.
-
-### C2. Extract Directives and Write Rules
-
-For each applicable rule:
-
-1. **Derive `paths:` globs** from detected file locations (e.g., if tests are at `src/**/*.test.ts` and `tests/**/*.spec.ts`, use those patterns)
-2. **Convert analysis observations into imperative directives** — "Use X", "Always Y", "Never Z"
-3. **Keep each file 15-40 lines** — be concise and actionable
-4. **Do NOT repeat** the 6 mandatory coding guidelines from CLAUDE.md
-
-Write files to `.claude/rules/`:
-
-```bash
-mkdir -p .claude/rules
-```
-
-### C3. Rule File Format
-
-Each rule file uses YAML frontmatter with `paths:` for scoping. Rules without `paths:` load unconditionally.
-
-**Example — `testing.md`:**
-
-```markdown
----
-paths:
-  - "**/*.test.ts"
-  - "**/*.spec.ts"
----
-
-# Testing Conventions
-
-- Use `describe`/`it` blocks with descriptive names
-- Mock external dependencies with jest.mock, never mock internal modules
-- Use factory functions from `tests/factories/` for test data
-- Each test file mirrors its source file path: `src/foo/Bar.ts` → `src/foo/__tests__/Bar.test.ts`
-- Assert one behavior per test
-```
-
-**Example — `code-style.md`:**
-
-```markdown
----
-paths:
-  - "src/**/*.{ts,tsx}"
----
-
-# Code Style
-
-- Use PascalCase for classes and types, camelCase for functions and variables
-- Import order: external packages → internal modules → relative imports
-- Use absolute imports with `@/` alias
-- Prefer named exports over default exports
-```
-
-**Example — `dependencies.md` (unconditional):**
-
-```markdown
-# Dependency Conventions
-
-- Database access through Prisma client only, never raw SQL
-- HTTP requests use axios instance from `src/lib/http.ts`
-- Environment variables accessed via `src/config/env.ts`, never `process.env` directly
-```
-
-### Refresh Mode Behavior for Rules
-
-When running in REFRESH MODE:
-- Re-analyze codebase and overwrite all existing rule files with updated directives
-- Remove rule files for patterns no longer detected in the codebase
-- Create new rule files if new patterns are detected that weren't present before
-
----
-
-## Output Contract
-
-Returns structured results for each component:
-
-```
-Component A (Documentation): SUCCESS - Created 7 documentation files + index
-  - .5/ARCHITECTURE.md (Pattern: Layered, 4 layers identified)
-  - .5/STACK.md (TypeScript + Express, 23 dependencies)
-  - .5/STRUCTURE.md (8 top-level directories mapped)
-  - .5/CONVENTIONS.md (PascalCase/camelCase, Prettier formatting)
-  - .5/TESTING.md (Jest framework, 45 test files)
-  - .5/INTEGRATIONS.md (PostgreSQL, 2 APIs, GitHub Actions)
-  - .5/CONCERNS.md (3 TODO items, 1 deprecated dependency)
-  - CLAUDE.md (index with references)
-Component B (Pattern Skills): SUCCESS - Generated 3 create-* skills (create-component, create-hook, create-context)
-Component C (Command Skills): SUCCESS - Generated 2 run-* skills (run-tests, run-lint)
-Component D (Rules): SUCCESS - Generated 3 rule files (code-style, testing, dependencies)
-```
-
-Or on failure:
-
-```
-Component A (Documentation): FAILED - Unable to read template files
-Component B (Pattern Skills): FAILED - No patterns found in codebase
-Component D (Rules): SKIPPED - rules.generate is false in config
-```
-
-## DO NOT
-
-- DO NOT overwrite existing user-written CLAUDE.md sections
-- DO NOT generate skills for patterns that don't exist in the project
-- DO NOT generate command skills for commands that don't exist in the project
-- DO NOT generate rules for patterns not detected in the codebase
-- DO NOT include `steps` in config.json
-- DO NOT hardcode conventions - always derive from actual project analysis
-- DO NOT generate empty or placeholder skill or rule files
-- DO NOT assume command syntax - always read from actual config files (package.json, Makefile, etc.)
-- DO NOT repeat the 6 mandatory coding guidelines from CLAUDE.md in rule files

package/src/skills/run-tests/SKILL.md

@@ -1,162 +0,0 @@
----
-name: run-tests
-description: Executes tests using auto-detected or configured test runner. Supports jest, pytest, cargo test, go test, gradle, maven, and more. Use when running tests, verifying test results, or checking test status.
-allowed-tools: Bash, Read, Grep
-model: sonnet
-context: fork
-user-invocable: true
----
-
-# Run Tests
-
-## Overview
-
-This skill executes test tasks with auto-detection of the test runner and sufficient timeout for long-running test suites. It provides structured test result reporting and actionable suggestions when tests fail.
-
-## Test Runner Detection
-
-The skill automatically detects the test runner using:
-
-1. **Config file** (`.5/config.json`) - if `build.testCommand` is specified
-2. **Auto-detection** - by examining project files and package.json scripts:
-   - `package.json` with jest/vitest/mocha → npm test
-   - `pytest.ini` or test files → pytest
-   - `Cargo.toml` → cargo test
-   - `go.mod` → go test
-   - `build.gradle` → gradle test
-   - `pom.xml` → mvn test
-
-## Test Targets
-
-| Target | Use Case |
-|--------|----------|
-| `all` | Run all tests in all modules |
-| `module` | Run all tests in a specific module |
-| `file` | Run tests in a specific file |
-| `test` | Run a specific test by name |
-
-## Parameters
-
-When invoked, the skill expects:
-
-- **target** (optional, default: `all`): One of `all`, `module`, `file`, `test`
-- **module** (optional): Module name (for monorepos)
-- **file** (optional): Test file path (for `file` target)
-- **test** (optional): Specific test name (for `test` target)
-- **pattern** (optional): Test name pattern/filter
-
-## Execution Process
-
-### 1. Load Configuration
-
-Read `.5/config.json` if it exists:
-
-```json
-{
-  "build": {
-    "testCommand": "npm test",
-    "testFileCommand": "npm test -- {{file}}",
-    "testNameCommand": "npm test -- -t {{name}}"
-  }
-}
-```
-
-If commands are specified, use them with variable substitution. Otherwise, auto-detect.
-
-### 2. Detect Test Runner
-
-If no config, detect by checking project files: `package.json` (jest/vitest/mocha), `pytest.ini`/test files (pytest), `Cargo.toml` (cargo), `go.mod` (go), `build.gradle` (gradle), `pom.xml` (mvn).
-
-### 3. Determine Test Command
-
-Based on detected runner and target:
-
-| Runner | all | module | file | test |
-|--------|-----|--------|------|------|
-| npm | `npm test` | `npm test -- {module}` | `npm test -- {file}` | `npm test -- -t "{name}"` |
-| jest | `jest` | `jest {module}` | `jest {file}` | `jest -t "{name}"` |
-| vitest | `vitest run` | `vitest run {module}` | `vitest run {file}` | `vitest run -t "{name}"` |
-| pytest | `pytest` | `pytest {module}` | `pytest {file}` | `pytest -k "{name}"` |
-| cargo | `cargo test` | `cargo test -p {module}` | N/A | `cargo test {name}` |
-| go | `go test ./...` | `go test ./{module}/...` | `go test {file}` | `go test -run {name}` |
-| gradle | `./gradlew test --offline` | `./gradlew :{module}:test --offline` | N/A | `./gradlew test --tests {name} --offline` |
-| mvn | `mvn test` | `mvn test -pl {module}` | `mvn test -Dtest={ClassName}` | `mvn test -Dtest={ClassName}#{method}` |
-
-### 4. Execute Tests with Proper Timeout
-
-**IMPORTANT**: Test suites can take several minutes. Use generous timeout:
-
-```bash
-# Timeout based on target:
-# - single test: 1 minute (60000ms)
-# - file: 5 minutes (300000ms)
-# - module: 10 minutes (600000ms)
-# - all: 15 minutes (900000ms)
-```
-
-Execute the command and capture output.
-
-### 5. Parse Test Output
-
-Parse runner-specific output to extract: total tests, passed, failed, skipped, duration, and failed test names with error messages and file/line info.
-
-### 6. Format Output
-
-Provide structured response:
-
-```
-TEST STATUS: ✓ PASSED | ✗ FAILED | ⚠ PARTIAL
-DURATION: 1m 23s
-RUNNER: {detected-runner}
-TARGET: {target type}
-MODULE: {module or "all"}
-
-SUMMARY:
-- {N} tests total
-- {N} passed
-- {N} failed
-- {N} skipped
-
-FAILED TESTS: (if any)
-
-1. {TestSuite} › {test name}
-   File: path/to/file.test.ext:42
-   Error: {error message}
-
-2. {Another test}
-   File: path/to/another.test.ext:15
-   Error: {error message}
-
-SUGGESTIONS:
-- Review failed test assertions
-- Check test fixtures and mocks
-- Run specific failed tests individually to debug
-```
-
-## Error Handling
-
-- If test runner cannot be detected, return error with detection attempted
-- If command times out, report timeout with suggestion
-- Always include failed test details with file locations
-- If no tests found, report warning (not error)
-- Include suggestion to check test file patterns
-
-## DO NOT
-
-- DO NOT modify source or test files
-- DO NOT retry failed tests automatically (user decides)
-- DO NOT run build before tests (use `/build-project` first if needed)
-- DO NOT assume a specific test framework - always detect or use config
-- DO NOT truncate test output too aggressively (users need full error messages)
-
-## Example
-
-```
-User: /run-tests
-Skill: [Detects jest] → [Runs: jest] → [Reports: 47 passed, 0 failed]
-```
-
-## Related Documentation
-
-- [5-Phase Workflow Guide](../../docs/workflow-guide.md)
-- [/build-project skill](../build-project/SKILL.md)

package/src/templates/CONVENTIONS.md

@@ -1,75 +0,0 @@
-# Coding Conventions
-
-**Analysis Date:** {YYYY-MM-DD}
-
-## Naming Patterns
-
-**Files:**
-- {Pattern observed}
-
-**Functions:**
-- {Pattern observed}
-
-**Variables:**
-- {Pattern observed}
-
-**Types:**
-- {Pattern observed}
-
-## Code Style
-
-**Formatting:**
-- {Tool used}
-- {Key settings}
-
-**Linting:**
-- {Tool used}
-- {Key rules}
-
-## Import Organization
-
-**Order:**
-1. {First group}
-2. {Second group}
-3. {Third group}
-
-**Path Aliases:**
-- {Aliases used}
-
-## Error Handling
-
-**Patterns:**
-- {How errors are handled}
-
-## Logging
-
-**Framework:** {Tool or "console"}
-
-**Patterns:**
-- {When/how to log}
-
-## Comments
-
-**When to Comment:**
-- {Guidelines observed}
-
-**JSDoc/TSDoc:**
-- {Usage pattern}
-
-## Function Design
-
-**Size:** {Guidelines}
-
-**Parameters:** {Pattern}
-
-**Return Values:** {Pattern}
-
-## Module Design
-
-**Exports:** {Pattern}
-
-**Barrel Files:** {Usage}
-
----
-
-*Convention analysis: {date}*