keploy-pr-workflow
When to use
- About to run
gh pr create, gh pr edit, or gh issue create.
- Writing a commit message that will land in
main.
- Reviewing your own diff before pushing.
- Copying error output, logs, or sample data into a PR description, issue, test
fixture, or README.
1. Customer-data hygiene (non-negotiable)
Keploy records real user applications. Traces, mocks, recordings, and logs
routinely carry customer data — headers with auth tokens, bodies with PII,
internal hostnames, request IDs that map back to users. Treat every fixture,
log snippet, and error dump as tainted until you've checked it.
Before anything leaves your machine, scrub for:
- Credentials — API keys, bearer tokens, JWTs, DB passwords, session
cookies, OAuth client secrets, AWS/GCP/Azure keys. If a test needs one,
read from env; use placeholders in docs (
sk-xxxxxxxx, Bearer <token>).
- Internal hostnames and URLs —
*.internal, *.prod, *.corp, real
company domains. Use example.com, httpbin.org, or loopback in samples.
- IP addresses that aren't RFC1918 / loopback / TEST-NET — assume any
public IP in a log is traceable. Replace with
192.0.2.1 (TEST-NET-1).
- User identifiers — emails, usernames, account IDs, order IDs, customer
names. Substitute with
user@example.com, user-123, etc.
- Request/trace IDs — these tie back to real traffic in observability
systems. Redact them from pasted logs.
- Real recorded traffic — never commit a customer's
keploy/test-set-*
directory. Even anonymized ones tend to keep giveaways in paths or timings.
If you need sample recordings, generate them against samples-go,
samples-python, etc.
- Stack traces from production runs — they leak file paths, binary
versions, and sometimes in-memory values.
If you're unsure whether something is customer-derived, it is. Err on the
side of redaction — you can always add detail back, you can't un-publish.
2. Commit messages
Format: <type>(<scope>): <subject> — Conventional Commits, enforced by
commitizen via .pre-commit-config.yaml.
Types: feat, fix, docs, style, refactor, test, chore.
Rules:
- Subject in present tense, imperative mood.
fix: resolve null pointer on test-set reset, not fixed or fixes.
- Every commit includes a body — blank line after the subject, then a
paragraph describing what changed and why. Mandatory even for
one-liners.
- Sign off with
git commit -s. Let git read identity from config; don't
hand-construct the Signed-off-by trailer.
3. PR/issue title and body
The PR/issue template should match the template that is being used in the repository that we are working in.
4. Destructive git operations
Never, without explicit user approval:
git push --force to main (or any shared branch).git reset --hard / git clean -fd on a branch with uncommitted work.git branch -D on anything not your own local branch.- Rebase across other contributors' published commits.
When in doubt, ask. Destructive ops are cheap to confirm and expensive to
undo.
5. Issues
When filing or commenting on an issue:
- Same customer-data rules apply — scrub logs before pasting.
- Include: keploy version (
keploy --version), OS/arch, the exact command
you ran, and whether it reproduces in Docker vs native.
- If you're attaching a recording to reproduce, regenerate it against a
public sample app; never attach a customer's test-set.
Related skills
keploy-e2e-test — verify a behavior change against a real sample before
opening the PR.
1---2name: keploy-pr-workflow3description: Guide for creating PRs and issues on keploy repositories — PR format, customer-data hygiene, commit conventions, sign-off. Invoke when the user asks to open, update, or review a pull request or issue, when preparing a commit that will land in main, or whenever a change is about to leave the local machine.4---56# keploy-pr-workflow78## When to use910- About to run `gh pr create`, `gh pr edit`, or `gh issue create`.11- Writing a commit message that will land in `main`.12- Reviewing your own diff before pushing.13- Copying error output, logs, or sample data into a PR description, issue, test14 fixture, or README.1516## 1. Customer-data hygiene (non-negotiable)1718Keploy records real user applications. Traces, mocks, recordings, and logs19routinely carry customer data — headers with auth tokens, bodies with PII,20internal hostnames, request IDs that map back to users. Treat every fixture,21log snippet, and error dump as tainted until you've checked it.2223Before anything leaves your machine, scrub for:2425- **Credentials** — API keys, bearer tokens, JWTs, DB passwords, session26 cookies, OAuth client secrets, AWS/GCP/Azure keys. If a test needs one,27 read from env; use placeholders in docs (`sk-xxxxxxxx`, `Bearer <token>`).28- **Internal hostnames and URLs** — `*.internal`, `*.prod`, `*.corp`, real29 company domains. Use `example.com`, `httpbin.org`, or loopback in samples.30- **IP addresses that aren't RFC1918 / loopback / TEST-NET** — assume any31 public IP in a log is traceable. Replace with `192.0.2.1` (TEST-NET-1).32- **User identifiers** — emails, usernames, account IDs, order IDs, customer33 names. Substitute with `user@example.com`, `user-123`, etc.34- **Request/trace IDs** — these tie back to real traffic in observability35 systems. Redact them from pasted logs.36- **Real recorded traffic** — never commit a customer's `keploy/test-set-*`37 directory. Even anonymized ones tend to keep giveaways in paths or timings.38 If you need sample recordings, generate them against `samples-go`,39 `samples-python`, etc.40- **Stack traces from production runs** — they leak file paths, binary41 versions, and sometimes in-memory values.4243If you're unsure whether something is customer-derived, it is. Err on the44side of redaction — you can always add detail back, you can't un-publish.4546## 2. Commit messages4748Format: `<type>(<scope>): <subject>` — Conventional Commits, enforced by49`commitizen` via `.pre-commit-config.yaml`.5051Types: `feat`, `fix`, `docs`, `style`, `refactor`, `test`, `chore`.5253Rules:5455- Subject in present tense, imperative mood. `fix: resolve null pointer on56 test-set reset`, not `fixed` or `fixes`.57- Every commit includes a body — blank line after the subject, then a58 paragraph describing **what changed and why**. Mandatory even for59 one-liners.60- Sign off with `git commit -s`. Let git read identity from config; don't61 hand-construct the `Signed-off-by` trailer.6263## 3. PR/issue title and body6465The PR/issue template should match the template that is being used in the repository that we are working in. 6667## 4. Destructive git operations6869Never, without explicit user approval:7071- `git push --force` to `main` (or any shared branch).72- `git reset --hard` / `git clean -fd` on a branch with uncommitted work.73- `git branch -D` on anything not your own local branch.74- Rebase across other contributors' published commits.7576When in doubt, ask. Destructive ops are cheap to confirm and expensive to77undo.7879## 5. Issues8081When filing or commenting on an issue:8283- Same customer-data rules apply — scrub logs before pasting.84- Include: keploy version (`keploy --version`), OS/arch, the exact command85 you ran, and whether it reproduces in Docker vs native.86- If you're attaching a recording to reproduce, regenerate it against a87 public sample app; never attach a customer's test-set.8889## Related skills9091- `keploy-e2e-test` — verify a behavior change against a real sample before92 opening the PR.
keploy