ਚੈਟ-ਨਿਰਮਿਤ ਐਪਾਂ ਲਈ ਏਜੰਟ ਰੋਲ: ਪਲੈਨਰ ਤੋਂ ਰਿਵਿਊਅਰ ਵਰਕਫਲੋ

ਵਿਸ਼ਵਾਸਯੋਗਤਾ ਕਿਉਂ ਟੁੱਟਦੀ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਚੈਟ ਨਾਲ ਐਪ ਬਣਾਉਂਦੇ ਹੋ

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

पहਲਾ ਫੱਟ ਆਉਂਦਾ ਹੈ ਗੈਰ-ਮੌਜੂਦ ਪਾਵਣੀਆਂ ਵਿਚੋਂ: ਤੁਸੀਂ "ਇੱਕ ਸਧਾਰਣ ਸਾਇਨਅਪ ਫਲੋ" ਮੰਗਦੇ ਹੋ, ਪਰ ਕੋਈ ਵੀ ਐਡਜ ਕੇਸ ਲਿਖਦਾ ਨਹੀਂ ਕਿ ਪਾਸਵਰਡ ਰੀਸੈੱਟ ਕਿਵੇਂ ਕਿਰਿਆ ਹੋਏਗਾ, ਈਮੇਲ ਪਹਿਲਾਂ ਤੋਂ ਵਰਤੀ ਹੋਈ ਹੋਵੇ ਤਾਂ ਕੀ ਹੋਵੇਗਾ, ਜਾਂ ਉਪਭੋਗਤਾ ਰਾਹ ਰਾਹ ਵਿੱਚ ਟੈਬ ਬੰਦ ਕਰ ਦੇਵੇ ਤਾਂ ਕੀ ਹੋਵੇਗਾ।ਸਹਾਇਕ ਖੁਦ-ਹੀ ਖਾਲੀਆਂ ਭਰ ਲੈਂਦਾ ਹੈ, ਅਤੇ ਉਹ ਅਨੁਮਾਨ ਤੁਹਾਡੇ ਉਤਪਾਦ ਬਣ ਜਾਂਦੇ ਹਨ।

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

ਤੀਜਾ ਫੱਟ ਪ੍ਰਮਾਣ ਦੀ ਘਾਟ ਹੈ।ਬੁਨਿਆਦੀ ਟੈਸਟ ਅਤੇ ਸਾਫ਼ ਐਕਸੈਪਟੈਂਸ ਚੈੱਕਾਂ ਦੇ ਬਿਨਾ, ਤੁਸੀਂ ਮੁਸ਼ਕਲਾਂ ਸਿਰਫ਼ ਬਾਅਦ ਵਿੱਚ ਹੀ ਪਤਾ ਲਗਦੀਆਂ ਹਨ।ਫਿਰ "ਮੇਰੇ ਸਕਰੀਨ ਤੇ ਚੱਲਦਾ ਹੈ" ਦੇ ਰੂਪ ਵਿੱਚ ਦੇਰ ਰਾਤਾਂ, ਤੁਰੰਤ ਫਿਕਸ ਅਤੇ ਅਣਜਾਣ ਰਿਗ੍ਰੈਸ਼ਨਾਂ ਵਿੱਚ ਬਦਲ ਜਾਂਦਾ ਹੈ।

ਸਧਾਰਨ ਸੁਧਾਰ ਇਹ ਹੈ ਕਿ ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੇ ਪੇਰਸੋਨਾ ਵਰਤੋ: ਇੱਕ Planner ਜੋ ਕੰਮ ਨੂੰ konkret ਬਣਾਏ, ਇੱਕ Architect ਜੋ ਆਕਾਰ ਨਿਰਧਾਰਤ ਕਰੇ, ਇੱਕ Implementer ਜੋ ਛੋਟੇ ਕਦਮਾਂ ਵਿੱਚ ਬਣਾਏ, ਇੱਕ Tester ਜੋ ਟੁੱਟਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੇ, ਅਤੇ ਇੱਕ Reviewer ਜੋ ਆਖਰੀ 10% ਪਕੜੇ ਜੋ 90% ਦਰਦ ਦਾ ਕਾਰਨ ਬਣਦੇ ਹਨ।ਇਹ ਕੋਈ ਭਾਰੀ ਪ੍ਰਕਿਰਿਆ ਨਹੀਂ ਹੈ—ਇਹ ਫੈਸਲਿਆਂ ਨੂੰ ਕੁਨਿਸਟੈਂਟ ਰੱਖਣ ਦਾ ਇੱਕ ਦੁਹਰਾਇਆ ਜਾ ਸਕਣ ਵਾਲਾ ਤਰੀਕਾ ਹੈ।

ਇਹ तरीका solo founder, ਛੋਟੀ ਟੀਮਾਂ ਅਤੇ ਗੈਰ-ਟੈਕਨੀਕਲ ਨਿਰਮਾਤਿਆਂ ਲਈ ਵੀ ਕੰਮ ਕਰਦਾ ਹੈ ਜੋ Koder.ai ਵਰਗੇ ਚੈਟ ਟੂਲ ਵਰਤ ਰਹੇ ਹਨ।ਤੁਸੀਂ ਫਿਰ ਵੀ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵੱਧ ਸਕਦੇ ਹੋ, ਪਰ ਤੁਹਾਡੀ ਭਰੋਸਾ ਕਿਸੇ ਕਿਸਮ ਦੀ ਕਿਸਮਤ 'ਤੇ ਨਾਹ ਰਹੇਗੀ।

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

ਮੂਲ ਵਿਚਾਰ: ਜਿੰਮੇਵਾਰੀਆਂ ਵੱਖਰੀਆਂ ਰੱਖੋ, ਫਿਰ ਸਾਫ਼ ਹੈਂਡਆਫ ਕਰੋ

ਜਦੋਂ ਇੱਕ ਹੀ ਚੈਟ ਹਰ ਕੰਮ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ—ਕੀ ਬਣਾਉਣਾ ਹੈ ਤੈਅ ਕਰਨਾ, ਡਿਜ਼ਾਈਨ, ਕੋਡ, ਟੈਸਟ ਅਤੇ ਜੱਜ—ਤਾਂ ਵਿਸ਼ਵਾਸਯੋਗਤਾ ਘੱਟ ਹੁੰਦੀ ਹੈ।ਇਹਨਾਂ ਕੰਮਾਂ ਨੂੰ ਮਿਲਾਉਣਾ ਐਥੇ ਆਸਾਨੀ ਨਾਲ ਐਡਜ ਕੇਸਾਂ ਗੁੰਮ ਹੋ ਜਾਣਾ, ਬਿਲਡ ਦੌਰਾਨ ਮੰਗ ਬਦਲਣਾ, ਜਾਂ ਬੱਗ ਨੂੰ "ਫਿਕਸ" ਕਰਨ ਲਈ ਹੋਰ ਗੁੰਝਲਦਾਰ ਤੱਤ ਜੁੜ ਜਾਣਾ ਬਣਾਉਂਦਾ ਹੈ।

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

ਆਮ ਤੌਰ 'ਤੇ ਕਿਸੇ ਵੀ ਫੀਚਰ ਲਈ ਇਹ ਕ੍ਰਮ ਵਰਤੋ:

• Planner: ਲਕਸ਼, ਉਪਭੋਗਤਾ, ਐਕਸੈਪਟੈਂਸ ਚੈੱਕ ਅਤੇ ਜੋ ਬਾਹਰ ਹੈ ਉਹ ਪਰਿਚਾਰ ਕਰੋ
• Architect: ਲਕਸ਼ ਨੂੰ ਸਹਿਯੋਗ ਦੇ ਸਕਣ ਵਾਲੀ ਸਭ ਤੋਂ ਸਧਾਰਣ ਡਿਜ਼ਾਈਨ ਸੁਝਾਓ
• Implementer: ਯੋਜਨਾ ਮੁਤਾਬਕ ਬਿਲਡ ਕਰੋ, ਛੋਟੇ-ਛੋਟੇ ਕਦਮਾਂ ਵਿੱਚ
• Tester: ਟੁੱਟਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ ਅਤੇ ਅਸਫਲਤਾਵਾਂ ਸਪਸ਼ਟ ਤਰੀਕੇ ਨਾਲ ਰਿਪੋਰਟ ਕਰੋ
• Reviewer: ਆਖਰੀ ਮਿਲੀ ਦੂਰੀ ਦੇ ਵੇਰਵੇ ਜਾਂਚੋ (ਨਾਮਕਰਨ, ਸੁਰੱਖਿਆ ਬੇਸਿਕ, UX ਗੈਪ, ਖਤਰਨਾਕ ਸ਼ਾਰਟਕਟ)

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

ਮਕਸਦ ਨਾਲ ਪਿੱਛੇ ਜਾਓ, ਯਾਦਗਾਰ ਤਰੀਕੇ ਨਾਲ ਨਹੀਂ।ਜੇ ਟੈਸਟ ਫੇਲ ਹੋਏ, Implementer ਨੂੰ ਇੱਕ ਮਿੰਨੀਮਲ ਬੱਗ ਰਿਪੋਰਟ ਨਾਲ ਵਾਪਸ ਜਾਓ।ਜੇ ਡਿਜ਼ਾਈਨ ਨਵੀਂ ਮੰਗ ਨੂੰ ਸਹਾਰ ਨਹੀਂ ਸਕਦੀ, Architect ਕੋਲ ਵਾਪਸ ਜਾਓ।ਜੇ ਮੰਗ ਅਸਪਸ਼ਟ ਹੈ ਜਾਂ ਲਗਾਤਾਰ ਬਦਲ ਰਹੀ ਹੈ, ਤਾਂ ਰੁਕੋ ਅਤੇ Planner ਕੋਲ ਵਾਪਸ ਜਾਓ।

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

ਪਰਸੋਨਾ 1: Planner (ਕਿਸੇ ਨੇ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਕੰਮ ਸਾਫ਼ ਬਣਾਓ)

Planner ਦਾ ਕੰਮ ਇੱਕ ਧੁੰਦਲਾ ਆਈਡੀਆ ਲੈ ਕੇ ਉਸਨੂੰ ਅਜਿਹੇ ਰੂਪ ਵਿੱਚ ਬਦਲਣਾ ਹੈ ਜਿਹੜਾ ਬਣਾਉਣਾ ਅਤੇ ਜਾਂਚਨਾ ਸੰਭਵ ਹੋਵੇ।ਇਹ "ਡੌਕਸ ਲਿਖਣ" ਨਹੀਂ—ਇਹ ਪਹਿਲੇ ਸਕਰੀਨ ਜਾਂ API endpoint ਬਣਨ ਤੋ ਪਹਿਲਾਂ "ਡਨ" ਦਾ ਸਹਿਮਤੀ ਹੈ।

ਇੱਕ ਵਧੀਆ Planner ਆਉਟਪੁੱਟ ਛੋਟਾ ਅਤੇ ਟੈਸਟਯੋਗ ਹੁੰਦਾ ਹੈ: ਇੱਕ ਸਪਸ਼ਟ ਸਮੱਸਿਆ ਬਿਆਨ, ਕੁਝ ਯੂਜ਼ਰ ਸਟੋਰੀਜ਼, ਸਧਾਰਣ ਐਕਸੈਪਟੈਂਸ ਮਾਪਦੰਡ, ਅਤੇ ਕੁਝ ਐਡਜ ਕੇਸ।ਇਹ ਇਹ ਵੀ ਦੱਸਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਅਜੇ ਕੀ ਨਹੀਂ ਕਰ ਰਹੇ, ਤਾਂ ਜੋ Implementer ਗਲਤੀ ਨਾਲ ਵੱਡੀ ਫੀਚਰ ਨਾ ਬਣਾਏ।

Planner ਪ੍ਰਾਂਪਟ ਟੈਂਪਲੇਟ (ਛੋਟੀ, ਤਰਜੀਹੀ ਯੋਜਨਾ)

ਇਸਦਾ ਪ੍ਰਯੋਗ ਉਦੋਂ ਕਰੋ ਜਦੋਂ ਤੁਹਾਡੇ ਕੋਲ ਕੋਈ ਫੀਚਰ ਆਈਡੀਆ ਹੋਵੇ ਅਤੇ ਤੁਸੀਂ ਇੱਕ ਟੀਟ ਯੋਜਨਾ ਚਾਹੁੰਦੇ ਹੋ ਜੋ ਬਾਕੀ ਰੋਲ ਫਾਲੋ ਕਰ ਸਕਣ।

You are the Planner. Turn the feature idea below into a buildable plan.

Feature idea:
<PASTE IDEA>

Context:
- App type:
- Target users:
- Current behavior (if any):
- Constraints (time, data, compliance, devices):

Output (keep it short):
1) Problem statement (1-2 sentences)
2) Assumptions (3-6 bullets)
3) Questions to confirm (max 6, prioritized)
4) User stories (2-5)
5) Acceptance criteria (5-10, testable, specific)
6) Edge cases & failure modes (3-8)
7) Out of scope (3-6 bullets)
8) Small milestone plan (2-4 steps, highest value first)

Planner ਤੋਂ Architect ਹੈਂਡਆਫ (ਸੰਰਚਿਤ ਅਤੇ ਛੋਟਾ)

ਇਸ ਸੁਨੇਹੇ ਨੂੰ ਇਸੇ ਰੂਪ ਵਿੱਚ (ਭਰਿਆ ਹੋਇਆ) ਭੇਜੋ ਤਾਂ ਕਿ ਘੁੰਮ-ফਿਰ ਕੇ ਸੰਚਾਰ ਘੱਟ ਹੋਵੇ।

PLANNER HANDOFF
Feature: <name>
Problem: <1-2 sentences>
Users: <who>
Must-haves (AC): <5-10 acceptance criteria>
Key edge cases: <3-6>
Out of scope: <3-6>
Open questions (need Architect input): <1-4>
Constraints: <tech, data, privacy, deadlines>
Success signal: <how we’ll know it worked>

ਜੇ Planner ਵਜੋਂ ਤੁਸੀਂ ਸਿਰਫ਼ ਇੱਕ ਚੀਜ਼ ਕਰੋ, ਤਾਂ acceptance criteria ਨੂੰ ਮਾਪਯੋਗ ਬਣਾਉ।ਉਦਾਹਰਣ ਲਈ: “ਉਪਭੋਗਤਾ 60 ਸਕਿੰਟ ਵਿੱਚ ਪਾਸਵਰਡ ਰੀਸੈੱਟ ਲਈ ਈਮੇਲ ਪ੍ਰਾਪਤ ਕਰ ਲੈਂਦਾ ਹੈ” ਬਿਹਤਰ ਹੈ ਬਨਾਮ “ਪਾਸਵਰਡ ਰੀਸੈੱਟ ਕੰਮ ਕਰਦਾ ਹੈ।”

ਪਰਸੋਨਾ 2: Architect (ਉਹ ਆਕਾਰ ਚੁਣੋ ਜੋ ਐਪ ਅਸਲ ਵਿੱਚ ਸਹਾਰ ਸਕੇ)

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

ਇਥੇ ਵਿਸ਼ਵਾਸਯੋਗਤਾ ਅਸਲੀ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ: ਸਪਸ਼ਟ ਸીમਾਵਾਂ, ਸਪਸ਼ਟ ਡੇਟਾ ਅਤੇ ਸਪਸ਼ਟ ਫੇਲਅਰ ਪਾਥ।

ਇੱਕ ਵਰਤਣਯੋਗ Architect ਆਉਟਪੁੱਟ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਕਵਰ ਕਰਦਾ ਹੈ:

• ਸਕ੍ਰੀਨ (React ਜਾਂ Flutter) ਜਾਂ API endpoint (Go)
• ਇੱਕ ਛੋਟਾ ਡੇਟਾ ਮਾਡਲ (PostgreSQL ਟੇਬਲ ਅਤੇ ਮੁੱਖ ਫੀਲਡ)
• ਇੱਕ ਜਾਂ ਦੋ ਕੋਰ ਫਲੋ (ਹੈਪੀ ਪਾਥ ਨਾਲ ਜੋ ਖਰਾਬ ਹੋ ਸਕਦਾ ਹੈ)
• ਨਾਨ-ਫੰਕਸ਼ਨਲ ਬੇਸਿਕਸ ਜੋ ਹੁਣ ਮਾਮਲੇ ਵਿੱਚ ਮਾਇਨੇ ਰੱਖਦੇ ਹਨ (auth, privacy, performance, logging)
• ਟਰੇਡਆਫਸ (ਕਿਹੜਾ ਕੰਮ ਅਜੇ ਨਹੀਂ ਬਣਾਇਆ ਜਾ ਰਿਹਾ)

ਇਹ konkreਤ ਰੱਖੋ।"ਨੋਟੀਫਿਕੇਸ਼ਨ ਸਿਸਟਮ" ਕਿਉਂਕਿ ਨਹੀਂ, ਬਲਕਿ "POST /api/alerts, table alerts(user_id, type, status), show unread count in header." ਜਿਵੇਂ ਲਿਖੋ।"ਸੇਫ" ਕਹਿਣ ਦੀ ਬਜਾਏ, ਕਹੋ "JWT session, role checks on admin endpoints, protect PII fields."

ਪ੍ਰਾਂਪਟ ਟੈਂਪਲੇਟ: Architect ਹੈਂਡਆਫ (ਟਰੇਡਆਫ ਮਜਬੂਰ ਕਰਦਾ ਹੈ)

ਇਸਦਾ ਪ੍ਰਯੋਗ ਉਸ ਵੇਲੇ ਕਰੋ ਜਦੋਂ Planner ਨੇ ਕੰਮ Architect ਨੂੰ ਦਿੱਤਾ ਹੋਵੇ, ਜਾਂ ਜਦੋਂ ਕੋਈ ਫੀਚਰ ਗੁੰਝਲਦਾਰ ਮਹਿਸੂਸ ਹੋਵੇ।

You are the Architect.
Goal: design the simplest buildable structure for this feature.
Context:
- App type: [web/mobile/both]
- Stack: React UI, Go API, PostgreSQL DB (Flutter screens if mobile)
- Existing constraints: [auth method, existing tables, deadlines]

Input (from Planner):
- User story:
- Acceptance criteria:
- Out of scope:

Deliverables (keep it short and specific):
1) UI map: list screens/components with 1-line purpose each.
2) API map: list endpoints with method, path, request/response fields.
3) Data model: tables + key columns + relationships.
4) Key flows: happy path + 2 failure cases and how UI should respond.
5) Non-functional needs: security, performance, audit/logging (only what matters now).
6) Tradeoffs: 3 decisions you made (and what you avoided) to prevent over-design.

Rules:
- Prefer the smallest option that meets acceptance criteria.
- If something is unclear, ask up to 3 questions, otherwise make a reasonable assumption and write it down.

ਜੇ ਤੁਸੀਂ Koder.ai ਵਿੱਚ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ ਇਹ ਤਰ੍ਹਾਂ ਦਾ ਹੈਂਡਆਫ Implementation ਤੇਜ਼ ਬਣਾਉਂਦਾ ਹੈ ਕਿਉਂਕਿ Implementer ਕਿਸੇ ਅਨੁਮਾਨ 'ਤੇ ਨਿਰਭਰ ਕਰਨ ਦੀ ਬਜਾਏ ਇੱਕ ਸਪਸ਼ਟ ਨਕਸ਼ਾ ਫਾਲੋ ਕਰ ਸਕਦਾ ਹੈ।

ਪਰਸੋਨਾ 3: Implementer (ਛੋਟੇ ਕਦਮਾਂ ਵਿੱਚ ਬਣਾਓ, ਸਕੋਪ ਨੂੰ ਕਠੋਰ ਰੱਖੋ)

Implementer ਇੱਕ ਸਪਸ਼ਟ ਯੋਜਨਾ ਨੂੰ ਕਾਰਗਰ ਕੋਡ ਵਿੱਚ ਬਦਲਦਾ ਹੈ, ਬਿਨਾਂ ਯੋਜਨਾ ਬਦਲੇ।ਇੱਥੇ ਜ਼ਿਆਦਾਤਰ ਵਿਸ਼ਵਾਸਯੋਗਤਾ ਜਿੱਤੀ ਜਾਂ ਹਾਰ ਹੁੰਦੀ ਹੈ।ਲਕਸ਼ ਸਪਸ਼ਟ ਹੈ: ਜੋ ਸਹਿਮਤ ਕੀਤਾ ਗਿਆ ਉਹੀ ਬਣਾਓ, ਛੋਟੇ ਕਦਮਾਂ ਵਿੱਚ ਜੋ ਵਾਪਸ ਲਏ ਜਾ ਸਕਣ।

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

ਇੱਕ ਵਧੀਆ Implementer ਇੱਕ ਛੋਟਾ ਪ੍ਰਮਾਣ ਛੱਡਦਾ ਹੈ: ਬਿਲਡ ਕ੍ਰਮ, ਕੀ ਬਦਲਿਆ, ਕੀ ਨਹੀਂ ਬਦਲਿਆ (ਠੀਕ, ਛੁਪੇ ਸਕੋਪ ਕ੍ਰੀਪ ਤੋਂ ਬਚਾਉਣ ਲਈ), ਅਤੇ ਕਿਵੇਂ ਵੇਰਿਫਾਈ ਕਰਨਾ ਹੈ।

ਇੱਥੇ ਇੱਕ ਪ੍ਰਾਂਪਟ ਟੈਂਪਲੇਟ ਹੈ ਜੋ ਤੁਸੀਂ Implementer ਨੂੰ ਹੈਂਡਆਫ ਕਰਨ ਵੇਲੇ ਪੇਸਟ ਕਰ ਸਕਦੇ ਹੋ:

You are the Implementer.

Context:
- Feature: <name>
- Current behavior: <what happens today>
- Desired behavior: <what should happen>
- Acceptance criteria: <bullets>
- Constraints: <tech choices, performance, security, no schema change, etc.>

Before writing code:
1) Ask up to 5 questions if anything is unclear.
2) Propose a step-by-step build plan (max 6 steps). Each step must be reversible.
3) For each step, list the exact files/modules you expect to touch.

Then implement:
- Execute steps one by one.
- After each step, summarize what changed and how to verify.
- Do not add extras. If you notice a better idea, stop and ask first.

ਉਦਾਹਰਣ: ਜੇ Planner ਨੇ "ਪਾਸਵਰਡ ਰੀਸੈੱਟ ਈਮੇਲ ਫਲੋ ਜੋੜੋ" ਮੰਗੀ, ਤਾਂ Implementer ਲੌਗਿਨ ਸਕ੍ਰੀਨ ਦਾ ਡਿਜ਼ਾਈਨ ਨਹੀਂ ਬਦਲੇਗਾ।ਈਮੇਲ ਰਿਕੁਐਸਟ ਐਂਡਪੋਇੰਟ, ਫਿਰ ਟੋਕਨ ਹੈਂਡਲਿੰਗ, ਫਿਰ UI—ਹਰ ਇੱਕ ਲਘੁ-ਪੜਚੋਲ ਨੋਟ ਦੇ ਨਾਲ।ਜੇ ਤੁਹਾਡੇ टੂਲ ਵਿੱਚ ਸਨੈਪਸ਼ਾਟ ਅਤੇ ਰੋਲਬੈਕ ਦੀ ਸਹਾਇਤਾ ਹੈ (Koder.ai ਇਹ ਕਰਦਾ ਹੈ), ਤਾਂ ਛੋਟੇ ਕਦਮ ਬਹੁਤ ਸੁਰੱਖਿਅਤ ਬਣ ਜਾਂਦੇ ਹਨ।

ਪਰਸੋਨਾ 4: Tester (ਇਸ ਗੱਲ ਦਾ ਸਾਬਤ ਕਰੋ ਕਿ ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ, ਅਤੇ ਦਿਖਾਓ ਕਿ ਇਹ ਕਿਵੇਂ ਫੇਲ ਹੁੰਦਾ ਹੈ)

Tester ਦਾ ਕੰਮ ਫੀਚਰ ਨੂੰ ਯੂਜ਼ਰਾਂ ਤੋਂ ਪਹਿਲਾਂ ਤੋੜਨਾ ਹੈ।ਉਹ ਹੈਪੀ ਪਾਥ 'ਤੇ ਭਰੋਸਾ ਨਹੀਂ ਕਰਦੇ।ਉਹ ਅਸਪਸ਼ਟ ਸਥਿਤੀਆਂ, ਗੁੰਝਲਦਾਰ ਵੈਲਿਡੇਸ਼ਨ ਅਤੇ ਐਡਜ ਕੇਸਾਂ ਦੀ ਤਲਾਸ਼ ਕਰਦੇ ਹਨ ਜੋ ਪਹਿਲੇ ਦਿਨ ਉੱਪਰ ਆ ਸਕਦੇ ਹਨ।

ਇੱਕ ਚੰਗਾ Tester ਆਉਟਪੁੱਟ ਕਿਸੇ ਹੋਰ ਦੁਆਰਾ ਵਰਤਣਯੋਗ ਹੁੰਦਾ ਹੈ: ਐਕਸੈਪਟੈਂਸ ਕ੍ਰਾਈਟੇਰੀਆ ਨਾਲ ਜੁੜਿਆ ਟੈਸਟ ਮੈਟਰਿਕਸ, ਇੱਕ ਛੋਟੀ ਮੈਨੁਅਲ ਸਕ੍ਰਿਪਟ, ਅਤੇ ਬੱਗ ਰਿਪੋਰਟਾਂ ਜੋ ਸਟੈਪ-ਬਾਈ-ਸਟੈਪ (ਉਮੀਦ ਵਰਤੋਂ ਦੇ ਮੁਕਾਬਲੇ ਅਸਲ) ਨਾਲ ਹੋਣ।

ਕੀ ਟੈਸਟ ਕਰਨਾ ਹੈ (UI, API, ਅਤੇ ਡੇਟਾ)

ਕਵਰੇਜ ਉਪਰ ਉੱਤੇ ਧਿਆਨ ਦਿਓ, ਮਾਤਰਾ ਉੱਤੇ ਨਹੀਂ।ਉਸ ਜਗ੍ਹਾ 'ਤੇ ਧਿਆਨ ਦਿਓ ਜਿੱਥੇ ਫੇਲ ਹੋਣਾ ਮਹਿੰਗਾ ਪੈਂਦਾ: ਵੈਲਿਡੇਸ਼ਨ, ਅਧਿਕਾਰ ਅਤੇ ਐਰਰ ਸਥਿਤੀਆਂ।

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

ਉਦਾਹਰਣ: ਜੇ ਤੁਸੀਂ "Create invoice" ਜੋੜਿਆ, ਤਾਂ ਨੈਗੇਟਿਵ ਐਮਾਊਂਟ, 10,000 ਕੈਰੈਕਟਰ ਨੋਟ, ਗੁੰਮ ਘਾਹਕ, ਅਤੇ ਡਬਲ-submit ਕਲਿੱਕ ਟੈਸਟ ਕਰੋ।

ਪ੍ਰਾਂਪਟ ਟੈਂਪਲੇਟ: acceptance criteria ਤੋਂ ਟੈਸਟ ਮੈਟਰਿਕਸ ਬਣਾਓ

ਇਸਦਾ ਉਪਯੋਗ Implementer ਤੋਂ Tester ਨੂੰ ਹੈਂਡਆਫ ਕਰਨ ਵੇਲੇ ਕਰੋ।ਐਕਸੈਪਟੈਂਸ ਕ੍ਰਾਈਟੇਰੀਆ ਅਤੇ ਕੋਈ ਸੰਬੰਧਿਤ UI/API ਨੋਟ ਪੇਸਟ ਕਰੋ।

ROLE: Tester
GOAL: Produce a test matrix tied to acceptance criteria, including negative tests.
CONTEXT:
- Feature: <name>
- Acceptance criteria:
  1) <AC1>
  2) <AC2>
- Surfaces: UI screens: <list>; API endpoints: <list>; DB changes: <notes>
OUTPUT FORMAT:
1) Test matrix table with columns: AC, Test case, Steps, Expected result, Notes
2) Negative tests (at least 5) that try to break validation and permissions
3) Manual test script (10 minutes max) for a non-technical person
4) Bug ticket template entries for any failures you predict (Title, Steps, Expected, Actual, Severity)
CONSTRAINTS:
- Keep steps precise and reproducible.
- Include at least one test for loading/error states.

ਪਰਸੋਨਾ 5: Reviewer (ਉਹ ਆਖਰੀ 10% ਫੜੋ ਜੋ 90% ਦਰਦ ਦਾ ਕਾਰਨ ਬਣਦਾ ਹੈ)

Reviewer ਆਖਰੀ ਗੁਣਵੱਤਾ ਪਾਸ ਹੈ।ਮਕਸਦ ਸਭ ਕੁਝ ਦੁਬਾਰਾ ਲਿਖਣਾ ਨਹੀਂ, ਪਰ ਛੋਟੀ ਮਿਸਾਂ, ਗੁੰਝਲਦਾਰ ਨਾਮ, ਕਮਜ਼ੋਰ ਐਰਰ ਸੁਨੇਹੇ ਅਤੇ ਖਤਰਨਾਕ ਸ਼ਾਰਟਕਟਾਂ ਨੂੰ ਪਕੜਨਾ ਹੈ ਜੋ ਬਾਅਦ ਵਿੱਚ ਲੰਬੇ ਬੱਗ ਬਣ ਜਾਂਦੇ ਹਨ।

ਇੱਕ ਵਧੀਆ ਰਿਵਿਊ ਸਪਸ਼ਟ ਆਉਟਪੁੱਟ ਦਿੰਦਾ ਹੈ: ਕੀ ਜਾਂਚਿਆ ਗਿਆ, ਕੀ ਬਦਲਣਾ ਲਾਜ਼ਮੀ ਹੈ, ਕੀ ਰਿਸਕੀ ਪਰ ਬਰਦਾਸ਼ਤ ਯੋਗ ਹੈ, ਅਤੇ ਕੀ ਫੈਸਲਾ ਕੀਤਾ ਗਿਆ (ਤਾਂ ਜੋ ਅਗਲੇ ਹਫ਼ਤੇ ਇਸ 'ਤੇ ਦੁਬਾਰਾ ਬਹਿਸ ਨਾ ਹੋਵੇ)।

Reviewer ਕਿਸ ਨੂੰ ਵੇਖਦਾ ਹੈ

ਪਾਸ-ਛੋਟਾ ਅਤੇ ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲਾ ਰੱਖੋ।ਉਹ ਚੀਜ਼ਾਂ 'ਤੇ ਧਿਆਨ ਦਿਓ ਜੋ ਜ਼ਿਆਦਾਤਰ ਵਾਰ ਵਿਸ਼ਵਾਸਯੋਗਤਾ ਤੋੜਦੀਆਂ ਹਨ:

• Consistency: ਨਾਮ, ਪੈਟਰਨ, ਫੋਲਡਰ ਸੰਰਚਨਾ ਅਤੇ UI ਵਿਹੈਵੀਅਰ ਮੌਜੂਦਾ ਐਪ ਨਾਲ ਮਿਲਦੇ ਹੋਣ
• Security basics: ਇਨਪੁੱਟ ਵੈਲਿਡੇਸ਼ਨ, auth ਚੈੱਕ, ਲੋਗਜ਼ ਵਿੱਚ ਸੰਵેદਨਸ਼ੀਲ ਡੇਟਾ ਨਾ ਹੋਵੇ
• Errors: ਯੂਜ਼ਰ-ਮੁਖਾਬਲੇ ਸੁਨੇਹੇ ਸਪਸ਼ਟ; ਸਰਵਰ ਐਰਰ actionable; ਕੋਈ ਸਾਇਲੈਂਟ ਫੇਲਅਰ ਨਾ ਹੋਵੇ
• Maintainability: ਛੋਟੇ ਫੰਕਸ਼ਨ, ਇਰਾਦਾ ਸਪਸ਼ਟ, ਬੇਕਾਰ ਨਕਲ ਨਾਹ ਹੋਵੇ ਬਿਨਾਂ ਕਾਰਨ
• Future changes: ਕੀ ਵਧੇਰੇ ਮਹਿੰਗਾ ਹੋਵੇਗਾ ਅਤੇ ਉਸ ਲਾਗਤ ਨੂੰ ਘਟਾਉਣ ਦੇ ਤਰੀਕੇ

ਸੰਰਚਿਤ ਰੀਵਿਊ ਪ੍ਰਾਂਪਟ (ਮੰਜ਼ੂਰ ਕਰੋ ਜਾਂ ਬਦਲਾਅ ਮੰਗੋ)

ਇਸ ਹੈਂਡਆਫ ਦੀ ਵਰਤੋਂ ਕਰੋ ਜਦੋਂ Implementer ਕਹੇ ਕਿ ਫੀਚਰ ਹੋ ਗਿਆ ਹੈ:

You are the Reviewer. Do a final review for correctness, clarity, and maintainability.

Context
- Feature goal:
- User flows:
- Key files changed:
- Data model/migrations:

Review checklist
1) Correctness: does it meet the goal and handle edge cases?
2) Security basics: auth, validation, safe logging.
3) Errors: clear messages, consistent status codes.
4) Consistency: naming, patterns, UI text.
5) Maintainability: complexity, duplication, TODOs.

Output format
- Findings (bulleted): include file/function references and severity (high/medium/low)
- Requested changes (must-fix before merge)
- Risk notes (acceptable with reason)
- Decision log updates (what we decided and why)

Finish with exactly one:
APPROVE
CHANGES REQUESTED

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

ਹੈਂਡਆਫ ਟੈਂਪਲੇਟ ਜੋ ਦੁਬਾਰਾ ਕੰਮ ਨੂੰ ਰੋਕਦੇ ਹਨ

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

ਹਰ ਵਾਰੀ ਇਕ ਸਾਂਝਾ ਹੈਡਰ ਦਿਓ, ਭਾਵੇਂ ਛੋਟੇ ਟਾਸਕ ਲਈ:

• Context + Goal: ਇੱਕ ਪੈਰਾਗ੍ਰਾਫ ਵਿੱਚ ਤੁਸੀਂ ਕੀ ਬਣਾਉਂਦੇ ਹੋ ਅਤੇ ਕਿਉਂ।
• Inputs: ਸਕ੍ਰੀਨ, API ਨੋਟਸ, ਡੇਟਾ ਫੀਲਡ, ਸੈਂਪਲ ਰਿਕਾਰਡ, ਸੰਬੰਧਤ ਕੋਡ ਖੇਤਰ।
• Constraints: ਟੈਕ ਚੋਣਾਂ, ਡੈਡਲਾਈਨ, ਪਰਫਾਰਮੈਂਸ, ਸੁਰੱਖਿਆ, ਉਹ ਵਿਹਾਰ ਜੋ ਰੱਖਣੇ ਨੇ।
• Definition of Done: ਮਾਪਯੋਗ ਚੈੱਕ (ਕੀ ਪਾਸ ਹੋਣਾ ਚਾਹੀਦਾ, ਕੀ ਮੌਜੂਦ ਹੋਣਾ ਚਾਹੀਦਾ)।
• Assumptions / Open questions / Decisions made: ਜੋ ਤੁਸੀਂ ਅਨੁਮਾਨ ਲਿਆ, ਜੋ ਅਣਜਾਣ ਹੈ, ਅਤੇ ਜੋ ਫੈਸਲਾ ਕੀਤਾ ਗਿਆ।

ਇਥੇ Architect -> Implementer ਲਈ ਇੱਕ ਸਿੰਗਲ ਹੈਂਡਆਫ ਉਦਾਹਰਣ ਹੈ:

ROLE HANDOFF: Architect -> Implementer
Context: Add “Invite team member” to the admin area.
Goal: Admin can send an invite email; invited user can accept and set a password.
Inputs: Existing Users table; auth uses JWT; email provider already configured.
Constraints: Go backend + PostgreSQL; React UI; audit log required; no breaking auth changes.
Definition of Done:
- UI: invite modal + success state
- API: POST /invites, POST /invites/accept
- DB: invites table with expiry; audit event on create/accept
- Tests: happy path + expired invite + reused token
Assumptions: Email templates can reuse “reset password” styling.
Open questions: Should invites be single-use per email?
Decisions made: 72h expiry; tokens stored hashed.

ਜੇ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਇਹ ਅਟਕ ਜਾਵੇ, ਤਾਂ ਆਪਣੇ ਟੈਂਪਲੇਟ ਸੇਵ ਕਰੋ ਜਿੱਥੇ ਹਰ ਕੋਈ ਕਾਪੀ ਕਰ ਸਕੇ।ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਤ ਰਹੇ ਹੋ, ਤਾਂ ਇਹ ਪ੍ਰਾਂਪਟਸ Planning Mode ਵਿੱਚ ਰੱਖੋ ਅਤੇ ਇੰਪਲੀਮੇਂਟੇਸ਼ਨ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਸਨੈਪਸ਼ਾਟ ਲਓ ਤਾਂ ਕਿ ਜਦੋਂ ਸਕੋਪ ਬਦਲੇ, ਰੋਲਬੈਕ ਸੌਖਾ ਹੋਵੇ।

ਹਰ ਫੀਚਰ ਲਈ ਤੁਸੀਂ ਅਨੁਸਰਨ ਯੋਗ ਕਦਮ-ਬਦ-ਕਦਮ ਵਰਕਫਲੋ

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

ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਫਲੋ ਇਸ ਤਰ੍ਹਾਂ ਹੁੰਦੀ ਹੈ:

1. Planner: ਯੂਜ਼ਰ ਸਟੋਰੀ, ਐਡਜ ਕੇਸ ਅਤੇ acceptance criteria ਪੁਸ਼ਟੀ ਕਰੋ (ਸਫਲਤਾ, ਅਸਫਲਤਾ, ਅਤੇ "ਜੇ ਯੂਜ਼ਰ X ਕਰਦਾ ਹੈ ਤਾਂ ਕੀ")।
2. Architect: ਸਭ ਤੋਂ ਛੋਟਾ ਡੇਟਾ ਮਾਡਲ ਅਤੇ API ਸਤਹ ਸੁਝਾਓ (ਟੇਬਲ/ਫੀਲਡ, endpoints, auth ਨਿਯਮ), ਅਤੇ ਕੀ ਤੁਸੀਂ ਨਹੀਂ ਬਣਾ ਰਹੇ ਉਸਦੀ ਛੋਟੀ ਨੋਟ।
3. Implementer: ਇੱਕ ਪਤਲਾ ਸਲਾਈਸ end-to-end ਬਣਾਓ (UI ਤੋਂ API ਤੱਕ DB) ਜੋ acceptance criteria ਮਿਲਾਏ, ਭਾਵੇਂ UI ਸਧਾਰਣ ਹੋਵੇ।
4. Tester: ਇੱਕ ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲਾ ਟੈਸਟ ਸਕ੍ਰਿਪਟ ਚਲਾਓ, ਫੇਲ ਹੋਇਆਂ ਦੀਆਂ ਸਟੀਪਾਂ ਨਾਲ ਲੌਗ ਕਰੋ, ਅਤੇ ਕੋਈ ਅਸਪਸ਼ਟ ਵਿਹਾਰ ਨੋਟ ਕਰੋ।
5. Reviewer: ਸੁਰੱਖਿਆ ਬੇਸਿਕ ਅਤੇ ਪ੍ਰੋਡਕਟ ਪੋਲਿਸ਼ ਲਈ ਆਖਰੀ ਪਾਸ ਕਰੋ, ਫਿਰ ਫੈਸਲਿਆਂ ਨੂੰ ਰਿਕਾਰਡ ਕਰੋ।

ਹਰ ਕਦਮ ਦਾ ਆਉਟਪੁੱਟ ਛੋਟਾ ਅਤੇ ਸਪਸ਼ਟ ਰੱਖੋ।ਅਕਸਰ ਇੱਕ ਹੈਂਡਆਫ ਸੁਨੇਹਾ ਪਰ ਰੋਲ ਲਈ ਕਾਫੀ ਹੁੰਦਾ ਹੈ: ਇਨਪੁੱਟ, ਫੈਸਲੇ, ਅਤੇ ਤੁਹਾਨੂੰ ਅਗਲੇ ਕਦਮ ਲਈ ਕੀ ਚਾਹੀਦਾ ਹੈ।

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

ਇੱਕ ਹਕੀਕਤੀ ਉਦਾਹਰਣ: ਇੱਕ ਫੀਚਰ ਆਈਡੀਆ ਤੋਂ ਰਿਵਿਊਡ ਰਿਲੀਜ਼ ਤਕ

ਫੀਚਰ: ਇੱਕ ਸਧਾਰਣ CRM ਸਕ੍ਰੀਨ ਜਿੱਥੇ ਯੂਜ਼ਰ ਸੰਪਰਕ ਜੋੜ ਸਕਦੇ ਹਨ, ਟੈਗ ਲਗਾ ਸਕਦੇ ਹਨ (ਜਿਵੇਂ "Lead" ਜਾਂ "Vendor"), ਅਤੇ ਨਾਮ ਜਾਂ ਟੈਗ ਨਾਲ ਖੋਜ਼ ਸਕਦੇ ਹਨ।ਪਾਬੰਦੀ: ਤੁਹਾਡੇ ਕੋਲ 90 ਮਿੰਟ ਹਨ, ਅਤੇ ਤੁਹਾਨੂੰ ਮੌਜੂਦਾ contacts ਟੇਬਲ ਰੀਯੂਜ਼ ਕਰਨੀ ਹੈ (ਕੋਈ ਬ੍ਰੇਕਿੰਗ ਮਾਈਗਰੇਸ਼ਨ ਨਹੀਂ)।ਮੋਬਾਈਲ ਲਈ ਇੱਕ single "Add Contact" ਸਕਰੀਨ ਜੋ ਇੱਕ ਪੇਜ਼ 'ਤੇ ਫਿੱਟ ਹੋ ਜਾਵੇ।

ਹੇਠਾਂ ਹੈ ਹੈਂਡਆਫ ਜਦੋਂ ਤੁਸੀਂ ਇਹ ਪੇਰਸੋਨਾ ਚੇਨ ਵਰਤਦੇ ਹੋ।ਹਰ ਰੋਲ ਇੱਕ ਛੋਟਾ ਨਿਰਧਾਰਿਤ ਆਰਟੀਫੈਕਟ ਤੈਅ ਕਰਦਾ ਹੈ ਜਿਸ 'ਤੇ ਅਗਲਾ ਵਿਅਕਤੀ ਨਿਰਭਰ ਕਰ ਸਕਦਾ ਹੈ।

Planner output (definition + acceptance)
- Goal: Add contacts with tags and fast search.
- Must: Create, edit, list contacts; add/remove tags.
- Search: matches name OR any tag; results update in under 300ms.
- Constraint: keep existing contacts table; tags can be new table.
- Done when: 5 test cases pass; mobile screen has no scroll on common devices.

Architect output (shape + data)
- Tables: contacts (existing), tags (id, name), contact_tags (contact_id, tag_id).
- API: POST /contacts, PATCH /contacts/:id, GET /contacts?query=.
- Search: SQL ILIKE on contact name + join on tags.
- UI: Contact list with search bar; contact form with tag picker.
- Risk: duplicate tags ("lead" vs "Lead") - enforce lowercase unique.

Implementer output (small steps)
- Step 1: Add tags + join table migrations.
- Step 2: Update backend handlers and query.
- Step 3: Build React UI list + form; wire to API.
- Step 4: Add basic validation (name required, tag length).
- Step 5: Add loading/error states; keep UI responsive.

Tester output (proof + failure)
- Case: search "lea" returns contacts tagged "lead". FAIL: returns none.
- Case: adding tag "Lead" then "lead" should not create two tags. PASS.
- Case: empty name rejected. PASS.
- Bug note: backend search only checks contact name, not tags.

Loop-back (Planner update)
- Update acceptance: search must match tags via join; include a test for it.
- Add edge case: searching by tag should return even if name doesn’t match.

Reviewer output (last 10%)
- Check: query uses indexes; add index on tags.name and contact_tags.tag_id.
- Check: error messages are clear; avoid raw SQL errors.
- Check: mobile form spacing and tap targets.
- Confirm: snapshots/rollback point created before release.

ਉਸ ਇਕ ਫੇਲ ਹੋਏ ਟੈਸਟ ਨੇ ਸਾਫ਼ ਲੂਪ-ਬੈਕ ਮਜਬੂਰ ਕੀਤਾ: ਯੋਜਨਾ ਹੋਰ ਤੀਖੀ ਹੋ ਗਈ, Implementer ਨੇ ਇਕ ਕਵੈਰੀ ਬਦਲੀ, ਅਤੇ Reviewer ਨੇ ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਪੋਲਿਸ਼ ਨੂੰ ਮਨਜ਼ੂਰ ਕੀਤਾ।

ਆਮ ਫੰਨਾਂ (ਅਤੇ ਸਧਾਰਨ ਸੁਧਾਰ)

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

• ਪਰਸੋਨਾ ਇਕੱਠੇ ਹੋ ਜਾਂਦੇ ਹਨ (ਜਰੂਰਤਾਂ ਸਥਿਰ ਨਾ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਬਿਲਡ ਕਰਨਾ)। ਸੁਧਾਰ: Planner ਆਉਟਪੁੱਟ ਨੂੰ ਲੌਕ ਕਰੋ ਪਹਿਲਾਂ ਕਿ ਕੋਈ ਕੋਡ ਬਣਾ।ਟੈਂਪਲੇਟ ਟਵੀਕ: “Implementer: Planner ਦੇ Scope, Assumptions ਅਤੇ Acceptance Criteria ਮੌਜੂਦ ਹੋਣ ਤੱਕ ਕੋਡ ਨਾਹ ਲਿਖੋ।ਜੇ ਨਹੀਂ, ਤਾਂ ਵੱਧ ਤੋਂ ਵੱਧ 3 ਸਵਾਲ ਪੁੱਛੋ।”
• Definition of Done ਨਹੀਂ ਹੁੰਦਾ, ਇਸ ਲਈ ਕੰਮ ਕਦੇ ਖਤਮ ਨਹੀਂ ਹੁੰਦਾ। ਸੁਧਾਰ: ਹਰ ਹੈਂਡਆਫ ਵਿੱਚ ਇੱਕ Done ਲਾਈਨ ਜ਼ਰੂਰੀ ਕਰੋ।ਉਦਾਹਰਣ: “Done ਮਤਲਬ: acceptance criteria ਪੂਰੇ, ਕੋਈ ਨਵੇਂ TODOs ਨਹੀਂ, ਅਤੇ ਬਦਲਾਅ 5 ਬੁਲੇਟਸ ਵਿੱਚ ਦਸਤਾਵੇਜ਼ ਕੀਤੇ ਹੋਏ।”
• Tester ਸਿਰਫ਼ ਹੈਪੀ ਪਾਥ ਚੈੱਕ ਕਰਦਾ ਹੈ। ਸੁਧਾਰ: ਹਰ ਵਾਰੀ ਇੱਕ ਗਲਤ-ਇਨਪੁੱਟ ਕੇਸ ਅਤੇ ਇੱਕ ਐਡਜ ਕੇਸ ਦੀ ਲੋੜ ਰੱਖੋ।ਟੈਂਪਲੇਟ ਟਵੀਕ: “Tester: (1) happy path, (2) ਇਕ invalid input case, (3) ਇਕ edge case ਦਿਓ।ਜੇ ਤੁਸੀਂ ਚਲਾ ਨਹੀਂ ਸਕਦੇ, ਤਾਂ ਸਹੀ-ਸਟੀਪਸ ਅਤੇ ਉਮੀਦ ਦਰਜ ਕਰੋ।”
• Reviewer ਅੰਦਾਜ਼ ਵਿੱਚ ਬਹਿਸ ਕਰਦਾ ਹੈ ਬਨਾਮ ਪ੍ਰੋਡਕਟ ਖਤਰੇ। ਸੁਧਾਰ: Reviewer ਨੂੰ ਪਹਿਲਾਂ ਖਤਰਾ ਉਪਰ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕਰਨ ਲਈ ਮਸਬੂਰ ਕਰੋ।ਟੈਂਪਲੇਟ ਟਵੀਕ: “Reviewer: ਸਿਖਰ 3 ਖਤਰੇ ਲਿਸਟ ਕਰੋ (ਸੁਰੱਖਿਆ, ਡੇਟਾ ਨੁਕਸਾਨ, ਟੁੱਟਿਆ UX, ਪਰਫਾਰਮੈਂਸ)।ਸਟਾਈਲ ਸਿਰਫ਼ ਉਸ ਵੇਲੇ ਦੱਸੋ ਜੇ ਇਹ ਪਾਠਯੋਗਤਾ ਰੁਕਦਾ ਹੈ ਜਾਂ ਬੱਗ ਬਣਾਉਂਦਾ ਹੈ।”
• ਹੈਂਡਆਫ ਸੰਦਰਭ ਗੁੰਮ ਜਾ ਹਨ, ਤਦ ਪਿੱਛਲੇ ਵਿਅਕਤੀ ਅਨੁਮਾਨ ਲਗਾਉਂਦਾ ਹੈ। ਸੁਧਾਰ: ਹਰ ਵਾਰੀ ਇੱਕ ਛੋਟੀ ਹੈਂਡਆਫ ਬਲੌਕ ਬੇਨਤੀ ਕਰੋ: “Goal, What changed, How to verify, Known gaps.” ਇਸਨੂੰ 8 ਲਾਈਨਾਂ ਤੋਂ ਘੱਟ ਰੱਖੋ।

ਇੱਕ ਛੋਟਾ ਅਭਿਆਸ ਜੋ ਮਦਦ ਕਰਦਾ ਹੈ: ਜਦੋਂ Implementer ਖਤਮ ਕਰੇ, acceptance criteria ਦੁਬਾਰਾ ਪੇਸਟ ਕਰਕੇ ਇੱਕ-ਇੱਕ ਟਿਕ ਮਾਰੋ।

ਭਰੋਸੇਯੋਗ ਚੈਟ-ਨਿਰਮਿਤ ਰਿਲੀਜ਼ ਲਈ ਤੁਰੰਤ ਚੈੱਕਲਿਸਟ

ਇਸ ਚੈੱਕਲਿਸਟ ਨੂੰ ਬਿਲਡ ਤੋਂ ਪਹਿਲਾਂ, ਮਰਜ ਤੋਂ ਪਹਿਲਾਂ, ਅਤੇ ਸ਼ਿਪ ਕਰਨ ਤੋਂ ਬਾਅਦ ਚਲਾਓ।

প্রੀ-ਬਿਲਡ (ਕੋਈ ਵੀ ਕੋਡ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ)

• ਇੱਕ ਵਾਕ ਵਿੱਚ ਲਕਸ਼ ਲਿਖੋ ਅਤੇ 2-3 acceptance checks ਲਿਖੋ ("ਡਨ" ਦਾ ਕੀ ਮਤਲਬ)।
• ਜੋ ਬਾਹਰ ਹੈ ਉਸਦਾ ਨਾਮ ਦਿਓ (ਤਾਂ ਜੋ Implementer ਅਨੁਮਾਨ ਨਾ ਕਰੇ)।
• ਨਿਸ਼ਚਤ ਡੇਟਾ ਫੀਲਡ ਅਤੇ ਨਿਯਮ ਲਿਖੋ (ਟਾਈਪ, required/optional, defaults)।
• ਮੁੱਖ ਐਰਰ ਕੇਸ ਦਰਜ ਕਰੋ (ਖ਼ਰਾਬ ਇਨਪੁੱਟ, ਅਧਿਕਾਰ ਗੁੰਮ, খালি ਸਥਿਤੀਆਂ, ਟਾਈਮਆਉਟ)।
• ਤੈਅ ਕਰੋ ਕਿ ਤੁਸੀਂ ਇਸਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਕਿਵੇਂ ਵੇਰਿਫਾਈ ਕਰੋਗੇ (ਇੱਕ ਸਕ੍ਰੀਨ, API ਪ੍ਰਤੀਕਿਰਿਆ, ਜਾਂ ਲੌਗ ਲਾਈਨ)।

ਛੋਟਾ ਉਦਾਹਰਣ: “Invite-by-email ਸ਼ਾਮਲ ਕਰੋ।” ਫੀਲਡ (ਈਮੇਲ, ਰੋਲ), ਗਲਤ ਈਮੇਲ ਹੋਣ 'ਤੇ ਕੀ ਹੁੰਦਾ, ਅਤੇ ਕੀ ਤੁਸੀਂ ਦੁਬਾਰਾ-ਨਿਮন্ত্রণ ਆਗਿਆ ਦਿੰਦੇ ਹੋ—ਇਹ ਸਭ ਸ਼ਾਮਲ ਕਰੋ।

ਪ੍ਰੀ-ਮਰਜ ਅਤੇ ਪੋਸਟ-ਰਿਲੀਜ਼ (ਬਦਲਾਅ ਦਾ ਡਰ ਘੱਟ ਕਰੋ)

• ਪ੍ਰੀ-ਮਰਜ: ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਟੈਸਟ ਚੱਲੇ (ਜਾਂ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਛੋਟੀ ਮੈਨੁਅਲ ਸਕ੍ਰਿਪਟ) ਅਤੇ ਕੀ ਹਨ ਜਵਾਬ ਕਿੱਥੇ ਚੈੱਕ ਕੀਤੇ ਗਏ।
• ਪ੍ਰੀ-ਮਰਜ: 2-3 ਐਡਜ ਕੇਸ ਖਾਸ ਤੌਰ 'ਤੇ ਕਵਰ ਕਰੋ, "ਚੰਕ ਤੋਂ ਕੰਮ ਕਰੇ" ਨਹੀਂ।
• ਪ੍ਰੀ-ਮਰਜ: ਰੋਲਬੈਕ ਯੋਜਨਾ ਨੋਟ ਕਰੋ ਅਤੇ ਕਿਹੜਾ ਬਦਲਾਅ ਇਸਨੂੰ ਟ੍ਰਿਗਰ ਕਰੇਗਾ।
• ਪੋਸਟ-ਰਿਲੀਜ਼: ਪਹਿਲੇ ਘੰਟੇ/ਦਿਨ ਲਈ 1-2 ਸਿਗਨਲ (ਐਰਰ, ਸਲੋ ਪੇਜ਼, ਫੇਲਡ ਜੋਬ) ਦੇਖੋ।
• ਪੋਸਟ-ਰਿਲੀਜ਼: ਯੂਜ਼ਰ ਫੀਡਬੈਕ ਲੋ, ਅਤੇ ਮਾਲੂਮ ਸੀਮਾਵਾਂ ਨੂੰ ਨੋਟ ਕਰੋ ਤਾਂ ਕਿ ਸਪੋਰਟ ਅਨੁਮਾਨ ਨਾ ਕਰੇ।

ਜੇ ਤੁਹਾਡਾ ਪਲੇਟਫਾਰਮ ਇਸਨੂੰ ਸਹਾਇਤ ਕਰਦਾ ਹੈ (Koder.ai ਕਰਦਾ ਹੈ), ਤਾਂ ਖਤਰਨਾਕ ਸੋਧਾਂ ਤੋਂ ਪਹਿਲਾਂ ਸਨੈਪਸ਼ਾਟ ਲਓ।ਰੋਲਬੈਕ ਜਾਣਦੇ ਹੋਏ ਛੋਟੇ, ਸੁਰੱਖਿਅਤ ਬਦਲਾਅ ਸ਼ਿਪ ਕਰਨਾ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ।

ਅਗਲੇ ਕਦਮ: ਇਸਨੂੰ ਆਪਣੀ ਡਿਫੌਲਟ ਵਰਕਫਲੋ ਬਣਾਓ

ਇੱਕ ਛੋਟਾ ਫੀਚਰ ਚੁਣੋ ਅਤੇ ਪੂਰਾ ਪੇਰਸੋਨਾ ਚੇਨ ਇੱਕ ਵਾਰੀ ਚਲਾਓ।ਕੁਝ ਹਕੀਕਤੀ ਪਰ ਸੀਮਤ ਚੁਣੋ, ਜਿਵੇਂ "ਪਾਸਵਰਡ ਰੀਸੈੱਟ ਜੋੜੋ", "ਇਕ ਐਡਮਿਨ-ਓਨਲੀ ਪੇਜ਼ ਬਣਾਓ", ਜਾਂ "ਇਨਵਾਇਸਸ CSV ਵਿੱਚ ਐਕਸਪੋਰਟ ਕਰੋ"।ਦਰਸ ਇਹ ਹੈ ਕਿ ਜਦੋਂ ਤੁਸੀਂ Planner ਤੋਂ Reviewer ਤੱਕ ਸਾਫ਼ ਹੈਂਡਆਫ ਨੂੰ ਮਜ਼ਬੂਰ ਕਰਦੇ ਹੋ ਤਾਂ ਕੀ ਬਦਲਦਾ ਹੈ।

ਜੇ ਤੁਸੀਂ Koder.ai (koder.ai) ਵਰਤ ਰਹੇ ਹੋ, ਤਾਂ Planning Mode ਇੱਕ ਵਰਤੋਂਯੋਗ ਸਥਾਨ ਹੈ ਸਕੋਪ ਅਤੇ acceptance checks ਨੂੰ ਬਿਲਡ ਤੋਂ ਪਹਿਲਾਂ ਲਾਕ ਕਰਨ ਲਈ।ਫਿਰ ਸਨੈਪਸ਼ਾਟ ਅਤੇ ਰੋਲਬੈਕ ਤੁਹਾਨੂੰ ਇੱਕ ਸੁਰੱਖਿਅਤ ਏਸਕੇਪ ਹੈਚ 'ਦਿੰਦੇ ਹਨ ਜਦੋਂ ਕੋਈ ਫੈਸਲਾ ਗਲਤ ਸਾਬਤ ਹੋਵੇ, ਬਿਨਾਂ ਪੂਰੇ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਬਹਿਸ ਵਿੱਚ ਬਦਲਣ ਦੇ।

ਵਰਕਫਲੋ ਨੂੰ ਦੁਹਰਾਏ ਜਾਓ, ਆਪਣੇ ਟੀਮ ਲਈ ਪ੍ਰਾਂਪਟਸ ਟੈਂਪਲੇਟ ਸੇਵ ਕਰੋ, ਆਉਟਪੁੱਟ ਫ਼ਾਰਮੈਟ ਸਥਿਰ ਰੱਖੋ, ਅਤੇ ਤੁਸੀਂ ਹਰ ਵਾਰੀ ਘੱਟ ਸਮਾਂ ਸੰਦੇਸ਼ ਕਰਦੇ ਹੋਵੋਗੇ ਅਤੇ ਘੱਟ ਦੁਹਰਾਉਂਦਾ ਕੰਮ ਕਰੋਗੇ।