owflow 0.6.0 → 0.7.0

package/dist/skills/standards-discover/references/aggregation-strategy.md

@@ -1,76 +1,76 @@
-# Aggregation Strategy — Confidence Scoring & Deduplication
-
-## Deduplication Rules
-
-Group findings by `category + standard_name`. When multiple findings match:
-
-1. **Merge evidence** — Combine all evidence items from all sources
-2. **Track sources** — Note which phases contributed (config, code, docs, external)
-3. **Take strongest description** — Prefer documented > config > code-inferred
-4. **Preserve examples** — Combine unique examples
-
-## Confidence Scoring
-
-Calculate final confidence using these factors:
-
-### Source Count (max 45 points)
-- Each unique source: +15 points (config, code-patterns, documentation, pr-reviews, ci-config, pre-commit)
-- Cap at 45 points (3+ sources)
-
-### Consistency (max 20 points)
-- >= 90% consistency across sampled files: +20
-- 70-89% consistency: +10
-- < 70% consistency: +0
-
-### Explicitness (max 15 points)
-- Found in config file (explicit rule): +15
-- Found in documentation (explicitly stated): +10
-- Inferred from code patterns only: +5
-
-### Evidence Strength (max 20 points)
-- Per evidence item: +5 points, cap at 20 (4+ evidence items)
-
-### PR Feedback Boost (max 10 points)
-- 5+ PR reviews mention this: +10
-- 3-4 PR reviews: +5
-
-**Final score**: Sum of factors, capped at 100.
-
-## Conflict Detection
-
-Flag conflicts when two findings for the same aspect give contradictory guidance:
-
-- Same tool, different settings (e.g., ESLint vs Prettier disagreeing on semicolons)
-- Documentation says one thing, config enforces another
-- Code patterns don't match documented standards
-
-Present each conflict to user with both sides and evidence.
-
-## Confidence Categories
-
-| Level | Range | Guidance |
-|-------|-------|----------|
-| High | >= 80% | Strong evidence, multiple sources. Safe to apply. |
-| Medium | 60-79% | Some evidence, may need clarification. Review recommended. |
-| Low | < 60% | Weak or inconsistent patterns. May indicate area needing standardization. |
-
-## Presentation Order
-
-1. High confidence findings (batch approval option)
-2. Medium confidence findings (individual review)
-3. Conflicts (resolution required)
-4. Low confidence findings (informational, skip option)
-
-## Presentation Format
-
-Before approval prompts, present a **full summary table** grouped by confidence level. Each finding row shows:
-
-- **Standard name** and **category**
-- **Confidence score** (numeric, 0-100)
-- **Sources** — all contributing sources listed (e.g., "config, code, docs"). This is key for user trust and decision-making.
-- **Brief description** (one line, truncated if needed)
-
-When drilling into individual findings (medium confidence, or user-requested drill-down), show:
-- Full description and examples (preferred/avoid patterns)
-- Evidence items with source attribution (which source provided each piece of evidence)
-- Confidence score breakdown: show points from each factor (source count, consistency, explicitness, evidence strength, PR boost) so user understands why the score is what it is
+# Aggregation Strategy — Confidence Scoring & Deduplication
+
+## Deduplication Rules
+
+Group findings by `category + standard_name`. When multiple findings match:
+
+1. **Merge evidence** — Combine all evidence items from all sources
+2. **Track sources** — Note which phases contributed (config, code, docs, external)
+3. **Take strongest description** — Prefer documented > config > code-inferred
+4. **Preserve examples** — Combine unique examples
+
+## Confidence Scoring
+
+Calculate final confidence using these factors:
+
+### Source Count (max 45 points)
+- Each unique source: +15 points (config, code-patterns, documentation, pr-reviews, ci-config, pre-commit)
+- Cap at 45 points (3+ sources)
+
+### Consistency (max 20 points)
+- >= 90% consistency across sampled files: +20
+- 70-89% consistency: +10
+- < 70% consistency: +0
+
+### Explicitness (max 15 points)
+- Found in config file (explicit rule): +15
+- Found in documentation (explicitly stated): +10
+- Inferred from code patterns only: +5
+
+### Evidence Strength (max 20 points)
+- Per evidence item: +5 points, cap at 20 (4+ evidence items)
+
+### PR Feedback Boost (max 10 points)
+- 5+ PR reviews mention this: +10
+- 3-4 PR reviews: +5
+
+**Final score**: Sum of factors, capped at 100.
+
+## Conflict Detection
+
+Flag conflicts when two findings for the same aspect give contradictory guidance:
+
+- Same tool, different settings (e.g., ESLint vs Prettier disagreeing on semicolons)
+- Documentation says one thing, config enforces another
+- Code patterns don't match documented standards
+
+Present each conflict to user with both sides and evidence.
+
+## Confidence Categories
+
+| Level | Range | Guidance |
+|-------|-------|----------|
+| High | >= 80% | Strong evidence, multiple sources. Safe to apply. |
+| Medium | 60-79% | Some evidence, may need clarification. Review recommended. |
+| Low | < 60% | Weak or inconsistent patterns. May indicate area needing standardization. |
+
+## Presentation Order
+
+1. High confidence findings (batch approval option)
+2. Medium confidence findings (individual review)
+3. Conflicts (resolution required)
+4. Low confidence findings (informational, skip option)
+
+## Presentation Format
+
+Before approval prompts, present a **full summary table** grouped by confidence level. Each finding row shows:
+
+- **Standard name** and **category**
+- **Confidence score** (numeric, 0-100)
+- **Sources** — all contributing sources listed (e.g., "config, code, docs"). This is key for user trust and decision-making.
+- **Brief description** (one line, truncated if needed)
+
+When drilling into individual findings (medium confidence, or user-requested drill-down), show:
+- Full description and examples (preferred/avoid patterns)
+- Evidence items with source attribution (which source provided each piece of evidence)
+- Confidence score breakdown: show points from each factor (source count, consistency, explicitness, evidence strength, PR boost) so user understands why the score is what it is

package/dist/skills/standards-discover/references/code-pattern-prompt.md

@@ -1,68 +1,68 @@
-# Code Pattern Analyzer — Subagent Prompt Template
-
-Analyze source code patterns to discover coding conventions and standards used in the project.
-
-## Task
-
-Sample code files, detect consistent patterns in naming/imports/structure, return findings as YAML.
-
-## Sampling Strategy
-
-For performance, sample rather than exhaustive analysis:
-
-- **Frontend files**: Sample up to 50 files (`*.ts`, `*.tsx`, `*.js`, `*.jsx`, `*.vue`, `*.svelte`)
-- **Backend files**: Sample up to 50 files (`*.py`, `*.rb`, `*.java`, `*.go`, `*.rs`)
-- **Test files**: Sample up to 30 files (`*.test.*`, `*.spec.*`, `*_test.*`)
-
-Use Glob to find files, then Read a representative sample from different directories.
-
-## Patterns to Detect
-
-1. **File Naming**: PascalCase, kebab-case, snake_case, camelCase — calculate consistency %
-2. **Import Patterns**: Absolute vs relative, path aliases (`@/`), import grouping/sorting
-3. **Error Handling**: try/catch usage, custom error classes, error wrapping, logging patterns
-4. **Component Structure** (frontend): Functional vs class components, hooks usage, props patterns
-5. **API Patterns** (backend): Endpoint naming, resource naming (plural/singular), versioning
-6. **Function Style**: Arrow functions vs declarations, async/await vs promises
-7. **Type Patterns**: TypeScript strictness, type vs interface usage, generics patterns
-
-## Consistency Threshold
-
-Only report patterns with **>= 60% consistency** across sampled files.
-
-Calculate: `(files following pattern / total files sampled) * 100`
-
-## Categorization
-
-Discover existing categories from `.owflow/docs/standards/*/`. Baseline categories: `global/`, `frontend/`, `backend/`, `testing/`. Propose new categories if patterns don't fit existing ones.
-
-## Confidence Range
-
-Code pattern findings: **60-88%** confidence. Higher when consistency is >= 90%.
-
-## Output Format
-
-Return YAML:
-
-```yaml
-findings:
-  - category: "[category/subcategory]"
-    standard_name: "[Short Name]"
-    description: "[What the convention is]"
-    confidence: [60-88]
-    evidence:
-      - "[X] of [Y] files follow this pattern"
-      - "Examples: [file1], [file2], [file3]"
-    source: "code-patterns"
-    examples:
-      - "[Correct pattern example]"
-```
-
-## Rules
-
-- Sample files randomly across directories for representative results
-- Report file counts in evidence (e.g., "247 of 250 .tsx files use PascalCase")
-- Only report patterns with >= 60% consistency
-- Return empty findings list if no clear patterns emerge
-- Focus on actionable, consistent patterns — not one-off occurrences
-- Do NOT write any files to the project directory. Write your YAML results to: `[output_file]` (the orchestrator replaces this placeholder with an actual temp file path when invoking you).
+# Code Pattern Analyzer — Subagent Prompt Template
+
+Analyze source code patterns to discover coding conventions and standards used in the project.
+
+## Task
+
+Sample code files, detect consistent patterns in naming/imports/structure, return findings as YAML.
+
+## Sampling Strategy
+
+For performance, sample rather than exhaustive analysis:
+
+- **Frontend files**: Sample up to 50 files (`*.ts`, `*.tsx`, `*.js`, `*.jsx`, `*.vue`, `*.svelte`)
+- **Backend files**: Sample up to 50 files (`*.py`, `*.rb`, `*.java`, `*.go`, `*.rs`)
+- **Test files**: Sample up to 30 files (`*.test.*`, `*.spec.*`, `*_test.*`)
+
+Use Glob to find files, then Read a representative sample from different directories.
+
+## Patterns to Detect
+
+1. **File Naming**: PascalCase, kebab-case, snake_case, camelCase — calculate consistency %
+2. **Import Patterns**: Absolute vs relative, path aliases (`@/`), import grouping/sorting
+3. **Error Handling**: try/catch usage, custom error classes, error wrapping, logging patterns
+4. **Component Structure** (frontend): Functional vs class components, hooks usage, props patterns
+5. **API Patterns** (backend): Endpoint naming, resource naming (plural/singular), versioning
+6. **Function Style**: Arrow functions vs declarations, async/await vs promises
+7. **Type Patterns**: TypeScript strictness, type vs interface usage, generics patterns
+
+## Consistency Threshold
+
+Only report patterns with **>= 60% consistency** across sampled files.
+
+Calculate: `(files following pattern / total files sampled) * 100`
+
+## Categorization
+
+Discover existing categories from `.owflow/docs/standards/*/`. Baseline categories: `global/`, `frontend/`, `backend/`, `testing/`. Propose new categories if patterns don't fit existing ones.
+
+## Confidence Range
+
+Code pattern findings: **60-88%** confidence. Higher when consistency is >= 90%.
+
+## Output Format
+
+Return YAML:
+
+```yaml
+findings:
+  - category: "[category/subcategory]"
+    standard_name: "[Short Name]"
+    description: "[What the convention is]"
+    confidence: [60-88]
+    evidence:
+      - "[X] of [Y] files follow this pattern"
+      - "Examples: [file1], [file2], [file3]"
+    source: "code-patterns"
+    examples:
+      - "[Correct pattern example]"
+```
+
+## Rules
+
+- Sample files randomly across directories for representative results
+- Report file counts in evidence (e.g., "247 of 250 .tsx files use PascalCase")
+- Only report patterns with >= 60% consistency
+- Return empty findings list if no clear patterns emerge
+- Focus on actionable, consistent patterns — not one-off occurrences
+- Do NOT write any files to the project directory. Write your YAML results to: `[output_file]` (the orchestrator replaces this placeholder with an actual temp file path when invoking you).

package/dist/skills/standards-discover/references/config-analyzer-prompt.md

@@ -1,67 +1,67 @@
-# Config Standards Analyzer — Subagent Prompt Template
-
-Analyze project configuration files to discover coding standards and conventions.
-
-## Task
-
-Find and analyze configuration files, extract standards, return structured findings as YAML.
-
-## Configuration Files to Analyze
-
-1. **Linter configs**: `.eslintrc.*`, `.prettierrc*`, `pylintrc`, `.pylintrc`, `.rubocop.yml`, `biome.json`
-2. **Compiler configs**: `tsconfig.json`, `jsconfig.json`
-3. **Package managers**: `package.json` (scripts, conventions), `requirements.txt`, `Gemfile`, `pom.xml`, `go.mod`
-4. **Editor configs**: `.editorconfig` (indentation, line endings, charset)
-5. **Container configs**: `Dockerfile`, `docker-compose.yml`
-
-## What to Extract
-
-For each config file found, extract rules/settings that indicate coding standards:
-
-- **ESLint**: Naming conventions, code style (quotes, semicolons, indentation), framework patterns, import rules
-- **Prettier**: Formatting rules (semi, singleQuote, trailingComma, tabWidth, printWidth)
-- **TypeScript**: Compiler strictness (strict, noImplicitAny), module resolution, path aliases
-- **Package.json**: Script patterns, testing conventions, pre-commit hooks (husky/lint-staged)
-- **EditorConfig**: Indentation style/size, charset, line endings, trailing whitespace
-- **Biome**: Combined lint + format rules
-
-## Categorization
-
-Discover existing categories from `.owflow/docs/standards/*/`. Baseline categories:
-
-- `global/` — Language-agnostic (indentation, line endings, general error handling)
-- `frontend/` — UI-specific (React rules, CSS conventions, component patterns)
-- `backend/` — Server-specific (API rules, database conventions)
-- `testing/` — Test-related (test frameworks, coverage requirements)
-
-Propose new categories if findings don't fit existing ones.
-
-## Confidence Range
-
-Config-based findings: **70-85%** confidence (explicit configuration = strong evidence).
-
-## Output Format
-
-Return YAML:
-
-```yaml
-findings:
-  - category: "[category/subcategory]"
-    standard_name: "[Short Name]"
-    description: "[What the standard requires]"
-    confidence: [70-85]
-    evidence:
-      - "[config-file]: [specific rule or setting]"
-    source: "config"
-    examples:
-      - "[Brief correct example if applicable]"
-```
-
-## Rules
-
-- Only include findings with clear evidence from actual config files
-- Be specific in descriptions (not "follow ESLint rules" but "use single quotes for strings")
-- Include exact file paths in evidence
-- Return empty findings list if no config files found
-- Focus on actionable, verifiable standards
-- Do NOT write any files to the project directory. Write your YAML results to: `[output_file]` (the orchestrator replaces this placeholder with an actual temp file path when invoking you).
+# Config Standards Analyzer — Subagent Prompt Template
+
+Analyze project configuration files to discover coding standards and conventions.
+
+## Task
+
+Find and analyze configuration files, extract standards, return structured findings as YAML.
+
+## Configuration Files to Analyze
+
+1. **Linter configs**: `.eslintrc.*`, `.prettierrc*`, `pylintrc`, `.pylintrc`, `.rubocop.yml`, `biome.json`
+2. **Compiler configs**: `tsconfig.json`, `jsconfig.json`
+3. **Package managers**: `package.json` (scripts, conventions), `requirements.txt`, `Gemfile`, `pom.xml`, `go.mod`
+4. **Editor configs**: `.editorconfig` (indentation, line endings, charset)
+5. **Container configs**: `Dockerfile`, `docker-compose.yml`
+
+## What to Extract
+
+For each config file found, extract rules/settings that indicate coding standards:
+
+- **ESLint**: Naming conventions, code style (quotes, semicolons, indentation), framework patterns, import rules
+- **Prettier**: Formatting rules (semi, singleQuote, trailingComma, tabWidth, printWidth)
+- **TypeScript**: Compiler strictness (strict, noImplicitAny), module resolution, path aliases
+- **Package.json**: Script patterns, testing conventions, pre-commit hooks (husky/lint-staged)
+- **EditorConfig**: Indentation style/size, charset, line endings, trailing whitespace
+- **Biome**: Combined lint + format rules
+
+## Categorization
+
+Discover existing categories from `.owflow/docs/standards/*/`. Baseline categories:
+
+- `global/` — Language-agnostic (indentation, line endings, general error handling)
+- `frontend/` — UI-specific (React rules, CSS conventions, component patterns)
+- `backend/` — Server-specific (API rules, database conventions)
+- `testing/` — Test-related (test frameworks, coverage requirements)
+
+Propose new categories if findings don't fit existing ones.
+
+## Confidence Range
+
+Config-based findings: **70-85%** confidence (explicit configuration = strong evidence).
+
+## Output Format
+
+Return YAML:
+
+```yaml
+findings:
+  - category: "[category/subcategory]"
+    standard_name: "[Short Name]"
+    description: "[What the standard requires]"
+    confidence: [70-85]
+    evidence:
+      - "[config-file]: [specific rule or setting]"
+    source: "config"
+    examples:
+      - "[Brief correct example if applicable]"
+```
+
+## Rules
+
+- Only include findings with clear evidence from actual config files
+- Be specific in descriptions (not "follow ESLint rules" but "use single quotes for strings")
+- Include exact file paths in evidence
+- Return empty findings list if no config files found
+- Focus on actionable, verifiable standards
+- Do NOT write any files to the project directory. Write your YAML results to: `[output_file]` (the orchestrator replaces this placeholder with an actual temp file path when invoking you).

package/dist/skills/standards-discover/references/docs-extractor-prompt.md

@@ -1,65 +1,65 @@
-# Documentation Standards Extractor — Subagent Prompt Template
-
-Extract coding standards and conventions explicitly documented in project files.
-
-## Task
-
-Find and parse documentation files, extract explicitly stated standards, return findings as YAML.
-
-## Documentation Files to Analyze
-
-1. **README.md** — Look for: Code Style, Contributing Guidelines, Conventions, Best Practices sections
-2. **CONTRIBUTING.md** — PR requirements, commit conventions, testing requirements, code review standards
-3. **ARCHITECTURE.md** / `docs/architecture/` — Design patterns, architectural decisions
-4. **ADRs** (Architecture Decision Records) — `adr/`, `decisions/`, `docs/decisions/` directories
-5. **AGENTS.md** / `AGENTS.md` — AI-specific coding instructions and project conventions
-6. **Code of Conduct**, **STYLEGUIDE.md** — If present
-
-## What to Extract
-
-Look for explicit standard statements:
-
-- "We use..." / "This project uses..."
-- "Always..." / "Never..."
-- "Prefer X over Y"
-- "Required: ..." / "Must..."
-- Code examples showing correct/incorrect patterns
-- Numbered rules or guidelines lists
-
-**Only extract explicitly stated standards** — do not infer from code examples alone.
-
-## Categorization
-
-Discover existing categories from `.owflow/docs/standards/*/`. Baseline categories: `global/`, `frontend/`, `backend/`, `testing/`. Propose new categories if patterns don't fit existing ones.
-
-## Confidence Range
-
-Documentation findings: **80-92%** confidence (explicitly documented = strong evidence).
-
-Higher end (90+) when multiple docs agree or when stated as mandatory rules.
-
-## Output Format
-
-Return YAML:
-
-```yaml
-findings:
-  - category: "[category/subcategory]"
-    standard_name: "[Short Name]"
-    description: "[What the standard requires]"
-    confidence: [80-92]
-    evidence:
-      - '[filename]: "[exact quote or paraphrase]"'
-    source: "documentation"
-    examples:
-      - "[Example from docs if provided]"
-```
-
-## Rules
-
-- Include exact quotes or close paraphrases in evidence
-- Note which file each standard comes from
-- Return empty findings list if no documentation files found
-- Prioritize actionable, clear standards over vague guidance
-- Do not duplicate what config files already enforce — focus on human-written guidelines
-- Do NOT write any files to the project directory. Write your YAML results to: `[output_file]` (the orchestrator replaces this placeholder with an actual temp file path when invoking you).
+# Documentation Standards Extractor — Subagent Prompt Template
+
+Extract coding standards and conventions explicitly documented in project files.
+
+## Task
+
+Find and parse documentation files, extract explicitly stated standards, return findings as YAML.
+
+## Documentation Files to Analyze
+
+1. **README.md** — Look for: Code Style, Contributing Guidelines, Conventions, Best Practices sections
+2. **CONTRIBUTING.md** — PR requirements, commit conventions, testing requirements, code review standards
+3. **ARCHITECTURE.md** / `docs/architecture/` — Design patterns, architectural decisions
+4. **ADRs** (Architecture Decision Records) — `adr/`, `decisions/`, `docs/decisions/` directories
+5. **AGENTS.md** / `AGENTS.md` — AI-specific coding instructions and project conventions
+6. **Code of Conduct**, **STYLEGUIDE.md** — If present
+
+## What to Extract
+
+Look for explicit standard statements:
+
+- "We use..." / "This project uses..."
+- "Always..." / "Never..."
+- "Prefer X over Y"
+- "Required: ..." / "Must..."
+- Code examples showing correct/incorrect patterns
+- Numbered rules or guidelines lists
+
+**Only extract explicitly stated standards** — do not infer from code examples alone.
+
+## Categorization
+
+Discover existing categories from `.owflow/docs/standards/*/`. Baseline categories: `global/`, `frontend/`, `backend/`, `testing/`. Propose new categories if patterns don't fit existing ones.
+
+## Confidence Range
+
+Documentation findings: **80-92%** confidence (explicitly documented = strong evidence).
+
+Higher end (90+) when multiple docs agree or when stated as mandatory rules.
+
+## Output Format
+
+Return YAML:
+
+```yaml
+findings:
+  - category: "[category/subcategory]"
+    standard_name: "[Short Name]"
+    description: "[What the standard requires]"
+    confidence: [80-92]
+    evidence:
+      - '[filename]: "[exact quote or paraphrase]"'
+    source: "documentation"
+    examples:
+      - "[Example from docs if provided]"
+```
+
+## Rules
+
+- Include exact quotes or close paraphrases in evidence
+- Note which file each standard comes from
+- Return empty findings list if no documentation files found
+- Prioritize actionable, clear standards over vague guidance
+- Do not duplicate what config files already enforce — focus on human-written guidelines
+- Do NOT write any files to the project directory. Write your YAML results to: `[output_file]` (the orchestrator replaces this placeholder with an actual temp file path when invoking you).