Claude Code Plugin

Your prompts have defects you can't see.

prompt-engineering-suite scans every LLM call in your codebase, scores each prompt against a 12-point rubric, and proposes targeted rewrites — architecture-aware, nothing applied without your approval.

One suite, four commands.

Each command is focused on a single responsibility, and nothing modifies your code without explicit approval.

/prompt-audit
Find what's broken.

Runs a discovery sweep, then fans out parallel reviewers — one per prompt — each scoring against the full rubric. Findings land in the terminal; your codebase stays untouched.

/prompt-audit [scope]
/prompt-author
Build what's correct from the start.

Reads your codebase conventions and rules folder, then proposes a best-practice prompt with correct layer placement, call parameters, and a starter eval — for your approval before anything is written.

/prompt-author <feature>
/prompt-init + /prompt-fix
Set up. Fix one at a time.

/prompt-init creates a persistent docs/prompt-engineering/ workspace with a prompt inventory and shared conventions. /prompt-fix targets one finding and applies an approved rewrite.

/prompt-fix <file:line>

12 checks. One shared standard.

Every audit, author, and fix command reads from the same rubric, so a prompt this suite writes would also pass the review this suite runs.

HIGH — ship-blocking
MEDIUM — should fix
LOW — nice to fix
Security & Correctness — PE-01 through PE-04
PE-01
HIGH
Role separation
Stable instructions in the system role; per-request data in the user role. User-controlled text must never be concatenated into system instructions.
f-string mixing fixed instructions + user input in one role
PE-02
HIGH
Untrusted input is delimited
User- or third-party-supplied content wrapped in explicit delimiters (<doc>…</doc>, triple backticks) and the instructions name those delimiters.
User input passed with no structural separation from the instructions
PE-03
HIGH
Trust boundary stated
The prompt explicitly tells the model that delimited content is DATA — not instructions — and to ignore any instructions found inside it.
No injection-hardening statement when embedding external input
PE-04
HIGH
Output contract
If output is parsed by code, the prompt constrains it (JSON mode / tool calling / named schema) rather than hoping for a parseable shape from prose.
Code does json.loads(response) or regex-scrapes a free-text answer
Reliability & Quality — PE-05 through PE-08
PE-05
MEDIUM
Specificity
The task is concrete: action, exact output format, audience, and constraints — what to do AND what not to do.
Vague verb ("summarize this") with no format, length, or audience constraint
PE-06
MEDIUM
Grounding & escape hatch
For knowledge/extraction tasks: supplies source material and includes an explicit "if not present, say NOT_FOUND" escape hatch to curb hallucination.
Model asked to answer from a document with no escape for missing facts
PE-07
LOW
Few-shot examples
Classification, extraction, or strict-format tasks include 2–4 examples (as data, not prose) when zero-shot reliability is shaky.
Zero-shot on a classification or strict-format task
PE-08
MEDIUM
Determinism settings
The call sets appropriate parameters: temperature=0 for extraction/classification; max_tokens bounded; not relying on provider defaults.
temperature and max_tokens not set; using provider defaults
Engineering Hygiene — PE-09 through PE-12
PE-09
MEDIUM
Prompts as code
The prompt is a named, parameterized template — not a scattered inline string literal. Reusable, reviewable, and located in the right architecture layer.
Near-duplicate prompt string in multiple files; prompt in a controller or domain entity
PE-10
MEDIUM
Evaluation reference
There is some test or eval covering this prompt's behavior — a golden set, snapshot test, or assertion. A prompt with no test can silently regress.
No tests or eval assertions for this prompt's behavior
PE-11
LOW
Token & context efficiency
No redundant boilerplate, no duplicated instructions, no needlessly long examples. Instructions are tight.
Same constraint stated 3+ times; examples longer than necessary
PE-12
LOW
Model-appropriateness
For small or local models, the prompt is explicit and tightly structured. Cross-tier prompt portability is acknowledged where relevant.
Vague prompt on a small model; cross-tier portability undocumented

Severities can be overridden per-project via docs/prompt-engineering/rules/ or .prompt-review.yaml.

Four focused commands.

Each does one thing. Nothing writes to your codebase without your approval first.

/prompt-init
One-time project setup

Scans the codebase for existing LLM usage, creates a persistent docs/prompt-engineering/ workspace with an inventory, auto-generated conventions, and a house-rules file all commands share. Safe to re-run.

/prompt-init # Scanning for LLM calls… # Found 7 prompts across 4 files # Created docs/prompt-engineering/
/prompt-audit [scope]
Full codebase review

Discovers all LLM prompts, then fans out parallel subagent reviewers — one per prompt — each scoring against the full PE rubric. Reads your rules folder when present. Output is terminal-only; nothing is changed.

/prompt-audit src/payments/ # PE-01 HIGH src/payments/invoice.py:44 # PE-04 HIGH src/payments/classify.py:91 # 2 HIGH · 1 MEDIUM · 0 LOW
/prompt-author <feature>
Author new prompts correctly

Creates a feature-brief file for you to fill in the product intent, reads the codebase and rules folder, then proposes a best-practice prompt with correct layer placement, call params, and a starter eval — for your approval.

/prompt-author invoice-summary # Created docs/prompt-engineering/ # features/invoice-summary.md # Fill in the brief, then re-run.
/prompt-fix <file:line>
Targeted rewrite

Re-reviews a single prompt at the given location, applies the rubric, and proposes a rewrite as a diff. You approve before it is applied. Use after /prompt-audit to address specific findings one at a time.

/prompt-fix src/payments/invoice.py:44 # Reviewing PE-01 finding… # --- a/src/payments/invoice.py # +++ b/src/payments/invoice.py

One init. Persistent context.

Running /prompt-init creates a workspace committed to your repo and shared with your team.

docs/prompt-engineering/ ├── OVERVIEW.md ← generated inventory ├── rules/ │ ├── project-conventions.md ← generated │ ├── house-rules.md ← you write this │ └── model-config.md ← you write this └── features/ └── invoice-summary.md ← per /prompt-author
OVERVIEW.md
Generated inventory of every LLM prompt — file path, line, model, and confidence score. Updated on each re-run of /prompt-init.
rules/project-conventions.md
Auto-extracted: your LLM provider, which models you use, where prompts live, how calls are structured. All commands read this before reviewing or authoring.
rules/house-rules.md
Human-written team norms: brand voice, PII handling, off-limits topics, formatting constraints. These take precedence over the default rubric in every command.
features/
One file per AI feature, created by /prompt-author. Tracks a feature brief from draft through implemented — the audit trail for every intentional prompt in your codebase.

Three commands to get started.

Requires Claude Code. The marketplace is private to the ASSIST Software GitHub org — org members only.

1
Add the marketplace
/plugin marketplace add assist-software/claude-code-repository
Requires org membership and git credentials (gh auth login or an SSH key in ssh-agent).
2
Install the plugin
/plugin install prompt-engineering-suite@assist-claude-marketplace
3
Initialize your project
/prompt-init
Run inside the repo you want to audit. Creates docs/prompt-engineering/ with your project's conventions pre-filled.