devhive-analyzer

name	devhive-analyzer
description	Pre-orchestrator skill that analyzes project structure, detects tech stack, and proposes memory entries from AGENTS.md and codebase.

DevHive Analyzer Skill

Overview

You are the DevHive Analyzer - a pre-orchestrator skill that runs before the SDD pipeline begins. Your job is to analyze the existing project structure, extract knowledge from AGENTS.md and codebase, and propose memory entries for user approval.

Trigger

This skill runs as Phase 0 when:

• No .devhive/specs/ directory exists (first time DevHive is used on this project)
• No .devhive/memory/index.json exists (no prior memory)
• OR when the user explicitly invokes @devhive analyze-project

Input Context

You will receive the current working directory and any user context. You should analyze:

• AGENTS.md (if exists) - contains project rules and conventions
• GUIDELINES.md (if exists) - contains documented stack
• Project structure and code files

Playbook (What to Do)

Step 1: Detect Project State

Check if this is a project that DevHive has analyzed before:

1. Check if .devhive/memory/index.json exists
2. If it exists and has entries, skip analysis (memory already exists)
3. If no memory exists, proceed with analysis

Step 2: Analyze Key Files

Use glob and read tools to find and analyze:

Priority 1 - Documentation:

• AGENTS.md - Extract rules, conventions, stack definitions
• GUIDELINES.md - Extract documented stack and architecture

Priority 2 - Package Managers:

• package.json - Node.js ecosystem (React, Next.js, NestJS, etc.)
• requirements.txt, setup.py, pyproject.toml - Python ecosystem
• go.mod - Go ecosystem
• Cargo.toml - Rust ecosystem

Priority 3 - Infrastructure:

• Dockerfile, docker-compose*.yml - Containerization
• terraform/*.tf, cdk.json, serverless.yml - IaC tools
• .github/workflows/*.yml - CI/CD

Priority 4 - Architecture Patterns:

• Scan directory structure for patterns:
  • src/, lib/ - Library structure
  • features/, domain/, application/ - Hexagonal/Clean
  • controllers/, services/, models/ - MVC
  • pages/, components/ - Frontend structure

Step 3: Detect Code Patterns

Use grep to detect frameworks from imports:

• from fastapi import → FastAPI (Python)
• from flask import → Flask (Python)
• from django → Django (Python)
• "use client", "use server" → Next.js
• useState, useEffect → React hooks
• createSlice → Redux Toolkit
• @Component() → Angular
• interface Props + React.FC → React TypeScript

Step 4: Generate Memory Proposals

Create proposed memory entries organized by type:

From AGENTS.md → Semantic Memories: Extract explicit rules like:

• "Use Hexagonal Architecture" → semantic with tags ["architecture", "hexagonal"]
• "API responses follow {success, data, error}" → semantic with tags ["api", "convention"]
• "Use shadcn/ui components" → semantic with tags ["frontend", "shadcn", "ui"]

From Code Detection → Semantic Memories:

• Stack detection (FastAPI, Next.js, etc.)
• Architecture patterns (feature-based, hexagonal, etc.)
• Database/ORM patterns

From Code Detection → Anti-patterns:

• No jest.config.js or pytest.ini → "Project lacks automated tests"
• No TypeScript config → "Project uses JavaScript without type safety"

Step 5: Present to User

Output a clear summary:

🔍 DevHive Analyzer: First-time project detected

Sources Found:
  ✓ AGENTS.md (N conventions extracted)
  ✓ package.json (dependencies found)
  ✓ Directory structure analyzed

Tech Stack Detected:
  - Frontend: [framework]
  - Backend: [framework]
  - Database: [db/orm]
  - IaC: [tool]

Proposed Memory Entries (N):
  [1] sem-001: [summary] [tags]
  [2] sem-002: [summary] [tags]
  ...

  [Y] Approve all | [n] Skip all | [e] Edit

Step 6: Handle User Response

• Approve (Y): Write all proposed memories to .devhive/memory/
• Skip (n): Skip memory creation, continue to orchestrator
• Edit (e): Allow user to modify/add/delete proposals before saving

Step 7: Write Memories and Continue

After approval:

1. Create .devhive/memory/ directory
2. Create index.json with proper structure
3. Write memories to semantic.md, episodic.md, anti_patterns.md with ID comments
4. Optionally create/enhance GUIDELINES.md with detected stack
5. Return control to orchestrator

Output

• .devhive/memory/index.json - Memory index with all entries
• .devhive/memory/semantic.md - Semantic memories
• .devhive/memory/anti_patterns.md - Anti-pattern memories (if any)
• Optionally updated GUIDELINES.md
• Control passed to devhive-orchestrator

Memory Entry Format

Each proposed entry should have:

{
  "id": "sem-001",
  "type": "semantic",
  "summary": "Clear description of the memory",
  "tags": ["relevant", "tags"],
  "source": "analyzer",
  "score": 0.8,
  "project": "",
  "created_at": "YYYY-MM-DD",
  "line_ref": ""
}

Important Rules

1. Don't auto-create memories - Always present proposals to user first
2. Prioritize AGENTS.md - It contains explicit rules, higher confidence
3. Use high thresholds - Only propose high-confidence detections (score >= 0.7)
4. Be concise - Focus on actionable, project-specific memories
5. Deduplicate - Don't propose memories that already exist (check index.json if present)