v0.4.0 — verification pass, register, and a fingerprint gate

Three of the forty-two prompts in this library have been run against a real
codebase. This release publishes the process behind that, including the parts
of the process that went wrong.

What "verified" means, exactly: the prompt was run against a real codebase
and the run produced anti-patterns it did not already contain. It is not a
score, and a prompt nobody has run is not a suspect one.

Verified (3):

• platform-engineering — two Kubernetes repositories, an earlier pass
• backend-services — production code where many services implement one contract
• data-platforms — a private production system whose data path is an
  operational streaming plane rather than a warehouse

The other thirty-nine have not been run, and each is named individually in
the register so the absence is on the record rather than inferred from a
summary. jvm-backend is the one not simply waiting on time: no codebase with a
JVM service layer was available to run it against, and its row says that.

Two caveats worth more than the tick. data-platforms was run against a
streaming system, so the warehouse half of that prompt — columnar storage, file
formats, compaction, query plans, per-dataset cost — has no evidence behind it,
and nothing was written about it. The absence of findings there is not coverage.
And platform-engineering's corpus was public rather than private, which is a
different kind of evidence.

Also in this release

• docs/verification.md — a register with one row per prompt
• docs/worked-example.md — one prompt end to end, including what it got wrong
• A Verified column in the generated index, so a reader can tell at a glance
• check_no_fingerprint.py — CI now fails if a committed file names a private
  codebase. It catches names, paths, and commit hashes; it does not catch
  magnitudes, and that limit is documented rather than hidden

The findings were derived from a private system and are published in generalised
form. No name, path, count, or product from that codebase appears in this
repository or its history.

Full detail in CHANGELOG.md.

v0.3.1 — maintenance and repositioning

The library is no longer presented as a trading library, and a confidential
name is gone from the entire git history.

Repositioning. 26 of the 42 prompts are non-trading, across eight areas,
and the audience is anyone wiring an agent into a codebase. The README, the
site nav, and the site front page all led with financial trading instead. A
42-prompt library was reading as a 16-prompt one.

• README leads with the count, the eight areas, and the agent-tool audience
• Nav leads with architecture and application; Financial Engineering moves last
• New framing: these are system prompts, not user prompts; how to pick one by
  mode; how to compose several for multi-area work

The financial prompts are unchanged and remain the depth differentiator.

History rewrite. A project name was in 2,016 file instances across 4
commits, 3 commit messages, and one filename. All rewritten; verified zero
occurrences across every commit, message, path, and tag. The four release
notes were already clean.

Corrections. Mode table said 30/7 against an actual 32/8. The browse
section said 38 prompts, wrong in every release since 0.1.0. Repository
description carried the old 38-prompt split.

Full detail in CHANGELOG.md.

v0.3.0 — four new prompts, three new categories

v0.3.0 — breadth, made visible

The library was broader than its positioning claimed. This release both
extends it and finally says so.

42 prompts. 4 new. 3 new categories.

Four new prompts

Prompt	Category	What it covers
platform-engineering.md	platform (new)	Kubernetes, packaging, GitOps, networking, policy, secrets, progressive delivery, cost
backend-services.md	architecture	Language-neutral service design: boundaries, idempotency, consistency, versioning, resilience
data-platforms.md	data (new)	Lakehouse, data contracts, late-arriving data, lineage, quality gates, cost
jvm-backend.md	java (new)	Spring Boot vs Quarkus vs Micronaut, persistence, concurrency, JVM operations

Why platform engineering

The audit found zero infrastructure prompts in a library whose owner runs
K3s, Talos, and ArgoCD. It is written around what breaks when an agent writes
it: drift from a hand-mutated cluster, secrets in a ConfigMap or an image
layer, a change reaching 100% in one step, and a PodDisruptionBudget ignored
during a routine node upgrade.

Why backend services is language-neutral

The cross-stack claim was an assertion until this existed. Every
recommendation is a property of the operation rather than of a stack:
idempotency belongs to the operation, not the caller; a timeout means
unknown, not failed; a shared write needs a precondition; retries need a
budget and jitter. It names no language framework deliberately.

Why the JVM prompt is a comparison

The audit found Java was the only genuinely absent language, and the request
was for a comparison rather than a Spring manual. Each framework is stated
with its cost: Spring for ecosystem breadth, Quarkus for startup and native
image against a steeper extension model, Micronaut for compile-time DI
against the smallest ecosystem of the three.

Breadth, generated rather than claimed

A new Browse by Language table is generated from frontmatter, split on
implementation languages only, with framework and platform tags excluded so a
developer searching for their stack does not miss architecture or testing.

	Prompts
Go	17
Python	7
TypeScript	2
Any stack	16

Generating it also caught a mis-tagged prompt: llm-integration.md has 15
Python code blocks and no python tag. Fixed, which moved the "any stack"
count from 17 to 16. Three other candidates were checked and are genuinely
multi-language, so the number is honest rather than convenient.

Metadata

Description now leads with cross-stack practice rather than Go. Topics went
from 15 to 20, adding java, python, typescript, software-architecture,
and kubernetes. golang and aws stay — they are real search hooks.

Enforcement

All four new prompts carry anti-patterns and guardrails from the start, so
check_prompt_sections.py gates them like any other. Verified by injection:
stripping the guardrails from jvm-backend.md produces a non-zero exit
naming the file.

42 prompts, 44 pages, 2815 internal links resolve, all three structural
checks pass.

Also worth reading

The 0.1.1 section still documents the four wrong vendor facts corrected after
the first release. If you built an adapter from v0.1.0, read it before
trusting any value.

License

MIT.

v0.2.0 — anti-patterns and guardrails in every prompt

v0.2.0 — the judgement sections

Every one of the 38 prompts now carries the two sections README.md and
CONTRIBUTING.md present as what makes a prompt worth reading over a wall of
prose:

• Anti-Patterns (Never Do These)
• Guardrails

No new prompts in this release, and no existing guidance removed. This adds
the part that was missing.

What was actually missing

Measurement before the work, not after:

	Count
Had both sections	17
Had one	14
Had neither	7

The 7 with neither included every broker SDK prompt — the files a reader is
most likely to trust on name alone.

What the sections say

The anti-patterns name failures a given prompt's subject can actually
produce, not generic advice. Examples:

• IBKR — treating Client Portal as a remote hosted API when it is a local
  bridge at localhost:5000; assuming live and paper are separable when the
  API mirrors whichever account TWS holds; retrying a timed-out order
  request, converting an unknown order state into a duplicate.
• Futu — inferring binary frame layouts from observed traffic, which
  breaks silently on upgrade and corrupts orders rather than reads; reusing a
  request serial after reconnect, matching a stale response to a new request.
• trading-risk — hard-coding a maintenance margin threshold that is
  actually a per-broker, per-account-type mandate.
• event-driven — publishing before the transaction commits; treating
  at-least-once as exactly-once; a side effect in a consumer with no
  idempotency key.

The guardrails are written as checks that can fail:

• trip the kill switch in a test and assert no order reaches the broker
• inject a timeout after submission and assert reconciliation, not a retry
• prove redaction with a test that scans everything the suite emits
• inject gaps and duplicates and assert resnapshot, not a plausible book
• measure trade-direction accuracy against a labelled sample, because VPIN
  inherits that error

Shared gates, stated once

All seven broker prompts independently restated the same items — quality
gates, fuzz, redaction, the compatibility matrix, the live-trading gate,
bounded allocation, order reconciliation. Seven restatements drift seven
ways, so the ten venue-independent gates now live once in sdk-build.md
under Cross-Cutting Guardrails. Each broker prompt keeps the gates that
are genuinely its own.

Two gates are not in any broker prompt and are new:

• bound allocation before the allocation happens, not after reading a
  length field
• prove redaction with a test, because redaction asserted in prose is not
  redaction

CI now enforces all three

Check	Catches
check_nav.py	a prompt that renders but is missing from the sidebar
check_vendor_claims.py	vendor internals asserted as fact; risk thresholds stated as rules
check_prompt_sections.py	a prompt shipping without either section

Every check is proven to fail by injection, not merely to pass. Five of the
defects found in the checks themselves were found this way — including one
that passed when it should have failed, and a discharge window that let one
config entry's framing excuse a neighbour's hard-coded value.

The section check is structural only. A prompt can pass it and still be
filler, and the script says so in its own docstring. What it prevents is the
next prompt shipping without the sections, which is how the gap opened.

Also in this release

The 0.1.1 corrections are included, and the 0.1.1 changelog section
remains the reference for the four wrong vendor facts. If you built an
adapter from v0.1.0, read it before trusting any of the values.

License

MIT.

v0.1.1 — vendor fact corrections

Correction release. No new prompts — v0.1.0 shipped facts that were wrong, and this release fixes them.

If you cloned or built an adapter from v0.1.0, check it against vendor
documentation before trusting it.

What was wrong

prompts/broker-integration.md carried a per-broker adapter table asserting
endpoints, auth schemes, and capabilities as fact, with no provenance note.
Four were wrong:

	v0.1.0 said	Corrected to
Longbridge endpoint	openapi.longbridgeapp.com (404)	openapi.longbridge.com, with separate WebSocket hosts for quote and trade
Longbridge auth	HMAC-SHA256, X-Broker-Id headers	OAuth 2.0 by default; API-key signature is a legacy fallback
Tiger endpoint	openapi.tigerbroker.com (does not resolve)	openapi.tigerfintech.com
Tiger auth	Tiger-Open-API-Key + X-Signature	private-key signature, not header-based HMAC
Webull endpoint	openapi.webull.com (does not resolve)	api.webull.com, plus separate gRPC and streaming hosts
Webull auth	OAuth2-like token flow	HMAC-SHA1 with x-app-key / x-signature, plus a reusable token

Also retracted: "Webull does NOT support order cancellation via API." The
current API exposes order place, replace, and cancel together.

Two corrections were independently confirmed against working Go clients in
this workspace, which is stronger evidence than any documentation page:
webullapi4go uses api.webull.com, data-api.webull.com,
events-api.webull.com, x-app-key, x-signature; longbridge-go-demo
uses openapi.longbridge.com and the two WebSocket hosts. Every one of those
contradicted the published prompt.

What else changed

• trading-risk.md had the same class of error, carrying actual money. It
  asserted > 90% utilized = margin call imminent, max drawdown > 10%, and
  a 25% position cap as constants. Maintenance margin varies by broker, by
  account type, by instrument, and by market. The const block is now
  explicitly per-broker configuration; the risk limits are framed as mandates
  rather than rules.
• broker-webull.md carried the same SHA256 error and was framed as a
  Hong Kong API when the published OpenAPI is US-market.
• broker-vbroker.md now says plainly that no public developer portal
  could be located and that its specifics are unverified.
• sdk-docs.md told the agent to document "all supported auth schemes" as
  a flat checklist, inventing auth documentation for an SDK that may use none
  of them.

Enforcement

scripts/check_vendor_claims.py now runs in CI and fails a prompt that:

• asserts vendor auth internals without an instruction to verify them, or
  cites a doc URL that belongs to a different vendor than the file names
• states a risk threshold as a rule without nearby framing that it is
  configurable, and will not let one config entry's framing discharge a
  neighbour's

Every rule is verified by injection, not just by passing. Six negative tests
cover stripped verification wording, hard-coded auth claims, cross-vendor
citation mismatches, and unframed threshold blocks.

Audit scope

Covered the 12 prompts that hard-code broker or exchange specifics: the nine
broker-* prompts, the two sdk-* prompts, and the risk-management prompt.
The other 26 were reviewed and carry no vendor claims — they are
principle-based rather than tied to a particular API, so this audit says
nothing about the correctness of their technical judgement.

License

MIT.

v0.1.0

First public release.

38 agentic-AI prompts for software project delivery, built around
financial trading systems, Go backend development, and AWS cloud
infrastructure. MIT licensed.

Browse: https://shing1211.github.io/prompt-engineering/

What is in it

19 of the 38 prompts cover multi-broker trading systems — the vertical
wedge, and the reason this library is not another generic prompt collection:

• Broker SDKs, one prompt per venue: Longbridge, Tiger Trade, Webull, IBKR
  Client Portal, Futu OpenD, Hua Sing Tong vbroker, plus a generic HMAC pattern
• Consolidated L2 tape from six brokers into MSK, Redis, and S3
• Market microstructure: VPIN, order flow imbalance, arbitrage detection
• Intraday risk: VaR/CVaR, drawdown controls, margin calls, Greeks, kill switch
• Money correctness: multi-currency PnL, corporate actions, reconciliation
• MiFID II best execution, trade surveillance, audit trails

The other 19 are the cross-cutting practice behind that work: architecture,
API design, testing, security, performance, observability, migration,
incident response.

Corrections after this release

The v0.1.0 notes were published before a full audit of the broker prompts.
The audit found that broker-integration.md carried a per-broker adapter table
asserting endpoints and auth schemes as fact, and four of them were wrong:

	Published in v0.1.0	Corrected
Longbridge endpoint	openapi.longbridgeapp.com (404)	openapi.longbridge.com, with separate WebSocket hosts for quote and trade
Longbridge auth	HMAC-SHA256, X-Broker-Id headers	OAuth 2.0 by default; API-key signature is a legacy fallback
Tiger endpoint	openapi.tigerbroker.com (does not resolve)	openapi.tigerfintech.com
Tiger auth	Tiger-Open-API-Key + X-Signature	private-key signature, not HMAC headers
Webull endpoint	openapi.webull.com (does not resolve)	api.webull.com, plus separate gRPC and streaming hosts
Webull auth	OAuth2-like token flow	HMAC-SHA1 signature with x-app-key / x-signature, plus a reusable token

Also retracted: the claim that "Webull does NOT support order cancellation
via API". The current API exposes order place, replace, and cancel together.

trading-risk.md had the same class of error: broker-specific maintenance
margin thresholds presented as universal constants ("> 90% utilized = margin
call imminent", "max drawdown > 10%"). These are mandates that vary by broker,
account type, instrument, and market.

If you built an adapter from the v0.1.0 table, check it against the vendor
documentation before trusting it. The corrected table is in
prompts/broker-integration.md, with a working doc root per vendor, and every
broker prompt now carries an instruction to verify its specifics. CI enforces
this via scripts/check_vendor_claims.py.

Notable fixes made in getting this public

• 15 of 39 files had CRLF endings, split against the rest. Normalized, and
  .gitattributes plus .editorconfig now prevent recurrence.
• 62 [reference:N] artifacts removed from two prompts — generation noise
  that read as broken citations on a rendered page.
• Heading hierarchy in 19 prompts. Several used # for what were really
  top-level sections, so each document had multiple H1s and the generated
  table of contents listed the title three times. 455 headings fixed.
• Stale model pins unpinned to model: any.
• Counts made generated rather than hand-maintained, after they drifted.

Every check is proven to fail

Validation is verified by injection, not just by passing. A bad mode value,
a missing category, a malformed tag, a title/H1 mismatch, a hand-edited
count, a broken link, a prompt missing from the site nav, and a second H1 in
a document each produce a non-zero exit naming the file.

scripts/validate.sh

Contributing

Proposals go in an issue via the Prompt idea form; finished prompts go
straight to a pull request. CONTRIBUTING.md has the frontmatter contract
and review criteria. Adding a prompt touches three files, and the one that's
easy to miss is the site nav entry.

License

MIT. Use them, fork them, adapt them.