v0.6.1 Independent plugin for Claude Code
GitHub Español
Claude Code, but with a team
PLUGIN FOR CLAUDE CODE

A WORK SYSTEM FOR CLAUDE CODE

19 real agents, 25 namespaced commands + /alfred, 62 published skills, per-project SQLite memory, and operational PM. Alfred turns Claude Code into a flow with continuity, context, and quality gates.

19 agents 25 + /alfred SQLite + PM
Installers by platform Each button opens a popup with the command ready to copy.

CHANGELOG

Latest release v0.6.1
2026-06-22
Changed
  • More resilient installers: Bash and PowerShell clear stale local Claude Code marketplace checkouts before reinstalling.
  • Normalized global updates: the flow re-registers the GitHub source, refreshes the alfred-dev marketplace, and keeps the plugin installed at user scope.
Fixed
  • Fixes the case where Claude Code reported Successfully installed plugin: alfred-dev@alfred-dev while the installed cache still resolved to an older version such as 0.5.2.
  • The /alfred alias is materialized again from the correct plugin root after updating from old versions or inherited local caches.
A plugin for CLAUDE CODE for working with rigor
19 agents25 + /alfredlocal memoryquality gates

that turn an isolated session into a governed process.

What Alfred actually does
01

Decides the next step

Reads the repo, the current session, and SonIA state to start with map-codebase, discuss, feature, or verify without assembling the flow by hand.

02

Exposes operational state

Kanban, blockers, handoff, UAT, memory, and the next action stay visible from the CLI with progress, standup, blocked, validate, and search.

03

Ships with evidence

The flow forces technical design, TDD, security, QA, documentation, and release work before a phase can be closed.

Team 19 real agents

Published in plugin.json. Core and optional agents with their real names and function in the plugin.
10 Core

Operational core

Orchestration, scope, architecture, implementation, security, QA, release, traceability, and design-system direction.

09 Optional

Activatable specialists

They activate depending on stack, task, or config: data, UX, performance, GitHub, SEO, i18n, copy, memory, and external audit.

Commands 26

The 26 public plugin routes, grouped by entry, orientation, build, control, and operations.
03

Entry

Bootstrap and help

Load Alfred, set configuration, and understand the public surface of the plugin.

07

Orientation

Context and continuity

Read the real state of the repo and decide the next step without reopening all context.

06

Build

Delivery and audit

Open real delivery work: features, quick changes, fixes, technical exploration, ship, and audit.

05

Control

Verification and blockers

Verify UAT, detect blockers, and review operational health before continuing or closing.

05

Operations

Memory and maintenance

Search memory, open the local UI, sync GitHub, update, and request a second opinion.

Skills and playbooks

62 published / 15 domains
61 published skills 15 domains covered

The published catalog encapsulates repeatable decisions for incidents, releases, dependencies, style, QA, security, and delivery.

Featured examples

Incident ResponseSonarqubeRelease PlanningDependency StrategyStyle Direction
Reusable, versioned procedures inside the plugin, not ad-hoc prompts.
Product 4 skills
Acceptance Criteria · Competitive Analysis · User Stories · Write Prd
Architecture 4 skills
Choose Stack · Design System · Evaluate Dependencies · Write ADR
Development 4 skills
Code Review Response · Explore Codebase · Refactor · Tdd Cycle
Quality 8 skills
Code Review · E2e Testing · Exploratory Testing · Incident Response · Regression Check · Sonarqube · Spelling Check · Test Plan
Security 7 skills
Compliance Check · Dependency Audit · Dependency Strategy · Dependency Update · Sbom Generate · Security Review · Threat Model
Data 3 skills
Migration Plan · Query Optimization · Schema Design

Auxiliary layers

6 active

How to start 03 steps

Start in 3 steps

entry flow
01

Install Alfred Dev

Use the installer for your system; it registers the plugin and leaves the runtime ready to work.

02

Configure stack and team

Run /alfred-dev:config to set stack, memory, autonomy, and optional agents.

03

Enter through the right command

New repo: /alfred. Existing repo: /alfred-dev:map-codebase and /alfred-dev:discuss.

Brownfield first: /map-codebase and /discuss. Greenfield: /alfred.

Install, update, and uninstall

CLI-FIRST
Install on macOS Copy
curl -fsSL https://raw.githubusercontent.com/686f6c61/alfred-dev/main/install.sh | bash

The command registers the global GitHub source in Claude Code and leaves Alfred Dev ready to install or update.

Update /alfred-dev:update Read release notes and decide from Claude Code.

FAQ

Does it work on Windows?

Yes. Alfred Dev has a native PowerShell installer for Windows 10/11. You can also use the bash installer through WSL (Windows Subsystem for Linux) or Git Bash. It requires a recent Claude Code CLI and Python 3.10+ on Windows too.

What dependencies does it need?

On macOS, Linux and Windows it needs a recent Claude Code CLI and Python 3.10+. On Windows, PowerShell 5.1+ comes pre-installed on Windows 10/11.

How do I update the plugin?

Run /alfred-dev:update inside Claude Code. The command queries GitHub, compares versions, detects the installed scope with claude plugin list --json, and shows release notes if a new version is available. User, local, project or unknown scopes use the idempotent installer, clean inherited local/project traces and normalize to a global user install; managed scope is left to the administrator.

What does Alfred do in an existing repository?

If the project already has code but does not yet have a persistent map, Alfred prioritises /alfred-dev:map-codebase. It analyzes the structure, detects the stack, entrypoints, risks and conventions, and leaves the context in docs/project/codebase-map.md and docs/project/current.md before opening feature, fix, spike or audit.

When should I use quick and when should I use feature?

/alfred-dev:quick is for small, local, bounded changes: two lightweight phases, tests for the touched area and quick security review. /alfred-dev:feature is for new functionality or changes that cross domains, need a PRD, architecture decisions or a full product-to-delivery cycle.

Can I pause and resume a session?

Yes. /alfred-dev:pause stores the current state in .claude/alfred-handoff.json and docs/project/handoff.md. Later you can come back with /alfred-dev:resume or simply ask for /alfred-dev:next. Alfred restores the workflow, current phase, pending gate and exact next step.

What is verify, and why does it exist if tests already run?

/alfred-dev:verify closes human validation for a deliverable. Automatic tests tell you whether the system works technically; verify records whether it actually meets the user's expectation in UAT. The state is tracked as pending, approved or rejected in .claude/alfred-uat.json and docs/project/uat.md.

What does progress show?

/alfred-dev:progress makes the project's operational state visible: active workflow or handoff, general progress, kanban, blockers, traceability and UAT state. It does not open new work or force a gate; it helps decide what should happen next based on real context.

Does GitHub become the project's source of truth?

No. /alfred-dev:sync-github runs SonIA Sync as a collaboration mirror for issues. The source of truth stays local: docs/project/, .claude/ and the project's SQLite memory.

What is Memory UI and when should I use it?

/alfred-dev:memory-ui opens a local browser view on top of the project's real SQLite memory. Use it when you want to quickly understand what happened, which decisions are recorded, which commits were captured, how continuity is going or whether memory is healthy, without reading the database by hand.

Do I have to configure Alfred manually the first time?

Not necessarily. On the first session Alfred can bootstrap .claude/alfred-dev.local.md with a baseline configuration that is already usable from CLI. Afterwards you can fine-tune autonomy, optional agents, memory and personality with /alfred-dev:config.

What is persistent memory?

It's a local SQLite database that stores each project's decisions, commits and iterations. Optionally activated from /alfred-dev:config. Once active, Alfred automatically records workflow events and the Librarian agent can answer historical queries like "why was this architecture chosen" or "what was done in the last iteration", always citing sources. Data stays within the project: everything is kept in .claude/alfred-memory.db.

If you already use Claude Code, install Alfred Dev and enter the flow with context, memory, and a full team.

Independent plugin for teams that want to move from isolated prompts to an operational flow with state, traceability, and gates.

Installation 
 
The command is copied automatically when the browser allows it. Otherwise use the Copy button.
 
   
 
 Uninstall Alfred Dev  
 
 
 
Two clear paths
 
If you only want to remove Alfred Dev from Claude Code, use the script for your system. If the installation was left half-done or you want to review every trace, use the manual path.
 
 
 
 
 
macOS / Linux
  
 
curl -fsSL https://raw.githubusercontent.com/686f6c61/alfred-dev/main/uninstall.sh | bash
 
It first tries native uninstallation with the Claude CLI and then cleans cache, marketplace, and residual records.
 
 
 
 
Windows
  
 
irm https://raw.githubusercontent.com/686f6c61/alfred-dev/main/uninstall.ps1 | iex
 
It performs the same full cleanup on Windows: plugin, marketplace, cache, and internal JSON files if they still keep traces.
 
 
 
 
 
Manual
 
 
 
 1. Try Claude Code native removal first 
 claude plugin uninstall alfred-dev@alfred-dev --scope user  
 claude plugin marketplace remove alfred-dev --scope user  
 
 
 2. If anything remains, review these paths 
     
  • ~/.claude/plugins/cache/alfred-dev/
  • ~/.claude/plugins/marketplaces/alfred-dev/
  • ~/.claude/plugins/known_marketplaces.json
  • ~/.claude/plugins/installed_plugins.json
  • ~/.claude/settings.json
    •  
 
 
 3. This is not deleted automatically 
     
  • .claude/alfred-dev.local.md
  • .claude/alfred-dev-state.json
    •  
 
If you want full cleanup for a specific project, delete those files manually inside each repo where you used Alfred Dev.
 
 
 
 
After uninstalling, run /reload-plugins; if Alfred is still visible, restart Claude Code.
 
 
   
 
 Full changelog  
 
 
 
 
v0.6.1
 2026-06-22 
  
 Changed 
     
  • More resilient installers: Bash and PowerShell clear stale local Claude Code marketplace checkouts before reinstalling.
  • Normalized global updates: the flow re-registers the GitHub source, refreshes the alfred-dev marketplace, and keeps the plugin installed at user scope.
    •  
 
 
 Fixed 
     
  • Fixes the case where Claude Code reported Successfully installed plugin: alfred-dev@alfred-dev while the installed cache still resolved to an older version such as 0.5.2.
  • The /alfred alias is materialized again from the correct plugin root after updating from old versions or inherited local caches.
    •  
 
 
 
 
v0.6.0
 2026-06-19 
  
 Changed 
     
  • Agents loaded from the root: the 9 optional agents move into agents/ so Claude Code can discover all 19 plugin agents.
  • MCP compatible with the current CLI: alfred-memory is declared in .mcp.json with a portable launcher that uses CLAUDE_PLUGIN_ROOT when installed and cwd during local development.
  • Updated terminology: commands, agents, and operational docs replace obsolete Task references with Agent.
  • Human UI name: plugin.json and marketplace.json declare displayName: "Alfred Dev" so Claude Code shows Alfred Dev (alfred-dev) without changing the technical namespace.
  • 0.6.0 stabilization release: plugin.json is the canonical version source and the marketplace does not duplicate version.
  • The memory MCP server speaks modern JSONL stdio and still reads legacy Content-Length framing.
    •  
 
 
 Fixed 
     
  • Claude Code can now show the 19 agents in the plugin inventory.
  • Claude Code counts alfred-memory in the plugin inventory again.
  • claude mcp get plugin:alfred-dev:alfred-memory now connects to the real server.
    •  
 
 
 
 
v0.5.2
 2026-04-11 
 
 Added 
     
  • Full skills catalog published: plugin.json stops enumerating a partial sample and now exposes all 15 domains under skills/.
  • Stricter public surface contracts: the suite now validates the published catalog, canonical frontmatter, manual-only skills, and the absence of collisions with commands.
  • Selina gets a real guided flow: base system first, then typography and palette, and only then three comparable final proposals inside that family.
    •  
 
 
 Changed 
     
  • Heavier skills or those with clear side effects remain published, but are forced to manual activation with disable-model-invocation: true.
  • Help and public docs now group commands by actual value: core, advanced operations, and views/aliases.
  • Selina’s final proposals now respect the selected visual system instead of recolouring the same generic layout shell.
  • The landing no longer frames the catalog as an internal/partial sample and now reflects the 62 published skills in the release.
  • Version alignment to 0.5.2 across plugin, marketplace, installers, packages, docs, changelog, and landing.
    •  
 
 
 Fixed 
     
  • style-direction now declares canonical frontmatter instead of relying on implicit inference.
  • The public skill surface no longer depends on partial lists that drift from the real repository.
  • Selina’s visual companion still records the user choice when the local WebSocket handshake fails and the HTTP fallback has to take over.
    •  
 
 
 
 
v0.5.1
 2026-04-10 
 
 Added 
     
  • Canonical Selina catalog with 10 base design systems: core/selina_style_catalog.py gathers the free/contextual mode plus nine trend-led families so the visual phase starts from an explicit vocabulary.
  • Visual demo gallery: core/selina_style_demo.py and visual/scripts/write-style-demo-gallery.py generate a browsable catalog before the three final proposals are locked.
  • Palettes and type pairings per family: each design system declares colour modes, typography pairings and links to references or Google Fonts.
    •  
 
 
 Changed 
     
  • Selina is no longer framed as “three isolated styles”: it now works from 10 base design systems and narrows them down to three comparable proposals based on the PRD, audience, and stack.
  • Version aligned to 0.5.1 across plugin, marketplace, installers, packages, Memory MCP, session report, README, changelog, docs and landing.
  • The landing explains more faithfully how Selina enters the flow and what it really means to close a design system before touching frontend code.
    •  
 
 
 Fixed 
     
  • Update surface without drift: internal fallback points that still returned an older release now reflect the current version.
  • Release tests are less brittle: the suite no longer depends on thin Astro wrappers or hardcoded version paths when the manifest is the real source of truth.
    •  
 
 
 
 
v0.5.0
 2026-03-31 
 
 Added 
     
  • Lucius — The Technical Director: new optional agent that acts as an external technical second opinion. It invokes codex exec with an explicit read-only sandbox, uses the configured Codex CLI model and returns diagnosis + prescription per item.
  • /alfred-dev:lucius command: entry point for the audit. It accepts an optional target directory and scope (all, security, tests, architecture, performance).
  • Structured report per item: Lucius returns diagnosis + prescription + effort (S/M/L) + suggested implementer (Alfred or Codex) in four sections: Critical, Relevant, Opportunities and What's working well.
  • Prerequisite preflight: checks that codex is on the PATH and authenticated. If something is missing, it stops with clear install instructions.
  • Hard gate with no modifications: Lucius compares Git status before and after running Codex CLI in --sandbox read-only; if it detects differences, it reports them instead of hiding the problem.
  • Selina — The Stylist: new core agent (10th) that occupies phase 1b of the feature workflow and presents three style directions before component design starts.
  • Local visual server: zero-dependency HTTP + WebSocket server in visual/scripts/server.cjs with hot reload, per-project sessions and graceful shutdown.
  • Visual style skill: skills/estilo/style-direction/SKILL.md guides Selina to start the server, propose options, capture the selection and generate docs/style-direction.md.
  • Conditional visual_style phase: the orchestrator only enables it when config_loader.has_frontend(stack) detects a public UI.
  • _advance_skipping_phases helper: extracted orchestrator function that skips phases whose condition is not met and reduces cognitive complexity.
    •  
 
 
 Changed 
     
  • 19 agents total: the plugin moves from 18 to 19 agents (10 core + 9 optional) with Lucius included.
  • 26 commands: /alfred-dev:lucius joins the manifest and the public surface of the plugin.
  • Version aligned to 0.5.0 across plugin, marketplace, installers, packages, README, changelog, docs and landing.
  • Landing updated: Lucius card appears before Selina with a “New” badge, optional-agent use cases and counters updated to 19 agents and 26 commands.
    •  
 
 
 Fixed 
     
  • Native module imports in server.cjs: mandatory node: prefix (node:http, node:crypto, node:fs, node:path).
  • Number.parseInt instead of parseInt in server.cjs (SonarQube linting rule).
  • Reduced cognitive complexity of handleRequest: the /files/* block was extracted into serveStaticFile().
  • catch block without unused variable: catch (e) becomes catch {} in serveStaticFile.
  • Cognitive complexity in config_loader.py: _count_source_files and suggest_optional_agents were simplified by extracting reusable helpers.
  • SonarQube skill registered in plugin.json: the file existed but was missing from the plugin manifest.
  • Docker execution in subagents: scoped Bash(docker ...) entries let security-officer run the SonarQube workflow after /audit confirms Docker is operational or the user authorizes preparing it.
    •  
 
 
 
 
v0.4.7
 2026-03-31 
  
 Changed 
     
  • Hook JSON generation moves from bash heredoc interpolation to direct stdin emission via json.dumps, eliminating the entire error class.
  • Version aligned to 0.4.7 across plugin, marketplace, installers, packages, structured metadata, README, changelog, docs and landing.
    •  
 
 
 Fixed 
     
  • SessionStart hook fixed: the session context JSON output no longer truncates when content exceeds kernel ARG_MAX or contains special characters.
    •  
 
 
 
 
v0.4.6
 2026-03-23 
 
 Added 
     
  • New local Memory UI: /alfred-dev:memory-ui opens overview, timeline, decisions, commits, search and health directly on top of the project SQLite.
  • Memory UI now starts with useful data: map-codebase, discuss and quick seed progress, traceability, kanban and lightweight iterations naturally.
  • The UI imports recent Git commits when memory still has no linked commits and explains empty states better in temporary or non-repo workspaces.
  • Expanded E2E coverage for Memory UI, helper-first seeding and local server rendering.
    •  
 
 
 Changed 
     
  • Alfred now exposes 25 visible commands and adds memory-ui as a first-class public surface in the website, README, help and session-start.
  • This release removes internal planning docs from the published repo and aligns homepage, metadata and operational docs for 0.4.6.
    •  
 
  
 
 
v0.4.5
 2026-03-22 
 
 Added 
     
  • New PM layer for SonIA: /alfred-dev:standup, /alfred-dev:blocked, /alfred-dev:in-progress, /alfred-dev:validate and /alfred-dev:search.
  • SonIA Sync for GitHub through /alfred-dev:sync-github, while keeping docs/project and SQLite as the source of truth.
  • Expanded E2E coverage for PM helpers, board parsing and issue synchronization.
    •  
 
 
 Changed 
     
  • Alfred now exposes 24 commands and 13 visible hooks: continuity, operational PM, persistent memory and multi-agent workflows in one interface.
  • The website, README and docs now reflect SonIA as a CLI operational layer and the new GitHub collaboration surface.
    •  
 
  
 
 
v0.4.4
 2026-03-22 
 
 Added 
     
  • Operational continuity layer: new commands /alfred-dev:map-codebase, /alfred-dev:next, /alfred-dev:pause, /alfred-dev:resume, /alfred-dev:verify and /alfred-dev:progress.
  • New /alfred-dev:discuss command to refine ideas before building, with discovery.md and current.md artifacts.
  • New /alfred-dev:quick 2-phase workflow for small changes with tests and security review.
  • Shared memory configuration parser and new coverage for event FTS, purge + health, Git import with "|" and sync beyond 1000 decisions.
    •  
 
 
 Changed 
     
  • /alfred becomes a contextual router: it decides whether continuity, brownfield mapping, refinement or a multi-agent workflow should happen next.
  • SessionStart bootstraps local configuration and recommends the next step from the very first session.
  • The website now reflects the current model: 6 execution workflows, 18 commands and a visible operational layer.
  • Persistent memory stops producing false negatives: content-bearing events are searchable, purge cleans FTS, retention_days is read from project config and size_bytes includes WAL.
    •  
 
  
 
 
v0.4.2
 2026-03-14 
 
 Added 
     
  • Go test support in evidence guard: go test output is correctly detected as success.
  • Partial session reports: the stop-hook generates a report when a session is interrupted, not only when completed.
  • Autopilot mode and iterations in reports: reports show whether the session was autopilot and how many retries each phase had.
  • Evidence verification in markdown: explicit instruction to read alfred-evidence.json before advancing automatic gates.
  • Iterative loop documented in feature, fix and ship commands (max 5 retries per phase).
    •  
 
 
 Changed 
     
  • Stop-hook refactored into testable functions: should_block, build_block_message, handle_session_report.
  • Block message adapted for autopilot: does not ask for user confirmation but instructs to investigate the error.
  • Dynamic version in reports: template reads version from plugin.json.
  • Evidence cleanup between sessions to avoid cross-contamination.
    •  
 
 
 Fixed 
     
  • False positive in evidence guard: the failure detection pattern matched "0 failures" as a failure. Fixed to exclude zero.
  • Architecture gate mistyped: the architecture phase had gate "user" instead of "user+security", making security validation inoperative.
  • Divergent patterns: quality-gate.py had its own patterns that diverged from evidence_guard_lib.py. Unified to use a single source of truth.
  • Inconsistent autopilot key: commands looked for "mode: autopilot" but code wrote "autopilot: true". Fixed.
    •  
 
 
 
 
v0.4.1
 2026-03-13 
 
 Added 
     
  • Automatic initial setup: when using Alfred for the first time in a project, it asks whether you want interactive or autopilot mode. No manual steps required.
    •  
 
  
 Fixed 
     
  • Autopilot mode disconnected from actual flow: autopilot detection was not reaching the composition. Fixed so user gates are auto-approved when mode is autopilot.
    •  
 
 
 
 
v0.4.0
 2026-03-13 
 
 Added 
     
  • Evidence verification (evidence guard): hook that records each test execution as verifiable evidence. When an agent claims tests pass, the system checks they were actually run.
  • Session report on close: automatic summary in docs/alfred-reports/ with phases, test evidence, team and artifacts.
  • Iterative loop within phases: agents iterate up to 5 times within a phase until the gate is passed, enabling natural TDD cycles.
  • Autopilot mode: full execution without human interruption. User gates are auto-approved; automatic and security gates are evaluated normally.
    •  
 
 
 Changed 
     
  • 17 agent personalities rewritten with Alfred Pennyworth tone: impeccable service, subtle irony, technical precision.
  • Orchestrator extended with iterative loop functions (should_retry_phase, reset_phase_iterations) and autopilot (is_autopilot_gate_passable, run_flow_autopilot).
  • Stop-hook automatically generates session report when closing a completed session.
    •  
 
  
 
 
v0.3.9
 2026-03-13 
 
 Added 
     
  • Optional i18n-specialist agent for multilingual projects: automatic detection of i18n signals (i18n/, locales/, translations/ directories), integration in development and quality phases.
  • Automatic i18n detection in suggest_optional_agents(): analyzes i18n directories and configuration files in the project.
    •  
 
 
 Changed 
     
  • Optional agent selection redesigned: 2 multiSelect questions grouped by theme (technical + content/UX) instead of a long list, compatible with AskUserQuestion 4-option limit.
  • Product Owner reformulated: product phase questions are asked one at a time (one per turn) instead of in bulk, following the progressive refinement pattern from superpowers:brainstorming.
  • 8 optional agents (previously 7): added i18n-specialist to catalog, config, orchestrator, documentation, and tests.
    •  
 
  
 
 
v0.3.8
 2026-03-13 
 
 Added 
     
  • SQLite to native memory sync layer: decisions, iterations, and commits stored in alfred-memory.db are automatically projected as .md files in ~/.claude/projects//memory/ using native Claude Code format.
  • Hybrid synchronization: full regeneration on session start + incremental updates after each SQLite write.
  • Safe MEMORY.md management with delimited markers that preserve user manual content.
  • Automatic memory directory creation when Alfred loads for the first time.
  • New E2E testing skill (calidad/e2e-testing) for setting up Playwright or Cypress.
    •  
 
 
 Changed 
     
  • 60 skills reviewed and improved: enriched descriptions for better triggering, "What NOT to do" section in 51 skills, persistent memory integration in 10 skills, detect_stack reference in 9 skills.
  • 3 standalone protocols (incident-response, dependency-strategy, release-planning) reorganized into their logical categories (calidad/, seguridad/, devops/).
  • Overlaps between skills explicitly documented. Normative versions (GDPR, NIS2, CRA, OWASP, WCAG) added.
    •  
 
  
 
 
v0.3.7
 2026-03-12 
 
 Added 
     
  • SonIA -- Project Manager -- new transversal core agent. Decomposes the PRD into tasks, manages a kanban board in docs/project/kanban/ with 4 MD files (backlog, in-progress, done, blocked), maintains the traceability matrix (criterion -- task -- test -- doc) and generates progress reports per phase.
  • The Interpreter -- i18n Specialist -- new optional agent for internationalisation. i18n key audit, hardcoded string detection, per-locale format validation, skeleton generation for new languages. HARD-GATE: key completeness (N in base = N in all languages).
  • QA Engineer expanded -- new integration and E2E testing section with strategies for Playwright/Cypress, decision table for test types (unit, integration, E2E, regression) and selection criteria.
    •  
 
 
 Changed 
     
  • The Scribe (formerly The Translator) -- tech-writer rewritten as a core agent with dual activation: phase 3b (inline code documentation: headers, docstrings, context comments) and phase 5 (project documentation: API, architecture with Mermaid diagrams, guides, changelogs). Strict style guide: Castilian Spanish without Latinisms, anglicisms allowed, no emojis.
  • HARD-GATEs on 5 optional agents -- data-engineer (migration integrity), ux-reviewer (WCAG 2.1 level A), performance-engineer (performance thresholds), seo-specialist (minimum indexing requirements), github-manager (destructive operations require confirmation).
  • Team expanded to 17 agents -- 9 core (previously 8) + 8 optional (previously 7). All counts updated across web, README and manifest.
  • Agent colours unified -- QA Engineer from red to amber (conflict with security-officer), performance-engineer and copywriter aligned between frontmatter and agent body.
  • Persistent memory improved -- SQLite module optimisations, more efficient queries and better database management between sessions.
  • Capture hooks unified -- memory-capture.py and commit-capture.py merged into activity-capture.py, a single hook with internal dispatch by event type. From 11 to 10 hooks.
  • All agents reviewed -- frontmatter inconsistencies fixed, descriptions aligned with actual capabilities, personalities refined and integration chains updated.
    •  
 
  
 
 
v0.3.6
 2026-03-10 
   
 Fixed 
     
  • Core agents registered -- the core agents were missing from the plugin manifest, so Claude Code could not load their system prompts. All 15 agents (8 core + 7 optional) are now registered and operational.
  • Librarian MCP tools -- the librarian agent referenced 5 MCP tools with incorrect names. Fixed to match the real server tool names.
  • Empty dashboard on first session -- the data pipeline failed in cascade: config without memory, commits without iteration and empty queries. Fixed with auto-config creation, automatic iteration and global fallback.
  • Port conflict -- if another project was using the dashboard ports, it now detects the conflict and finds alternatives automatically.
    •  
 
 
 
 
v0.3.5
 2026-03-10 
  
 Changed 
     
  • SonarQube moved to security-officer -- the SonarQube analysis is now run by the security-officer instead of the qa-engineer during /alfred-dev:audit. When Docker is operational or authorized, it runs the scanner and integrates findings into its security report.
  • Imperative instructions -- the subagent receives explicit, sequential steps (read the skill, execute all 7 steps, integrate results) instead of a textual reference that could be ignored.
    •  
 
  
 
 
v0.3.4
 2026-03-03 
   
 Fixed 
     
  • Command nomenclature -- all web commands updated from /alfred X to /alfred-dev:X to reflect the actual Claude Code convention.
  • Stats corrected -- skills from 56 to 59, commands from 10 to 11, hooks from 7 to 11. Aligned with actual implementation.
  • Command /alfred-dev:gui visible -- added to the public commands table in both languages.
  • SonarQube integrated in audit -- the security-officer runs the SonarQube skill after the audit preflight confirms Docker is operational or the user authorizes preparing it.
  • Dashboard port file -- session-start.sh creates .claude/alfred-gui-port and verifies real server connection instead of relying on kill -0.
  • Optional agent colours -- the 5 agents without colour in their frontmatter now have assigned colours for the dashboard.
    •  
 
 
 
 
v0.3.3
 2026-02-24 
   
 Fixed 
     
  • SQLite initialization at startup -- the memory database is automatically created on each session if it does not exist. Removes the circular dependency that prevented the GUI server from starting on the first session.
  • GUI server always operational -- the dashboard starts from minute 1. The WebSocket is immediately available for the client.
  • Agents served via WebSocket -- the 15-agent catalogue is sent from the server in the init message, removing the hardcoded list from the dashboard.
  • Hooks resilient to updates -- test -f guards on all hooks for graceful degradation when the plugin directory has changed.
    •  
 
 
 
 
v0.3.2
 2026-02-23 
 
 Added 
     
  • Dynamic team composition -- 4-layer system (heuristic, reasoning, presentation, execution) that suggests optional agents based on the task description. The selection is ephemeral and does not modify persistent configuration.
  • run_flow() function -- entry point for flows with ephemeral session team. Validates structure, injects team and records error diagnostics.
  • TASK_KEYWORDS table -- map of 8 optional agents with contextual keywords and base weights for dynamic composition.
    •  
 
 
 Changed 
     
  • _KNOWN_OPTIONAL_AGENTS derived from TASK_KEYWORDS (single source of truth). 6 command skills updated. 326 tests.
    •  
 
 
 Fixed 
     
  • Whole-word matching -- match_task_keywords() uses word boundaries instead of substrings, eliminating false positives for short keywords.
  • Validation feedback -- the reason for team rejection is recorded in the session for downstream diagnostics.
  • Truncation warning -- task descriptions longer than 10,000 characters emit a warning instead of being silently truncated.
    •  
 
 
 
 
v0.3.1
 2026-02-23 
 
 Added 
     
  • Mobile support -- hamburger menu with sliding sidebar for narrow screens.
  • HTTP security headers -- X-Content-Type-Options, Cache-Control and Content-Security-Policy.
  • Dynamic injection -- version and WebSocket port injected from the server, no hardcoded values.
  • Pinned SVG icon -- replaced [*] with pin icon in timeline and decisions.
  • SEO audit -- canonical, og:image, FAQPage schema, hreflang, image dimensions (CLS).
    •  
 
  
 Fixed 
     
  • Robust WebSocket frame reading -- rewritten with readexactly() to eliminate disconnections from TCP fragmentation.
  • Cross-thread SQLite connection -- added check_same_thread=False to avoid errors in Python 3.12+.
  • get_full_state() consistency -- all queries use the same polling connection.
  • Pinned items polling -- pinned elements now propagate in real time.
  • Timestamp format -- automatic detection of epoch (s/ms) and ISO strings without timezone.
  • GUI action type validation -- explicit casts to prevent type injection.
  • WebSocket handshake buffer -- expanded to 8192 bytes.
  • WebSocket writer cleanup -- explicit socket close on server stop.
    •  
 
 
 
 
v0.3.0
 2026-02-22 
 
 Added 
     
  • Dashboard GUI (Alpha Phase) -- real-time web dashboard with 7 views: status, timeline, decisions, agents, memory, commits and pinned items. Launched with /alfred-dev:gui.
  • Monolithic Python server -- HTTP + manual WebSocket RFC 6455 + SQLite watcher. No external dependencies.
  • Bidirectional WebSocket protocol -- init, update, action and action_ack messages. Reconnection with exponential backoff.
  • Pinning system -- pinned items survive context compaction.
  • New SQLite tables -- gui_actions and pinned_items. Automatic migration to schema v3.
  • Automatic startup -- GUI server starts with each session and stops on close.
  • Fail-open principle: if the GUI fails, Alfred works the same. 297 tests.
    •  
 
 
 Changed 
     
  • README and documentation expanded with dashboard screenshots and WebSocket protocol guide.
    •  
 
  
 
 
v0.2.3
 2026-02-21 
 
 Added 
     
  • Persistent memory v2 -- schema migration, tags, status and relationships between decisions.
  • 5 new MCP tools -- total 15: update, link, health, export, import.
  • Search filters -- since, until, tags, status parameters.
  • Export/Import -- decisions to Markdown (ADR), import from Git and ADRs.
  • activity-capture.py hook -- unified capture hook (workflow events + commits).
  • memory-compact.py hook -- protects decisions during compaction.
  • Context injection by active iteration. ~268 tests.
    •  
 
 
 Changed 
     
  • The Librarian expanded: decision lifecycle, integrity, export/import.
    •  
 
  
 
 
v0.2.2
 2026-02-21 
 
 Added 
     
  • dangerous-command-guard.py hook -- blocks rm -rf /, force push, DROP DATABASE, fork bombs and more.
  • sensitive-read-guard.py hook -- warning when reading private keys, .env, credentials.
  • 4 new MCP tools -- total 10: stats, iterations, abandon.
  • 3 new skills -- incident-response, release-planning, dependency-strategy.
  • /alfred-dev:feature allows selecting start phase.
  • Version consistency test. 219 total tests.
    •  
 
  
 Fixed 
     
  • quality-gate.py -- position anchor for runners, re.IGNORECASE on failures.
  • MCP responses with isError: true for errors.
  • 8 technical debt issues: logging, encapsulation, recovery.
    •  
 
 
 
 
v0.2.1
 2026-02-21 
   
 Fixed 
     
  • Windows cache path -- install.ps1 and uninstall.ps1 aligned with Claude Code convention.
  • activity-capture.py -- diagnostics in silent except blocks.
  • session-start.sh -- specific catches instead of generic Exception.
    •  
 
 
 
 
v0.2.0
 2026-02-20 
 
 Added 
     
  • Persistent memory -- local SQLite per project with decisions, commits, iterations and events.
  • MCP server -- 6 stdio tools: search, record, query.
  • The Librarian -- optional agent for historical queries.
  • activity-capture.py hook -- automatic workflow event capture.
  • FTS5 search, secret sanitisation, 0600 permissions.
  • 114 tests (58 new for memory).
    •  
 
   
 
 
v0.1.5
 2026-02-20 
   
 Fixed 
     
  • Secret-guard fail-closed -- blocks when it cannot determine the target path.
  • Idempotent installer in clean environment (mkdir -p).
  • More reliable version detection in /alfred-dev:update.
    •  
 
 
 
 
v0.1.4
 2026-02-19 
 
 Added 
     
  • 6 optional agents -- data-engineer, ux-reviewer, performance, github, seo, copywriter.
  • 27 new skills across 6 domains. Total: 56 skills in 13 domains.
  • Windows support -- native install.ps1 and uninstall.ps1.
  • spelling-guard.py hook -- missing accents in Spanish.
  • Quality gates expanded: 8 to 18.
    •  
 
   
 
 
v0.1.2
 2026-02-18 
  
 Changed 
     
  • New personality -- friendly colleague with humour, all 8 agents with their own voice.
  • Full spelling correction across 68 files (RAE).
    •  
 
 
 Fixed 
     
  • Correct command prefix, robust update, explicit registration of all 10 commands.
    •  
 
 
 
 
v0.1.1
 2026-02-18 
   
 Fixed 
     
  • session-start.sh -- syntax error preventing context injection.
  • secret-guard.sh -- fail-closed policy restored.
  • stop-hook.py -- type validation for corrupt state.
    •  
 
 
 
 
v0.1.0
 2026-02-18 
 
 Added 
     
  • First public release.
  • 8 specialised agents, 5 workflows, 29 skills, 5 hooks.
  • Quality gates, GDPR/NIS2/CRA compliance, stack detection.
    •  
 
   
 
 
   
 
 
 Alfred Dev Origin 
  
 
  
 
 
What we wanted to build
 
We did not want another pretty prompt or a collection of characters performing theatre. We wanted a system that genuinely helps a developer: something that organizes work, detects what matters, keeps continuity between sessions, and pushes toward serious execution.
 
 
Why it is called Alfred
 
The name comes from Alfred Pennyworth, Batman’s figure who was always where he was needed. He was not the visible protagonist, but he was the one sustaining the operation with judgment, calm, and reliability. Resolute, precise, elegant in execution, and capable of saying things with dry irony when needed without losing professionalism.
 
 
What we wanted to bring from that reference
 
What mattered was that difficult mix: an assistant with personality but no theatrics; with style but no frivolity; with judgment of its own but in service of the work. Alfred Dev tries to capture exactly that: help you make better decisions, anticipate problems, and keep the bar high without turning the tool into a show.
 
 
How that becomes a plugin
 
That is why Alfred orchestrates agents, memory, quality gates, traceability, and continuity instead of merely answering prompts. The product ambition is simple to explain and difficult to execute: as a developer, you should feel that you finally have a serious, reliable assistant with real craft.
 
 
 
 
   
 
 
 Plugin technical vision System map 
  
 
  
 
 
What this project is
 
It turns AI-assisted development into a process governed by sequential phases, specialized agents, and control points that cannot be skipped without evidence.
 
     
  • Works with 19 specialized agents and tightly bounded responsibilities.
  • Automates six main workflows: feature, fix, spike, ship, audit, and quick.
  • Detects the repo technology stack and adapts artifacts, testing, and optional agents.
    •  
 
 
Operational summary for reconstruction
 
The visible surface is 26 command files and an agent catalog, but the real system lives behind that: Python core, lifecycle hooks, SQLite memory, and an orchestrator that never delegates state to anyone else.
 
     
  • 10 core agents stay outside plugin.json and enter only through orchestrated flow.
  • 9 optional agents can be configured and activated according to stack or task.
  • Quality gates are hard: evidence-guard and quality-gate stop progress if real proof is missing.
  • Each phase can retry up to 5 times before escalation to the user.
    •  
 
 
Technology stack
 
The project operates over separated but coordinated ecosystems: Python for orchestration and memory, Astro for public documentation, and native Node.js for Selina visual server.
 
     
  • The core uses Python 3.10+ for orchestrator, config_loader, memory, continuity, and hooks.
  • The public website lives in static Astro with TypeScript and sitemap.
  • Selina uses native Node.js modules: http, crypto, fs, and path, with no external dependencies.
  • Development relies on pytest for Python and astro check for the website.
    •  
 
 
Layered architecture
 
Commands, agents, core, hooks, MCP, and visual server are separated. Commands do not call agents directly: they activate the orchestrator, and Alfred decides what enters and in what order.
 
     
  • Visible commands -> orchestrator.py -> agents and phases.
  • Hooks intercept SessionStart, PreToolUse, PostToolUse, and Stop.
  • memory_server exposes MCP tools to query memory from any agent.
  • Agents do not talk to each other; everything goes through Alfred and session state.
    •  
 
 
Persistence and database
 
Persistent memory lives in .claude/alfred-memory.db. It is designed to be local, portable, and safe, not dependent on remote services or additional infrastructure.
 
     
  • Local SQLite with WAL mode and FTS5 search.
  • Persistence of decisions, commits, iterations, and events.
  • 0600 permissions and sanitization with 14 regex patterns for secrets.
  • Automatic schema migration and configurable purge with retention_days.
    •  
 
 
Business logic and quality gates
 
The system solves a very concrete problem: stopping AI-driven development from skipping critical phases and closing work without enough security, QA, documentation, or evidence.
 
     
  • Without recorded evidence, a claim like “tests pass” does not count.
  • Security Officer appears transversally in architecture, quality, and delivery.
  • Selina visual phase activates only when the stack has frontend surface.
  • User gates and automatic gates stay separated; autopilot never skips security or evidence.
    •  
 
 
Runtime and auxiliary components
 
Beyond the core, the system adds operational pieces that make the flow usable day to day: continuity, inspectable memory, optional GitHub sync, and a visual server with timeout.
 
     
  • Continuity keeps next, pause, resume, and handoff without losing phase.
  • Memory UI opens timeline, decisions, commits, and health over local SQLite.
  • GitHub Sync mirrors local state to issues when shared tracking is useful.
  • Selina visual server uses a 30-minute timeout and checks the parent process every 60 seconds.
    •  
 
 
Boot and reconstruction
 
You do not need complex infrastructure to rebuild or boot it, but you do need to respect the rules that make the system reliable.
 
     
  • Claude Code, Python 3.10+, and Node.js must be available in the environment.
  • SQLite memory is created automatically when memory is enabled in /alfred-dev:config.
  • map-codebase, discuss, and quick generate useful context so memory does not start empty.
  • The most expensive mistake would be breaking agent isolation or allowing another layer to replace the orchestrator as the source of truth.
    •  
 
 
 
 
   
 
 
 /alfred-dev:command Operational 
  
 
  
 
 
Core agents involved
 
 
 
 
Optional agents that may join
 
 
 
 
Active layers
 
 
 
 
What it really does
 
     
     
     
     
           
     
     
     Agent Core 
      
     
      
     
     
    How it enters the flow
     
       
       
       
      What it does
       
         
         
         
        What it doesn't do
         
           
           
           
           
                       
           
           
           Auxiliary layer Runtime 
            
           
           
           
           
          What it adds