DOCSEARCHbyAlgolia
Submit Docs

Compound Engineering Plugin

repository·main·Indexed 28 days ago

https://github.com/everyinc/compound-engineering-plugin

Official Compound Engineering skills plugin for coding agents. An AI engineering productivity suite that uses a 'compounding' methodology to automate workflows through a structured core loop: ideate, brainstorm, plan, work, and compound. Includes 32 specialized skills for autonomous engineering (/lfg), Git workflow management, debugging, code review, and knowledge reuse via automated documentation.

Tokens
566.3K
Snippets
358
Records
2K
Agent score
96%

What's inside compound-engineering

  1. Understand the Persona-Based Review Pipeline

    main

    The document-review skill has been replaced with a multi-persona review pipeline. Instead of a single evaluator, the system now dispatches specialized reviewer agents in parallel to provide richer, role-specific feedback on plans and requirements documents.

    Reviewer Personas

    Always-on Personas (Run on every review):

    • coherence
    • feasibility

    Conditional Personas (Activated based on document content analysis):

    • product-lens: Uses the Premise challenge pattern to question if the problem is being framed correctly and evaluates implementation alternatives.
    • design-lens: Uses the Dimensional rating pattern (0-10 rating loop) to evaluate information architecture, user journeys, and AI slop risk.
    • security-lens: Focuses on security-specific concerns.
    • scope-guardian: Uses the Existing-code audit pattern to check for code duplication, complexity, and completeness.

    Execution Model

    1. Parallel Dispatch: Specialized agents analyze the document simultaneously (read-only).
    2. Synthesis & Dedup: Findings are normalized and deduplicated using fingerprinting (normalize(section) + normalize(title)). Findings with confidence below 0.50 are treated as residual concerns and may be promoted if corroborated by other personas.
    3. Hybrid Action Model:
      • Auto-fixes: Quality issues are automatically corrected in a single pass after synthesis.
      • Strategic Questions: High-level strategic or conflicting concerns are presented to the user for decision-making.

  2. Understand the `ce:ideate` v2 mode-aware capabilities

    main

    The ce:ideate skill (v2) is designed for two distinct modes of operation, allowing users to switch between repository-grounded engineering tasks and general ideation:

    1. Repo Mode: Optimized for the current repository. It performs a mandatory codebase scan, weights ideas based on "groundedness in current repo," and defaults persistence to the docs/ideation/ directory.
    2. Elsewhere Mode: Designed for non-repository use cases such as greenfield product ideation, business model exploration, UX/naming/narrative work, or personal decisions. In this mode, the skill uses external context via a web-researcher agent and defaults persistence to Proof instead of the local file system.

    Regardless of the mode, the core mechanism remains: Generate many ideas $\rightarrow$ Adversarial critique $\rightarrow$ Present survivors with reasons.

  3. Understand the new Config and Storage model

    main

    The Compound Engineering plugin is transitioning from a repo-local configuration model to a two-scope state model to ensure compatibility with git worktrees and improve durability.

    Storage Scopes

    • repo_state_dir: Used for repo-local CE configuration (YAML-based). This replaces the legacy compound-engineering.local.md format.
    • user_state_dir: Used for user-level CE state and per-project durable storage.
    • Per-Project Path: Durable project data is stored at <user_state_dir>/projects/<project-slug>/. The <project-slug> is derived from the repository name and a hash of the git common directory to ensure that different git worktrees of the same repository map to the same CE project state.

    Migration and Maintenance

    • /ce-setup: This is the only skill authorized to write migration state and reconcile legacy configurations into the new format.
    • /ce-doctor: Use this skill to diagnose your current configuration and storage health. It identifies if you have legacy/conflicting configs or stale compatibility contracts.
    • Legacy Support: The system maintains dual-read compatibility for todos during the migration period, but future writes for durable state will move to the user_state_dir.

  4. Understand the Slack Analyst Agent (ce-slack-researcher)

    main

    The ce-slack-researcher is a research-category agent designed to surface organizational knowledge from Slack during compound-engineering workflows. It acts as an analytical sub-agent that searches for context relevant to a task and returns a structured digest.

    Key Characteristics

    • Role: Analytical research only. It does not send messages, create canvases, or perform any write actions in Slack.
    • Placement: Located at agents/research/ce-slack-researcher.md.
    • Integration: It is dispatched programmatically by ce-ideate, ce-plan, and ce-brainstorm during their respective research/context-gathering phases.
    • Dependency: It relies on the official Slack MCP server being connected and authenticated. It does not require the Slack plugin to be bundled with compound-engineering.

    Search & Output Behavior

    • Search Strategy: Performs 2-3 targeted searches using slack_search_public_and_private based on task keywords. It searches both public and private channels by default.
    • Thread Reading: Only reads threads (slack_read_thread) for high-relevance hits, capped at ~3-5 reads to manage token usage.
    • Channel Hints: If a caller provides a specific channel hint, the agent will also read recent history from that channel using slack_read_channel.
    • Output Format: Returns a concise summary (target 200-500 tokens) organized by topic/theme, including the topic, a brief summary, source attribution (channel, date, participants), and relevance to the task. If no context is found, it returns an explicit "No relevant Slack discussions found" message.

  5. Understand the Shared Repo-Grounding Profile Cache

    main

    The Shared Repo-Grounding Profile Cache is an optimization designed to prevent redundant re-derivation of project-wide information across different engineering skills.

    Key Concept: The cache stores a question-agnostic 'project profile' (e.g., tech stack, dependencies, topology, and root instruction files). While the profile is cached, every skill still performs its own question-specific grounding (e.g., scanning specific code patterns, issues, or recent git history) fresh on every run to ensure correctness.

    Note: This specific implementation was retired in favor of lean task-specific grounding. Refer to docs/solutions/skill-design/cross-skill-shared-cache-primitive.md for the current recommended approach.

  6. Understand the ce-pov Cross-Model Panel feature

    main

    The ce-pov (Cross-Model Panel) feature allows an AI agent to consult multiple independent model perspectives to reach a decisive, project-grounded Point of View (POV). It is designed to reduce bias and increase confidence in engineering decisions by facilitating a structured 'debate' between different models.

    Key Capabilities:

    • Multi-Model Consultation: Can summon specific peers by name or use the oracle command to trigger an automated selection of up to two peers.
    • Structured Debate: If peers disagree, ce-pov initiates a bounded debate where peers receive the same evidence delta and must signal whether they have moved (changed their stance) or held (maintained their stance).
    • Stalemate Handling: In the event of a genuine stalemate, the system provides an honest recommendation or a tradeoff analysis rather than forcing a false consensus.
    • Read-Only Sandboxing: Peers are dispatched as detached, read-only jobs. They operate within a normalized, repository-relative workspace root and cannot perform mutating commands or inspect files outside the allowed scope.

  7. Understand the ce-pov skill purpose and differentiation

    main

    The ce-pov skill provides a decisive, project-grounded verdict on external inputs (e.g., "Should we adopt framework X?", "Does this CVE affect us?"). Unlike generic web research which explains a topic, ce-pov judges an input specifically for your project's context.

    Key Differentiators:

    • vs. ce-ideate: ce-ideate generates options; ce-pov evaluates a specific input.
    • vs. ce-brainstorm: ce-brainstorm scopes a chosen idea; ce-pov decides whether to proceed.
    • vs. ce-plan: ce-plan handles task breakdown after a verdict is accepted; ce-pov stops at the verdict.
    • vs. ce-debug: ce-debug investigates observed failures; ce-pov assesses exposure and priority of external claims.

  8. Understand Cross-Model Adversarial Review in ce-doc-review

    main

    The ce-doc-review skill supports an optional cross-model pass to improve review quality by using a different model provider than the host. This pass targets the three conditional judgment lenses: adversarial-document-reviewer, product-lens-reviewer, and security-lens-reviewer.

    Key Features

    • Automated Peer Selection: The system identifies the host provider and selects one different provider based on a preference order (Conversation > Config > Project Instructions > Availability). The default availability order is codex, claude, grok, then composer.
    • High Reasoning Requirement: The peer model always runs at its highest reasoning tier (e.g., gpt-5.6-sol for codex, opus for claude, grok-4.5 for grok).
    • Promotion via Agreement: If a cross-model finding shares a fingerprint with its in-process twin (the host model's finding), the finding is promoted by one anchor step due to the cross-model agreement signal.
    • Safety and Isolation: The peer process is strictly read-only and non-blocking. If the peer fails (due to authentication, timeouts, or missing CLIs), the review continues without the cross-model pass.
    • Privacy Notice: In interactive mode, the tool prominently announces that full document content is being sent to the third-party peer provider.

  9. Understand the Conversion process for Target platforms

    main

    To support coding-agent platforms other than Claude Code (referred to as Targets), the project uses a conversion pipeline:

    • Target: A destination platform (e.g., OpenCode, Codex, Pi, Antigravity, Kimi Code).
    • Converter: Transforms a parsed Plugin into a Target's specific in-memory form, mapping tools, permissions, and models.
    • Writer: Emits the converted Bundle (the in-memory form) onto the disk at the Target's expected paths.
    • Native plugin surface: Some Targets can consume the repository's plugin manifest directly without needing a Converter/Writer pair.
    • Install manifest: A per-plugin ledger written by a Writer during installation. It tracks which paths were created by the tool so that user-managed content (like symlinks or hand-authored directories) is preserved and not overwritten during reinstalls.

  10. Understand the new per-project storage model

    main

    The system has moved from repo-local storage to a user-state-based per-project storage model to ensure worktree safety.

    Storage Locations

    • Machine-Local Config: Stored in .compound-engineering/config.local.yaml (this file should be added to your .gitignore).
    • Todo Lifecycle: Durable todos are now stored under <user_state_dir>/projects/<project-slug>/todos/.
    • Per-Run Artifacts: Workflow artifacts (e.g., from ce:review, deepen-plan, or feature-video) are stored under <user_state_dir>/projects/<project-slug>/<workflow>/.

    Migration Behavior

    • Todos: The system supports 'legacy-drain' behavior. It writes new todos to the new canonical path but can still read existing todos from legacy directories like todos/ or .context/compound-engineering/todos/ until they are cleared.

  11. Understand cross-invocation cluster analysis in `resolve-pr-feedback`

    main

    The resolve-pr-feedback skill uses cross-invocation awareness to detect recurring feedback patterns across multiple review rounds on the same Pull Request. This replaces the previous 'verify-loop re-entry' gate, allowing the skill to trigger cluster analysis even if there is only 1 new feedback item, provided there is evidence of prior review rounds (resolved threads).

    Clustering Triggers

    Cluster analysis is triggered if either of the following conditions is met:

    1. Volume Gate: There are 3 or more new unresolved items.
    2. Cross-Invocation Signal: The cross_invocation.signal is true (detected via the presence of resolved threads alongside new ones).

    Resolver Assessment Modes

    When running in cluster mode, the ce-pr-comment-resolver agent performs a three-mode assessment:

    • Band-aid: Redo prior fixes holistically.
    • Correct-but-incomplete: Keep existing fixes but investigate sibling code.
    • Sound-and-independent: Provide context only.

  12. Understand the Codex native plugin installation model

    main

    The current Compound Engineering model uses a native plugin installation for Codex. Instead of using a converter to generate skills and prompts, Codex reads them directly from the plugin manifest.

    Key characteristics:

    • Source of Truth: Skills are sourced from the native plugin install via the .codex-plugin/plugin.json manifest.
    • Skill Declaration: The manifest declares the skills directory using the skills key (e.g., "skills": "./skills/").
    • Skill Structure: User-facing skills are located in root directories such as skills/ce-plan, skills/ce-work, and skills/ce-code-review.
    • Specialist Behavior: Specialist research or review behaviors are stored as local prompt assets within the skill directory under references/agents/ or references/personas/.
    • No Standalone Agents: The current plugin surface does not include standalone CE agents; all functionality is encapsulated within skills.
    {
  "name": "compound-engineering",
  "skills": "./skills/"
}