Claude Code ਨਾਲ Prompt ਤੋਂ PR ਵਰਕਫਲੋ: ਛੋਟੇ ਬਦਲਾਅ

ਕਿਉਂ Prompt-ਤੋਂ-PR ਵੱਡੇ ਇਕ-ਸ਼ਾਟ ਪ੍ਰੰਪਟਾਂ ਨਾਲੋਂ ਬਿਹਤਰ ਹੈ

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

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

Prompt-to-PR ਇੱਕ ਸਧਾਰਣ ਲੂਪ ਹੈ:

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

ਇਹ ਰਿਦਮ ਅਸਫਲਤਾਵਾਂ ਨੂੰ ਅਖੀਰ ਵਿੱਚ ਹੈਰਾਨੀ ਦੀ ਥਾਂ ਤੇ ਤੇਜ਼ ਫੀਡਬੈਕ ਵਿੱਚ ਬਦਲ ਦਿੰਦੀ ਹੈ। ਜੇ ਤੁਸੀਂ Claude Code ਨੂੰ ਕੋਈ ਵੈਧਤਾ ਨਿਯਮ ਠੀਕ ਕਰਨ ਲਈ ਕਹਿੰਦੇ ਹੋ, ਤਾਂ ਉਸੇ ਇੱਕ ਨਿਯਮ ਤੱਕ ਸੀਮਤ ਰੱਖੋ। ਜੇ ਕੋਈ ਟੈਸਟ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਫੇਲ੍ਹ ਹੋਣ ਵਾਲੀ ਆਉਟਪੁਟ ਪੇਸਟ ਕਰੋ ਅਤੇ ਇੱਕੋ ਵੱਡੀ ਮੋਡੀਫਿਕੇਸ਼ਨ ਦੀ ਬਜਾਏ ਉਸ ਟੈਸਟ ਨੂੰ ਪਾਸ ਕਰਨ ਲਈ ਸਭ ਤੋਂ ਛੋਟਾ ਫਿਕਸ ਮੰਗੋ।

ਇੱਕ ਗੱਲ नहीं ਬਦਲਦੀ: ਅੰਤਿਮ ਕੋਡ ਲਈ ਤੁਸੀਂ ਹੀ ਜ਼ਿੰਮੇਵਾਰ ਹੋ। ਮਾਡਲ ਨੂੰ ਇੱਕ ਲੋਕਲ ਪੇਅਰ-ਪਰੋਗ੍ਰਾਮਰ ਵਾਂਗ ਸਮਝੋ ਜੋ ਤੇਜ਼ੀ ਨਾਲ ਟਾਈਪ ਕਰਦਾ ਹੈ, ਆਟੋਪਾਇਲਟ ਨਹੀਂ। ਤੁਸੀਂ ਫ਼ੈਸਲਾ ਕਰੋ ਕਿ ਕੀ ਸ਼ਾਮਲ ਹੋਵੇ, ਕੀ ਰਹੇ, ਅਤੇ ਕਦੋਂ PR ਖੋਲ੍ਹਣਾ ਸੁਰੱਖਿਅਤ ਹੈ।

ਆਪਣਾ ਰੇਪੋ ਅਤੇ ਲੋਕਲ ਪੇਅਰਿੰਗ ਸੈਟਅਪ ਤਿਆਰ ਕਰੋ

ਸਾਫ਼ ਬੇਸਲਾਈਨ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ। ਜੇ ਤੁਹਾਡੀ ਬ੍ਰਾਂਚ ਪਿੱਛੇ ਹੈ ਜਾਂ ਟੈਸਟ ਪਹਿਲਾਂ ਤੋਂ ਫੇਲ੍ਹ ਹਨ, ਤਾਂ ਹਰ ਸੁਝਾਅ ਅਨੁਮਾਨ ਬਣ ਜਾਂਦਾ ਹੈ। ਤਾਜ਼ਾ ਬਦਲਾਅ ਖਿੱਚੋ, ਜਿਵੇਂ ਟੀਮ ਪਸੰਦ ਕਰਦੀ ਹੈ, ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਮੌਜੂਦਾ ਸਥਿਤੀ ਸਿਹਤਮੰਦ ਹੈ।

"ਲੋਕਲ ਪੇਅਰ-ਪਰੋਗ੍ਰਾਮਰ" ਸੈਟਅਪ ਦਾ ਮਤਲਬ ਹੈ ਕਿ Claude Code ਤੁਹਾਡੇ ਰੇਪੋ ਦੀਆਂ ਫਾਈਲਾਂ ਸੋਧਦਾ ਹੈ ਜਦਕਿ ਤੁਸੀਂ ਲਕਸ਼, ਗਾਰਡਰੇਲ ਅਤੇ ਹਰ ਡਿਫ਼ 'ਤੇ ਨਿਯੰਤਰਣ ਰੱਖਦੇ ਹੋ। ਮਾਡਲ ਤੁਹਾਡਾ ਕੋਡਬੇਸ ਨਹੀਂ ਜਾਣਦਾ ਜਦ ਤੱਕ ਤੁਸੀਂ ਉਹਨੂੰ ਨਹੀਂ ਦਿਖਾਉਂਦੇ, ਇਸ ਲਈ ਫਾਈਲਾਂ, ਪਾਬੰਦੀਆਂ ਅਤੇ ਦੀਖਾਵ ਦੱਸਣ ਵਿੱਚ ਵਾਜਬ ਹੋਵੋ।

ਪਹਿਲੇ ਪ੍ਰੰਪਟ ਤੋਂ ਪਹਿਲਾਂ ਫੈਸਲਾ ਕਰੋ ਕਿ ਚੈੱਕ ਕਿੱਥੇ ਚੱਲਣਗੇ। ਜੇ ਤੁਸੀਂ ਲੋਕਲ ਤੌਰ 'ਤੇ ਟੈਸਟ ਚਲਾ ਸਕਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਮਿੰਟਾਂ ਵਿੱਚ ਫੀਡਬੈਕ ਲੈ ਸਕਦੇ ਹੋ, ਜੋ ਇਤਰੈਸ਼ਨ ਨੂੰ ਛੋਟਾ ਰੱਖਦਾ ਹੈ। ਜੇ ਕੁਝ ਚੈੱਕ ਸਿਰਫ CI ਵਿੱਚ ਚੱਲਦੇ ਹਨ (ਕੁਝ ਲਿਨਟ ਨਿਯਮ, ਲੰਬੀ ਸੂਟ, ਬਿਲਡ ਕਦਮ), ਤਾਂ ਫੈਸਲਾ ਕਰੋ ਕਿ ਤੁਸੀਂ ਕਦੋਂ CI ਤੇ ਨਿਰਭਰ ਰਹੋਗੇ ਤਾਂ ਕਿ ਹਰ ਛੋਟੇ ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਪ੍ਰਤੀਖਾ ਨਾ ਕਰਣਾ ਪਵੇ।

ਇੱਕ ਸਧਾਰਣ ਪ੍ਰੀ-ਫਲਾਈਟ:

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

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

ਐਸੇ ਪ੍ਰੰਪਟ ਲਿਖੋ ਜੋ ਕੁਦਰਤੀ ਢੰਗ ਨਾਲ ਛੋਟੇ ਬਦਲਾਅ ਲੈ ਕੇ ਆਉਣ

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

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

ਇੱਕ ਪ੍ਰੰਪਟ ਆਕਾਰ ਜੋ ਬਦਲਾਅ ਨੂੰ ਟਾਈਟ ਰੱਖਦਾ ਹੈ:

• Goal: ਉਹ ਇਕਲ-ਵਰਤੋਂ ਜੋ ਤੁਸੀਂ ਬਦਲਣਾ ਚਾਹੁੰਦੇ ਹੋ।
• Location: ਜਿਹੜੀ ਫਾਈਲ(ਾਂ) ਜਾਂ ਕੰਪੋਨੈਂਟ ਛੇਡੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ।
• Constraints: ਕੀ ਨਹੀਂ ਬਦਲਣਾ ਚਾਹੀਦਾ।
• Acceptance: "ਡਨ" ਕਿਵੇਂ ਦਿਸੇਗਾ।
• Diff size: ਸਭ ਤੋਂ ਛੋਟਾ ਬਦਲਾਅ ਮੰਗੋ ਜੋ ਕੰਮ ਕਰੇ।

ਸੀਮਾਵਾਂ ਸੱਚਮੁੱਚੀ ਤਾਕਤ ਹਨ। "ਲੌਗਿਨ ਬੱਗ ਠੀਕ ਕਰੋ" ਦੇ ਬਦਲੇ ਦੱਸੋ ਕਿ ਕੀ ਬਰਕਰਾਰ ਰਹਿਣਾ ਚਾਹੀਦਾ: "API ਆਕਾਰ ਨਿਕਲ ਨਾ ਕਰੋ," "ਪਬਲਿਕ ਫੰਕਸ਼ਨ ਨਾਂ-ਬਦਲੋ," "ਸਿਰਫ ਫਾਰਮੈਟਿੰਗ ਸੋਧ ਨਾ ਕਰੋ," "ਨਵੀਆਂ ਡੀਪੈਂਡੇਨਸੀਜ਼ ਤੋਂ ਬਚੋ." ਇਸ ਨਾਲ ਤੁਹਾਡਾ ਪੇਅਰ-ਪਰੋਗ੍ਰਾਮਰ ਪਤਾ ਲਗਾ ਲੈਂਦਾ ਕਿ ਕਿੱਥੇ ਚਲਾਕੀ ਨਾ ਵਰਤੀ ਜਾਏ।

ਜਦੋਂ ਬਦਲਾਅ ਅਜੇ ਵੀ ਅਸਪਸ਼ਟ ਲੱਗੇ, ਪਹਿਲਾਂ ਇੱਕ ਯੋਜਨਾ ਮੰਗੋ। ਇੱਕ ਛੋਟੀ ਯੋਜਨਾ ਕੰਮ ਨੂੰ ਕਦਮਾਂ ਵਿੱਚ ਤਬਦੀਲ ਕਰਦੀ ਹੈ ਅਤੇ ਤੁਹਾਨੂੰ ਛੋਟੀ ਪਹਿਲੀ ਕਦਮ ਮਨਜ਼ੂਰ ਕਰਨ ਦਾ ਮੌਕਾ ਦਿੰਦੀ ਹੈ।

Goal: Fix the null crash when rendering the profile header.
Location: src/components/ProfileHeader.tsx only.
Constraints: Do not change styling, props, or any exported types.
Expected outcome: If user.name is missing, show "Anonymous" and no crash.
Diff constraint: Minimal diff. No refactors. No unrelated formatting.
If unclear: First reply with a 3-step plan, then wait for approval.

ਜੇ ਤੁਸੀਂ ਟੀਮ 'ਤੇ ਕੰਮ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਰਿਵਿਊ ਪਾਬੰਦੀਆਂ ਵੀ ਸ਼ਾਮਲ ਕਰੋ: "~30 ਲਾਈਨਾਂ ਤੋਂ ਘੱਟ ਬਦਲਾਅ ਰੱਖੋ" ਜਾਂ "ਇਕ ਫਾਈਲ ਹੀ ਛੇਡੋ ਜਦ ਤੱਕ ਜ਼ਰੂਰੀ ਨਾਹ ਹੋਵੇ." ਇਹ ਡਿਫ਼ ਨੂੰ ਸਕੈਨ ਕਰਨ ਲਈ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਜਦੋਂ ਕੁਝ ਫੇਲ੍ਹ ਹੋਵੇ ਤਾਂ ਅਗਲੇ ਪ੍ਰੰਪਟ ਨੂੰ ਤੇਜ਼ ਕਰਦਾ ਹੈ।

ਹਰiteration ਲਈ ਠੀਕ ਯੂਨਿਟ ਦਾ ਚੋਣ ਕਰੋ

ਹਰ ਲੂਪ ਨੂੰ ਇੱਕ ਛੋਟੇ, ਟੈਸਟਯੋਗ ਬਦਲਾਅ 'ਤੇ ਕੇਂਦਰਿਤ ਰੱਖੋ। ਜੇ ਤੁਸੀਂ ਲਕਸ਼ ਇਕ ਵਾਕ ਵਿੱਚ ਵਰਣਨ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਅੰਦਾਜ਼ਾ ਲਗਾ ਸਕਦੇ ਹੋ ਕਿ ਕਿਸ ਫਾਈਲਾਂ ਨੂੰ ਬਦਲਣਾ ਪਏਗਾ, ਤਾਂ ਇਹ ਠੀਕ ਆਕਾਰ ਹੈ।

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

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

ਸ਼ੁਰੂ ਤੋਂ ਹੀ "ਡਨ" ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ:

• ਬਦਲਾਅ ਉਦੇਸ਼ਿਤ ਫਾਈਲਾਂ ਅਤੇ ਵਿਹਾਰ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ।
• ਇੱਕ ਚੈੱਕ ਦੱਸਦਾ ਹੈ ਕਿ ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ (ਟੈਸਟ, ਲਿਨਟ, ਜਾਂ ਇੱਕ ਸਧਾਰਣ ਰਨ ਕਦਮ)।
• ਕੋਈ ਨਵੀਆਂ ਚੇਤਾਵਨੀਆਂ ਜਾਂ ਉਲਝਣ-ਭਰੀ ਫਾਰਮੈਟਿੰਗ ਸੋਧ ਨਹੀਂ।
• ਡਿਫ਼ ਨੂੰ ਦੋ ਵਾਕਾਂ ਵਿੱਚ ਸਪਸ਼ਟ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਜਦੋਂ ਸਕੋਪ ਵਧਣ ਲੱਗੇ, ਤੁਰੰਤ ਰੁਕੋ। ਜੇ ਤੁਸੀਂ ਕਹਿਣ ਲੱਗਦੇ ਹੋ "ਜਦੋਂ ਅਸੀਂ ਇੱਥੇ ਹਾਂ," ਤਾਂ ਤੁਸੀਂ ਨਵੀਂ ਇਟਰੇਸ਼ਨ ਲੱਭ ਲੈ ਚੁੱਕੇ ਹੋ। ਇਸਨੂੰ ਫਾਲੋ-ਅਪ ਵਜੋਂ ਕੈਪਚਰ ਕਰੋ, ਮੌਜੂਦਾ ਛੋਟਾ ਡਿਫ਼ ਕਮਿਟ ਕਰੋ, ਅਤੇ ਅੱਗੇ ਵਧੋ।

ਚੈੱਕ ਚਲਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਡਿਫ਼ ਦੀ ਸਮੀਖਿਆ ਕਰੋ

ਚੈੱਕ ਜਾਂ ਬਿਲਡ ਚਲਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਡਿਫ਼ ਨੂੰ ਰਿਵਿਊਰ ਵਾਂਗ ਪੜ੍ਹੋ। ਇਹ ਓਥੇ ਹੈ ਜਿੱਥੇ ਵਰਕਫਲੋ ਸਾਫ਼ ਰਹਿੰਦਾ ਹੈ ਜਾਂ ਚੁਪਚਾਪ "ਉਹ ਫਾਈਲ ਕਿਉਂ ਛੇਡੀ?" ਵਾਲੇ ਹਾਲਤ ਵਿੱਚ ਬਦਲ ਜਾਂਦਾ ਹੈ।

Claude Code ਨੂੰ ਪਹੁੰਚ ਪ੍ਰੰਪਟ ਕਰਕੇ ਪੁੱਛੋ ਕਿ ਉਸਨੇ ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਕੀ-ਕੀ ਬਦਲਿਆ: ਛੇਡੀਆਂ ਫਾਈਲਾਂ, ਵਿਹਾਰਿਕ ਬਦਲਾਅ, ਅਤੇ ਕੀ ਨਹੀਂ ਬਦਲਿਆ। ਜੇ ਉਹ ਬਦਲਾਅ ਨੂੰ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਨਹੀਂ ਸਮਝਾ ਸਕਦਾ, ਤਾਂ ਸੰਭਵ ਹੈ ਕਿ ਡਿਫ਼ ਜ਼ਿਆਦਾ ਕਰ ਰਿਹਾ ਹੈ।

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

ਇੱਕ ਤੇਜ਼ ਪ੍ਰੀ-ਚੈਕ:

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

ਜੇ ਡਿਫ਼ ਉਮੀਦ ਤੋਂ ਵੱਡਾ ਹੈ, ਤਾਂ ਟੈਸਟ ਰਾਹੀਂ ਨਿਕਲਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਾ ਕਰੋ। ਰਿਵਰਟ ਕਰੋ ਅਤੇ ਮੁੜ-ਪ੍ਰੰਪਟ ਕਰਕੇ ਛੋਟਾ ਕਦਮ ਮੰਗੋ। ਉਦਾਹਰਣ ਲਈ: "ਸਿਰਫ਼ ਇੱਕ failing test ਜੋ ਬੱਗ ਨੂੰ ਦੁਹਰਾਉਂਦਾ ਹੈ ਜੋ ਕਿ ਕੋਈ ਰਿਫੈਕਟਰ ਨਹੀਂ।" ਛੋਟੇ ਡਿਫ਼ ਫੇਲ੍ਹੀਆਂ ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦੇ ਹਨ ਅਤੇ ਅਗਲੇ ਪ੍ਰੰਪਟ ਨੂੰ ਨੁਕਤਾ ਬਣਾਉਂਦੇ ਹਨ।

ਹਰ ਛੋਟੇ ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਚੈੱਕ ਚਲਾਓ

ਛੋਟੇ ਡਿਫ਼ ਤਾਂ ਹੀ ਲਾਭਦਾਇਕ ਹਨ ਜਦੋਂ ਤੁਸੀਂ ਓਹਨਾਂ ਦੀ ਤੁਰੰਤ ਜਾਂਚ ਕਰਦੇ ਹੋ। ਲਕਸ਼ ਇੱਕ ਗੰਢੀਵਾਰ ਲੂਪ ਹੈ: ਥੋੜ੍ਹਾ ਬਦਲੋ, ਥੋੜ੍ਹਾ ਚੈੱਕ ਕਰੋ, ਜਦੋਂ ਸੰਦਰਭ ਤਾਜ਼ਾ ਹੋ ਫੇਲ੍ਹੀਆਂ ਫੜੋ।

ਜਿਸ ਸਭ ਤੋਂ ਤੇਜ਼ ਚੈੱਕ ਨਾਲ ਤੁਸੀਂ "ਇਹ ਟੁੱਟਿਆ ਹੈ" ਦੇ ਸਕਦੇ ਹੋ, ਉਸਨੂੰ ਪਹਿਲਾਂ ਚਲਾਓ। ਜੇ ਤੁਸੀਂ ਫਾਰਮੈਟਿੰਗ ਜਾਂ ਇੰਪੋਰਟਾਂ ਛੇਡੇ ਹਨ, ਪਹਿਲਾਂ ਲਿਨਟ ਜਾਂ ਫਾਰਮੈਟਰ ਚਲਾਓ। ਜੇ ਤੁਸੀਂ ਬਿਜ਼ਨਸ ਲਾਜਿਕ ਛੇਡੀ ਹੈ, ਤਾਂ ਜਿਸ ਫਾਈਲ ਜਾਂ ਪੈਕੇਜ ਨੂੰ ਤੁਸੀਂ ਛੇਡਿਆ ਉਹਨਾਂ ਲਈ ਨਿਸ਼ਾਨਾ ਯੂਨਿਟ ਟੈਸਟ ਚਲਾਓ। ਜੇ ਤੁਸੀਂ ਟਾਈਪ ਜਾਂ ਬਿਲਡ ਸੋਧਿਆ ਹੈ, ਇੱਕ ਛੋਟਾ ਕੰਪਾਇਲ ਚਲਾਓ।

ਇੱਕ ਹੈਂਡਸ-ਆਨ ਓਰਡਰ:

• ਲਿਨਟ ਜਾਂ ਫਾਰਮੈਟ.
• ਟਾਰਗੇਟ ਕੀਤੀ ਯੂਨਿਟ ਟੈਸਟ.
• ਬਿਲਡ ਜਾਂ ਟਾਈਪਚੈਕ.
• ਧੀਮੀ ਸੂਟ (ਇੰਟੀਗਰੇਸ਼ਨ, e2e) ਬੇਸਿਕਸ ਪਾਸ ਹੋਣ ਤੋਂ ਬਾਅਦ.

ਜਦੋਂ ਕੁਝ ਫੇਲ੍ਹ ਹੋਵੇ, ਕੁਝ ਠੀਕ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਦੋ ਚੀਜ਼ਾਂ ਕੈਪਚਰ ਕਰੋ: ਜਿਸ ਕਮਾਂਡ ਨੂੰ ਤੁਸੀਂ ਚਲਾਇਆ ਅਤੇ ਪੂਰਾ ਐਰਰ ਆਉਟਪੁੱਟ (ਜਿਵੇਂ-ਇਸ) ਨੂੰ ਕਾਪੀ ਕਰੋ। ਇਹ ਰਿਕਾਰਡ ਅਗਲੇ ਪ੍ਰੰਪਟ ਨੂੰ ਨਿਰਦਿਸ਼ਟ ਬਣਾਂਦਾ ਹੈ ਅਤੇ "ਹਾਲੇ ਵੀ ਫੇਲ੍ਹ ਹੋ ਰਿਹਾ ਹੈ" ਵਾਲੇ ਲੂਪ ਨੂੰ ਰੋਕਦਾ ਹੈ।

ਸਕੋਪ ਕੱਢ ਕੇ ਰੱਖੋ। ਜੇ ਲਿਨਟ ਫੇਲ੍ਹ ਕਰਦਾ ਹੈ ਅਤੇ ਟੈਸਟ ਵੀ ਫੇਲ੍ਹ ਕਰਦੇ ਹਨ, ਪਹਿਲਾਂ ਲਿਨਟ ਠੀਕ ਕਰੋ, ਦੁਬਾਰਾ ਚਲਾਓ, ਫਿਰ ਟੈਸਟਾਂ ਦਾ ਸਲਾਹ ਲਓ। ਇੱਕੋ ਸਮੇਂ "ਛੋਟੇ ਸਾਫ-ਸੁਥਰੇ" ਕੰਮਾਂ ਨੂੰ ਇੱਕ-ਥੱਲੇ ਨਾ ਮਿਲਾਓ।

ਚੈੱਕ ਹਰੇ ਹੋਣ ਤੱਕ ਫੇਲ੍ਹੀਆਂ ਨਾਲ ਮੁੜ-ਪ੍ਰੰਪਟ ਕਰੋ

ਜਦੋਂ ਚੈੱਕ ਫੇਲ੍ਹ ਹੁੰਦੇ ਹਨ, ਤਾਂ ਫੇਲ੍ਹ ਆਉਟਪੁੱਟ ਨੂੰ ਆਪਣੇ ਅਗਲੇ ਪ੍ਰੰਪਟ ਵਜੋਂ ਵਰਤੋ। ਸਭ ਤੋਂ ਤੇਜ਼ ਲੂਪ ਇਹ ਹੈ: ਐਰਰ ਪੇਸਟ ਕਰੋ, ਇਕ ਨਿਰਣਾ ਲਵੋ, ਸਭ ਤੋਂ ਛੋਟਾ ਫਿਕਸ ਲਗਾਓ, ਅਤੇ ਦੁਬਾਰਾ ਚਲਾਓ।

ਫੇਲ੍ਹੀਆਂ ਨੂੰ ਬਿਲਕੁਲ-ਬਿਲਕੁਲ ਵਰਤੀ-ਬਿਲਕੁਲ ਪੇਸਟ ਕਰੋ, ਜਿਸ ਵਿੱਚ ਕਮਾਂਡ ਅਤੇ ਪੂਰਾ ਸਟੈਕ ਟਰੇਸ ਸ਼ਾਮਲ ਹੋਵੇ। ਪਹਿਲਾਂ ਸਭ ਤੋਂ ਸੰਭਾਵਿਤ ਕਾਰਨ ਮੰਗੋ, ਇੱਕ ਵਿਕਲਪਾਂ ਦੀ ਮੀਨੂੰ ਨਹੀਂ। Claude Code ਜਦੋਂ ਸਹੀ ਲਾਈਨ ਨੰਬਰਾਂ ਅਤੇ ਸੁਨੇਹਿਆਂ 'ਤੇ ਅੰਕਿਤ ਕਰ ਸਕਦਾ ਹੈ ਤਾਂ ਉਹ ਬਿਹਤਰ ਕੰਮ ਕਰਦਾ ਹੈ।

ਇੱਕ ਵਾਕ ਵਿੱਚ ਜੋ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਉਸ ਬਾਰੇ ਦੱਸੋ ਤਾਂ ਕਿ ਉਹ ਤੁਹਾਨੂੰ ਚੱਕਰ ਵਿੱਚ ਨਾ ਭੇਜੇ। ਉਹਨਾਂ ਪਾਬੰਦੀਆਂ ਨੂੰ ਦੁਹਰਾਓ ਜੋ ਜ਼ਰੂਰੀ ਹਨ ("ਪਬਲਿਕ APIs ਨਾ ਬਦਲੋ," "ਸਿਰਫ਼ ਕਰੈਸ਼ ਠੀਕ ਕਰੋ"). ਫਿਰ ਸਭ ਤੋਂ ਛੋਟਾ ਪੈਚ ਮੰਗੋ ਜੋ ਚੈੱਕ ਪਾਸ ਕਰਵਾਏ।

ਜੇ ਸੁਝਾਇਆ ਗਿਆ ਫਿਕਸ ਵਿਹਾਰ ਬਦਲਦਾ ਹੈ, ਤਾਂ ਇੱਕ ਟੈਸਟ ਮੰਗੋ ਜੋ ਨਵੇਂ ਵਿਹਾਰ ਨੂੰ ਸਹੀ ਸਾਬਿਤ ਕਰੇ। ਜੇ ਇੱਕ ਹੈਂਡਲਰ ਹੁਣ 400 ਵਾਪਸ ਕਰਦਾ ਹੈ ਬਜਾਏ 500 ਦੇ, ਤਾਂ ਇੱਕ ਫੋਕਸਡ ਟੈਸਟ ਮੰਗੋ ਜੋ ਪੁਰਾਣੇ ਕੋਡ 'ਤੇ ਫੇਲ੍ਹ ਹੋਵੇ ਅਤੇ ਫਿਕਸ 'ਤੇ ਪਾਸ ਹੋਵੇ। ਇਹ ਕੰਮ ਨੂੰ ਇਮਾਨਦਾਰ ਰੱਖਦਾ ਹੈ ਅਤੇ PR ਨੂੰ ਜ਼ਿਆਦਾ ਭਰੋਸੇਯੋਗ ਬਣਾਉਂਦਾ ਹੈ।

ਜਦੋਂ ਚੈੱਕ ਹਰੇ ਹੋਣ ਅਤੇ ਡਿਫ਼ ਇੱਕ ਸੋਚ ਦੀ ਤਰ੍ਹਾਂ ਹੀ ਰਹੇ, ਰੁਕੋ। ਜੇ ਮਾਡਲ ਗੈਰ-ਸੰਬੰਧਿਤ ਕੋਡ ਸੁਧਾਰਣਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦਾ ਹੈ, ਫਿਰ ਮੁੜ-ਪ੍ਰੰਪਟ ਕਰੋ: "Only address the failing test. No cleanup."