keploy-pr-workflow

name	keploy-pr-workflow
description	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.

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 [e-mail], 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.