neolabhq/context-engineering-kit

1. What this repository is

- This is a plugin marketplace for AI coding assistants, centered on Claude Code compatibility.

- The repo is mostly content/configuration, not a traditional application: plugins are delivered as markdown prompts, rules, skills, agents, and hooks.

2. Top-level architectural split

- The repository has three major surfaces:

- Installable plugins under plugins/

- Human-facing documentation under docs/

- Internal specs/process artifacts under .specs/

- That separation is important: the installable assets are what users load into their assistant; the docs explain usage; the specs track ongoing development work.

3. Plugin packaging model

- Each plugin lives in its own folder under plugins/<name>/ and has a .claude-plugin/plugin.json manifest.

- That manifest is the boundary between repo content and the installer/runtime: it tells the host tool what to install and load.

- Most plugins are delivered as Markdown-based skill files and/or agent prompts, with minimal executable code.

4. Primary plugin types

- Skills-only plugins: many folders contain skills/.../SKILL.md, which encode behavior instructions for the assistant.

- Agent-based plugins: some include agents/*.md, defining specialized sub-agent roles for tasks like review, architecture, or research.

- Rule-based plugins: ddd and tech-stack provide reusable rules that influence generation behavior when relevant files are touched.

- Command/workflow plugins: sdd, sadd, git, tdd, kaizen, mcp, and customaize-agent focus on command-driven flows orchestrating multiple steps.

5. The most code-like subsystem: Reflexion hooks

- plugins/reflexion/hooks/ is the only clear executable subsystem in the repo.

- It is implemented in TypeScript and uses Bun tooling (package.json, bun.lockb, vitest).

- Its job is to act as a runtime hook layer: when certain prompt conditions are met, it triggers reflection behavior and related logic.

- This makes Reflexion the repo’s main boundary between static prompt content and live execution.

6. Multi-agent workflow architecture

- Several plugins are designed around sub-agent orchestration rather than a single prompt:

- sadd coordinates parallel, sequential, competitive, or judge-based agent patterns.

- review fans out to specialized reviewers like bug, security, test coverage, and historical-context agents.

- sdd uses a planning pipeline with distinct roles such as researcher, code-explorer, architect, tech lead, QA, developer, reviewer, and writer.

- fpf introduces an evidence-based hypothesis/verification loop via a dedicated reasoning agent.

- Architecturally, these plugins are “control planes” for dispatching specialized prompt agents.

7. Spec-driven development as a workflow system

- plugins/sdd is the repo’s most structured workflow subsystem.

- It organizes development into task files and phases under .specs/tasks/..., then produces implementation guidance using multiple agents.

- The important data flow is: task prompt → spec refinement → implementation plan → execution → verification → archived task.

- This subsystem also integrates architectural guidance from ddd, showing a deliberate dependency between quality rules and implementation planning.

8. Documentation architecture

- docs/ is a GitBook-style documentation tree with:

- conceptual docs,

- getting started material,

- plugin guides,

- reference pages,

- best practices and resource lists.

- This docs layer mirrors the plugin catalog and acts as the user-facing explanation layer for installation and usage.

- docs/SUMMARY.md and the folder structure indicate a navigation-driven documentation site.

9. Repository-internal process and governance

- .specs/ contains task drafts, completed task records, research notes, and reports.

- This is a project-management boundary for how the marketplace itself evolves: feature drafts, work reports, analysis notes, and roadmap items are stored separately from the installable plugins.

- It suggests the repo is maintained through a spec-and-report workflow, not just ad hoc edits.

10. Tooling and environment

- .devcontainer/ indicates a containerized development setup.

- justfile provides task automation for contributor workflows.

- .cursor/, .claude/, and .claude-plugin/ files support editor/assistant integration and marketplace metadata.

- These are enabling layers rather than product runtime components.

11. Cross-plugin relationships

- The plugins are intentionally composable and non-overlapping:

- ddd supplies design rules used by sdd.

- tech-stack injects language-specific standards when relevant.

- reflexion adds reflection/memory loops.

- review adds post-change evaluation.

- git bridges assistant workflows to Git operations.

- The architecture is therefore a toolkit of orthogonal behaviors, not a single monolithic assistant.

12. External interfaces that matter

- The marketplace is distributed through the Claude plugin ecosystem and also references other assistant ecosystems like Cursor, OpenCode, Antigravity, and Codex.

- GitHub is relevant for installation, PR workflows, and CI integration.

- GitBook is used as the documentation publishing surface.

- Bun is required specifically for the Reflexion hook implementation.

13. How to draw it

- A good architecture diagram would show:

- a central plugin marketplace repository,

- branching into installable plugin packages,

- a separate docs site,

- a separate spec/task management area,

- and a small runtime hook/code subsystem for Reflexion.

- Inside plugins, emphasize that most behavior is encoded as markdown prompt assets plus manifests, with only a small amount of executable TypeScript.

14. Overall architectural character

- This repo is a content-oriented, modular plugin distribution system for agent behavior engineering.

- Its core design principles are: isolation, composability, minimal token footprint, and workflow specialization.

- The main architectural concern is not request routing or data storage, but how assistant capabilities are packaged, loaded, and orchestrated.