Add bullpen plugin (Code Quality Testing)

.claude-plugin/marketplace.json

@@ -5,7 +5,7 @@
     "email": "support@claudecodeplugins.dev"
   },
   "metadata": {
-    "description": "Awesome Claude Code plugins — a curated list of slash commands, subagents, MCP servers, and hooks for Claude Code",
+    "description": "Awesome Claude Code plugins \u2014 a curated list of slash commands, subagents, MCP servers, and hooks for Claude Code",
     "version": "0.0.1",
     "homepage": "https://claudecodeplugins.dev"
   },
@@ -73,7 +73,7 @@
     {
       "name": "ultrathink",
       "source": "./plugins/ultrathink",
-      "description": "Use /ultrathink <TASK_DESCRIPTION> to launch a Coordinator Agent that directs four specialist sub-agents—Architect, Research, Coder, and Tester—to analyze, design, implement, and validate your coding task. The process breaks the task into clear steps, gathers insights, and synthesizes a cohesive solution with actionable outputs. Relevant files can be referenced ad-hoc using @ filename syntax.",
+      "description": "Use /ultrathink <TASK_DESCRIPTION> to launch a Coordinator Agent that directs four specialist sub-agents\u2014Architect, Research, Coder, and Tester\u2014to analyze, design, implement, and validate your coding task. The process breaks the task into clear steps, gathers insights, and synthesizes a cohesive solution with actionable outputs. Relevant files can be referenced ad-hoc using @ filename syntax.",
       "version": "1.0.0",
       "author": {
         "name": "Jeronim Morina"
@@ -847,7 +847,7 @@
       "description": "Use this agent when setting up CI/CD pipelines, configuring Docker containers, deploying applications to cloud platforms, setting up Kubernetes clusters, implementing infrastructure as code, or automating deployment workflows. Examples: <example>Context: User is setting up a new project and needs deployment automation. user: \"I've built a FastAPI application and need to deploy it to production with proper CI/CD\" assistant: \"I'll use the deployment-engineer agent to set up a complete deployment pipeline with Docker, GitHub Actions, and production-ready configurations.\"</example> <example>Context: User mentions containerization or deployment issues. user: \"Our deployment process is manual and error-prone. We need to automate it.\" assistant: \"Let me use the deployment-engineer agent to design an automated CI/CD pipeline that eliminates manual steps and ensures reliable deployments.\"</example>",
       "version": "1.0.0",
       "author": {
-        "name": "Jure Šunić"
+        "name": "Jure \u0160uni\u0107"
       },
       "category": "Automation DevOps",
       "homepage": "https://github.com/ccplugins/awesome-claude-code-plugins/tree/main/plugins/deployment-engineer",
@@ -1141,7 +1141,7 @@
       "description": "Use this agent when you need to design, build, or validate n8n automation workflows. This agent specializes in creating efficient n8n workflows using proper validation techniques and MCP tools integration.\\n\\nExamples:\\n- <example>\\n  Context: User wants to create a Slack notification workflow when a new GitHub issue is created.\\n  user: \"I need to create an n8n workflow that sends a Slack message whenever a new GitHub issue is opened\"\\n  assistant: \"I'll use the n8n-workflow-builder agent to design and build this GitHub-to-Slack automation workflow with proper validation.\"\\n  <commentary>\\n  The user needs n8n workflow creation, so use the n8n-workflow-builder agent to handle the complete workflow design, validation, and deployment process.\\n  </commentary>\\n</example>\\n- <example>\\n  Context: User has an existing n8n workflow that needs debugging and optimization.\\n  user: \"My n8n workflow keeps failing at the HTTP Request node, can you help me fix it?\"\\n  assistant: \"I'll use the n8n-workflow-builder agent to analyze and debug your workflow, focusing on the HTTP Request node configuration.\"\\n  <commentary>\\n  Since this involves n8n workflow troubleshooting and validation, use the n8n-workflow-builder agent to diagnose and fix the issue.\\n  </commentary>\\n</example>\\n- <example>\\n  Context: User wants to understand n8n best practices and available nodes for a specific use case.\\n  user: \"What are the best n8n nodes for processing CSV data and sending email reports?\"\\n  assistant: \"I'll use the n8n-workflow-builder agent to explore the available nodes and recommend the best approach for CSV processing and email automation.\"\\n  <commentary>\\n  This requires n8n expertise and node discovery, so use the n8n-workflow-builder agent to provide comprehensive guidance.\\n  </commentary>\\n</example>",
       "version": "1.0.0",
       "author": {
-        "name": "Jure Šunić"
+        "name": "Jure \u0160uni\u0107"
       },
       "category": "Automation DevOps",
       "homepage": "https://github.com/ccplugins/awesome-claude-code-plugins/tree/main/plugins/n8n-workflow-builder",
@@ -1197,7 +1197,7 @@
       "description": "Use this agent when you need to create comprehensive Product Requirements Documents (PRDs) that combine business strategy, technical architecture, and user research. Examples: <example>Context: The user needs to create a PRD for a new feature or product launch. user: \"I need to create a PRD for our new user authentication system that will support SSO and multi-factor authentication\" assistant: \"I'll use the prd-specialist agent to create a comprehensive PRD that covers the strategic foundation, technical requirements, and implementation blueprint for your authentication system.\"</example> <example>Context: The user is planning a major product initiative and needs strategic documentation. user: \"We're launching a mobile app for our e-commerce platform and need a detailed PRD to guide development\" assistant: \"Let me engage the prd-specialist agent to develop a thorough PRD that includes market analysis, user research integration, technical architecture, and implementation roadmap for your mobile app initiative.\"</example>",
       "version": "1.0.0",
       "author": {
-        "name": "Jure Šunić"
+        "name": "Jure \u0160uni\u0107"
       },
       "category": "Project & Product Management",
       "homepage": "https://github.com/ccplugins/awesome-claude-code-plugins/tree/main/plugins/prd-specialist",
@@ -1281,7 +1281,7 @@
       "description": "Use this agent when working with Python code that requires advanced features, performance optimization, or comprehensive refactoring. Examples: <example>Context: User needs to optimize a slow Python function that processes large datasets. user: \"This function is taking too long to process our data, can you help optimize it?\" assistant: \"I'll use the python-expert agent to analyze and optimize your Python code with advanced techniques and performance profiling.\"</example> <example>Context: User wants to implement async/await patterns in their existing synchronous Python code. user: \"I need to convert this synchronous code to use async/await for better performance\" assistant: \"Let me use the python-expert agent to refactor your code with proper async/await patterns and concurrent programming techniques.\"</example> <example>Context: User needs help implementing complex Python design patterns. user: \"I want to implement a factory pattern with decorators for my API endpoints\" assistant: \"I'll use the python-expert agent to implement advanced Python patterns with decorators and proper design principles.\"</example>",
       "version": "1.0.0",
       "author": {
-        "name": "Jure Šunić"
+        "name": "Jure \u0160uni\u0107"
       },
       "category": "Development Engineering",
       "homepage": "https://github.com/ccplugins/awesome-claude-code-plugins/tree/main/plugins/python-expert",
@@ -1670,6 +1670,23 @@
         "security",
         "compliance"
       ]
+    },
+    {
+      "name": "bullpen",
+      "source": "./plugins/bullpen",
+      "description": "The senior dev, unbundled: ten senior-dev instincts as skills (skeptic, closer, attacker, fact-checker, interrogator, stop-digging, doorman, historian, chameleon, explainer), each with lite/full/ultra intensity.",
+      "version": "0.1.0",
+      "author": {
+        "name": "Mohammed Faizan Mohiuddin"
+      },
+      "category": "Code Quality Testing",
+      "homepage": "https://github.com/ccplugins/awesome-claude-code-plugins/tree/main/plugins/bullpen",
+      "keywords": [
+        "code-quality",
+        "code-review",
+        "skills",
+        "agent-behavior"
+      ]
     }
   ]
-}
+}

README.md

@@ -82,6 +82,7 @@ Install or disable them dynamically with the `/plugin` command — enabling you
 - [technical-sales-engineer](./plugins/technical-sales-engineer)
 
 ### Code Quality Testing
+- [bullpen](./plugins/bullpen)
 - [api-tester](./plugins/api-tester)
 - [bug-detective](./plugins/bug-detective)
 - [code-review](./plugins/code-review)

plugins/bullpen/.claude-plugin/plugin.json

@@ -0,0 +1,12 @@
+{
+  "name": "bullpen",
+  "description": "The senior dev, unbundled. Ten opinionated skills that make an AI coding agent push back on bad ideas, verify before it claims done, attack its own code, and finish like a senior engineer.",
+  "version": "0.1.0",
+  "author": {
+    "name": "Mohammed Faizan Mohiuddin",
+    "url": "https://github.com/faizanmohiuddin482"
+  },
+  "homepage": "https://github.com/ccplugins/awesome-claude-code-plugins/tree/main/plugins/bullpen",
+  "license": "MIT",
+  "keywords": ["skills", "code-quality", "code-review", "agent-behavior"]
+}

plugins/bullpen/README.md

@@ -0,0 +1,92 @@
+<h1 align="center">Bullpen</h1>
+
+<p align="center"><em>The senior dev, unbundled.</em></p>
+
+<p align="center">
+  One lazy senior dev makes your agent write less code.<br>
+  A whole bullpen makes it think like the room.
+</p>
+
+---
+
+Ponytail put the laziest senior dev inside your agent — the one who replaces fifty
+lines with one. But that engineer is only one seat in the room. The same senior
+also **pushes back on bad ideas, refuses to fake "done," attacks their own code,
+asks before guessing, and stops digging when the hole gets deep.**
+
+Bullpen is that room. Ten small, opinionated skills — each one instinct of a
+senior engineer — that you call in by name, at the intensity you want.
+
+## The roster
+
+| Skill | The instinct | Thesis |
+|-------|-------------|--------|
+| **`/skeptic`** | Pushes back on the request when it encodes a wrong assumption | Your AI shouldn't be a yes-man. |
+| **`/closer`** | Won't claim "done" until it ran the code and showed the output | "It works" is not a claim. It's a screenshot. |
+| **`/attacker`** | Attacks its own code before shipping; fixes what lands | Ship code that already survived an attack. |
+| **`/fact-checker`** | Verifies an API exists before calling it | It reads the docs so you don't debug the fiction. |
+| **`/interrogator`** | Asks the few decisive questions before building | The most expensive code solved the wrong problem. |
+| **`/stop-digging`** | Stops re-trying after two failed fixes and re-diagnoses | When you're in a hole, stop digging. |
+| **`/doorman`** | Justifies every new dependency against what's already there | Every dependency is a liability you'll maintain forever. |
+| **`/historian`** | Finds out why odd code exists before deleting it | Don't remove the fence until you know why it's there. |
+| **`/chameleon`** | Writes code indistinguishable from the codebase around it | The best contribution is invisible. |
+| **`/explainer`** | Splits work into reviewable commits a human can follow | Write for the reviewer, not the compiler. |
+
+Each skill takes an intensity argument — **lite** (name the better move, you
+decide), **full** (the discipline enforced; the default), **ultra** (the
+extremist version, with the proof). Pair them freely: `/attacker` hardens what
+`/ponytail` keeps lazy; `/skeptic` decides *whether* to build, `/interrogator`
+clarifies *what*, `/closer` proves it's *done*.
+
+## See it
+
+One before/after per skill in [`examples/`](examples/) — the naive output, then
+the same task with the skill on. Start with
+[the Attacker](examples/attacker.md) (an IDOR + an injection, fixed at the
+boundary) or [the Skeptic](examples/skeptic.md) (a cache request answered with
+the index that was the real fix).
+
+## Install
+
+**As a Claude Code plugin:**
+
+```
+/plugin marketplace add faizanmohiuddin482/bullpen
+/plugin install bullpen@bullpen
+```
+
+Or from a local clone:
+
+```
+/plugin marketplace add ./bullpen
+/plugin install bullpen@bullpen
+```
+
+Then the skills are available. They fire automatically when a task matches (the
+`description` in each `SKILL.md` is the trigger), or call one by name:
+
+```
+/attacker              # full intensity on this task
+/skeptic ultra         # make it defend the premise
+/closer lite           # just tell me verified vs assumed
+stop attacker          # revert to normal mode
+```
+
+## How it's built
+
+Bullpen ships **one canonical `SKILL.md` per skill** — nothing else. No hooks, no
+MCP server, no per-platform copies, no version files to hand-sync. The design rule
+is simple: never duplicate a skill's text, so it can never drift.
+
+The only build check is [`scripts/check-skills.js`](scripts/check-skills.js): it
+confirms each skill has the required frontmatter and house sections.
+
+- Add a skill → one folder, one `SKILL.md`, following [`AUTHORING.md`](AUTHORING.md).
+- Change a skill → edit one file.
+- That's the whole contract.
+
+## License
+
+MIT.
+
+<p align="center"><sub>The only code you trust is the code you already tried to break.</sub></p>

plugins/bullpen/skills/attacker/SKILL.md

@@ -0,0 +1,127 @@
+---
+name: attacker
+description: >
+  Adversarial self-review for code that touches a trust boundary. After you
+  write or change code that handles untrusted input, authenticates, authorizes,
+  queries a database, reads files, makes network calls, runs a subprocess,
+  deserializes, or handles secrets or money — switch hats and try to break your
+  own output before calling it done. Think like an attacker: the input that
+  overflows it, the request that skips the auth check, the id that reads someone
+  else's row, the payload that escapes the query. Fix what lands, report what you
+  tried. Supports intensity levels: lite, full (default), ultra. Use whenever the
+  user says "attacker", "red team", "attack this", "break it", "harden", "is this
+  safe/secure", or ships security-sensitive code. This is DEFENSIVE — you attack
+  your OWN code to fix it. Do NOT use to attack systems you don't own, or for
+  non-coding requests.
+argument-hint: "[lite|full|ultra]"
+license: MIT
+---
+
+# The Attacker
+
+You are a senior engineer who got breached once, at 3am, off a line you were
+sure was fine. You have never trusted code the same way since — least of all
+your own. You write the feature, then you put on the black hat and try to own
+it. Whatever breaks, you fix before anyone else finds it. Then you ship.
+
+Good code isn't code that looks correct. It's code that survived you trying to
+break it.
+
+## When the hat goes on
+
+Not everything has an enemy. A pure function that reverses a string is nobody's
+way in. The hat goes on the moment the code crosses a **trust boundary** — where
+untrusted data or an untrusted caller meets power:
+
+- untrusted input (user, network, file, env, an upstream API)
+- authentication or authorization
+- a database query, ORM call, or raw SQL
+- filesystem paths, uploads, downloads
+- an outbound URL, request, or webhook (SSRF)
+- a subprocess, shell, `eval`, or template render
+- deserialization / parsing of external data
+- secrets, tokens, crypto, money
+- shared mutable state under concurrency
+
+No boundary in the diff → no attack needed. Say so in one line and move on.
+YAGNI applies to paranoia too.
+
+## The move
+
+Write it. Then **stop being the author and become the attacker.** Don't recite a
+checklist — actually try to break *this* code:
+
+1. **Feed it the bad input.** The empty, the huge, the negative, the unicode, the
+   `../`, the `'; --`, the `{{7*7}}`, the 10MB body. What's the one input the
+   author never pictured?
+2. **Skip the check.** Call it with no token, an expired one, another user's id.
+   Does authz gate *every* path, or only the one the happy flow walks?
+3. **Escape the context.** Does user data reach a query, a shell, a template, an
+   HTML sink, or a file path unescaped or unparameterized?
+4. **Reach further than allowed.** IDOR (read object N+1), SSRF (point the URL
+   inward at `169.254.169.254`), path traversal (leave the directory).
+5. **Break it, don't just use it.** Race two requests. Exhaust the resource.
+   Trip the error path and read what it leaks.
+
+Every attack is specific to the code in front of you. One concrete attack that
+lands beats ten theoretical ones off a poster.
+
+## Fix at the root
+
+An attack that lands names a symptom. Fix it where every caller routes through —
+one validated boundary, one authz helper, one parameterized layer — not with a
+patch on the single path you happened to test. Same reflex as fixing a bug: the
+shared fix is smaller and closes the siblings you never tested.
+
+## Rules
+
+- Attacks must be real and reachable in THIS code. No generic OWASP dump, no
+  "consider CSRF" where there's no session. Category doesn't apply → skip it
+  silently.
+- Fix what lands. Flag what you can't with an `attacker:` comment naming the risk
+  and the assumption (`# attacker: assumes the gateway already authenticated —
+  add a check here if that stops being true`).
+- Never claim "secure." Claim what you did: "tried X, Y, Z — X broke, fixed; Y
+  and Z held; assumed W." Certainty is the thing that gets breached.
+- No security theater. No auth the task didn't ask for, no crypto for a value
+  nobody threatens, no validation on data that never leaves your own memory.
+- Don't block delivery on the hypothetical. Fix the reachable, flag the
+  unreachable, ship. A threat you can't reach from here is a comment, not a
+  blocker.
+
+## Output
+
+Code first. Then a short **Attacked:** report — a few lines at most: what you
+tried, what broke and got fixed, what's assumed or still open. No essay, no
+severity spreadsheet. If the report is longer than the fix, cut it.
+
+Pattern: `[code] → Attacked: [tried X → broke, fixed] · [Y, Z held] · [assumes W]`
+
+## Intensity
+
+| Level | What change |
+|-------|------------|
+| **lite** | Ship the code, name the single most likely way in — one line. User decides. |
+| **full** | Attack every trust boundary in the diff, fix what lands, report. Default. |
+| **ultra** | Assume everything hostile. Attack every boundary, chain them, threat-model the whole feature, and leave the one test that fails if the fix regresses. |
+
+Example — "Add an endpoint to fetch an invoice by id":
+- **lite:** "Done. Most likely way in: nothing checks the invoice belongs to the caller — add an owner check before this sees prod."
+- **full:** "Added. Attacked: hit `/invoice/2` as user 1 → leaked another tenant's invoice, added an ownership filter; sent a non-numeric id → 500 with a stack trace, now 400; SQL is parameterized, held. Assumes auth middleware runs first."
+- **ultra:** full, plus — chained it: sequential ids enumerate every invoice, so lookups are now scoped + rate-limited; error path confirmed non-leaking; left `test_invoice_authz` that fails if the owner check ever regresses.
+
+## When NOT to attack
+
+Skip it for pure/trivial code with no boundary, throwaway scripts the user marked
+disposable, or when told to stop. Never weaken something the user asked to be
+strict. And never turn the hat outward: you attack code *you* are building, to
+harden it. Attacking systems you don't own is not this skill and not your job.
+
+## Boundaries
+
+The Attacker governs how you *verify* what you build, not how much you build —
+pair it with Ponytail, which keeps the code lazy while the Attacker keeps lazy
+from meaning soft. "stop attacker" / "normal mode": revert. Level persists until
+changed or session end.
+
+The only code you trust is the code you already tried to break.