devflow-kit 1.8.3 → 2.0.1

package/plugins/devflow-ambient/skills/ambient-router/SKILL.md

@@ -1,145 +0,0 @@
----
-name: ambient-router
-description: This skill should be used when classifying user intent for ambient mode, auto-loading relevant skills without explicit command invocation. Used by the always-on UserPromptSubmit hook.
-user-invocable: false
-# No allowed-tools: orchestrator requires unrestricted access (Skill, Agent, Edit, Write, Bash)
----
-
-# Ambient Router
-
-Classify user intent and auto-load relevant skills. Zero overhead for simple requests, skill loading + optional agent orchestration for substantive work.
-
-## Iron Law
-
-> **PROPORTIONAL RESPONSE MATCHED TO SCOPE**
->
-> QUICK gets zero overhead. GUIDED gets skill loading + main session implementation
-> with Simplifier cleanup. ORCHESTRATED gets full skill loading via the Skill tool plus
-> agent pipeline execution. Misclassification in either direction is a failure —
-> false-positive ORCHESTRATED is expensive (5-6 agent spawns), false-negative
-> GUIDED leaves quality on the table.
-
----
-
-## Step 1: Classify Intent
-
-Determine what the user is trying to do from their prompt.
-
-| Intent | Signal Words / Patterns | Examples |
-|--------|------------------------|---------|
-| **IMPLEMENT** | "add", "create", "implement", "build", "write", "make" | "add a login form", "create an API endpoint" |
-| **DEBUG** | "fix", "bug", "broken", "failing", "error", "why does" | "fix the auth error", "why is this test failing" |
-| **REVIEW** | "check", "look at", "review", "is this ok", "any issues" | "check this function", "any issues with this?" |
-| **PLAN** | "how should", "design", "architecture", "approach", "strategy" | "how should I structure auth?", "what's the approach for caching?" |
-| **EXPLORE** | "what is", "where is", "find", "show me", "explain", "how does" | "where is the config?", "explain this function" |
-| **CHAT** | greetings, meta-questions, confirmations, short responses | "thanks", "yes", "what can you do?" |
-
-**Ambiguous prompts:** Default to the lowest-overhead classification. "Update the README" → QUICK. Git operations like "commit this" → QUICK.
-
-## Step 2: Classify Depth
-
-Determine how much enforcement the prompt warrants.
-
-| Depth | Criteria | Action |
-|-------|----------|--------|
-| **QUICK** | CHAT intent. EXPLORE intent. Git/devops operations (commit, push, merge, branch, pr, deploy, reinstall). Single-word continuations. Small edits, config changes, trivial single-file tweaks. | Respond normally. Zero overhead. Do not state classification. |
-| **GUIDED** | IMPLEMENT with small scope (≤2 files, single module). DEBUG with clear error location (stack trace, specific file, known function). PLAN for focused design questions (specific area/pattern). REVIEW (always GUIDED). | Load skills via Skill tool. Main session implements directly. Spawn Simplifier after code changes. State classification. |
-| **ORCHESTRATED** | IMPLEMENT with larger scope (>2 files, multi-module, complex). DEBUG with vague/cross-cutting bug (no clear location, multiple possible causes). PLAN for system-level architecture (caching layer, auth system, multi-module design). | Load skills via Skill tool, then orchestrate agents per Step 5. State classification. |
-
-**Scope-based decision criteria:**
-
-| Intent | GUIDED (small scope) | ORCHESTRATED (large scope) |
-|--------|---------------------|---------------------------|
-| **IMPLEMENT** | ≤2 files, single module, clear task | >2 files, multi-module, complex |
-| **DEBUG** | Clear error with known location (stack trace, specific file) | Vague/cross-cutting bug, multiple possible causes |
-| **PLAN** | Focused question about specific area/pattern | System-level architecture, multi-module design |
-| **REVIEW** | Always GUIDED | — |
-
-**Classification conservatism:** Default to QUICK. Only classify GUIDED/ORCHESTRATED when the prompt has clear task scope. When choosing between GUIDED and ORCHESTRATED, prefer GUIDED — escalate only when scope clearly exceeds main-session capacity.
-
-## Step 3: Select Skills
-
-Based on classified intent and depth, invoke each selected skill using the Skill tool.
-
-### GUIDED-depth skills
-
-| Intent | Primary Skills | Secondary (if file type matches) |
-|--------|---------------|----------------------------------|
-| **IMPLEMENT** | test-driven-development, implementation-patterns, search-first | typescript (.ts), react (.tsx/.jsx), go (.go), java (.java), python (.py), rust (.rs), frontend-design (CSS/UI), input-validation (forms/API), security-patterns (auth/crypto) |
-| **DEBUG** | core-patterns, test-patterns | git-safety (if git operations involved) |
-| **PLAN** | implementation-patterns, core-patterns | — |
-| **REVIEW** | self-review, core-patterns | test-patterns |
-
-### ORCHESTRATED-depth skills
-
-| Intent | Primary Skills | Secondary (if file type matches) |
-|--------|---------------|----------------------------------|
-| **IMPLEMENT** | implementation-orchestration, implementation-patterns | typescript (.ts), react (.tsx/.jsx), go (.go), java (.java), python (.py), rust (.rs), frontend-design (CSS/UI), input-validation (forms/API), security-patterns (auth/crypto) |
-| **DEBUG** | debug-orchestration, core-patterns | git-safety (if git operations involved) |
-| **PLAN** | plan-orchestration, implementation-patterns, core-patterns | — |
-
-**Excluded from ambient** (review-command-only): review-methodology, complexity-patterns, consistency-patterns, database-patterns, dependencies-patterns, documentation-patterns, regression-patterns, architecture-patterns, accessibility, performance-patterns.
-
-See `references/skill-catalog.md` for the full skill-to-intent mapping with file pattern triggers.
-
-## Step 4: Apply
-
-<IMPORTANT>
-When classification is GUIDED or ORCHESTRATED, skill loading is NON-NEGOTIABLE.
-Do not rationalize skipping skills. Do not respond without loading them first.
-BLOCKING REQUIREMENT: Your FIRST tool calls MUST be Skill tool invocations — before
-writing ANY text about the task. Invoke all selected skills, THEN state classification,
-THEN proceed with work. Do NOT write implementation text before all Skill tools return.
-For IMPLEMENT intent, enforce TDD: write the failing test before ANY production code.
-NOTE: Skills loaded in the main session via ambient mode are reference patterns only —
-their allowed-tools metadata does NOT restrict your tool access. You retain full access
-to all tools (Edit, Write, Bash, Agent, etc.) for implementation work.
-</IMPORTANT>
-
-- **QUICK:** Respond directly. No preamble, no classification statement.
-- **GUIDED:** First, invoke each selected skill using the Skill tool. After all Skill tools return, state classification briefly: `Ambient: IMPLEMENT/GUIDED. Loading: implementation-patterns, search-first.` Then work directly in main session. After code changes, spawn Simplifier on changed files.
-- **ORCHESTRATED:** First, invoke each selected skill using the Skill tool. After all Skill tools return, state classification briefly: `Ambient: IMPLEMENT/ORCHESTRATED. Loading: implementation-orchestration, implementation-patterns.` Then follow Step 5 for agent orchestration.
-
-### GUIDED Behavior by Intent
-
-| Intent | Main Session Work | Post-Work |
-|--------|------------------|-----------|
-| **IMPLEMENT** | Implement directly with loaded skills. Follow TDD cycle. | Spawn Simplifier on changed files. |
-| **DEBUG** | Investigate directly — reproduce bug, diagnose from stack trace/error, fix. | Spawn Simplifier on changed files. |
-| **PLAN** | Explore relevant code and design directly. The area is focused enough for main session. | No Simplifier (no code changes). |
-| **REVIEW** | Review directly with loaded skills. | No Simplifier. |
-
-## Step 5: Orchestrate Agents (ORCHESTRATED depth only)
-
-After loading skills via Step 3-4, execute the agent pipeline for the classified intent:
-
-| Intent | Pipeline |
-|--------|----------|
-| **IMPLEMENT** | Follow implementation-orchestration skill pipeline: pre-flight → plan synthesis → Coder → quality gates |
-| **DEBUG** | Follow debug-orchestration skill pipeline: hypotheses → parallel Explores → convergence → report → offer fix |
-| **PLAN** | Follow plan-orchestration skill pipeline: Skimmer → Explores → Plan agent → gap validation |
-| **EXPLORE** | No agents — respond in main session |
-| **CHAT** | No agents — respond in main session |
-
----
-
-## Transparency Rules
-
-1. **QUICK → silent.** No classification output.
-2. **GUIDED → brief statement + full skill enforcement.** One line: intent, depth, skills loaded. Then implement in main session with skill patterns applied.
-3. **ORCHESTRATED → brief statement + full skill enforcement + agent orchestration.** One line: intent, depth, skills loaded. Then follow every skill requirement and orchestrate agents per Step 5.
-4. **Never lie about classification.** If uncertain, say so.
-5. **Never over-classify.** When in doubt, go one tier lower.
-6. **Never under-apply.** Rationalization is the enemy of quality. If a skill requires a step, do the step.
-
-## Edge Cases
-
-| Case | Handling |
-|------|----------|
-| Mixed intent ("fix this bug and add a test") | Use the higher-overhead intent (IMPLEMENT > DEBUG) |
-| Continuation of previous conversation | Inherit previous classification unless prompt clearly shifts |
-| User explicitly requests no enforcement | Respect immediately — classify as QUICK |
-| Prompt references specific DevFlow command | Skip ambient — the command has its own orchestration |
-| Scope ambiguous between GUIDED and ORCHESTRATED | Default to GUIDED; escalate if complexity emerges during work |
-| REVIEW intent | Always GUIDED — single Reviewer focus, no orchestration pipeline |
-| Multiple triggers per session | Each runs independently; context compaction handles accumulation |

package/plugins/devflow-ambient/skills/ambient-router/references/skill-catalog.md

@@ -1,74 +0,0 @@
-# Ambient Router — Skill Catalog
-
-Full mapping of DevFlow skills to ambient intents and file-type triggers. The ambient-router SKILL.md references this for detailed selection logic.
-
-## Skills Available for Ambient Loading
-
-These skills may be loaded during GUIDED and ORCHESTRATED-depth ambient routing.
-
-### IMPLEMENT Intent
-
-| Skill | When to Load | Depth | File Patterns |
-|-------|-------------|-------|---------------|
-| implementation-orchestration | ORCHESTRATED only | ORCHESTRATED | Any — orchestrates agent pipeline |
-| test-driven-development | Always for IMPLEMENT | GUIDED + ORCHESTRATED | Any code file — enforces RED-GREEN-REFACTOR |
-| implementation-patterns | Always for IMPLEMENT | GUIDED + ORCHESTRATED | Any code file |
-| search-first | Always for IMPLEMENT | GUIDED + ORCHESTRATED | Any — enforces research before building |
-| typescript | TypeScript files in scope | GUIDED + ORCHESTRATED | `*.ts`, `*.tsx` |
-| react | React components in scope | GUIDED + ORCHESTRATED | `*.tsx`, `*.jsx` |
-| frontend-design | UI/styling work | GUIDED + ORCHESTRATED | `*.css`, `*.scss`, `*.tsx` with styling keywords |
-| input-validation | Forms, APIs, user input | GUIDED + ORCHESTRATED | Files with form/input/validation keywords |
-| go | Go files in scope | GUIDED + ORCHESTRATED | `*.go` |
-| java | Java files in scope | GUIDED + ORCHESTRATED | `*.java` |
-| python | Python files in scope | GUIDED + ORCHESTRATED | `*.py` |
-| rust | Rust files in scope | GUIDED + ORCHESTRATED | `*.rs` |
-| security-patterns | Auth, crypto, secrets | GUIDED + ORCHESTRATED | Files with auth/token/crypto/password keywords |
-
-### DEBUG Intent
-
-| Skill | When to Load | Depth | File Patterns |
-|-------|-------------|-------|---------------|
-| debug-orchestration | ORCHESTRATED only | ORCHESTRATED | Any — orchestrates investigation pipeline |
-| core-patterns | Always for DEBUG | GUIDED + ORCHESTRATED | Any code file |
-| test-patterns | Always for DEBUG (GUIDED) | GUIDED | Any code file |
-| git-safety | Git operations involved | GUIDED + ORCHESTRATED | User mentions git, rebase, merge, etc. |
-
-### REVIEW Intent
-
-| Skill | When to Load | Depth | File Patterns |
-|-------|-------------|-------|---------------|
-| self-review | Always for REVIEW | GUIDED | Any code file |
-| core-patterns | Always for REVIEW | GUIDED | Any code file |
-| test-patterns | Test files in scope | GUIDED | `*.test.*`, `*.spec.*` |
-
-### PLAN Intent
-
-| Skill | When to Load | Depth | File Patterns |
-|-------|-------------|-------|---------------|
-| plan-orchestration | ORCHESTRATED only | ORCHESTRATED | Any — orchestrates design pipeline |
-| implementation-patterns | Always for PLAN | GUIDED + ORCHESTRATED | Any planning context |
-| core-patterns | Always for PLAN | GUIDED + ORCHESTRATED | System design discussions |
-
-## Skills Excluded from Ambient
-
-These skills are loaded only by explicit DevFlow commands (primarily `/code-review`):
-
-- review-methodology — Full review process (6-step, 3-category classification)
-- complexity-patterns — Cyclomatic complexity, deep nesting analysis
-- consistency-patterns — Naming convention, pattern deviation detection
-- database-patterns — Index analysis, query optimization, migration safety
-- dependencies-patterns — CVE detection, license audit, outdated packages
-- documentation-patterns — Doc drift, stale comments, missing API docs
-- regression-patterns — Lost functionality, broken exports, behavioral changes
-- architecture-patterns — SOLID analysis, coupling detection, layering issues
-- accessibility — WCAG compliance, ARIA roles, keyboard navigation
-- performance-patterns — N+1 queries, memory leaks, caching opportunities
-
-## Selection Limits
-
-- **Maximum 3 knowledge skills** per ambient response (primary + up to 2 secondary)
-- **Orchestration skills** (implementation-orchestration, debug-orchestration, plan-orchestration) are loaded only at ORCHESTRATED depth — they don't count toward the knowledge skill limit
-- **Primary skills** are always loaded for the classified intent at both GUIDED and ORCHESTRATED depth
-- **Secondary skills** are loaded only when file patterns match conversation context
-- **GUIDED depth** loads knowledge skills only (no orchestration skills) — main session works directly
-- **ORCHESTRATED depth** loads orchestration skill + knowledge skills — agents execute the pipeline

package/plugins/devflow-ambient/skills/debug-orchestration/SKILL.md

@@ -1,69 +0,0 @@
----
-name: debug-orchestration
-description: Agent orchestration for DEBUG intent — hypothesis investigation, root cause analysis, optional fix
-user-invocable: false
-allowed-tools: Read, Grep, Glob, Bash, Task, AskUserQuestion
----
-
-# Debug Orchestration
-
-Agent pipeline for DEBUG intent in ambient ORCHESTRATED mode. Competing hypothesis investigation, parallel evidence gathering, convergence validation, and optional fix.
-
-This is a lightweight variant of `/debug` for ambient ORCHESTRATED mode. Excluded: knowledge persistence loading, GitHub issue fetching, pitfall recording.
-
-## Iron Law
-
-> **COMPETING HYPOTHESES BEFORE CONCLUSIONS**
->
-> Never investigate a single theory. Generate 3-5 distinct hypotheses, investigate them
-> in parallel, and let evidence determine the root cause. Confirmation bias is the enemy
-> of debugging — multiple hypotheses are the antidote.
-
----
-
-## Phase 1: Hypothesize
-
-Analyze the bug description, error messages, and conversation context. Generate 3-5 hypotheses that are:
-
-- **Specific**: Points to a concrete mechanism (not "something is wrong with auth")
-- **Testable**: Can be confirmed or disproved by examining specific files/logs
-- **Distinct**: Each hypothesis proposes a different root cause
-
-If fewer than 3 hypotheses are possible, proceed with 2.
-
-## Phase 2: Investigate (Parallel)
-
-Spawn one `Task(subagent_type="Explore")` per hypothesis **in a single message** (parallel execution):
-
-- Each investigator searches for evidence FOR and AGAINST its hypothesis
-- Must provide file:line references for all evidence
-- Returns verdict: **CONFIRMED** | **DISPROVED** | **PARTIAL** (some evidence supports, some contradicts)
-
-## Phase 3: Converge
-
-Evaluate investigation results:
-
-- **One CONFIRMED**: Spawn 1-2 additional `Task(subagent_type="Explore")` agents to validate from different angles (prevent confirmation bias)
-- **Multiple PARTIAL**: Look for a unifying root cause that explains all partial evidence
-- **All DISPROVED**: Report honestly — "No root cause identified from initial hypotheses." Generate 2-3 second-round hypotheses if conversation context suggests avenues not yet explored.
-
-## Phase 4: Report
-
-Present root cause analysis:
-
-- **Confidence level**: HIGH (confirmed + validated) | MEDIUM (partial convergence) | LOW (best guess from incomplete evidence)
-- **Evidence table**: Hypothesis → verdict → key evidence (file:line)
-- **Root cause**: Clear statement of what's wrong and why
-- **Recommended fix**: Specific changes with file references
-
-## Phase 5: Offer Fix
-
-Ask user via AskUserQuestion: "Want me to implement this fix?"
-
-- **YES** → Implement the fix directly in main session using GUIDED approach: load implementation-patterns, search-first, and test-driven-development skills, then code the fix. Spawn `Task(subagent_type="Simplifier")` on changed files after.
-- **NO** → Done. Report stands as documentation.
-
-## Error Handling
-
-- **All hypotheses disproved, no second-round ideas**: Report "No root cause identified" with summary of what was investigated and ruled out
-- **Explore agents return insufficient evidence**: Report LOW confidence with available evidence, suggest manual investigation areas

package/plugins/devflow-ambient/skills/implementation-orchestration/SKILL.md

@@ -1,92 +0,0 @@
----
-name: implementation-orchestration
-description: Agent orchestration for IMPLEMENT intent — pre-flight, Coder, quality gates
-user-invocable: false
-allowed-tools: Read, Grep, Glob, Bash, Task, AskUserQuestion
----
-
-# Implementation Orchestration
-
-Agent pipeline for IMPLEMENT intent in ambient ORCHESTRATED mode. Pre-flight checks, plan synthesis, Coder execution, and quality gates.
-
-This is a lightweight variant of `/implement` for ambient ORCHESTRATED mode. Excluded: strategy selection (single/sequential/parallel Coders), retry loops, PR creation, knowledge loading.
-
-## Iron Law
-
-> **QUALITY GATES ARE NON-NEGOTIABLE**
->
-> Every Coder output passes through Validator → Simplifier → Scrutinizer → re-Validate → Shepherd.
-> Skipping a gate because "it looks fine" is never acceptable. The pipeline runs to completion
-> or halts on failure — there is no shortcut.
-
----
-
-## Phase 1: Pre-flight — Branch Safety
-
-Detect branch type before spawning Coder:
-
-- **Work branches** (`feat/`, `fix/`, `chore/`, `refactor/`, `docs/` prefix): proceed on current branch.
-- **Protected branches** (`main`, `master`, `develop`, `release/*`, `staging`, `production`): ask user via AskUserQuestion with 2-3 suggested branch names following `{type}/{ticket}-{slug}` convention. Include ticket number if available from conversation context.
-- **If user declines branch creation**: proceed on the protected branch. Respect the user's choice.
-
-## Phase 2: Plan Synthesis
-
-Synthesize conversation context into a structured EXECUTION_PLAN for Coder:
-
-- **If a plan exists** in conversation context (from plan mode — accepted in-session or injected after "accept and clear") → use the plan as-is.
-- **Otherwise** → synthesize from conversation: what to build, files/modules affected, constraints, decisions made during discussion.
-
-Format as structured markdown with: Goal, Steps, Files, Constraints, Decisions.
-
-## Phase 3: Coder Execution
-
-Record git SHA before first Coder: `git rev-parse HEAD`
-
-Spawn `Task(subagent_type="Coder")` with input variables:
-- **TASK_ID**: Generated from timestamp (e.g., `task-2026-03-19_1430`)
-- **TASK_DESCRIPTION**: From conversation context
-- **BASE_BRANCH**: Current branch (or newly created branch from Phase 1)
-- **EXECUTION_PLAN**: From Phase 2
-- **PATTERNS**: Codebase patterns from conversation context
-- **CREATE_PR**: `false` (commit only, no push)
-- **DOMAIN**: Inferred from files in scope (`backend`, `frontend`, `tests`, `fullstack`)
-
-**Execution strategy**: Single sequential Coder by default. Parallel Coders only when tasks are self-contained — zero shared contracts, no integration points, different files/modules with no imports between them.
-
-If Coder returns **BLOCKED**, halt the pipeline and report to user.
-
-## Phase 4: FILES_CHANGED Detection
-
-After Coder completes, detect changed files:
-
-```bash
-git diff --name-only {starting_sha}...HEAD
-```
-
-Pass FILES_CHANGED to all quality gate agents.
-
-## Phase 5: Quality Gates
-
-Run sequentially — each gate must pass before the next:
-
-1. `Task(subagent_type="Validator")` (build + typecheck + lint + tests) — retry up to 2× on failure (Coder fixes between retries)
-2. `Task(subagent_type="Simplifier")` — code clarity and maintainability pass on FILES_CHANGED
-3. `Task(subagent_type="Scrutinizer")` — 9-pillar quality evaluation on FILES_CHANGED
-4. `Task(subagent_type="Validator")` (re-validate after Simplifier/Scrutinizer changes)
-5. `Task(subagent_type="Shepherd")` — verify implementation matches original request — retry up to 2× if misalignment found
-
-If any gate exhausts retries, halt pipeline and report what passed and what failed.
-
-## Phase 6: Completion
-
-Report results:
-- Commits created (from Coder)
-- Files changed
-- Quality gate results (pass/fail per gate)
-- No push — user decides when to push
-
-## Error Handling
-
-- **Coder BLOCKED**: Halt immediately, report blocker to user
-- **Validator fails after retries**: Report specific failures, halt pipeline
-- **Shepherd misalignment after retries**: Report misalignment details, let user decide next steps

package/plugins/devflow-ambient/skills/plan-orchestration/SKILL.md

@@ -1,71 +0,0 @@
----
-name: plan-orchestration
-description: Agent orchestration for PLAN intent — codebase orientation, design exploration, gap validation
-user-invocable: false
-allowed-tools: Read, Grep, Glob, Bash, Task, AskUserQuestion
----
-
-# Plan Orchestration
-
-Agent pipeline for PLAN intent in ambient ORCHESTRATED mode. Codebase orientation, targeted exploration, architecture design, and gap validation.
-
-This is a lightweight variant of the Plan phase in `/implement` for ambient ORCHESTRATED mode.
-
-## Iron Law
-
-> **PLANS WITHOUT CODEBASE GROUNDING ARE FANTASIES**
->
-> Orient before architecting. Every design decision must reference existing patterns,
-> real file structures, and actual integration points. A plan that ignores the codebase
-> will fail on contact with implementation.
-
----
-
-## Phase 1: Orient
-
-Spawn `Task(subagent_type="Skimmer")` to get codebase overview relevant to the planning question:
-
-- Existing patterns and conventions in the affected area
-- File structure and module boundaries
-- Test patterns and coverage approach
-- Related prior implementations (similar features, analogous patterns)
-
-## Phase 2: Explore
-
-Based on Skimmer findings, spawn 2-3 `Task(subagent_type="Explore")` agents **in a single message** (parallel execution):
-
-- **Integration explorer**: Examine integration points — APIs, shared types, module boundaries the plan must respect
-- **Pattern explorer**: Find existing implementations of similar features to follow as templates
-- **Constraint explorer**: Identify constraints — test infrastructure, build system, CI requirements, deployment concerns
-
-Adjust explorer focus based on the specific planning question.
-
-## Phase 3: Design
-
-Spawn `Task(subagent_type="Plan")` with combined Skimmer + Explore findings:
-
-- Design implementation approach with file-level specificity
-- Reference existing patterns discovered in Phase 1-2
-- Include: architecture decisions, file changes, new files needed, test strategy
-- Flag any areas where existing patterns conflict with the proposed approach
-
-## Phase 4: Validate
-
-Main session reviews the plan for:
-
-- **Gaps**: Missing files, unhandled edge cases, integration points not addressed
-- **Risks**: Areas where the plan deviates from existing patterns, potential regressions
-- **Ambiguities**: Design choices that need user input
-
-Present plan to user with identified risks. Use AskUserQuestion for any ambiguous design choices.
-
-## Output
-
-Structured plan ready to feed into IMPLEMENT/ORCHESTRATED if user proceeds:
-
-- Goal and scope
-- Architecture decisions with rationale
-- File-level change list (create/modify/delete)
-- Test strategy
-- Risks and mitigations
-- Open questions (if any)

package/plugins/devflow-audit-claude/.claude-plugin/plugin.json

@@ -1,19 +0,0 @@
-{
-  "name": "devflow-audit-claude",
-  "description": "Audit CLAUDE.md files against Anthropic best practices",
-  "author": {
-    "name": "Dean0x"
-  },
-  "version": "1.8.3",
-  "homepage": "https://github.com/dean0x/devflow",
-  "repository": "https://github.com/dean0x/devflow",
-  "license": "MIT",
-  "keywords": [
-    "audit",
-    "claude-md",
-    "best-practices",
-    "lint"
-  ],
-  "agents": [],
-  "skills": []
-}

package/plugins/devflow-audit-claude/README.md

@@ -1,46 +0,0 @@
-# devflow-audit-claude
-
-Audit CLAUDE.md files against Anthropic's best practices for size, structure, and content quality.
-
-## Command
-
-### `/audit-claude`
-
-Analyzes CLAUDE.md files and reports issues with severity levels and fix suggestions.
-
-```bash
-/audit-claude              # Audit all CLAUDE.md files in project + global
-/audit-claude ./CLAUDE.md  # Audit a specific file
-```
-
-## What It Checks
-
-| Category | What It Finds |
-|----------|--------------|
-| **SIZE** | Files exceeding line/token limits |
-| **MISSING** | Required sections (tech stack, structure, commands) |
-| **ANTI-PATTERN** | Content that belongs elsewhere (runbooks, catalogs, style rules) |
-| **STRUCTURE** | Deep heading nesting, non-scannable layout |
-| **CONTENT** | Generic advice, removable lines, vague instructions |
-| **HIERARCHY** | Duplicated content across root/subdir/global |
-| **INTEGRATION** | Content that should be skills, hooks, or linter config |
-| **CLAUDE-SPECIFIC** | Re-documented skills, agent internals, build details |
-
-## Severity Levels
-
-- **Critical**: File exceeds size limits, missing essential sections
-- **High**: Anti-pattern content (runbooks, catalogs), skill re-documentation
-- **Medium**: Section bloat, generic advice, integration opportunities
-- **Low**: Style issues, minor nesting problems
-
-## Guidelines
-
-Based on Anthropic's official CLAUDE.md guidance:
-- Target < 300 lines for root CLAUDE.md
-- "For each line, ask whether removing it would cause Claude to make mistakes; if not, cut it"
-- Use progressive disclosure: brief summary with pointers to detailed docs
-- CLAUDE.md loads every session — only include universally-applicable guidance
-
-## Agent
-
-- `claude-md-auditor` — Plugin-specific agent that runs the 8-category audit rubric

package/plugins/devflow-audit-claude/agents/claude-md-auditor.md

@@ -1,134 +0,0 @@
----
-name: claude-md-auditor
-description: Audits CLAUDE.md files against Anthropic best practices for size, structure, and content quality
-model: sonnet
-allowed-tools: Read, Grep, Glob
----
-
-# CLAUDE.md Auditor
-
-You are a strict auditor that evaluates CLAUDE.md files against Anthropic's official guidance. You find issues that waste tokens, confuse Claude, or belong in other locations. You never soften findings.
-
-## Input Context
-
-- `file_path`: Absolute path to the CLAUDE.md file
-- `location_context`: root | subdirectory | global
-- `tech_stack`: Detected project technologies (optional)
-
-## Audit Rubric
-
-Run all 8 checks against the file. Every finding needs: severity, category tag, line reference, explanation, and fix suggestion.
-
-### 1. Size Limits [SIZE]
-
-| Context | Line Limit | Token Estimate |
-|---------|-----------|----------------|
-| Root CLAUDE.md | < 300 | ~5KB |
-| Subdirectory CLAUDE.md | < 150 | ~2.5KB |
-| Global ~/.claude/CLAUDE.md | < 200 | ~3.5KB |
-
-- Count total lines (excluding blank lines at end)
-- Estimate tokens: word_count * 1.3
-- Flag sections exceeding 50 lines
-- **Critical** if file exceeds limit. **Medium** if any section exceeds 50 lines.
-
-### 2. Required Sections [MISSING]
-
-For root CLAUDE.md, check for presence of:
-- Project overview / purpose (what this project does)
-- Tech stack (languages, frameworks, key dependencies)
-- Project structure (directory layout or key files)
-- Development commands (build, test, run)
-- Key conventions (naming, patterns, gotchas)
-
-**High** if tech stack or project overview is missing. **Medium** for others.
-
-### 3. Anti-Pattern Detection [ANTI-PATTERN]
-
-Flag these content types — they belong elsewhere:
-- **Code style rules** (indentation, semicolons, quotes) — belongs in `.editorconfig` / ESLint / Prettier
-- **Procedural runbooks** (step-by-step release processes, deploy scripts) — belongs in `docs/` or scripts
-- **Reference catalogs** (full API lists, complete type inventories, exhaustive pattern tables) — belongs in `docs/reference/`
-- **Aspirational / motivational content** ("Remember: quality matters!") — provides no operational value
-- **Generic advice** ("test thoroughly", "write clean code") — Claude already knows this
-- **Duplicated content** — information already in skills, agents, or other config files
-
-**High** for procedural runbooks and reference catalogs. **Medium** for others.
-
-### 4. Structure Quality [STRUCTURE]
-
-- Headers should be scannable (clear hierarchy, descriptive names)
-- Maximum 3 heading levels (`#`, `##`, `###`) — deeper nesting hurts readability
-- Sections should use progressive disclosure: brief summary with pointer to detailed doc
-- Code blocks should be minimal — only include code that prevents mistakes
-
-**Medium** for nesting violations. **Low** for style issues.
-
-### 5. Content Quality [CONTENT]
-
-For each line, apply the test: "Would removing this cause Claude to make mistakes?"
-- If no: flag for removal
-- Flag vague instructions ("be careful", "use best practices")
-- Flag obvious statements that any model already follows
-- Prefer specific, actionable instructions over general guidance
-
-**Medium** for removable content. **Low** for vagueness.
-
-### 6. Hierarchical Usage [HIERARCHY]
-
-- Root CLAUDE.md: project-wide guidance only
-- Subdirectory CLAUDE.md: module-specific overrides only
-- Global CLAUDE.md: cross-project preferences only
-- No duplicated content across hierarchy levels
-
-**High** if global file contains project-specific content. **Medium** for duplication.
-
-### 7. Integration Opportunities [INTEGRATION]
-
-Flag content that should be:
-- A **skill** (auto-activating pattern enforcement)
-- A **hook** (pre-commit, post-save automation)
-- A **linter config** (.editorconfig, ESLint, Prettier)
-- A **CI check** (automated enforcement)
-- A **script** (repeatable procedures)
-
-**Medium** for clear integration opportunities.
-
-### 8. Claude Code Specifics [CLAUDE-SPECIFIC]
-
-Flag if file contains:
-- Re-documentation of skill contents (skills auto-load)
-- Plugin manifest details (Claude reads plugin.json directly)
-- Build process internals (belongs in docs/reference/)
-- Agent implementation details (belongs in agent definitions)
-
-**High** for skill/agent re-documentation. **Medium** for build/manifest details.
-
-## Output Format
-
-Return findings as structured markdown:
-
-```markdown
-### File: {file_path} ({line_count} lines, ~{token_estimate} tokens)
-
-#### CRITICAL
-- [{CATEGORY}] {description}. **Fix**: {suggestion}.
-
-#### HIGH
-- [{CATEGORY}] Lines {start}-{end}: {description}. **Fix**: {suggestion}.
-
-#### MEDIUM
-- [{CATEGORY}] {description}. **Fix**: {suggestion}.
-
-#### LOW
-- [{CATEGORY}] {description}. **Fix**: {suggestion}.
-```
-
-Omit severity sections that have no findings. Always include the file summary line with line count and token estimate.
-
-## Boundaries
-
-- **Read-only**: Never modify CLAUDE.md files
-- **No false positives**: Only flag issues you're confident about
-- **Severity accuracy**: Don't inflate severity to seem thorough
-- **Escalate**: If file structure is so unusual you can't assess it, say so