Developer workflow guides

$ debug-api-response

1. Paste the response into the JSON formatter to validate syntax and reveal exact parse errors.
2. Pretty-print the payload before sharing it with teammates so nested fields are readable.
3. Compare the failing response against a known-good response in the diff checker.
4. If the response contains a token-like value, decode only the non-secret parts you are allowed to inspect.
5. Remove API keys, cookies, user identifiers, and private data before copying the result into a ticket or chat.

$ ship-regex-change

1. Start with real examples that should match and real examples that must not match.
2. Test flags deliberately; global, multiline, and case-insensitive modes can change results dramatically.
3. Check capture groups by name or index so downstream code receives the expected values.
4. Test edge cases such as empty strings, whitespace, punctuation, Unicode, and very long input.
5. URL-encode the final pattern when it needs to be passed through a query parameter or configuration URL.

$ prepare-test-data

1. Generate UUID v4 values for sample records instead of reusing production identifiers.
2. Hash sample strings when you need deterministic placeholders without exposing the original value.
3. Use color conversion for design-system tokens and keep HEX, RGB, and HSL values together.
4. Label sample values clearly so nobody mistakes generated test data for real customer data.
5. Keep private source data out of online tools unless processing happens entirely in your browser, as DevPop does.

$ review-config-change

1. Paste old and new config into the diff checker to isolate the exact changed lines.
2. Format JSON or structured snippets before comparing so whitespace does not hide meaningful changes.
3. Use hashes to confirm whether two long values are identical without exposing the values themselves.
4. Look for accidental changes to URLs, feature flags, scopes, and expiration settings.
5. Remove secrets before sharing screenshots or copied output during code review.

$ markdown-release-notes

1. Preview headings, lists, tables, links, and code blocks before publishing release notes.
2. Compare draft versions to make sure important changes were not accidentally removed.
3. URL-encode links with special characters before embedding them in docs or query strings.
4. Check that code fences use the right language tag for syntax highlighting.
5. Read the rendered version, not just the raw Markdown, because users see the rendered output.