Claude Code PR ਰਿਵਿਊ: ਪ੍ਰੀ-ਰਿਵਿਊ ਨਾਲ ਡਿਫਜ਼ ਤੇਜ਼ ਅਤੇ ਸੁਰੱਖਿਅਤ

ਕਿਉਂ PR ਸਮੀਖਿਆ ਦਾ ਸਮਾਂ ਲੰਮਾ ਹੋ ਜਾਂਦਾ ਹੈ

PR ਸਮੀਖਿਆ ਆਮ ਤੌਰ 'ਤੇ ਇਸ ਕਰਕੇ ਲੰਮੀ ਨਹੀਂ ਹੁੰਦੀ ਕਿ ਕੋਡ "ਕਠਿਨ" ਹੈ। ਇਹ ਇਸ ਲਈ ਲੰਮੀ ਹੁੰਦੀ ਹੈ ਕਿ ਰਿਵਿਊਅਰ ਨੂੰ ਇੱਕ ਐਸੇ ਡਿਫ ਤੋਂ ਇਰਾਦਾ, ਖ਼ਤਰਾ ਅਤੇ ਪ੍ਰਭਾਵ ਦੁਬਾਰਾ ਬਣਾਉਣਾ ਪੈਂਦਾ ਹੈ ਜੋ ਸਿਰਫ ਤਬਦੀਲੀਆਂ ਦਿਖਾਉਂਦਾ ਹੈ, ਸਾਰੀ ਗੱਲ ਨਹੀਂ।

ਇੱਕ ਛੋਟੀ ਸੋਧ ਗੁਪਤ ਨਿਰਭਰਤਾਵਾਂ ਨੂੰ ਛੇੜ ਸਕਦੀ ਹੈ: ਇੱਕ ਫੀਲਡ ਦਾ ਨਾਮ ਬਦਲੋ ਅਤੇ ਰਿਪੋਰਟ ਟੁੱਟ ਸਕਦੀ ਹੈ, ਇੱਕ ਡਿਫਾਲਟ ਬਦਲੋ ਅਤੇ ਵਿਹਾਰ ਬਦਲ ਸਕਦਾ ਹੈ, ਇੱਕ ਸ਼ਰਤ ਸੁਧਾਰੋ ਅਤੇ ਐਰਰ ਹੈਂਡਲਿੰਗ ਪ੍ਰਭਾਵਿਤ ਹੋ ਸਕਦੀ ਹੈ। ਜਦੋਂ ਰਿਵਿਊਅਰ ਨੂੰ ਸੰਦਰਭ ਲਈ ਕਲਿਕ ਕਰਨਾ ਪੈਂਦਾ ਹੈ, ਐਪ ਨੂੰ ਲੋਕਲ ਚਲਾਉਣਾ ਪੈਂਦਾ ਹੈ, ਅਤੇ ਸਮਝਣ ਲਈ ਫਾਲੋ-ਅੱਪ ਸਵਾਲ ਪੁੱਛਣੇ ਪੈਂਦੇ ਹਨ ਕਿ PR ਦਾ ਮਕਸਦ ਕੀ ਹੈ, ਤਾਂ ਸਮੀਖਿਆ ਦਾ ਸਮਾਂ ਵੱਧ ਜਾਂਦਾ ਹੈ।

ਇੱਥੇ ਇੱਕ ਮਨੁੱਖੀ ਰੁਝਾਨ ਵੀ ਹੈ। ਲੋਕ ਡਿਫਜ਼ ਨੂੰ ਨਿਯਮਤ ਢੰਗ ਨਾਲ ਸਕੈਨ ਕਰਦੇ ਹਨ: ਅਸੀਂ "ਮੁੱਖ" ਤਬਦੀਲੀ ਉੱਤੇ ਧਿਆਨ ਦਿੰਦੇ ਹਾਂ ਅਤੇ ਬੋਰਿੰਗ ਲਾਈਨਾਂ ਨੂੰ ਛੱਡ ਦਿੰਦੇ ਹਾਂ ਜਿੱਥੇ ਬੱਗ ਲੁਕਿਆ ਹੋ ਸਕਦੇ ਹਨ (ਬਾਊਂਡਰੀ ਚੈੱਕ, ਨਲ ਹੈਂਡਲਿੰਗ, ਲੌਗਿੰਗ, ਸਫਾਈ)। ਅਸੀਂ ਉਹੀ ਪੜ੍ਹਨ ਦੀ ਆਦਤ ਬਣਾਉਂਦੇ ਹਾਂ ਜੋ ਅਸੀਂ ਉਮੀਦ ਕਰਦੇ ਹਾਂ, ਇਸ ਲਈ ਕਾਪੀ-ਪੇਸਟ ਗਲਤੀਆਂ ਅਤੇ ਉਲਟੀਆਂ ਸ਼ਰਤਾਂ ਬਿਨਾਂ ਨੋਟਿਸ ਦੇ ਰਹਿ ਸਕਦੀਆਂ ਹਨ।

ਅੱਛੀ ਪ੍ਰੀ-ਰਿਵਿਊ ਇੱਕ ਫੈਸਲਾ ਨਹੀਂ ਹੁੰਦੀ। ਇਹ ਤੇਜ਼, ਸੰਰਚਿਤ ਦੂਜੀ ਨਜ਼ਰ ਹੁੰਦੀ ਹੈ ਜੋ ਦੱਸਦੀ ਹੈ ਕਿ ਮਨੁੱਖ ਕਿੱਥੇ ਧੀਰੇ ਹੋ ਕੇ ਦੇਖੇ। ਸਭ ਤੋਂ ਵਧੀਆ ਨਤੀਜਾ ਇਹ ਹੋਵੇ:

• ਕੀ ਬਦਲਿਆ, ਇਸਦਾ ਸਾਦਾ-ਸਾਫ਼ ਸਾਰ
• ਖ਼ਾਸ ਖ਼ਤਰਾ ਵਾਲੇ ਬਿੰਦੂ (ਫਾਇਲਾਂ, ਫੰਕਸ਼ਨ, ਧਾਰਣਾਵਾਂ)
• ਪੜ੍ਹਨ ਯੋਗਤਾ ਨੋਟ (ਨਾਮ, ਗੁੰਝਲਦਾਰ ਕੰਟਰੋਲ ਫਲੋ)
• ਸਹੀ ਹੋਣ ਬਾਰੇ ਚਿੰਤਾਵਾਂ (ਲਾਜਿਕ, ਐਰਰ ਹੈਂਡਲਿੰਗ, ਡਾਟਾ ਸੰਗਤਤਾ)
• ਟੈਸਟ ਕਰਨ ਯੋਗ ਐਜ ਕੇਸ (ਇਨਪੁਟ, ਸਮਾਂ, ਪਰਮਿਸ਼ਨ, ਖਾਲੀ ਸਥਿਤੀਆਂ)

ਇਹ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ: PR ਨੂੰ "ਅਨੁਮোদਿਤ" ਕਰ ਦਿੱਤੇ ਜਾਣਾ, ਲੋੜਾਂ ਬਣਾਉਣਾ, ਜਾਂ ਬਿਨਾਂ ਸਬੂਤ ਦੇ ਰਨਟਾਈਮ ਵਿਹਾਰ ਦੀ ਅਨੁਮਾਨ ਲਗਾਉਣਾ। ਜੇ ਡਿਫ ਵਿੱਚ ਕਾਫੀ ਸੰਦਰਭ ਨਹੀਂ ਹੈ (ਉਮੀਦ ਕੀਤੀ ਇਨਪੁਟ, ਸੀਮਾਵਾਂ, ਕਾਲਰ ਕਾਂਟ੍ਰੈਕਟ), ਤਾਂ ਪ੍ਰੀ-ਰਿਵਿਊ ਨੂੰ ਇਹ ਗੱਲ ਆਖਣੀ ਚਾਹੀਦੀ ਹੈ ਅਤੇ ਵਾਜਬ ਤੌਰ 'ਤੇ ਰਹਿੰਦੀ ਗਈ ਚੀਜ਼ਾਂ ਦੀ ਸੂਚੀ ਦੇਣੀ ਚਾਹੀਦੀ ਹੈ।

AI ਸਹਾਇਤਾ ਸਭ ਤੋਂ ਮਜ਼ਬੂਤ ਹੈ ਉਹਨਾਂ ਮਧ्यम-ਆਕਾਰ PRs 'ਤੇ ਜੋ ਬਿਜ਼ਨਸ ਲੌਜਿਕ ਜਾਂ ਰੀਫੈਕਟਰ ਟਚ ਕਰਦੇ ਹਨ ਜਿੱਥੇ ਮੀਨਿੰਗ ਖੋ ਸਕਦੀ ਹੈ। ਇਹ ਉਸ ਵੇਲੇ ਘੱਟ ਫਾਇਦੇਮੰਦ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਸਹੀ ਉੱਦਿਦ ਸ਼ੈ ਜਾਣਕਾਰੀ ਤੇ منحصر ਹੋਵੇ (ਲੈਗਸੀ ਵਿਹਾਰ, ਪ੍ਰੋਡਕਸ਼ਨ ਪਰਫਾਰਮੈਂਸ ਖਾਸੀਅਤਾਂ, ਅੰਦਰੂਨੀ ਸੁਰੱਖਿਆ ਨਿਯਮ)।

ਉਦਾਹਰਨ: ਇੱਕ PR ਜੋ "ਸਿਰਫ pagination ਨੂੰ ਅਪਡੇਟ ਕਰਦਾ ਹੈ" ਅਕਸਰ ਆਫ-ਬਾਈ-ਵਨ ਪੇਜ, ਖਾਲੀ ਨਤੀਜੇ, ਅਤੇ API ਅਤੇ UI ਵਿੱਚ ਅਣਮੇਲਤ ਸੋਰਟਿੰਗ ਨੂੰ ਲੁਕਾਉਂਦਾ ਹੈ। ਇੱਕ ਪ੍ਰੀ-ਰਿਵਿਊ ਨੂੰ ਇਹ ਸਵਾਲ ਮਨੁੱਖ ਨੂੰ 30 ਮਿੰਟ ਬਰਬਾਦ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਉਠਾਉਣਾ ਚਾਹੀਦਾ ਹੈ।

ਪ੍ਰੀ-ਰਿਵਿਊ ਵਿੱਚ Claude ਨੂੰ ਕੀ ਪੁੱਛਣਾ ਹੈ

Claude ਨੂੰ ਇੱਕ ਤੇਜ਼, ਨੁਕਸਾਨ-ਖੋਜਕ ਪਹਿਲੀ-ਪਾਸ ਰਿਵਿਊਅਰ ਵਾਂਗ ਵਰਤੋ, ਉਸ ਵਿਅਕਤੀ ਵਾਂਗ ਨਹੀਂ ਜੋ ਫੈਸਲਾ ਕਰਦਾ ਹੈ ਕਿ PR ਸ਼ਿਪ ਹੋਵੇ। ਮਕਸਦ ਇਹ ਹੈ ਕਿ ਮੁਸ਼ਕਲੀਆਂ ਪਹਿਲਾਂ ਹੀ ਸਾਹਮਣੇ ਆ ਜਾਣ: ਗੁੰਝਲਦਾਰ ਕੋਡ, ਛੁਪਿਆ ਵਿਵਹਾਰ, ਗੁਮ ਹੋਏ ਟੈਸਟ, ਅਤੇ ਉਹ ਐਜ ਕੇਸ ਜਿਹੜੇ ਬਦਲਾਅ ਦੇ ਨੇੜੇ ਹੋਣ ’ਤੇ ਤੂਠ ਜਾਂਦੇ ਹਨ।

ਇਸਨੂੰ ਉਹੀ ਚੀਜ਼ ਦਿਓ ਜੋ ਇੱਕ ਨਿਆਇਕ ਮਨੁੱਖੀ ਰਿਵਿਊਅਰ ਨੂੰ ਚਾਹੀਦੀ ਹੈ:

• PR ਦਾ ਮਕਸਦ (1 ਤੋਂ 3 ਵਾਕ)
• ਕੀ ਨਹੀਂ ਟੁੱਟਣਾ ਚਾਹੀਦਾ (API ਆਕਾਰ, ਪਿੱਛੇ-ਅਨੁਕੂਲਤਾ, ਪ੍ਰਦਰਸ਼ਨ ਬਜਟ, ਸੁਰੱਖਿਆ ਨਿਯਮ)
• ਕੋਈ ਖ਼ਾਸ ਸੀਮਾ ਜਾਂ ਟਰੇਡ-ਆਫ (ਡੀਡਲਾਈਨ, ਹਿੱਸੇਵਾਰ ਰੋਲਆਊਟ)
• ਸੰਬੰਧਿਤ ਡਿਫ ਹੰਕਸ, ਇਰਾਦਾ ਸਮਝਣ ਲਈ ਕਾਫੀ ਆਸਪੈਸ਼ਿੰਗ ਕੋਡ ਨਾਲ

ਜੇ PR ਕਿਸੇ ਜਾਣੇ-ਪਛਾਣੇ ਖ਼ਤਰਨਾਕ ਖੇਤਰ ਨੂੰ ਛੂਹਦਾ ਹੈ ਤਾਂ ਪਹਿਲਾਂ ਹੀ ਕਹਿਣਾ (auth, billing, migrations, concurrency)।

ਫਿਰ ਐਸੇ ਨਤੀਜੇ ਮੰਗੋ ਜਿਨ੍ਹਾਂ ਉੱਤੇ ਤੁਸੀਂ ਕਾਰਵਾਈ ਕਰ ਸਕੋ। ਇੱਕ ਮਜ਼ਬੂਤ ਬੇਨਤੀ ਇਸ ਤਰ੍ਹਾਂ ਲੱਗਦੀ ਹੈ:

• ਸਧਾ-ਸਾਫ਼ ਅੰਗਰੇਜ਼ੀ ਵਿੱਚ ਕੀ ਬਦਲਿਆ, ਉਸ ਦਾ ਸਾਰ ਦਿਓ।
• ਪੜ੍ਹਨ ਯੋਗਤਾ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਝੰਡਾ ਲਗਾਓ (ਨਾਮਕਰਨ, ਬਣਤਰ, ਹੈਰਾਨੀਜਨਕ ਚੀਜ਼ਾਂ, ਬੇਲਗਾਮ ਉਪਰਾਲੇ)।
• ਸਹੀ ਹੋਣ ਦੇ ਖ਼ਤਰੇ ਪਛਾਣੋ (ਨਲ ਹੈਂਡਲਿੰਗ, ਐਰਰ ਪਾਥ, ਆਫ-ਬਾਈ-ਵਨ, ਡਾਟਾ ਆਕਾਰ ਅਣਮੈਚ)।
• ਟੈਸਟ ਕਰਨ ਯੋਗ ਏਜ ਕੇਸ ਅਤੇ ਫੇਲਿਊਰ ਮੋਡ ਦੀ ਸੂਚੀ ਦਿਓ (ਟਾਈਮਆਊਟ, ਰੀਟ੍ਰਾਈ, ਖਾਲੀ ਇਨਪੁਟ, ਅਧੂਰੇ ਅੱਪਡੇਟ)।
• ਗੁੰਮ ਹੋਏ ਟੈਸਟਾਂ ਦੀ ਸੁਝਾਵਾਂ ਅਤੇ ਹਰ ਟੈਸਟ ਕੀ ਸਬੂਤ ਦਿੰਦਾ ਹੈ, ਦਿਓ।
• ਇੱਕ ਛੋਟੀ ਰਿਵਿਊਅਰ ਚੈੱਕਲਿਸਟ ਅਤੇ ਮਿਲਾਓ 5 ਤੋਂ 10 "ਪ੍ਰਸ਼ਨ ਜੋ ਲਾਉਣੇ" ਬਣਾਓ ਜੋ ਮਰਜ ਤੋਂ ਪਹਿਲਾਂ ਪੁੱਛਣੇ ਜਾਣ।

ਮਨੁੱਖ ਨੂੰ ਫੈਸਲਾ ਕਰਨ ਵਾਲਾ ਰੱਖਣ ਲਈ ਅਸਪਸ਼ਟਤਾ 'ਤੇ ਸਪਸ਼ਟਤਾ ਜ਼ੋਰ ਦਿਓ। Claude ਨੂੰ ਆਮ ਮੌਕਿਆਂ ਨੂੰ "ਡਿਫ ਤੋਂ ਨਿਸਚਿਤ" ਅਤੇ "ਪਸ਼ਟੀਕਰਨ ਦੀ ਲੋੜ" ਵਜੋਂ ਲੇਬਲ ਕਰਨ ਅਤੇ ਹਰ ਚਿੰਤਾ ਨੂੰ ਟ੍ਰਿਗਰ ਕਰਨ ਵਾਲੀਆਂ ਠੀਕ ਲਾਈਨਾਂ ਨੂੰ ਕੋਟ ਕਰਨ ਲਈ ਕਹੋ।

ਪ੍ਰਾਂਪਟ ਅੱਗੇ ਪੇਸ਼ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਡਿਫ ਅਤੇ ਸੰਦਰਭ ਤਿਆਰ ਕਰੋ

Claude ਸਿਰਫ਼ ਉਸੀ ਗੱਲ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਦਿਖਾਉਂਦੇ ਹੋ। ਜੇ ਤੁਸੀਂ ਇੱਕ ਵੱਡਾ ਡਿਫ ਬਿਨਾਂ ਮਕਸਦ ਜਾਂ ਸੀਮਾ ਦੇ ਪੇਸਟ ਕਰੋਗੇ, ਤਾਂ ਤੁਹਾਨੂੰ ਜੈਨਰੇਲ ਸਲਾਹ ਮਿਲੇਗੀ ਅਤੇ ਅਸਲ ਖ਼ਤਰੇ ਛੁੱਟ ਜਾਣਗੇ।

ਇਕੱਠਾ ਹੋ ਕੇ ਇੱਕ ਮੌਜੂਦਾ ਮਕਸਦ ਅਤੇ ਸਫਲਤਾ ਮਾਪਦੰਡ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਉਦਾਹਰਨ ਲਈ: "ਇਹ PR ਲੌਗਿਨ ਐਂਡਪੌਇੰਟ 'ਤੇ ਰੇਟ ਲਿਮਿਟਿੰਗ ਸ਼ਾਮਲ ਕਰਦਾ ਹੈ ਤਾ ਕਿ ਦੁਰਵਰਤੋਂ ਰੁਕੀ ਜਾ ਸਕੇ। ਇਹ ਰਿਸਪਾਂਸ ਆਕਾਰ ਨਹੀਂ ਬਦਲਣਾ ਚਾਹੀਦਾ। ਔਸਤ ਲੇਟੈਂਸੀ 50 ms ਤੋਂ ਘੱਟ ਰਹੇ।"

ਅਗਲਾ, ਸਿਰਫ਼ ਉਹੀ ਸ਼ਾਮਲ ਕਰੋ ਜੋ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ। ਜੇ 20 ਫਾਇਲਾਂ ਵਿੱਚ ਤਬਦੀਲੀ ਹੈ ਪਰ ਸਿਰਫ਼ 3 ਵਿੱਚ ਲੌਜਿਕ ਹੈ, ਤਾਂ ਉਹੀ ਫੋਕਸ ਕਰੋ। ਜਦੋਂ ਇੱਕ ਸਨਿੱਪెట్ ਗੁੰਝਲਦਾਰ ਹੋਵੇ, ਤਦੋਂ ਆਸ-ਪਾਸ ਦਾ ਕੋਡ ਸ਼ਾਮਲ ਕਰੋ, ਜਿਵੇਂ ਫੰਕਸ਼ਨ ਸਿਗਨੇਚਰ, ਮੁੱਖ ਟਾਈਪ, ਜਾਂ کونਫਿਗ ਜੋ ਵਿਹਾਰ ਬਦਲ ਸਕਦਾ ਹੈ।

ਆਖਿਰ ਵਿੱਚ, ਟੈਸਟ ਦੀਆਂ ਉਮੀਦਾਂ ਬਾਰੇ ਸਪਸ਼ਟ ਰਹੋ। ਜੇ ਤੁਸੀਂ ਐਜ ਕੇਸ ਲਈ ਯੂਨਿਟ ਟੈਸਟ ਚਾਹੁੰਦੇ ਹੋ, ਇੱਕ ਅਹੰਕਾਰਕ ਰਸਤਾ ਟੈਸਟ ਜਾਂ ਮੈਨੂਅਲ UI ਰਨ-ਥਰੂ ਦੀ ਲੋੜ ਹੈ ਤਾਂ ਦੱਸੋ। ਜੇ ਟੈਸਟ ਇਰਾਦੀ ਤੌਰ 'ਤੇ ਗੁੰਮ ਹਨ, ਤਾਂ ਕਾਰਨ ਦੱਸੋ।

ਇੱਕ ਸਧਾਰਨ "ਕਾਨਟੈਕਸਟ ਪੈਕ" ਜੋ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ:

• PR ਮਕਸਦ: ਕੀ ਬਦਲ ਰਿਹਾ ਹੈ, ਉਪਭੋਗਤਾ ਕੀ ਦੇਖਣਗੇ, ਕੀ ਸੁਧਾਰੇਗਾ
• ਸੰਬੰਧਿਤ ਡਿਫ ਚੰਕ: ਮੁੱਖ ਫਾਇਲਾਂ, ਕਾਫੀ ਆਸਪੈਸ਼ਿੰਗ ਕੋਡ ਨਾਲ
• ਸਖ਼ਤ ਸੀਮਾਵਾਂ: ਪਰਫਾਰਮੈਂਸ, ਅਨੁਕੂਲਤਾ, ਸੁਰੱਖਿਆ/ਗੋਪਨੀਯਤਾ ਨਿਯਮ
• ਟੈਸਟ ਉਮੀਦਾਂ: ਕੀ ਕਵਰ ਹੋਣਾ ਚਾਹੀਦਾ, ਕੀ ਜੋੜਿਆ ਗਿਆ, ਕਿਵੇਂ ਚਲਾਉਣਾ ਹੈ
• "ਟੁੱਟਣਾ ਨਹੀਂ ਚਾਹੀਦਾ" ਚੀਜ਼ਾਂ: ਪਬਲਿਕ API ਕਾਂਟ੍ਰੈਕਟ, ਡੇਟਾਬੇਸ ਸਕੀਮਾ, UX ਵਿਹਾਰ, ਲੌਗਿੰਗ/ਆਡੀਟਿੰਗ ਫਾਰਮੈਟ

ਕਦਮ-ਬਾਇ-ਕਦਮ: ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲਾ ਪ੍ਰੀ-ਰਿਵਿਊ ਫਲੋ

ਇੱਕ ਚੰਗੀ Claude Code PR ਸਮੀਖਿਆ ਇੱਕ ਤਿੱਘ ਲੂਪ ਵਾਂਗ ਕੰਮ ਕਰਦੀ ਹੈ: ਕਾਫੀ ਸੰਦਰਭ ਦਿਓ, ਸੰਰਚਿਤ ਨੋਟ ਮਿਲਦੇ ਹਨ, ਫਿਰ ਉਹਨਾਂ ਨੂੰ ਕਾਰਵਾਈ ਵਿੱਚ ਬਦਲੋ। ਇਹ ਮਨੁੱਖਾਂ ਦੀ ਥਾਂ ਨਹੀਂ ਲੈਂਦੀ। ਇਹ ਆਸਾਨ ਖ਼ਤਿਆਂ ਨੂੰ ਫੜ ਲੈਂਦੀ ਹੈ ਜਦੋਂ ਇਕ ਸਾਥੀ ਲੰਮਾ ਸਮਾਂ ਲਗਾ ਕੇ ਪੜ੍ਹ ਰਿਹਾ ਹੋਵੇ।

5-ਪਾਸ ਫਲੋ

ਹਰ ਵਾਰੀ ਇੱਕੋ ਹੀ ਪਾਸ ਵਰਤੋ ਤਾਂ ਜੋ ਨਤੀਜੇ ਨਿਯਮਤ ਰਹਿਣ:

1. ਬਦਲਾਅ ਨੂੰ ਸਧੇ-ਸਾਫ਼ ਭਾਸ਼ਾ ਵਿੱਚ ਸਮਝਾਓ। Claude ਨੂੰ ਪੁੱਛੋ ਕਿ PR ਕੀ ਕਰਦਾ ਹੈ, ਕਿਹੜੀਆਂ ਫਾਇਲਾਂ ਬਦਲੀ ਹਨ, ਅਤੇ ਬਦਲਾਅ ਦਾ ਲਿਕੜਾ ਕੀ ਹੋ ਸਕਦਾ ਹੈ। ਜੇ ਇਹ ਸਾਦੀ ਤਰ੍ਹਾਂ ਸਮਝਾ ਨਹੀਂ ਸਕਦਾ, PR ਨੂੰ ਵਧੇਰੇ ਸੁਜ਼ਾਅ ਜਾਂ ਛੋਟਾ ਦਾਇਰਾ ਚਾਹੀਦਾ ਹੈ।
2. ਪਹਿਲਾਂ ਸਹੀ ਹੋਣ ਜਾਂਚੋ। ਲਾਜਿਕੀ ਗਲਤੀਆਂ, ਟੁੱਟੀਆਂ ਧਾਰਣਾਵਾਂ, ਅਤੇ ਖ਼ਾਮੋਸ਼ ਵਿਹਾਰ ਬਦਲਾਅ (ਡਿਫਾਲਟ, ਐਰਰ ਹੈਂਡਲਿੰਗ, ਪਰਮਿਸ਼ਨ, ਸਮਾਂ ਜ਼ੋਨ, ਆਫ-ਬਾਈ-ਵਨ) ਖੋਜੋ।
3. ਗੁਆਚੇ ਕੇਸਾਂ ਦੀ ਸਕੈਨ ਕਰੋ। ਉਪਭੋਗਤਾ ਅਤੇ ਪ੍ਰੋਡਕਸ਼ਨ ਦੀ ਨਜ਼ਰ ਨਾਲ ਸੋਚੋ: ਖਾਲੀ ਇਨਪੁਟ, ਨਲ, ਰੀਟ੍ਰਾਈ, ਅਧੂਰੇ ਫੇਲਿਊਰ, ਕਨਕਰੈਂਸੀ, ਪਿੱਛੇ-ਅਨੁਕੂਲਤਾ।
4. ਪੜ੍ਹਨ ਯੋਗਤਾ ਅਤੇ ਨੂੰ-ਅਪਕੀਪ-ਪੈਲੋਚ ਕਰੋ। ਗੁੰਝਲਦਾਰ ਨਾਮ, ਲੰਬੇ ਫੰਕਸ਼ਨ, ਨਕਲ ਲਾਜਿਕ, ਅਸਪਸ਼ਟ ਟਿੱਪਣੀਆਂ, ਅਤੇ ਸੂਖਮ ਰੀਫੈਕਟਰ ਜਿਹੜੇ ਭਵਿੱਖ ਦੀ ਸਮੀਖਿਆ ਘਟਾਉਂਦੇ ਹਨ, ਪਛਾਣੋ।
5. ਸੂਚੀਆਂ ਵਾਲੇ ਟਿੱਪਣੀਆਂ ਤਿਆਰ ਕਰੋ। ਟਿੱਪਣੀਆਂ ਨੂੰ ਫਾਇਲ ਅਨੁਸਾਰ ਗਰੁੱਪ ਕਰੋ ਅਤੇ ਫੰਕਸ਼ਨ ਨਾਂ ਜਾਂ ਕੋਟ ਕੀਤੀ ਸਨਿੱਪਟ ਸ਼ਾਮਲ ਕਰੋ ਤਾਂ ਕਿ ਮਨੁੱਖੀ ਰਿਵਿਊਅਰ ਤੁਰੰਤ ਉਸ ਸਥਾਨ ਤੱਕ ਪਹੁੰਚ ਸਕੇ।

ਨੋਟਾਂ ਮਿਲਣ ਦੇ ਬਾਅਦ, ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਛੋਟੀ ਮਰਜ ਗੇਟ ਵਿੱਚ ਬਦਲੋ:

ਮਰਜ ਚੈਕਲਿਸਟ (ਛੋਟੀ ਰੱਖੋ):

• ਨਵੇਂ ਵਿਹਾਰ ਅਤੇ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਏਜ ਕੇਸ ਲਈ ਟੈਸਟ ਹਨ
• ਐਰਰ ਇੱਕ ਸਥਿਰ ਢੰਗ ਨਾਲ ਹੈਂਡਲ ਕੀਤੇ ਗਏ ਹਨ (ਲੌਗ ਜੇ ਲੋੜੀਏ)
• ਕਿਸੇ ਵੀ ਬ੍ਰੇਕਿੰਗ ਚੇਂਜ ਲਈ ਸਪਸ਼ਟ ਮਾਈਗ੍ਰੇਸ਼ਨ ਪਥ
• ਨਾਮਕਰਨ ਅਤੇ ਬਣਤਰ ਨੇੜਲੇ ਕੋਡ ਨਾਲ ਮਿਲਦੇ ਹਨ
• ਖ਼ਤਰਨਾਕ ਹਿੱਸਿਆਂ ਲਈ ਰੋਲਬੈਕ ਯੋਜਨਾ ਮੌਜੂਦ ਹੈ

ਅੰਤ ਵਿੱਚ 3 ਤੋਂ 5 ਸਵਾਲ ਪੁੱਛੋ ਜੋ ਸਪਸ਼ਟੀ ਲਿਆਉਣ, ਉਦਾਹਰਨ: "ਜੇ API ਖਾਲੀ ਲਿਸਟ ਵਾਪਸੀ ਕਰੇ ਤਾਂ ਕੀ ਹੁੰਦਾ?" ਜਾਂ "ਕੀ ਇਹ concurrent requests ਹੇਠ ਸੁਰੱਖਿਅਤ ਹੈ?"

ਇੱਕ ਸਧਾਰਨ ਰੂਬਰਿਕ ਵਰਤੋ (ਪੜ੍ਹਨ ਯੋਗਤਾ, ਸਹੀ ਹੋਣਾ, ਏਜ ਕੇਸ)

Claude ਸਭ ਤੋਂ ਵਧੀਆ ਤਦੋਂ ਸਹਾਇਕ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਇਸਨੂੰ ਇੱਕ ਨਿਰਧਾਰਿਤ ਲੈਂਸ ਦਿਓ। ਬਿਨਾਂ ਰੂਬਰਿਕ ਦੇ, ਇਹ ਅਕਸਰ ਪਹਿਲੀ ਜੋ ਚੁਕਦੀ ਹੈ ਉਸ ਤੇ ਟਿੱਪਣੀ ਕਰਦਾ ਹੈ (ਆਮਤੌਰ 'ਤੇ ਸਟਾਈਲ ਨਿਟ) ਅਤੇ ਇੱਕ ਖਤਰਨਾਕ ਬਾਊਂਡਰੀ ਕੇਸ ਛੁੱਟ ਸਕਦਾ ਹੈ।

ਇੱਕ ਕਾਰਗਰ ਰੂਬਰਿਕ:

• ਪੜ੍ਹਨ ਯੋਗਤਾ: ਸਪਸ਼ਟ ਨਾਮ, ਸਧਾਰਨ ਫਲੋ, ਛੋਟੇ ਫੰਕਸ਼ਨ, ਟਿੱਪਣੀਆਂ ਜੋ ਕਿਉਂ ਦੱਸਦੀਆਂ ਹਨ, ਕੋਈ ਮ੍ਰਿਤ ਕੋਡ ਜਾਂ ਡਿਬੱਗ ਆਉਟਪੁਟ ਨਾ ਹੋਵੇ।
• ਸਹੀ ਹੋਣਾ: ਮੁੱਖ ਇਨਵੈਰੀਅੰਟ ਲਾਗੂ ਹਨ, ਐਰਰਾਂ ਇਕਸਾਰ ਹੈਂਡਲ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਨਲ/ਖਾਲੀ ਵਰਤੇ ਸੁਰੱਖਿਅਤ ਹਨ, ਸਰਹੱਦਾਂ ਠੀਕ ਹਨ (ਆਫ-ਬਾਈ-ਵਨ, ਗੋਲ ਕਰਨਾ)।
• ਏਜ ਕੇਸ: ਖਾਲੀ/ਬਹੁਤ ਵੱਡੇ ਇਨਪੁਟ, ਗੁਮਮਮਾਨ ਵਿਕਲਪ, ਸਮਾਂ ਜ਼ੋਨ, ਰੀਟ੍ਰਾਈਜ਼ ਜੋ ਡਬਲ-ਰਾਈਟ ਦਾ ਖਤਰਾ ਪੈਦਾ ਕਰ ਸਕਦੇ ਹਨ, ਕਨਕਰੈਂਸੀ ਰੇਸ।
• ਸੁਰੱਖਿਆ ਅਤੇ ਗੋਪਨੀਯਤਾ: ਠੀਕ ਥਾਂ ਤੇ auth ਚੈਕ, ਕੋਡ/ਲੌਗ ਵਿੱਚ ਰਹੱਸ ਨਹੀਂ, ਲੌਗ ਟੋਕਨ ਜਾਂ ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ ਨਹੀਂ ਲੀਕ ਕਰਨ।
• ਅਨੁਕੂਲਤਾ ਅਤੇ ਰੋਲਆਊਟ ਸੁਰੱਖਿਆ: ਪੁਰਾਣੇ ਕਲਾਇੰਟ ਅਤੇ ਸਟੋਰਡ ਡੇਟਾ ਟੁੱਟਣੇ ਨਾ, ਮਾਈਗ੍ਰੇਸ਼ਨ ਸੁਰੱਖਿਅਤ, ਰੋਲਬੈਕ ਯੋਜਨਾ ਹੋਵੇ।

ਜਦੋਂ ਤੁਸੀਂ ਪ੍ਰਾਂਪਟ ਦਿਓ, ਹਰ ਕੈਟੇਗਰੀ ਲਈ ਇੱਕ ਛੋਟੀ ਪੈਰਾ ਮੰਗੋ ਅਤੇ "ਸਭ ਤੋਂ ਉੱਚ-ਖ਼ਤਰਾ ਮੁੱਦਾ ਪਹਿਲਾਂ" ਮੰਗੋ। ਇਹ ਕ੍ਰਮ ਮਨੁੱਖਾਂ ਨੂੰ ਕੇਂਦ੍ਰਿਤ ਰੱਖੇਗਾ।

ਪ੍ਰਾਂਪਟ ਟੈਮਪਲੇਟ ਜੋ ਉਪਯੋਗੀ ਨੋਟ ਦਿੰਦੇ ਹਨ

ਇੱਕ ਦੁਹਰਾਏਯੋਗ ਬੇਸ ਪ੍ਰਾਂਪਟ ਵਰਤੋਂ ਤਾਂ ਜੋ ਨਤੀਜੇ ਹਰ PR ਤੇ ਸਮਾਨ ਰਹਿਣ। PR ਵੇਰਵਾ ਪੇਸਟ ਕਰੋ, ਫਿਰ ਡਿਫ। ਜੇ ਵਿਹਾਰ ਯੂਜ਼ਰ-ਫੇਸਿੰਗ ਹੈ, 1-2 ਵਾਕਾਂ ਵਿੱਚ ਉਮੀਦ ਕੀਤੀ ਵਿਹਾਰ ਜੋੜੋ।

You are doing a pre-review of a pull request.

Context
- Repo/service: <name>
- Goal of change: <1-2 sentences>
- Constraints: <perf, security, backward compatibility, etc>

Input
- PR description:
<...>
- Diff (unified diff):
<...>

Output format
1) Summary (max 4 bullets)
2) Readability notes (nits + suggested rewrites)
3) Correctness risks (what could break, and why)
4) Edge cases to test (specific scenarios)
5) Reviewer checklist (5-10 checkboxes)
6) Questions to ask the author before merge (3-7)

Rules
- Cite evidence by quoting the relevant diff lines and naming file + function/class.
- If unsure, say what info you need.

ਉੱਚ-ਖ਼ਤਰਾ ਬਦਲਾਵਾਂ (auth, payments, permissions, migrations) ਲਈ ਇਹ ਜੋੜੋ:

Extra focus for this review:
- Security/privacy risks, permission bypass, data leaks
- Money/credits/accounting correctness (double-charge, idempotency)
- Migration safety (locks, backfill, down path, runtime compatibility)
- Monitoring/alerts and rollback plan
Return a “stop-ship” section listing issues that should block merge.

ਰੀਫੈਕਟਰਸ ਲਈ, "ਵਿਹਾਰ ਬਦਲਣਾ ਨਹੀਂ" ਇਹ ਸਖ਼ਤ ਨਿਯਮ ਬਣਾਓ:

This PR is a refactor. Assume behavior must be identical.
- Flag any behavior change, even if minor.
- List invariants that must remain true.
- Point to the exact diff hunks that could change behavior.
- Suggest a minimal test plan to confirm equivalence.

ਜੇ ਤੁਸੀਂ ਤੇਜ਼ ਸਕੈਨ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ "200 ਸ਼ਬਦਾਂ ਤੋਂ ਘੱਟ ਉੱਤਰ" ਜਿਵੇਂ ਸੀਮਾ ਜੋੜੋ। ਜੇ ਡੀਪਥ ਚਾਹੀਦੀ ਹੈ, ਤਾਂ "ਤਕਰੀਬਨ 10 ਖੋਜਾਂ ਤੱਕ ਤਰਕ-ਸਹਿਤ" ਮੰਗੋ।

Claude ਦੀ ਨੋਟ ਨੂੰ ਰਿਵਿਊਅਰ ਚੈੱਕਲਿਸਟ ਵਿੱਚ ਬਦਲੋ

Claude ਦੀਆਂ ਨੋਟਾਂ ਅਸਲ ਵਿੱਚ ਤਦ ਹੀ ਲਾਭਦਾਇਕ ਹੁੰਦੀਆਂ ਹਨ ਜਦੋਂ ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਨੂੰ ਇੱਕ ਛੋਟੀ ਚੈੱਕਲਿਸਟ ਵਿੱਚ ਤਬਦੀਲ ਕਰ ਲਓ। ਡਿਫ ਨੂੰ ਦੁਹਰਾਓ ਨਾ। ਖਤਰੇ ਅਤੇ ਫੈਸਲੇ ਕੈਪਚਰ ਕਰੋ।

ਆਇਟਮਾਂ ਨੂੰ ਦੋ ਬਕੈਟਾਂ ਵਿੱਚ ਵੰਡੋ, ਤਾਂ ਕਿ ਥ੍ਰੇਡ ਪਸੰਦੀਆਂ ਦੀ ਚਰਚਾ ਨਾ ਬਣ ਜਾਵੇ:

ਜ਼ਰੂਰੀ-ਠੀਕ (ਮਰਜ ਰੋਕੋ)

• ਸਹੀ ਹੋਣਾ: ਉਮੀਦ ਰੱਖੀ ਗਈ ਨਤੀਜਾ ਇੱਕ ਵਾਕ ਵਿੱਚ ਲਿਖੀ ਹੋਵੇ ਅਤੇ ਟਿਕਟ ਨਾਲ ਮਿਲਦੀ ਹੋਵੇ
• ਏਜ ਕੇਸ: ਨਲ/ਖਾਲੀ ਇਨਪੁਟ ਅਤੇ ਐਰਰ ਪਾਥ ਸਾਫ਼ ਤਰੀਕੇ ਨਾਲ ਹੈਂਡਲ ਹੋਣ (ਜਾਂ ਰਿਜੈਕਟ)
• ਡਾਟਾ ਸੁਰੱਖਿਆ: ਲਿਖਤ ਅਤੇ ਮਾਈਗ੍ਰੇਸ਼ਨ ਮੌਜੂਦਾ ਡੇਟਾ ਅਤੇ ਪੁਰਾਣੇ ਕੋਡ ਲਈ ਸੁਰੱਖਿਅਤ ਹੋ
• ਟੈਸਟ: ਘੱਟੋ-ਘੱਟ ਇੱਕ ਟੈਸਟ ਮੁੱਖ ਵਿਹਾਰ ਦਾ ਅਤੇ ਇੱਕ ਟੈਸਟ ਸਭ ਤੋਂ ਖਤਰਨਾਕ ਫੇਲਿਊਰ ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੋ
• ਨਿਗਰਾਨੀਯੋਗਤਾ: ਲੌਗ/ਮੀਟਰਿਕਸ ਡਿਬੱਗ ਲਈ ਕਾਫ਼ੀ ਹੋ

ਚੰਗਾ-ਹੋਵੇ (ਫਾਲੋ-ਅਪਸ)

• ਪੜ੍ਹਨ ਯੋਗਤਾ: ਸਭ ਤੋਂ ਗੁੰਝਲਦਾਰ ਨਿਰਦੇਸ਼ਕ ਨੂੰ ਰੀਨੇਮ ਜਾਂ ਛੋਟੀ "ਕਿਉਂ" ਟਿੱਪਣੀ ਜੋੜੋ
• ਸੰਗਤਤਾ: ਗਲਤੀਆਂ, ਨਾਮਕਰਨ, ਅਤੇ ਫਾਈਲ ਲੇਆਊਟ ਲਈ ਮੌਜੂਦਾ ਪੈਟਰਨ ਨਾਲ ਮੇਲ ਕਰੋ
• ਪ੍ਰਦਰਸ਼ਨ: ਹੌਟ-ਪਾਥ ਤਬਦੀਲੀਆਂ ਅਤੇ ਕੀ ਇਹ ਮੌਜੂਦਾ ਸਕੇਲ 'ਤੇ ਮਾਇਨੇ ਰੱਖਦੀਆਂ ਹਨ
• ਡੌਕਸ: ਜੇ ਨਵਾਂ ਓਪਸ਼ਨ/ਫਲੈਗ ਜੋੜਿਆ ਗਿਆ ਤਾਂ ਇਨਲਾਈਨ ਡੌਕਅਪਡੇਟ ਕਰੋ

ਰੋਲਆਊਟ ਤਿਆਰੀ ਵੀ ਕੈਪਚਰ ਕਰੋ: ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਡਿਪਲੋਇ ਆਰਡਰ, ਰਿਲੀਜ਼ ਤੋਂ ਬਾਅਦ ਕੀ ਦੇਖਣਾ ਹੈ, ਅਤੇ ਤਬਦੀਲੀਆਂ ਨੂੰ ਵਾਪਸ ਕਿਵੇਂ ਲਿਆਉਣਾ ਹੈ।

ਮਰਜ ਤੋਂ ਪਹਿਲਾਂ ਪੁੱਛਣ ਵਾਲੇ ਸਵਾਲ

ਪ੍ਰੀ-ਰਿਵਿਊ ਸਿਰਫ਼ ਲਾਭਦਾਇਕ ਹੈ ਜੇ ਇਹ ਛੋਟੇ ਸਵਾਲਾਂ ਨਾਲ ਖਤਮ ਹੁੰਦਾ ਹੈ ਜੋ ਸਪਸ਼ਟਤਾ ਲਿਆਉਂਦੇ ਹਨ।

ਵਿਹਾਰ ਅਤੇ ਸਹੀ ਹੋਣਾ

• ਉਪਭੋਗਤਾ-ਵਿਊਅਬਲ ਵਿਹਾਰ ਕੀ ਬਦਲੇਗਾ, ਅਤੇ ਕੀ ਕੌਣ-ਕੌਣ ਚੀਜ਼ ਉਸੇ ਹੀ ਰਹਿਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ?
• ਜੇ ਇਹ "ਕੋਈ ਵਿਹਾਰ ਬਦਲਾਅ ਨਹੀਂ" ਹੈ, ਤਾਂ ਕੀ ਸਬੂਤ ਹੈ ਕਿ ਆਉਟਪੁੱਟ ਇੱਕੋ ਹੀ ਹਨ?
• ਸਭ ਤੋਂ ਸੰਭਾਵਤ ਪ੍ਰੋਡਕਸ਼ਨ ਫੇਲਿਊਰ ਕੀ ਹੈ, ਅਤੇ ਇਹ ਕਿੱਥੇ ਵੱਖਰੇਗਾ (UI, API, ਡਾਟਾ)?
• ਕੋਡ ਕਿਸ ਉਮੀਦ ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ — ਇਨਪੁਟ, ਆਰਡਰਿੰਗ, ਸਮਾਂ, ਜਾਂ ਨੈੱਟਵਰਕ ਕਾਲ?
• ਕੀ ਕੋਈ ਐਰਰ ਗੁਪਤ ਰੱਖ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ ਜਾਂ ਖ਼ਾਮੋਸ਼ ਡਿਫਾਲਟ ਵਿੱਚ ਬਦਲ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ?

ਏਜ ਕੇਸ, ਟੈਸਟ, ਅਤੇ ਓਪਰੇਸ਼ਨ

• ਸਭ ਤੋਂ ਖ਼ਰਾਬ ਅਸਲ ਇਨਪੁਟ ਕੀ ਹਨ (ਖਾਲੀ, ਬਹੁਤ ਵੱਡੇ, ਖਰਾਬ, ਡੁਪਲਿਕੇਟ), ਅਤੇ ਕੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ?
• ਕਿਹੜਾ ਆਮ ਫਲੋ ਇਹ ਦੋ ਵਾਰੀ ਟਰਿਗਰ ਕਰ ਸਕਦਾ ਹੈ (ਰੀਟ੍ਰਾਈ, ਡਬਲ-ਕਲਿੱਕ, ਬੈਕਗ੍ਰਾਊਂਡ ਜੌਬ), ਅਤੇ ਕੀ ਇਹ ਸੁਰੱਖਿਅਤ ਹੈ?
• ਕਿਹੜਾ ਟੈਸਟ ਮੁੱਖ ਵਿਹਾਰ ਨੂੰ ਸਾਬਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਕਿਹੜਾ ਟੈਸਟ ਸਭ ਤੋਂ ਖ਼ਤਰਨਾਕ ਏਜ ਕੇਸ ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ?
• ਜੇ ਇੱਕ ਟੈਸਟ ਗੁੰਮ ਹੈ, ਤਾਂ ਕੀ ਇਹ ਲਿਖਣਾ ਮੁਸ਼ਕਲ ਹੈ ਜਾਂ ਕੋਡ ਟੈਸਟ ਕਰਨ ਯੋਗ ਨਹੀਂ?
• ਓਪਰੇਸ਼ਨ ਲਈ ਕੀ ਲੋੜੇ ਹੋਣਗੇ: ਲਾਭਦਾਇਕ ਲੌਗ, ਮੈਟ੍ਰਿਕਸ, ਚੇਤਾਵਨੀ, ਕੰਫਿਗ ਡਿਫੌਲਟ, ਅਤੇ ਰੋਲਬੈਕ ਕਦਮ?

ਜੇ ਤੁਸੀਂ ਇਹਨਾਂ ਦਾ ਸਪਸ਼ਟ ਜਵਾਬ ਨਹੀਂ ਦੇ ਸਕਦੇ, ਤਾਂ ਮਰਜ ਰੋਕੋ ਅਤੇ ਸਕੋਪ ਸਾਫ਼ ਕਰੋ ਜਾਂ ਪ੍ਰਮਾਣ ਜੋੜੋ।

ਆਮ ਜਾਲ (ਅਤੇ ਉਨ੍ਹਾਂ ਤੋਂ ਬਚਾਅ)

ਅਧਿਕਤਰ ਫੇਲਿਊਰ ਪ੍ਰਕਿਰਿਆ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਹਨ, ਮਾਡਲ ਦੀਆਂ ਨਹੀਂ।

• ਬਿਨਾਂ ਫੋਕਸ ਦੇ ਵੱਡੇ ਡਿਫ ਪੇਸਟ ਕਰਨਾ। 1-3 ਖਤਰਨਾਕ ਖੇਤਰਾਂ ਉੱਤੇ ਸਮੀਖਿਆ ਮੰਗੋ ਅਤੇ ਸਿਰਫ਼ ਉਹੀ ਹੰਕਸ ਪੇਸਟ ਕਰੋ ਜੋ ਸੰਬੰਧਿਤ ਹਨ ਅਤੇ ਜਿਨ੍ਹਾਂ ਦੀ ਸਿਗਨੇਚਰ ਤੇ ਨਿਰਭਰਤਾ ਹੈ।
• इरादा ਅਤੇ ਉਮੀਦ ਕੀਤੀ ਵਿਹਾਰ ਛੱਡਨਾ। ਮਕਸਦ ਬਿਨਾਂ, ਰਿਵਿਊ ਭਟਕ ਜਾਂਦਾ ਹੈ। ਦੁਆ ਲਾਈਨ ਜੋੜੋ: ਕੀ ਬਦਲਿਆ, ਅਤੇ ਕੀ ਨਹੀਂ ਬਦਲਣਾ।
• ਆਤਮ-ਵਿਸ਼ਵਾਸੀ ਅਨੁਮਾਨਾਂ 'ਤੇ ਭਰੋਸਾ। ਸਬੂਤ ਵਾਪਸ ਮੰਗੋ। ਜੇ ਇਹ ਸਬੂਤ ਨਹੀਂ ਦੇ ਸਕਦਾ, ਤਾਂ ਉਹਨੂੰ ਪਰਿਕਲਪਨਾ ਸਮਝੋ ਅਤੇ ਜਾਂਚ ਕਰੋ।
• ਸਟਾਈਲ ਬਾਰੇ ਅਣਗੈਂਡਾ ਵਿਵਾਦ। "ਜ਼ਰੂਰੀ-ਠੀਕ" ਬਨਾਮ "ਚੰਗਾ-ਹੋਵੇ" ਪੂਠੋਂ ਅਤੇ ਸਟਾਈਲ ਨੋਟਾਂ 'ਤੇ ਸੀਮਾ ਲਗਾਓ।
• ਟੀਮ ਮਾਪਦੰਡਾਂ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨਾ। ਜੇ ਤੁਹਾਡੀ ਟੀਮ ਕੋਛ ਨਿਯਮ (ਜਿਵੇਂ early returns, error types, logging format) ਰੱਖਦੀ ਹੈ, ਤਾਂ ਉਹਨਾਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰੋ।

ਜੇ ਇੱਕ PR ਇੱਕ ਨਵਾਂ ਚੈੱਕਆਊਟ ਐਂਡਪੋਂਟ ਜੋੜਦਾ ਹੈ, ਤਾਂ ਸਾਰੀ ਸਰਵਿਸ ਪੇਸਟ ਨਾ ਕਰੋ। ਹੈਂਡਲਰ, ਵੈਲੀਡੇਸ਼ਨ, DB ਲਿਖਤ, ਅਤੇ ਕਿਸੇ ਵੀ ਸਕੀਮਾ ਬਦਲਾਅ ਨੂੰ ਪੇਸਟ ਕਰੋ। ਫਿਰ ਕਹੋ: "ਮਕਸਦ: ਡਬਲ-ਚਾਰਜ ਨੂੰ ਰੋਕਣਾ। ਨੋਨ-ਮਕਸਦ: ਨਾਮਕਰਨ ਰੀਫੈਕਟਰਿੰਗ." ਤੁਸੀਂ ਘੱਟ ਟਿੱਪਣੀਆਂ ਮਿਲੋਂਗੇ ਅਤੇ ਉਹ ਸਹੀ ਪਰਖਣਾ ਆਸਾਨ ਹੋਵੇਗਾ।

ਇੱਕ ਹਕੀਕਤੀ ਉਦਾਹਰਨ: ਇੱਕ ਛੋਟੀ PR ਦੀ ਪ੍ਰੀ-ਰਿਵਿਊ

ਇੱਕ ਛੋਟਾ, ਹਕੀਕਤ-ਵਾਂਗ PR: settings ਸਕ੍ਰੀਨ 'ਤੇ "display name" ਫੀਲਡ ਜੋੜਨਾ। ਇਹ ਵੈਲੀਡੇਸ਼ਨ (ਸਰਵਰ) ਅਤੇ UI ਟੈਕਸਟ (ਕਲਾਇੰਟ) ਨੂੰ ਛੂਹਦਾ ਹੈ। ਇਹ ਪਰਣਾਮ ਵਿਚ ਸੋਚਣ ਯੋਗ ਹੈ, ਪਰ ਅਜੇ ਵੀ ਥਾਣੇ-ਥਾਣੇ ਬੱਗ ਹੋ ਸਕਦੇ ਹਨ।

ਇੱਥੇ ਉਹ ਸਨਿੱਪੇਟ ਹਨ ਜੋ ਤੁਸੀਂ ਪੇਸਟ ਕਰੋਗੇ (ਅਤੇ 2-3 ਵਾਕ ਦਾ ਸੰਦਰਭ ਜਿਵੇਂ ਉਮੀਦ ਕੀਤੀ ਵਿਹਾਰ ਅਤੇ ਸੰਬੰਧਿਤ ਟਿਕਟ):

- if len(name) == 0 { return error("name required") }
+ if len(displayName) < 3 { return error("display name too short") }
+ if len(displayName) > 30 { return error("display name too long") }

- <TextInput label="Name" value={name} />
+ <TextInput label="Display name" value={displayName} helperText="Shown on your profile" />

ਤੁਸੀਂ ਇਹ ਤਰ੍ਹਾਂ ਖੋਜਾਂ ਪਾਉਣ ਦੀ ਉਮੀਦ ਕਰਦੇ ਹੋ:

• ਪੜ੍ਹਨ ਯੋਗਤਾ: ਕਈ ਫਾਇਲਾਂ ਵਿੱਚ "displayName" ਅਤੇ "name" ਮਿਲੇ-ਜੁਲੇ ਹਨ। ਇੱਕ ਸ਼ਬਦ ਚੁਣੋ ਤਾਂ ਜੋ ਭਵਿੱਖ ਦੀਆਂ ਤਬਦੀਲੀਆਂ ਮਨ ਲਈ ਆਸਾਨ ਹੋਣ।
• ਸਹੀ ਹੋਣਾ: ਸਰਵਰ ਲੰਬਾਈ ਦੀ ਜਾਂਚ ਕਰ ਰਿਹਾ ਹੈ, ਪਰ ਕਲਾਇੰਟ ਨਹੀਂ। ਉਪਭੋਗਤਾ 1-2 ਅੱਖਰ ਟਾਈਪ ਕਰ ਸਕਦੇ ਹਨ ਅਤੇ ਸਿਰਫ਼ Submit ਤੋਂ ਬਾਅਦ ਗਲਤੀ ਵੇਖਣਗੇ।
• ਏਜ ਕੇਸ: ਖਾਲੀ ਸਿਰਫ਼ ਸਪੇਸ ਵਾਲੇ ਸਤਰ len(displayName) ਪਾਸ ਕਰ ਜਾਂਦੇ ਹਨ ਪਰ ਫਿਰ ਵੀ ਖਾਲੀ ਦਿਸਦੇ ਹਨ। ਵੈਲੀਡੇਸ਼ਨ ਤੋਂ ਪਹਿਲਾਂ trim ਕਰੋ।

ਇਸਨੂੰ ਇੱਕ ਚੈੱਕਲਿਸਟ ਵਿੱਚ ਬਦਲੋ:

• API, ਡੇਟਾਬੇਸ ਫੀਲਡ ਅਤੇ UI ਲੇਬਲ ਵਿੱਚ ਨਾਮ ਇਕਸਾਰ ਹੋ
• ਕਲਾਇੰਟ-ਸਾਈਡ ਚੈੱਕ ਸਰਵਰ ਨਿਯਮਾਂ (min/max, required) ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਹੋ
• ਇਨਪੁਟ ਨੂੰ trim ਕੀਤਾ ਜਾਂਦਾ ਹੈ (ਅਤੇ Unicode/emoji ਸلوਕ ਕੈਸੇ ਵਰਤਣਾ ਹੈ, ਉਹ ਠੀਕ ਹੈ)
• ਐਰਰ ਸੁਨੇਹੇ ਸਪਸ਼ਟ ਅਤੇ ਸਰਵਰ-ਕਲਾਇੰਟ ਵਿੱਚ ਮਿਲਦੇ ਹਨ

ਤੇਜ਼ ਚੈੱਕ, ਮਾਪ ਅਤੇ ਅਗਲੇ ਕਦਮ

Claude Code PR ਰਿਵਿਊ ਸਭ ਤੋਂ ਵਧੀਆ ਤਦੋਂ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਇਹ ਕੁਝ ਤੇਜ਼ ਚੈਕ ਨਾਲ ਖਤਮ ਹੁੰਦਾ ਹੈ:

• ਵਿਹਾਰ: ਉਪਭੋਗਤਾ ਲਈ ਕੀ ਬਦਲਿਆ ਅਤੇ ਕੀ ਨਹੀਂ ਬਦਲਣਾ ਚਾਹੀਦਾ
• ਟੈਸਟ: ਕੀ ਕਵਰ ਹੈ, ਕੀ ਗੁੰਮ ਹੈ, ਕੀ ਫਲੇਕ ਕਰ ਸਕਦਾ ਹੈ
• ਲੌਗ ਅਤੇ ਐਰਰ: ਫੇਲਿਊਰ ਸਪਸ਼ਟ ਹਨ ਅਤੇ ਸੁਨੇਹੇ ਯੂਜ਼ਬਲ ਹਨ
• ਪ੍ਰਦਰਸ਼ਨ: ਨਵੀਆਂ ਲੂਪਾਂ, N+1 ਕਵੈਰੀਜ਼, ਵੱਡੇ ਪੇਲੋਡ, ਵਾਧੂ ਨੈੱਟਵਰਕ ਕਾਲ
• ਸੁਰੱਖਿਆ: ਵੈਲੀਡੇਸ਼ਨ, auth ਚੈਕ, ਰਹੱਸ, ਖ਼ਤਰਨਾਕ ਡਿਫਾਲਟ

ਦੇਖਣ ਲਈ ਕਿ ਇਹ ਲਾਭ ਦਿੰਦਾ ਹੈ ਜਾਂ ਨਹੀਂ, 2-4 ਹਫ਼ਤਿਆਂ ਲਈ ਦੋ ਸੁਧਾਰ ਮੈਟਰਿਕ ਟ੍ਰੈਕ ਕਰੋ: ਰਿਵਿਊ ਸਮਾਂ (ਖੋਲ੍ਹਣ ਤੋਂ ਪਹਿਲੀ ਮੈਨੇਅਰਿੰਗ ਰਿਵਿਊ, ਅਤੇ ਖੋਲ੍ਹਣ ਤੋਂ ਮਰਜ ਤੱਕ) ਅਤੇ ਰੀਵਰਕ (ਸਮੀਖਿਆ ਤੋਂ ਬਾਅਦ ਫਾਲੋ-ਅਪ ਕਮਿਟ ਜਾਂ ਕਿੰਨੀ ਟਿੱਪਣੀਆਂ ਨੇ ਕੋਡ ਬਦਲੀ ਮੰਗੀ)।

ਸੰਵਿਧਾਨਿਕਤਾ ਪੂਰੀ ਨਹੀ, ਬੇਹਤਰ ਪ੍ਰਾਂਪਟ ਬਣਾਉਣਾ। ਇੱਕ ਟੈਮਪਲੇਟ ਚੁਣੋ, ਇੱਕ ਛੋਟਾ ਸੰਦਰਭ ਬਲਾਕ ਲਾਜ਼ਮੀ ਬਣਾਓ (ਕੀ ਬਦਲਿਆ, ਕਿਉਂ, ਕਿਵੇਂ ਟੈਸਟ ਕਰਨਾ ਹੈ), ਅਤੇ 'ਡਨ' ਦਾ ਮਤਲਬ ਤੈਅ ਕਰੋ।

ਜੇ ਤੁਹਾਡੀ ਟੀਮ ਚੈਟ-ਅਧਾਰਿਤ ਵਿਕਾਸ ਰਾਹੀਂ ਫੀਚਰ ਬਣਾਉਂਦੀ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਇਸੇ ਵਰਕਫਲੋ ਨੂੰ Koder.ai ਵਿੱਚ ਲਾਗੂ ਕਰ ਸਕਦੇ ਹੋ: ਬਦਲਾਅ ਜਨਰੇਟ ਕਰੋ, ਸੋর্স ਕੋਡ ਐਕਸਪੋਰਟ ਕਰੋ, ਫਿਰ ਪ੍ਰੀ-ਰਿਵਿਊ ਚੈੱਕਲਿਸਟ PR ਨਾਲ ਜੁੜੋ ਤਾ ਕਿ ਮਨੁੱਖੀ ਸਮੀਖਿਆ ਸਭ ਤੋਂ ਉੱਚ-ਖ਼ਤਰਾ ਵਾਲੇ ਹਿੱਸਿਆਂ 'ਤੇ ਕੇਂਦਰਿਤ ਰਹੇ।