aka.ms/PromptKit · MIT License
Agentic prompts are the most important code you're not engineering. Every AI-assisted task — investigating bugs, writing requirements, reviewing code — lives or dies by the prompt that drives it. Yet most teams still write these prompts ad hoc: copy-pasted, untested, inconsistent, and impossible to improve systematically.
PromptKit treats prompts as code. It gives you composable, version-controlled components — personas, reasoning protocols, output formats, and task templates — that snap together into reliable, repeatable prompts. The same engineering rigor you apply to your software (modularity, reuse, testing, code review) now applies to the prompts that build it.
A composable, versioned library of prompt templates for engineering tasks — software, hardware, firmware, and protocol domains. Designed for engineers who design, build, verify, and ship.
136 components — 13 personas · 44 protocols · 20 formats · 5 taxonomies · 54 templates across 3 pipelines
- Node.js 18+ — Install Node.js (required for
npx @alan-jowett/promptkit) - Git — Install Git (only needed if cloning the repo)
To use the interactive mode, you'll also need one of the following LLM CLI tools:
- GitHub Copilot CLI — Install the GitHub CLI, authenticate with
gh auth login, ensure Copilot access is enabled for your account/organization, then rungh extension install github/gh-copilot - Claude Code — Install Claude Code
Not using a CLI tool? Use promptkit assemble to generate prompt files, or see
Using with any LLM (manual).
# Interactive mode — detects your LLM CLI and launches bootstrap
npx @alan-jowett/promptkit
# List available templates
npx @alan-jowett/promptkit list
# Assemble a specific prompt to a file
npx @alan-jowett/promptkit assemble investigate-bug \
-p problem_description="Segfault on startup" \
-p code_context="See attached files" \
-p environment="Linux x86_64" \
-o bug-investigation.mdClone the repo and point Copilot at the bootstrap prompt:
git clone https://github.com/microsoft/promptkit.git
cd promptkit
# Start a session — Copilot reads bootstrap.md, loads the manifest,
# and asks what you need.
copilot -i "Read and execute bootstrap.md"Copilot reads bootstrap.md, discovers all components via manifest.yaml,
and presents the available templates:
● Read bootstrap.md
● Read manifest.yaml
I've loaded the PromptKit manifest. I'm ready to help you build a task-specific prompt.
Available templates (54):
┌────────────────────────┬───────┬──────────────────────────────────────────────────────┐
│ Category │ Count │ Examples │
├────────────────────────┼───────┼──────────────────────────────────────────────────────┤
│ Document Authoring │ 16 │ author-requirements-doc, interactive-design, │
│ │ │ audit-traceability, validate-budget, ... │
├────────────────────────┼───────┼──────────────────────────────────────────────────────┤
│ Code Analysis │ 8 │ review-code, review-cpp-code, exhaustive-bug-hunt, │
│ │ │ review-schematic, review-bom, review-layout, ... │
├────────────────────────┼───────┼──────────────────────────────────────────────────────┤
│ DevOps │ 7 │ author-pipeline, triage-issues, author-release, ... │
├────────────────────────┼───────┼──────────────────────────────────────────────────────┤
│ Investigation │ 6 │ investigate-bug, investigate-security, │
│ │ │ find-and-fix-bugs, fix-compiler-warnings, ... │
├────────────────────────┼───────┼──────────────────────────────────────────────────────┤
│ Standards │ 4 │ extract-rfc-requirements, author-rfc, ... │
├────────────────────────┼───────┼──────────────────────────────────────────────────────┤
│ Protocol Engineering │ 3 │ evolve-protocol, analyze-protocol-conflicts, ... │
├────────────────────────┼───────┼──────────────────────────────────────────────────────┤
│ Code Generation │ 3 │ author-implementation-prompt, author-test-prompt, ...|
├────────────────────────┼───────┼──────────────────────────────────────────────────────┤
│ Testing · Planning · │ 7 │ discover-tests-for-changes, plan-implementation, │
│ Agent · Contribution │ │ author-agent-instructions, extend-library, ... │
└────────────────────────┴───────┴──────────────────────────────────────────────────────┘
Personas: systems-engineer · electrical-engineer · protocol-architect ·
embedded-firmware-engineer · security-auditor · ... (13 total)
What would you like to accomplish?
Describe your task and the LLM selects the right persona, protocols, and format, then assembles a complete prompt you can use in a fresh session.
See it in action: Examples — From One-Liner to Engineered Prompt shows what PromptKit actually assembles for tasks like C++ code review, compiler warning remediation, and adversarial bug hunting.
cd promptkit
claude "Read and execute bootstrap.md"If your tool doesn't have file access, paste the bootstrap prompt into a session along with the manifest, then follow the interactive flow:
1. Copy the contents of bootstrap.md into a new LLM chat.
2. Copy the contents of manifest.yaml into the same chat.
3. Describe your task.
4. The LLM will tell you which files to paste in (persona, protocols, etc.)
5. Paste the requested files, get the assembled prompt back.
The promptkit CLI provides three commands:
| Command | Description |
|---|---|
promptkit |
Launch interactive session with auto-detected LLM CLI |
promptkit list |
List all available templates with descriptions |
promptkit assemble <template> |
Assemble a prompt from a template to a file |
promptkit assemble <template> [options]
Options:
-o, --output <file> Output file path (default: "assembled-prompt.md")
-p, --param <key=value> Template parameter (repeatable)The assembled prompt follows the PromptKit composition order: Identity → Reasoning Protocols → Output Format → Task (with parameters filled).
Outputs the full template catalog as JSON for scripting.
The library uses 5 composable layers:
| Layer | Purpose | Directory |
|---|---|---|
| Persona | Who the LLM is — expertise, tone, behavioral constraints | personas/ |
| Protocol | How it reasons — systematic analysis, reasoning, and guardrails | protocols/ |
| Format | What the output looks like — document structure and rules | formats/ |
| Taxonomy | How findings are classified — domain-specific label schemes | taxonomies/ |
| Template | The task itself — composes the above layers with task-specific instructions | templates/ |
A task template references a persona, one or more protocols, an optional
taxonomy, and a format. The bootstrap prompt reads the manifest.yaml to
discover available components, then assembles them into a single coherent
prompt based on the user's needs.
┌────────────────────────────────────────────────────┐
│ Assembled Prompt │
├────────────────────────────────────────────────────┤
│ ┌──────────┐ │
│ │ Persona │ "You are a senior systems │
│ └──────────┘ engineer with expertise in..." │
│ ┌──────────┐ │
│ │ Protocol │ "Phase 1: Trace allocations..." │
│ │ Protocol │ "Phase 1: Map trust boundaries." │
│ └──────────┘ │
│ ┌──────────┐ │
│ │ Format │ "Output MUST contain sections: │
│ └──────────┘ Findings, Root Cause, ..." │
│ ┌──────────┐ │
│ │ Template │ "Investigate the following bug: │
│ └──────────┘ {{problem_description}}" │
└────────────────────────────────────────────────────┘
Templates declare input and output contracts so they can be chained. Three pipelines are included:
Document Lifecycle
author-requirements-doc → author-design-doc → author-validation-plan → audit-traceability
(produces: requirements) (consumes: requirements, (consumes: requirements, (consumes: requirements +
produces: design) produces: validation) validation; design optional,
produces: drift report)
Hardware Lifecycle
author-requirements-doc → review-schematic → validate-simulation → review-bom → review-layout
(produces: requirements) (consumes: req, (consumes: req, (consumes: req, (consumes: req,
audits netlist) audits sim output) audits BOM) audits PCB)
Protocol Engineering
extract-rfc-requirements → evolve-protocol → author-protocol-validation → analyze-protocol-conflicts
(produces: requirements) (produces: (produces: protocol (produces: investigation
protocol delta) validation spec) report)
The output of one template becomes the input parameter of the next.
After authoring requirements, design, and validation documents — whether through PromptKit's pipeline or by hand — you can audit all three for specification drift: gaps, contradictions, and divergence that accumulate as documents evolve independently.
# Assemble a traceability audit prompt
npx @alan-jowett/promptkit assemble audit-traceability \
-p project_name="Auth Service" \
-p requirements_doc="$(cat requirements.md)" \
-p design_doc="$(cat design.md)" \
-p validation_plan="$(cat validation-plan.md)" \
-o audit-report.mdThe audit uses the specification-drift taxonomy (D1–D16) to classify
findings — untraced requirements, orphaned design decisions, assumption
drift, constraint violations, and illusory test coverage. Each finding
includes specific document locations, evidence, severity, and remediation
guidance.
The design document is optional — omit it for a focused requirements ↔ validation plan audit.
PromptKit covers multiple engineering domains. Each domain has dedicated personas, analysis protocols, and task templates.
| Domain | Keywords |
|---|---|
| Software Engineering | Code review, bug investigation, design docs, requirements, testing, refactoring, implementation |
| Hardware / Electrical Engineering | Schematic review, BOM audit, PCB layout review, simulation validation, power budgets, component selection |
| Embedded Firmware | Boot sequences, OTA updates, flash memory management, power-fail-safe, watchdog timers, device recovery |
| Protocol Engineering | RFC authoring, protocol evolution, conflict analysis, protocol validation, state machines, interoperability |
| Specification Analysis | Invariant extraction, traceability audits, interface contracts, behavioral models, spec diffing, budget validation |
| DevOps & CI/CD | Pipelines, issue triage, PR triage, releases, commit messages, infrastructure review, CI failure analysis |
| Name | Description |
|---|---|
systems-engineer |
Memory management, concurrency, performance, debugging |
security-auditor |
Vulnerability discovery, threat modeling, secure design |
software-architect |
System design, API contracts, tradeoff analysis |
promptkit-contributor |
PromptKit architecture, conventions, contribution guidance |
devops-engineer |
CI/CD pipelines, release engineering, infrastructure-as-code |
reverse-engineer |
Specification extraction, behavioral requirements from code |
specification-analyst |
Cross-document traceability, coverage analysis, specification drift |
workflow-arbiter |
Multi-agent workflow evaluation, livelock detection, termination decisions |
implementation-engineer |
Spec-compliant code generation, requirement tracing |
test-engineer |
Specification-driven test authoring, coverage analysis |
embedded-firmware-engineer |
Boot sequences, OTA updates, flash management, power-fail-safe, watchdogs |
electrical-engineer |
Power delivery, signal integrity, PCB design, schematic review, component selection |
protocol-architect |
Protocol design, evolution, formal specification, state machines, interoperability |
Guardrails (cross-cutting, apply to all tasks):
| Name | Description |
|---|---|
anti-hallucination |
Prevents fabrication, enforces epistemic labeling |
self-verification |
Quality gate — LLM verifies its own output before finalizing |
operational-constraints |
Scoping, tool usage, deterministic analysis, reproducibility |
minimal-edit-discipline |
Minimal, type-preserving, encoding-safe code modifications |
adversarial-falsification |
Self-falsification discipline — disprove findings before reporting |
Analysis (domain/language-specific checks):
| Name | Description |
|---|---|
memory-safety-c |
Memory safety analysis for C codebases |
cpp-best-practices |
Research-validated C++ code review patterns |
memory-safety-rust |
Memory safety analysis for Rust codebases |
thread-safety |
Concurrency and thread safety analysis |
security-vulnerability |
Security vulnerability analysis |
win32-api-conventions |
Win32 API naming, typedefs, parameter ordering |
performance-critical-c-api |
Performance-critical C API design patterns |
winrt-design-patterns |
Windows Runtime API design patterns |
compiler-diagnostics-cpp |
C++ compiler diagnostic analysis and remediation |
msvc-clang-portability |
MSVC ↔ Clang/GCC cross-compiler portability |
kernel-correctness |
OS kernel/driver correctness (locks, refcounts, cleanup paths) |
schematic-compliance-audit |
Schematic review against requirements and datasheets |
simulation-validation |
Circuit simulation output vs. specification constraints |
bom-consistency |
BOM audit against schematic, ratings, sourcing |
layout-design-review |
PCB layout review (traces, impedance, thermal, DRC) |
Reasoning (systematic reasoning approaches):
| Name | Description |
|---|---|
root-cause-analysis |
Systematic root cause analysis |
requirements-elicitation |
Requirements extraction from natural language |
iterative-refinement |
Document revision through feedback cycles |
promptkit-design |
PromptKit component design reasoning |
devops-platform-analysis |
DevOps platform reasoning (pipelines, triggers, secrets) |
requirements-from-implementation |
Deriving requirements from existing source code |
traceability-audit |
Cross-document specification drift detection |
code-compliance-audit |
Source code audit against requirements/design docs |
test-compliance-audit |
Test code audit against validation plan |
integration-audit |
Cross-component integration point audit |
rfc-extraction |
Structured requirements extraction from RFCs |
invariant-extraction |
Invariant extraction from specifications or source code |
workflow-arbitration |
Multi-agent workflow progress evaluation |
requirements-reconciliation |
Multi-source requirements reconciliation |
finding-classification |
Finding classification against taxonomy/catalog |
interface-contract-audit |
Interface contract completeness and consistency audit |
exhaustive-path-tracing |
Per-file deep review with coverage ledger |
protocol-evolution |
Protocol specification modification and extension |
protocol-conflict-analysis |
Protocol specification comparison and conflict detection |
protocol-validation-design |
Validation specification derivation from protocol spec |
spec-invariant-audit |
Adversarial specification analysis against invariants |
quantitative-constraint-validation |
Budget/rollup/margin validation against spec constraints |
spec-evolution-diff |
Specification version comparison at invariant level |
session-profiling |
LLM session log analysis for token inefficiencies |
| Name | Produces | Description |
|---|---|---|
requirements-doc |
Requirements document | Numbered REQ-IDs, acceptance criteria |
design-doc |
Design document | Architecture, APIs, tradeoff analysis |
validation-plan |
Validation plan | Test cases, traceability matrix |
investigation-report |
Investigation report | Findings, root cause, remediation |
multi-artifact |
Multiple deliverable files | JSONL, reports, coverage logs |
promptkit-pull-request |
PromptKit contribution | PR-ready component files and manifest update |
pipeline-spec |
Pipeline specification | CI/CD YAML, rationale, deployment notes |
triage-report |
Triage report | Prioritized items by priority and effort |
release-notes |
Release notes | Changelog, breaking changes, upgrade instructions |
agent-instructions |
Agent instruction file | Copilot skill files, CLAUDE.md, .cursorrules |
implementation-plan |
Implementation plan | Task breakdown, dependencies, risk assessment |
north-star-document |
North-star document | Vision, guiding principles, transition considerations |
structured-findings |
Structured findings | Classified diagnostics with remediation guidance |
exhaustive-review-report |
Exhaustive review report | Per-file coverage ledgers, falsification proof |
protocol-delta |
Protocol delta | Specification amendments, tracked changes, redlines |
protocol-validation-spec |
Protocol validation spec | Conformance tests, state machine coverage |
rfc-document |
RFC document | xml2rfc v3 XML for internet-drafts |
behavioral-model |
Behavioral model | State machines, flow graphs, invariant catalogs |
interface-contract |
Interface contract | Per-resource guarantees, obligations, failure modes |
architecture-spec |
Architecture specification | System description, interfaces, cross-cutting concerns |
| Name | Domain | Description |
|---|---|---|
stack-lifetime-hazards |
Memory safety | H1–H5 labels for stack escape and lifetime violations |
specification-drift |
Specification traceability | D1–D16 labels for cross-document drift and divergence |
cpp-review-patterns |
C++ code review | 19 pattern labels across memory, concurrency, API, performance |
kernel-defect-categories |
Kernel correctness | K1–K14 labels for OS kernel and driver defects |
protocol-change-categories |
Protocol engineering | PC1–PC8 labels for protocol specification changes |
Document Authoring (16 templates):
| Name | Description |
|---|---|
author-requirements-doc |
Generate requirements from a description |
author-architecture-spec |
Generate architecture specification for a system |
interactive-design |
Multi-phase interactive design session |
author-north-star |
Interactive north-star / vision document authoring |
author-design-doc |
Generate design doc from requirements |
author-validation-plan |
Generate test plan from requirements |
reverse-engineer-requirements |
Extract requirements from existing source code |
audit-traceability |
Cross-document specification drift audit |
audit-code-compliance |
Audit source code against requirements/design |
audit-test-compliance |
Audit test code against validation plan |
audit-integration-compliance |
Audit cross-component integration points |
audit-spec-invariants |
Adversarial spec analysis against invariants |
diff-specifications |
Compare two specification versions at invariant level |
author-interface-contract |
Generate interface contract between components |
audit-interface-contract |
Audit interface contract completeness |
validate-budget |
Validate quantitative analysis against spec constraints |
Standards (4 templates):
| Name | Description |
|---|---|
extract-rfc-requirements |
Extract structured requirements from RFCs |
reconcile-requirements |
Reconcile multiple requirements sources into unified spec |
extract-invariants |
Extract invariants from specifications or source code |
author-rfc |
Author RFC / internet-draft in xml2rfc v3 format |
Code Generation (3 templates):
| Name | Description |
|---|---|
author-implementation-prompt |
Produce prompt for spec-compliant code generation |
author-test-prompt |
Produce prompt for spec-compliant test generation |
author-workflow-prompts |
Generate multi-agent workflow prompt assets |
Investigation (6 templates):
| Name | Description |
|---|---|
investigate-bug |
Root cause analysis of defects |
find-and-fix-bugs |
Autonomous bug-finding and fixing workflow |
fix-compiler-warnings |
Systematic batch remediation of compiler warnings |
investigate-security |
Security audit of code or system component |
profile-session |
Analyze LLM session log for token inefficiencies |
classify-findings |
Classify findings against a reference catalog |
Code Analysis (8 templates):
| Name | Description |
|---|---|
review-code |
Code review for correctness, safety, security |
review-cpp-code |
C/C++ specialized review with best practices |
exhaustive-bug-hunt |
Deep adversarial line-by-line code review |
reconstruct-behavior |
Extract behavioral model from engineering artifacts |
review-schematic |
Audit schematic/netlist against requirements and datasheets |
validate-simulation |
Review simulation output against spec constraints |
review-bom |
Audit BOM against schematic, ratings, sourcing |
review-layout |
Audit PCB layout against schematic intent |
Testing (2 templates):
| Name | Description |
|---|---|
discover-tests-for-changes |
Find relevant tests for local code changes |
scaffold-test-project |
Scaffold test project with build and runner setup |
Planning (2 templates):
| Name | Description |
|---|---|
plan-implementation |
Implementation task breakdown with dependencies |
plan-refactoring |
Safe, incremental refactoring plan |
Agent Authoring (1 template):
| Name | Description |
|---|---|
author-agent-instructions |
Assemble PromptKit components into agent skill files |
Contribution (2 templates):
| Name | Description |
|---|---|
extend-library |
Guide contributor through building new components |
audit-library-consistency |
Audit PromptKit library for overlap and inconsistency |
DevOps (7 templates):
| Name | Description |
|---|---|
author-pipeline |
Generate production-ready CI/CD pipeline |
triage-issues |
Triage and prioritize open issues |
triage-pull-requests |
Triage open pull requests for review |
root-cause-ci-failure |
Investigate failing CI/CD pipeline run |
author-release |
Generate structured release notes |
review-infrastructure |
Review infrastructure-as-code |
generate-commit-message |
Generate structured commit message from staged changes |
Protocol Engineering (3 templates):
| Name | Description |
|---|---|
evolve-protocol |
Interactive protocol evolution session |
analyze-protocol-conflicts |
Compare protocol specs for conflicts |
author-protocol-validation |
Derive validation spec from protocol spec |
promptkit/
├── README.md # This file
├── CONTRIBUTING.md # Guidelines for extending the library
├── TESTING.md # Prompt unit testing methodology
├── manifest.yaml # Index of all components
├── bootstrap.md # Meta-prompt entry point
├── LICENSE # MIT license
├── personas/ # LLM identity definitions
├── protocols/ # Reasoning and analysis protocols
│ ├── guardrails/ # Cross-cutting safety protocols
│ ├── analysis/ # Domain-specific analysis protocols
│ └── reasoning/ # General reasoning protocols
├── formats/ # Output structure definitions
├── taxonomies/ # Domain-specific classification schemes
├── templates/ # Task templates (compose other layers)
├── cli/ # npx CLI package
│ ├── bin/cli.js # Entry point
│ ├── lib/ # Manifest parsing, assembly, CLI launch
│ └── content/ # Bundled content (generated, gitignored)
└── tests/ # Prompt unit tests
├── references/ # Known-good reference prompts
└── generated/ # PromptKit-generated prompts for comparison
All components use Markdown with YAML frontmatter:
---
name: template-name
description: What this template does
persona: persona-name
protocols:
- protocol-path
format: format-name
params:
param_name: "Description of parameter"
input_contract:
type: artifact-type
description: What input this template expects
output_contract:
type: artifact-type
description: What this template produces
---
# Template body in Markdown
Instructions and content here.
Use {{param_name}} for parameter placeholders.The library is versioned as a unit via git tags (e.g., v0.1.0).
Individual components are not independently versioned — use git history
to access older versions of any component.
See LICENSE file for details.
