14 ਦਸੰ 2025·7 ਮਿੰਟ
Claude Code ਟਾਸਕ ਸਕੋਪਿੰਗ: ਅਸਪਸ਼ਟ ਬੇਨਤੀਆਂ ਤੋਂ ਕਮਿਟ ਤੱਕ
Claude Code ਟਾਸਕ ਸਕੋਪਿੰਗ ਸਿੱਖੋ—ਕਿਵੇਂ ਗੰਦੇ ਫੀਚਰ ਦੀ ਬੇਨਤੀ ਨੂੰ ਸਪੱਸ਼ਟ acceptance criteria, ਇੱਕ ਨਿੂੰਨਤਮ UI/API ਯੋਜਨਾ, ਅਤੇ ਕੁਝ ਛੋਟੇ ਕਮਿਟਾਂ ਵਿੱਚ ਬਦਲਿਆ ਜਾ ਸਕਦਾ ਹੈ।
Claude Code ਟਾਸਕ ਸਕੋਪਿੰਗ ਸਿੱਖੋ—ਕਿਵੇਂ ਗੰਦੇ ਫੀਚਰ ਦੀ ਬੇਨਤੀ ਨੂੰ ਸਪੱਸ਼ਟ acceptance criteria, ਇੱਕ ਨਿੂੰਨਤਮ UI/API ਯੋਜਨਾ, ਅਤੇ ਕੁਝ ਛੋਟੇ ਕਮਿਟਾਂ ਵਿੱਚ ਬਦਲਿਆ ਜਾ ਸਕਦਾ ਹੈ।
ਇੱਕ ਅਸਪਸ਼ਟ ਬੇਨਤੀ ਹਲਕੀ ਲੱਗਦੀ ਹੈ: “ਇੱਕ ਵਧੀਆ ਖੋਜ ਜੋੜੋ,” “Onboarding ਨੂੰ ਸਧਾਰੋ,” “ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਨੋਟੀਫਿਕੇਸ਼ਨ ਚਾਹੀਦੇ ਹਨ।” ਅਸਲ ਟੀਮਾਂ ਵਿੱਚ ਇਹ ਆਮ ਤੌਰ ’ਤੇ ਇੱਕ-ਲਾਈਨ ਚੈਟ ਸੁਨੇਹਾ, ਤੀਰ ਵਾਲੀ ਸਕਰੀਨਸ਼ਾਟ, ਜਾਂ ਅਧ-ਯਾਦ ਗ੍ਰਾਹਕ ਕਾਲ ਵਜੋਂ ਆਉਂਦਾ ਹੈ। ਸਾਰੇ ਇਸ਼ਾਰਿਆਂ ਨਾਲ ਸਹਿਮਤ ਹੋ ਸਕਦੇ ਹਨ, ਪਰ ਹਰ ਕੋਈ ਕੁਝ ਵੱਖਰਾ ਸੋਚਦਾ ਹੈ।
ਲਾਗਤ ਬਾਅਦ ਵਿੱਚ ਆਉਂਦੀ ਹੈ। ਜਦੋਂ ਸਕੋਪ ਅਸਪਸ਼ਟ ਹੁੰਦਾ ਹੈ, ਲੋਕ ਅਨੁਮਾਨਾਂ 'ਤੇ ਕੰਮ ਕਰਦੇ ਹਨ। ਪਹਿਲੀ ਡੈਮੋ ਇਕ ਹੋਰ ਸਪਸ਼ਟੀਕਰਨ ਵਿੱਚ ਤਬਦੀਲ ਹੋ ਜਾਂਦੀ ਹੈ: “ਇਹ ਉਹ ਨਹੀਂ ਸੀ ਜੋ ਮੈਂ ਮੰਨਿਆ ਸੀ।” ਕੰਮ ਦੁਬਾਰਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਬਦਲਾਅ ਚੁੱਪਚਾਪ ਵੱਡਾ ਹੋ ਜਾਂਦਾ ਹੈ। ਡਿਜ਼ਾਈਨ ਦੇ ਝਟਕੇ ਕੋਡ ਬਦਲਾਅ ਲਿਆਉਂਦੇ ਹਨ, ਜੋ ਹੋਰ ਟੈਸਟਿੰਗ ਨੂੰ ਜਨਮ ਦਿੰਦੇ ਹਨ। ਰਿਵਿਊ ਸਲੋ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਇਕ ਧੁੰਦਲਾ ਬਦਲਾਅ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਵੇਰਿਫਾਈ ਨਹੀਂ ਹੁੰਦਾ। ਜੇਕਰ ਕੋਈ “ਸਹੀ” ਦੀ ਪਰਿਭਾਸ਼ਾ ਨਹੀਂ ਦੇ ਸਕਦਾ, ਤਾਂ ਰਿਵਿਊਅਰ ਬਿਹੇਵਿਯਰ ਬਾਰੇ ਵਿਚਾਰ-ਵਟਾਂਦਰਾ ਕਰਨ ਲੱਗਦੇ ਹਨ ਨਾ ਕਿ ਗੁਣਵੱਤਾ ਜਾਂਚਣ।
ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਅਸਪਸ਼ਟ ਟਾਸਕ ਨੂੰ ਸ਼ੁਰੂ ਵਿੱਚ ਹੀ ਪਛਾਣ ਸਕਦੇ ਹੋ:
ਇੱਕ ਚੰਗਾ ਸਕੋਪ ਕੀਮਤੀ ਲਾਈਨ ਦਿੰਦਾ ਹੈ: ਸਾਫ਼ acceptance criteria, ਇੱਕ ਨ્યૂਨਤਮ UI ਅਤੇ API ਯੋਜਨਾ, ਅਤੇ ਉਹ ਚੀਜ਼ਾਂ ਜੋ ਸ਼ਾਮਿਲ ਨਹੀਂ ਹਨ ਉਨ੍ਹਾਂ ਦੀਆਂ ਹੱਦਾਂ। ਇਹ ਫਰਕ ਹੈ “ਖੋਜ ਸੁਧਾਰੋ” ਅਤੇ ਇਕ ਛੋਟੇ ਬਦਲਾਅ ਵਿਚ ਜਿਸਨੂੰ ਬੰਨ੍ਹਨਾ ਅਤੇ ਰਿਵਿਊ ਕਰਨਾ ਆਸਾਨ ਹੋਵੇ।
ਇੱਕ ਵਿਹਾਰਕ ਆਦਤ: “definition of done” ਨੂੰ “nice-to-have” ਤੋਂ ਵੱਖਰਾ ਕਰੋ। “Done” ਜ਼ਿਆਦਾ ਨਹੀਂ—ਕੁਝ ਚੈਕਾਂ ਦੀ ਸੂਚੀ ਹੁੰਦੀ ਹੈ ਜੋ ਤੁਸੀਂ ਚਲਾ ਸਕਦੇ ਹੋ (ਉਦਾਹਰਨ ਲਈ: “Search results title ਨਾਲ ਵਾਪਸ ਆਉਣ, ਖਾਲੀ ਹੋਣ 'ਤੇ ‘No results’ ਦਿਖਾਏ, ਅਤੇ query URL ਵਿੱਚ ਰਹੇ”)। “Nice-to-have” ਉਹ ਸਭ ਹੈ ਜੋ ਬਾਅਦ ਵਿੱਚ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ (ਸਿਨੋਨਿਮ, ranking tweaks, highlighting, analytics). ਪਹਿਲਾਂ ਹੀ ਇਹਨਾਂ ਨੂੰ ਲੇਬਲ ਕਰਨ ਨਾਲ ਅਕਸਮਾਤੀ ਸਕੋਪ ਵਾਧੇ ਰੁਕਦੇ ਹਨ।
ਅਸਪਸ਼ਟ ਬੇਨਤੀਆਂ ਅਕਸਰ ਸੁਝਾਵਾਂ ਵਜੋਂ ਆਉਂਦੀਆਂ ਹਨ: “ਇੱਕ ਬਟਨ ਜੋੜੋ,” “ਨਵਾਂ ਫਲੋ ਵਰਤੋ,” “ਵੱਖਰਾ ਮਾਡਲ ਵਰਤੋਂ।” ਰੁਕੋ ਅਤੇ ਪਹਿਲਾਂ ਸੁਝਾਅ ਨੂੰ ਨਤੀਜੇ ਵਿੱਚ ਬਦਲੋ।
ਇੱਕ ਸਧਾਰਨ ਫਾਰਮੈਟ ਮਦਦ ਕਰਦਾ ਹੈ: “As a [user], I want to [do something], so I can [reach a goal].” ਸਿੱਧਾ ਅਤੇ ਸਪਸ਼ਟ ਰੱਖੋ। ਜੇ ਤੁਸੀਂ ਇਕ ਸਾਹ ਲੈ ਕੇ ਨਹੀਂ ਕਹਿ ਸਕਦੇ, ਤਾਂ ਇਹ ਹਾਲੇ ਵੀ ਧੁੰਦਲਾ ਹੈ।
ਅਗਲਾ, ਵਰਣਨ ਕਰੋ ਕਿ ਉਪਭੋਗਤਾ ਲਈ ਕੀ ਬਦਲਿਆ ਜਾਵੇਗਾ ਜਦੋਂ ਕੰਮ ਖਤਮ ਹੋ ਜਾਵੇ। ਦਿੱਖਯੋਗ ਵਰਤਾਰ 'ਤੇ ਧਿਆਨ ਦਿਓ, ਨ ਕੀ ਇੰਪਲਿਮੈਂਟੇਸ਼ਨ ਤੇ। ਉਦਾਹਰਨ: “ਫਾਰਮ ਜਮ੍ਹਾਂ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਮੈਨੂੰ ਇੱਕ ਪੁਸ਼ਟੀ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ ਅਤੇ ਮੈਂ ਨਵਾਂ ਰਿਕਾਰਡ ਲਿਸਟ ਵਿੱਚ ਲੱਭ ਸਕਦਾ/ਸਕਦੀ ਹਾਂ।” ਇਹ ਇੱਕ ਸਾਫ਼ ਖਤਮ-ਲਾਈਨ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ “ਹੋਰ ਇੱਕ ਛੋਟੀ ਟਵੀਕ” ਨੂੰ ਚੁਪਚਾਪ ਦਾਖਲ ਹੋਣ ਤੋਂ ਰੋਕਦਾ ਹੈ।
ਇਹ ਵੀ ਲਿਖੋ ਕਿ ਕੀ ਉਹੀ ਰਹੇਗਾ। Non-goals ਤੁਹਾਡੇ ਸਕੋਪ ਦੀ ਰੱਖਿਆ ਕਰਦੇ ਹਨ। ਜੇ ਬੇਨਤੀ “onboarding ਸੁਧਾਰੋ” ਹੈ, ਤਾਂ ਇੱਕ non-goal ਹੋ ਸਕਦਾ ਹੈ “ਕੋਈ dashboard redesign ਨਹੀਂ” ਜਾਂ “ਕੋਈ pricing-tier logic ਬਦਲਾਅ ਨਹੀਂ।”
ਅੰਤ ਵਿੱਚ, ਪਹਿਲਾਂ ਇਕ ਮੁੱਖ ਰਸਤਾ ਚੁਣੋ: ਉਹ ਇੱਕ end-to-end slice ਜੋ ਪਹਿਲਾਂ ਸਾਬਿਤ ਕਰੇ ਕਿ ਫੀਚਰ ਕੰਮ ਕਰਦਾ ਹੈ।
ਉਦਾਹਰਨ: “ਸਭ ਥਾਂ snapshots ਜੋੜਣ ਦੀ ਬਜਾਏ, ਲਿਖੋ: ‘As a project owner, I can restore the latest snapshot of my app, so I can undo a bad change.’ Non-goals: ‘no bulk restore, no UI redesign.’”
ਇੱਕ ਅਸਪਸ਼ਟ ਬੇਨਤੀ ਅਕਸਰ ਜ਼ਰੂਰਤ ਦੀ ਘਾਟ ਨਹੀਂ ਹੁੰਦੀ—ਇਹ ਫੈਸਲਿਆਂ ਦੀ ਘਾਟ ਹੁੰਦੀ ਹੈ।
ਸ਼ੁਰੂ ਕਰੋ ਉਹਨਾਂ ਪਾਬੰਦੀਆਂ ਨਾਲ ਜੋ ਸਕੋਪ ਨੂੰ ਚੁਪਕੇ ਨਾਲ ਬਦਲ ਦਿੰਦੀਆਂ ਹਨ। ਡੇਡਲਾਈਨ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਪਰ ਐਕਸੇਸ ਨਿਯਮ ਅਤੇ ਕੰਪਲਾਇੰਸ ਲੋੜਾਂ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹਨ। ਜੇ ਤੁਸੀਂ ਇਕ ਐਸੇ ਪਲੈਟਫਾਰਮ 'ਤੇ ਬਣਾਉਂਦੇ ਹੋ ਜਿੱਥੇ ਟੀਅਰ ਅਤੇ ਰੋਲ ਹਨ, ਤਾਂ ਫੈਸਲਾ ਪਹਿਲਾਂ ਕਰੋ ਕਿ ਕੌਣ ਫੀਚਰ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ ਅਤੇ ਕਿਸ ਯੋਜਨਾ ਹੇਠ।
ਫਿਰ ਇੱਕ ਠੋਸ ਉਦਾਹਰਨ ਮੰਗੋ। ਇੱਕ ਸਕਰੀਨਸ਼ਾਟ, ਇੱਕ ਮੁਕਾਬਲੇਦਾਰ ਦਾ ਵਿਵਹਾਰ, ਜਾਂ ਪਹਿਲੀ ਟਿਕਟ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ “ਬਿਹਤਰ” ਦਾ ਕੀ ਮਤਲਬ ਹੈ। ਜੇ ਰੀਕੁਏਸਟਰ ਕੋਲ ਕੁਝ ਨਹੀਂ ਹੈ, ਤਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਪਿਛਲੀ ਵਾਰ ਦਰਦ ਮਹਿਸੂਸ ਕਰਨ ਵਕਤ ਦੀ ਪੁਨਰਾਵਰਤੀ ਕਰਨ ਲਈ ਕਹੋ: ਉਹ ਕਿਸ ਸਕਰੀਨ ਉੱਤੇ ਸਨ, ਉਹ ਕੀ ਕਲਿੱਕ ਕੀਤਾ, ਅਤੇ ਉਨ੍ਹਾਂ ਨੇ ਕੀ ਉਮੀਦ ਕੀਤੀ?
ਐਡਜ ਕੇਸ ਉਹ ਹਨ ਜਿੱਥੇ ਸਕੋਪ ਫੈਲਦਾ ਹੈ, ਇਸ ਲਈ ਵੱਡੇ ਕੇਸ ਪਹਿਲਾਂ ਨਾਮ ਕਰੋ: ਖਾਲੀ ਡਾਟਾ, validation errors, slow ਜਾਂ failed network calls, ਅਤੇ “undo” ਦਾ ਅਰਥ ਕੀ ਹੈ।
ਅਖੀਰਕਾਰ, ਫੈਸਲਾ ਕਰੋ ਕਿ ਤੁਸੀਂ ਕਿਵੇਂ ਸਫਲਤਾ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋਗੇ। ਇਕ ਟੈਸਟਬਲ ਨਤੀਜੇ ਦੇ ਬਗੈਰ, ਟਾਸਕ ਰਾਏਆਂ ਵਿੱਚ ਤਬਦੀਲ ਹੋ ਜਾਂਦਾ ਹੈ।
ਇਹ ਪੰਜ ਸਵਾਲ ਆਮ ਤੌਰ 'ਤੇ ਜ਼ਿਆਦਾਤਰ ਅਸਪਸ਼ਟਤਾ ਹਟਾ ਦਿੰਦੇ ਹਨ:
ਉਦਾਹਰਨ: “Add custom domains for clients” ਜ਼ਿਆਦਾ ਸਪਸ਼ਟ ਹੋ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਫੈਸਲਾ ਕਰੋ ਕਿ ਇਹ ਕਿਸ ਟੀਅਰ ਲਈ ਹੈ, ਕੌਣ ਸੈਟਅਪ ਕਰ ਸਕਦਾ ਹੈ, ਹੋਸਟਿੰਗ ਸਥਾਨ ਕੀ ਕੰਪਲਾਇੰਸ ਲਈ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ, invalid DNS ਲਈ ਕਿਹੜਾ ਐਰਰ ਦਿਖੇਗਾ, ਅਤੇ “done” ਦਾ ਕੀਮਤ ਕੀ ਹੈ (domain verified, HTTPS active, ਅਤੇ safe rollback ਯੋਜਨਾ)।
ਗੰਦੇ ਨੋਟਸ ਲਕ਼ਸ਼, ਅਨੁਮਾਨ, ਅਤੇ ਅਧ-ਯਾਦ ਕੀਤੀਆਂ ਐਡਜ ਕੇਸ ਨੂੰ ਮਿਲਾਉਂਦੇ ਹਨ। ਕੰਮ ਇਹ ਹੈ ਕਿ ਇਸਨੂੰ ਐਸੇ ਬਿਆਨਾਂ ਵਿੱਚ ਬਦਲਿਆ ਜਾਵੇ ਜੋ ਕੋਈ ਵੀ ਕਿਸੇ ਦੇ ਮਨ ਨੂੰ ਪੜ੍ਹੇ ਬਿਨਾਂ ਟੈਸਟ ਕਰ ਸਕੇ। ਉਹੀ criteria design, coding, review, ਅਤੇ QA ਲਈ ਰਾਹ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ।
ਇੱਕ ਸਧਾਰਨ ਨਮੂਨਾ ਸਪਸ਼ਟ ਰੱਖਦਾ ਹੈ। ਤੁਸੀਂ Given/When/Then ਵਰਤ ਸਕਦੇ ਹੋ ਜਾਂ ਛੋਟੀਆਂ ਗੋਲੀਆਂ ਜੋ ਉਹੀ ਮਤਲਬ ਰੱਖਦੀਆਂ ਹਨ।
ਹਰ criterion ਨੂੰ ਇੱਕ ਟੈਸਟ ਵਜੋਂ ਲਿਖੋ ਜੋ ਕੋਈ ਚਲਾ ਸਕਦਾ ਹੈ:
ਹੁਣ ਇਸਨੂੰ ਲਾਗੂ ਕਰੋ। ਮੰਨ ਲਓ ਨੋਟ ਕਹਿੰਦਾ ਹੈ: “Snapshots ਆਸਾਨ ਬਣਾਓ। ਮੈਂ ਅਖੀਰਲੇ ਬਦਲਾਅ ਨੂੰ ਵਾਪਸ ਲੈਣਾ ਚਾਹੁੰਦਾ/ਚਾਹੁੰਦੀ ਹਾਂ ਜੇ ਉਹ ਤੋੜ ਦੇਵੇ।” ਇਸਨੂੰ ਟੈਸਟਬਲ ਬਿਆਨਾਂ ਵਿੱਚ ਬਦਲੋ:
ਜੇ QA ਇਹਨਾਂ ਚੈਕਾਂ ਨੂੰ ਚਲਾ ਸਕਦੀ ਹੈ ਅਤੇ ਰਿਵਿਊਅਰ UI ਅਤੇ ਲੌਗਾਂ ਵਿੱਚ ਉਹਨਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰ ਸਕਦੇ ਹਨ, ਤਾਂ ਤੁਸੀਂ UI ਅਤੇ API ਕੰਮ ਦੀ ਯੋਜਨਾ ਬਣਾਉਣ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਛੋਟੇ ਕਮਿਟਾਂ ਵਿੱਚ ਵੰਡਣ ਲਈ ਤਿਆਰ ਹੋ।
ਇੱਕ ਨਿੂੰਨਤਮ UI ਯੋਜਨਾ ਇਕ ਵਾਅਦਾ ਹੈ: ਸਭ ਤੋਂ ਘੱਟ ਦਿੱਖਯੋਗ ਬਦਲਾਅ ਜੋ ਸਾਬਤ ਕਰੇ ਕਿ ਫੀਚਰ ਕੰਮ ਕਰਦਾ ਹੈ।
ਸ਼ੁਰੂ ਕਰੋ ਇਹ ਨਾਮ ਲਿਖ ਕੇ ਕਿ ਕਿਹੜੀਆਂ ਸਕ੍ਰੀਨਾਂ ਬਦਲਣਗੀਆਂ ਅਤੇ ਇਕ ਵਿਅਕਤੀ 10 ਸੈਕਿੰਡ ਵਿੱਚ ਕੀ ਨੋਟਿਸ ਕਰੇਗਾ। ਜੇ ਬੇਨਤੀ ਕਹਿੰਦੀ ਹੈ “ਇੱਕੋ-ਜਿਹੀ ਆਸਾਨ ਬਣਾਓ” ਜਾਂ “ਸਾਫ਼ ਕਰੋ,” ਤਾਂ ਉਸਨੂੰ ਇੱਕ ਨਿਰਧਾਰਿਤ ਬਦਲਾਅ ਵਿੱਚ ਤਰਜਮਾ ਕਰੋ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਨਿਸ਼ਾਨਾ ਬਣਾ ਸਕਦੇ ਹੋ।
ਇਸਨੂੰ ਇੱਕ ਛੋਟੀ ਮੈਪ ਵਜੋਂ ਲਿਖੋ, ਨਾ ਕਿ redesign। ਉਦਾਹਰਨ: “Orders page: add a filter bar above the table,” ਜਾਂ “Settings: add a new toggle under Notifications.” ਜੇ ਤੁਸੀਂ ਸਕ੍ਰੀਨ ਅਤੇ ਸਥਾਨਕ ਤੱਤ ਨਹੀਂ ਨਾਂਮਿਤ ਕਰ ਸਕਦੇ, ਤਾਂ ਸਕੋਪ ਹਾਲੇ ਵੀ ਅਸਪਸ਼ਟ ਹੈ।
ਜ਼ਿਆਦਾਤਰ UI ਬਦਲਾਅਾਂ ਨੂੰ ਕੁਝ ਸਪੱਸ਼ਟ ਸਥਿਤੀਆਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਸਿਰਫ ਉਹਨਾਂ ਨੂੰ ਲਿਖੋ ਜੋ ਲਾਗੂ ਹੁੰਦੇ ਹਨ:
UI copy ਵੀ ਸਕੋਪ ਦਾ ਹਿੱਸਾ ਹੈ। ਉਹਨਾਂ ਲੇਬਲਾਂ ਅਤੇ ਸੁਨੇਹਿਆਂ ਨੂੰ ਕੈਪਚਰ ਕਰੋ ਜੋ ਮੰਨਜ਼ੂਰ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ: button text, field labels, helper text, ਅਤੇ error messages। ਜੇ ਸ਼ਬਦ ਅਜੇ ਤੈਅ ਨਹੀਂ, ਤਾਂ ਉਸਨੂੰ placeholder ਕਾਪੀ ਵਜੋਂ ਚਿੰਨ੍ਹਿਤ ਕਰੋ ਅਤੇ ਲੇਖਕ ਦਾ ਨਾਂ ਜਾਣੋ ਜੋ ਇਸਨੂੰ ਪੱਕਾ ਕਰੇਗਾ।
ਕੋਈ ਵੀ “ਹੁਣ ਨਹੀਂ” ਨੋਟ ਰੱਖੋ ਉਹਨਾਂ ਚੀਜ਼ਾਂ ਲਈ ਜੋ ਵਰਤੋਂ ਲਈ ਜ਼ਰੂਰੀ ਨਹੀਂ ਹਨ (responsive polish, advanced sorting, animations, ਨਵੇਂ ਆਇਕਨ)।
ਇੱਕ ਸਕੋਪਡ ਟਾਸਕ ਲਈ UI, ਬੈਕਐਂਡ, ਅਤੇ ਡਾਟਾ ਵਿਚਕਾਰ ਇੱਕ ਛੋਟੀ, ਸਾਫ਼ قرارداد ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਲਕੜੀ ਦਾ ਮਕਸਦ ਪੂਰੇ ਸਿਸਟਮ ਨੂੰ ਡਿਜ਼ਾਈਨ ਕਰਨਾ ਨਹੀਂ—ਇਹ ਸਭ ਤੋਂ ਘੱਟ ਕਾਲਾਂ ਅਤੇ ਫੀਲਡ ਜੋ ਫੀਚਰ ਸਾਬਤ ਕਰਨ ਲਈ ਲੋੜੀਂਦੇ ਹਨ, ਉਹ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ ਲਈ ਹੈ।
ਸ਼ੁਰੂ ਕਰੋ ਲਿਸਟ ਕਰਨ ਨਾਲ ਕਿ ਤੁਹਾਨੂੰ ਕਿਹੜਾ ਡੇਟਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਉਹ ਕਿੱਥੋਂ ਆਵੇਗਾ: ਉਪਲਬਧ ਫੀਲਡ ਜੋ ਤੁਸੀਂ ਪੜ੍ਹ ਸਕਦੇ ਹੋ, ਨਵੀਆਂ ਫੀਲਡਾਂ ਜੋ ਸਟੋਰ ਕਰਨੀਆਂ ਹਨ, ਅਤੇ ਕਿਹੜੇ ਮੁੱਲ ਤੁਸੀਂ ਕੈਲਕੁਲੇਟ ਕਰ ਸਕਦੇ ਹੋ। ਜੇ ਤੁਸੀਂ ਹਰ ਫੀਲਡ ਲਈ ਸਰੋਤ ਨਹੀਂ ਨਾਂਮ ਦੇ ਸਕਦੇ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਯੋਜਨਾ ਨਹੀਂ ਹੈ।
API ਸਰਫੇਸ ਨਿੂੰਨਤਮ ਰੱਖੋ। ਕਈ ਫੀਚਰਾਂ ਲਈ ਇੱਕ read ਅਤੇ ਇੱਕ write ਕਾਫੀ ਹੁੰਦੇ ਹਨ:
GET /items/{id} returns the state needed to render the screenPOST /items/{id}/update accepts only what the user can change and returns the updated stateInputs ਅਤੇ outputs ਨੂੰ ਸਪੱਸ਼ਟ ਆਬਜੈਕਟਾਂ ਵਜੋਂ ਲਿਖੋ, ਨ ਕਿ ਪੈਰਾਗ੍ਰਾਫਾਂ ਵਜੋਂ। Required vs optional ਫੀਲਡਾਂ ਸ਼ਾਮਲ ਕਰੋ, ਅਤੇ ਆਮ ਐਰਰਾਂ (not found, validation failed) 'ਤੇ ਕੀ ਹੁੰਦਾ ਹੈ ਇਹ ਉੱਤੇ ਦਰਸਾਓ।
ਡੇਟਾਬੇਸ ਨੂੰ ਛੁਹਣ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ quick auth pass ਕਰੋ। ਨਿਰਧਾਰਤ ਕਰੋ ਕਿ ਕੌਣ ਪੜ੍ਹ ਸਕਦਾ ਹੈ ਅਤੇ ਕੌਣ ਲਿਖ ਸਕਦਾ ਹੈ, ਅਤੇ ਨਿਯਮ ਇਕ ਵਾਕ ਵਿੱਚ ਲਿਖੋ (ਉਦਾਹਰਨ: “any signed-in user can read, only admins can write”). ਇਹ ਛੱਡਣਾ ਅਕਸਰ ਦੁਬਾਰਾ ਕੰਮ ਦਾ ਕਾਰਨ ਬਣਦਾ ਹੈ।
ਅਖੀਰ ਵਿੱਚ, ਨਿਰਧਾਰਤ ਕਰੋ ਕਿ ਕੀ ਸਟੋਰ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਕੀ ਕੈਲਕੁਲੇਟ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਇੱਕ ਸਧਾਰਨ ਨਿਯਮ: facts ਸਟੋਰ ਕਰੋ, views ਨੂੰ compute ਕਰੋ।
Claude Code ਸਭ ਤੋਂ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਉਸਨੂੰ ਇੱਕ ਸਾਫ਼ ਟਾਰਗੇਟ ਅਤੇ ਇਕ ਤੰਗ ਬਾਕਸ ਦਿੰਦੇ ਹੋ। ਗੰਦੀ ਬੇਨਤੀ ਅਤੇ ਕਿਸੇ ਵੀ ਪਾਬੰਦੀਆਂ (ਡੇਡਲਾਈਨ, ਪ੍ਰਭਾਵਤ ਯੂਜ਼ਰ, ਡਾਟਾ ਨਿਯਮ) ਨੂੰ ਪੇਸਟ ਕਰੋ। ਫਿਰ ਇੱਕ ਸਕੋਪਡ ਆਉਟਪੁੱਟ ਮੰਗੋ ਜੋ ਇਹ ਸ਼ਾਮਲ ਹੋਵੇ:
ਜਦੋਂ ਇਹ ਜਵਾਬ ਦੇਵੇ, ਉਸਨੂੰ ਰਿਵਿਊਅਰ ਵਾਂਗ ਪੜ੍ਹੋ। ਜੇ ਤੁਸੀਂ “improve performance” ਜਾਂ “make it cleaner” ਵਰਗੇ ਫਰੇਜ਼ ਵੇਖਦੇ ਹੋ, ਤਾਂ ਮਾਪਯੋਗ ਸ਼ਬਦਾਂ ਲਈ ਪੁੱਛੋ।
Request: “Add a way to pause a subscription.”
A scoped version might say: “User can pause for 1 to 3 months; next billing date updates; admin can see pause status,” and out of scope: “No proration changes.”
ਇੱਥੋਂ, commit ਯੋਜਨਾ ਵਿਵਹਾਰਿਕ ਬਣ ਜਾਂਦੀ ਹੈ: DB ਅਤੇ API shape ਲਈ ਇੱਕ ਕਮਿਟ, UI control ਲਈ ਇੱਕ, validation ਅਤੇ error states ਲਈ ਇੱਕ, end-to-end tests ਲਈ ਇੱਕ।
ਵੱਡੇ ਬਦਲਾਅ ਬੱਗ ਛੁਪਾਉਂਦੇ ਹਨ। ਛੋਟੇ ਕਮਿਟ ਰਿਵਿਊਜ਼ ਤੇਜ਼ ਬਣਾਉਂਦੇ ਹਨ, ਰੋਲਬੈਕ ਸੁਰੱਖਿਅਤ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਇਹ ਤੁਹਾਨੂੰ ਨੋਟਿਸ ਦਿੰਦੇ ਹਨ ਜਦੋਂ ਤੁਸੀਂ acceptance criteria ਤੋਂ ਭਟਕਦੇ ਹੋ।
ਇੱਕ ਉਪਯੋਗ ਨਿਯਮ: ਹਰ ਕਮਿਟ ਨੂੰ ਇੱਕ ਨਵਾਂ ਵਿਹਾਰ ਅਨਲੌਕ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਇਸਦਾ ਪ੍ਰਮਾਣ ਦਿਖਾਉਣ ਲਈ ਇਕ ਛੋਟੀ ਜਹੀ ਪ੍ਰੂਫ਼ ਰਾਹ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।
ਇੱਕ ਆਮ ਕ੍ਰਮ ਇਹ ਹੋ ਸਕਦਾ ਹੈ:
ਹਰ ਕਮਿਟ ਨੂੰ ਕੇਵਲ ਇੱਕ ਫੋਕਸ ਰੱਖੋ। “While I was here” refactors ਤੋਂ ਬਚੋ। ਐਪ ਨੂੰ end-to-end ਕੰਮ ਕਰਦਾ ਰੱਖੋ, ਚਾਹੇ UI ਬੁਨਿਆਦੀ ਹੋਵੇ। migrations, behavior, ਅਤੇ UI ਨੂੰ ਇੱਕ ਕਮਿਟ ਵਿੱਚ ਪੈਕ ਨਾ ਕਰੋ ਜਦ ਤੱਕ ਮਜਬੂਤ ਕਾਰਨ ਨਾ ਹੋਵੇ।
Stakeholder ਕਹਿੰਦਾ ਹੈ: “Can we add Export reports?” ਇਹ ਕਈ ਚੋਣਾਂ ਨੂੰ ਛੁਪਾਉਂਦਾ ਹੈ: ਕਿਹੜਾ ਰਿਪੋਰਟ, ਕਿਸ ਫਾਰਮੈਟ, ਕੌਣ export ਕਰ ਸਕਦਾ, ਅਤੇ delivery ਕਿਵੇਂ ਹੋਵੇगी।
ਉਹੀ ਸਵਾਲ ਹੀ ਪੁੱਛੋ ਜੋ ਡਿਜ਼ਾਈਨ ਬਦਲ ਦਿੰਦੇ ਹਨ:
ਮੰਨ ਲਓ ਜਵਾਬ ਹਨ: “Sales Summary report, CSV only, manager role, direct download, last 90 days max.” ਹੁਣ v1 acceptance criteria ਸਪਸ਼ਟ ਹੈ: ਮੈਨੇਜਰ Sales Summary ਪੇਜ 'ਤੇ Export 'ਤੇ ਕਲਿੱਕ ਕਰ ਸਕਦਾ/ਸਕਦੀ ਹੈ; CSV on-screen table columns ਨੂੰ ਮਿਲਦਾ ਹੈ; export ਮੌਜੂਦਾ filters ਨੂੰ ਮੰਨਦਾ ਹੈ; 90 ਦਿਨਾਂ ਤੋਂ ਵੱਧ export ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ 'ਤੇ ਸਾਫ਼ ਐਰਰ ਦਿਖਦਾ ਹੈ; 50k rows ਤੱਕ 30 ਸਕਿੰਟ ਵਿੱਚ download ਪੂਰਾ ਹੋ ਜਾਂਦਾ ਹੈ।
ਨਿੂੰਨਤਮ UI ਯੋਜਨਾ: table actions ਕੋਲ ਇੱਕ Export button, generate ਹੋਣ ਦੌਰਾਨ loading state, ਅਤੇ ਐਰਰ ਸੁਨੇਹਾ ਜੋ ਯੂਜ਼ਰ ਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿਵੇਂ مسئلہ ਹੱਲ ਕਰਨਾ ਹੈ (ਜਿਵੇਂ “Choose 90 days or less”)।
ਨਿੂੰਨਤਮ API ਯੋਜਨਾ: ਇੱਕ endpoint ਜੋ filters ਲੈਂਦਾ ਹੈ ਅਤੇ generated CSV ਨੂੰ file response ਵਜੋਂ ਵਾਪਸ ਕਰਦਾ ਹੈ, table ਵਾਲੀ query ਨੂੰ reuse ਕਰਦਾ ਹੈ ਅਤੇ 90-day rule server-side ਲਾਗੂ ਕਰਦਾ ਹੈ।
ਫਿਰ ਇਸਨੂੰ ਕੁਝ ਤੰਗ ਕਮਿਟਾਂ ਵਿੱਚ ਸ਼ਿਪ ਕਰੋ: ਪਹਿਲਾਂ fixed happy path ਲਈ endpoint, ਫਿਰ UI wiring, ਫਿਰ validation ਅਤੇ user-facing errors, ਫਿਰ tests ਅਤੇ documentation।
“Add team roles” ਵਰਗੀਆਂ ਬੇਨਤੀਆਂ ਅਕਸਰ invite, edit, ਅਤੇ ਮੌਜੂਦਾ ਯੂਜ਼ਰਾਂ 'ਤੇ ਕੀ ਹੁੰਦਾ ਹੈ ਬਾਰੇ ਨਿਯਮ ਲੁਕਾਉਂਦੀਆਂ ਹਨ। ਜੇ ਤੁਸੀਂ ਅਨੁਮਾਨ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਉਹ ਅਨੁਮਾਨ ਲਿਖੋ ਅਤੇ ਇਸਨੂੰ ਇੱਕ ਸਵਾਲ ਜਾਂ ਸਪਸ਼ਟ ਨਿਯਮ ਬਣਾਓ।
ਟੀਮਾਂ ਦਿਨ ਲੁੱਟ ਦਿੰਦੀਆਂ ਹਨ ਜਦੋਂ ਇੱਕ ਟਾਸਕ ਵਿੱਚ “ਕੰਮ ਕਰੋ” ਅਤੇ “ਸੁੰਦਰ ਬਣਾਓ” ਦੋਹਾਂ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ। ਪਹਿਲਾ ਟਾਸਕ ਵਿਹਾਰ ਅਤੇ ਡਾਟਾ 'ਤੇ ਧਿਆਨ ਕੇਂਦ੍ਰਿਤ ਰੱਖੋ। styling, animations, ਅਤੇ spacing ਨੂੰ follow-up ਟਾਸਕ ਵਿੱਚ ਰੱਖੋ ਜੇ ਲੋੜ ਨਾ ਹੋਵੇ।
ਐਡਜ ਕੇਸ ਮਹੱਤਵਪੂਰਨ ਹਨ, ਪਰ ਸਾਰੇ ਇਨ੍ਹਾਂ ਨੂੰ turant ਹੱਲ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ। ਉਹਨਾਂ ਨੂੰ ਹੱਲ ਕਰੋ ਜੋ ਭਰੋਸਾ ਤੋੜ ਸਕਦੇ ਹਨ (double submits, conflicting edits) ਅਤੇ ਬਾਕੀ ਨੂੰ clear notes ਨਾਲ ਦੇਰ ਕਰੋ।
ਜੇ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਲਿਖ ਕੇ ਨਹੀਂ ਰੱਖਦੇ, ਤਾਂ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਛੱਡ ਦਿੰਦੇ ਹੋ। acceptance criteria ਵਿੱਚ ਘੱਟੋ-ਘੱਟ ਇੱਕ unhappy path ਅਤੇ ਇੱਕ permission rule ਸ਼ਾਮਲ ਕਰੋ।
“Fast” ਜਾਂ “intuitive” ਵਰਗੇ ਸ਼ਬਦਾਂ ਤੋਂ ਬਚੋ ਜਦ ਤੱਕ ਤੁਸੀਂ ਨੰਬਰ ਜਾਂ concrete check ਨਾ ਲਗਾਉ। ਉਹਨਾਂ ਨੂੰ ਕਿਸੇ ਐਸੇ ਬਿਆਨ ਨਾਲ ਬਦਲੋ ਜਿਨ੍ਹਾਂ ਦੀ ਰਿਵਿਊ ਵਿੱਚ ਪੁਸ਼ਟੀ ਹੋ ਸਕੇ।
ਟਾਸਕ ਨੂੰ ਇਸ ਹੱਦ ਤੱਕ ਪੱਕਾ ਕਰੋ ਕਿ ਕੋਈ teammate ਬਿਨਾਂ ਮਨ-ਪੜ੍ਹਾਈ ਦੇ ਰਿਵਿਊ ਅਤੇ ਟੈਸਟ ਕਰ ਸਕੇ:
ਉਦਾਹਰਨ: “Add saved searches” ਬਣ ਜਾਂਦਾ ਹੈ “Users can save a filter and reapply it later,” non-goals ਜਿਵੇਂ “no sharing” ਅਤੇ “no sorting changes.”
ਇੱਕ ਵਾਰ ਤੁਹਾਡੇ ਕੋਲ ਸਕੋਪਡ ਟਾਸਕ ਹੋਵੇ, ਉਸ ਦੀ ਰੱਖਿਆ ਕਰੋ। ਕੋਡਿੰਗ ਤੋਂ ਪਹਿਲਾਂ, ਜੋ ਲੋਕ ਬਦਲਾਅ ਮੰਗਿਆ ਉਹਨਾਂ ਨਾਲ ਇਕ quick sanity review ਕਰੋ:
ਫਿਰ criteria ਨੂੰ ਉਸੇ ਥਾਂ ਸੰਭਾਲੋ ਜਿੱਥੇ ਕੰਮ ਹੁੰਦਾ ਹੈ: ticket ਵਿੱਚ, PR description ਵਿੱਚ, ਅਤੇ ਜਿੱਥੇ ਵੀ ਟੀਮ ਅਸਲ ਵਿੱਚ ਵੇਖਦੀ ਹੈ।
ਜੇ ਤੁਸੀਂ Koder.ai (koder.ai) ਵਿੱਚ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਪਲੇਨਿੰਗ ਪਹਲਾਂ ਲਾਕ ਕਰੋ ਅਤੇ ਫਿਰ ਕੋਡ ਜੀਨਰੇਟ ਕਰੋ। Planning Mode ਇਸ ਵਰਕਫਲੋ ਲਈ ਚੰਗੀ ਫਿਟ ਹੈ, ਅਤੇ snapshots ਅਤੇ rollback ਐਸਪੈਰੀਮੈਂਟ ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੱਖ ਸਕਦੇ ਹਨ ਜਦੋਂ ਤੁਹਾਨੂੰ ਕਿਸੇ ਤਰੀਕੇ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਦੀ ਲੋੜ ਹੋਵੇ ਅਤੇ ਵਾਪਸ ਲੈਣਾ ਪਵੇ।
ਜਦੋਂ ਨਵੇਂ ਵਿਚਾਰ ਦੌਰਾਨ-ਨਿਰਮਾਣ ਆਉਂਦੇ ਹਨ, ਸਕੋਪ ਸਥਿਰ ਰੱਖੋ: ਉਹਨਾਂ ਨੂੰ follow-up ਸੂਚੀ ਵਿੱਚ ਲਿਖੋ, ਜੇ ਉਹ acceptance criteria ਨੂੰ ਬਦਲਦੇ ਹਨ ਤਾਂ ਰੀ-ਸਕੋਪ ਕਰਨ ਲਈ ਰੁਕੋ, ਅਤੇ ਕਮਿਟਾਂ ਨੂੰ ਹਰ ਵਾਰੀ ਇੱਕ criterion ਨਾਲ ਜੋੜਕੇ ਰੱਖੋ।
Start by writing the outcome in one sentence (what the user can do when it’s done), then add 3–7 acceptance criteria that a tester can verify.
If you can’t describe the “correct” behavior without debating it, the task is still vague.
Use this quick format:
Then add one concrete example of the expected behavior. If you can’t give an example, replay the last time the problem happened and write what the user clicked and expected to see.
Write a short “Definition of done” list first (the checks that must pass), then a separate “Nice-to-have” list.
Default rule: if it’s not needed to prove the feature works end-to-end, it goes into nice-to-have.
Ask the few questions that change scope:
These force the missing decisions into the open.
Treat edge cases as scope items, not surprises. For v1, cover the ones that break trust:
Anything else can be explicitly deferred as out-of-scope notes.
Use testable statements anyone can run without guessing:
Include at least one failure case and one permission rule. If a criterion can’t be tested, rewrite it until it can.
Name the exact screens and the one visible change per screen.
Also list the required UI states:
Keep copy (button text, errors) in scope too, even if it’s placeholder text.
Keep the contract small: usually one read and one write is enough for v1.
Define:
Store facts; compute views when possible.
Ask for a boxed deliverable:
Then re-prompt any vague wording like “make it cleaner” into measurable behavior.
Default sequence:
Rule of thumb: one commit = one new user-visible behavior + a quick way to prove it works. Avoid bundling “while I’m here” refactors into the feature commits.