05 ਜਨ 2026·7 ਮਿੰਟ
ਮੋਨੋਰੇਪੋਜ਼ ਵਿੱਚ Claude Code: ਸੰਦਰਭ ਸੀਮਤ ਰੱਖੋ ਅਤੇ ਸਹੀ ਰਹੋ
ਜਦ ਰੇਪੋ ਵੱਡਾ ਹੋਵੇ ਤਾਂ Claude Code monorepos ਵਿੱਚ ਭਟਕ ਸਕਦਾ ਹੈ। ਜਵਾਬਾਂ ਨੂੰ ਸਹੀ ਰੱਖਣ ਲਈ ਹੱਦਾਂ, ਲੋਕਲ ਸੰਖੇਪ ਅਤੇ ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੇ ਵਰਕਫਲੋ ਸਿੱਖੋ।
ਜਦ ਰੇਪੋ ਵੱਡਾ ਹੋਵੇ ਤਾਂ Claude Code monorepos ਵਿੱਚ ਭਟਕ ਸਕਦਾ ਹੈ। ਜਵਾਬਾਂ ਨੂੰ ਸਹੀ ਰੱਖਣ ਲਈ ਹੱਦਾਂ, ਲੋਕਲ ਸੰਖੇਪ ਅਤੇ ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੇ ਵਰਕਫਲੋ ਸਿੱਖੋ।
Claude Code monorepos ਵਿੱਚ ਅਚਾਨਕ ਅਣਪੜਤਾ ਵਾਲਾ ਮਹਿਸੂਸ ਕਰ ਸਕਦਾ ਹੈ ਇੱਕ ਸਧਾਰਣ ਕਾਰਨ ਕਰਕੇ: ਰੇਪੋ ਉਸ ਤੋਂ ਵੱਡਾ ਹੈ ਜੋ ਮਾਡਲ ਇੱਕ ਵਾਰ ਵਿੱਚ ਵਰਕਿੰਗ ਮੈਮੋਰੀ ਵਿੱਚ ਰੱਖ ਸਕਦਾ ਹੈ।
“ਸੰਦਰਭ” ਉਹ ਫਾਈਲਾਂ, ਸਨਿੱਪੇਟਸ, ਨੋਟਸ ਅਤੇ ਨਿਰਦੇਸ਼ਾਂ ਦਾ ਸੈੱਟ ਹੈ ਜੋ Claude ਨੂੰ ਇਸ ਟਾਸਕ ਲਈ ਦਿੱਤੇ ਗਏ ਹਨ, ਨਾਲ ਹੀ ਉਹ ਜੋ ਇਹ ਉਨ੍ਹਾਂ ਤੋਂ ਨਿਕਾਲ ਸਕਦਾ ਹੈ। ਜਦੋਂ ਕੀਂਜ ਵੇਰਵੇ ਗਾਇਬ ਹੁੰਦੇ ਹਨ, Claude ਖਾਲੀਆਂ ਨੂੰ ਅੰਦਾਜ਼ਿਆਂ ਨਾਲ ਭਰਦਾ ਹੈ। ਵੱਡੇ ਰੇਪੋ ਵਿੱਚ ਇਹ ਬਾਰ-ਬਾਰ ਹੁੰਦਾ ਹੈ।
ਤਿੰਨ ਨਾਕਾਮੀ ਦੇ ਰੂਪ ਮੁੜ-ਮੁੜ ਸਾਹਮਣੇ ਆਉਂਦੇ ਹਨ:
ਪਹਿਲਾਂ, ਫਾਈਲਾਂ ਦਾ ਮਿਸ ਹੋਣਾ। ਕਿਸੇ ਫੋਲਡਰ ਵਿੱਚ ਜਿਸ ਤਰ੍ਹਾਂ ਦਾ ਬਦਲਾਅ ਸੁਰੱਖਿਅਤ ਲੱਗਦਾ ਹੈ, ਅਸਲ ਵਿੱਚ ਕਿਸੇ ਸਾਂਝੇ ਟਾਇਪ, ਕੌਨਫਿਗ ਰੂਲ, ਜਾਂ ਬਿਲਡ ਸਟੈਪ 'ਤੇ ਨਿਰਭਰ ਹੋ ਸਕਦਾ ਹੈ ਜੋ ਦੂਜੀ ਜਗ੍ਹਾ_DEFINED ਕੀਤਾ ਗਿਆ ਹੈ। ਜੇ ਉਹ ਨਿਰਭਰਤਾ ਸੰਦਰਭ ਵਿੱਚ ਨਹੀਂ ਹੈ, Claude ਧੀਰਜ ਨਾਲ ਗਲਤ ਚੀਜ਼ ਸੋਧ ਸਕਦਾ ਹੈ ਜਾਂ ਜਲਦੀ ਰੁਕ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਅਸਲ ਸਰੋਤ-ਸੱਚ ਨਹੀਂ ਵੇਖ ਪਾ ਰਿਹਾ।
ਦੂਜਾ, ਗਲਤ ਸਮਾਨਤਾ। ਮੋਨੋਰੇਪੋਅਜ਼ ਅਕਸਰ ਕਈ ਪੈਕੇਜ ਰੱਖਦੇ ਹਨ ਜੋ ਇੱਕ-ਜਿਹੇ ਲੱਗਦੇ ਹਨ: ਦੋ auth ਮੋਡੀਊਲ, ਤਿੰਨ API clients, ਜਾਂ ਕਈ React ਐਪ ਜਿਨ੍ਹਾਂ ਦੀ ਫੋਲਡਰ ਸਟ੍ਰਕਚਰ ਸਮਾਨ ਹੁੰਦੀ ਹੈ। Claude ਪੈਟਰਨਾਂ ਨੂੰ ਮਿਲਾ ਸਕਦਾ ਹੈ, ਗਲਤ ਪੈਕੇਜ ਵਿੱਚ ਹੈਲਪਰ ਅਪਡੇਟ ਕਰ ਸਕਦਾ ਹੈ, ਜਾਂ “ਲਗਭਗ ਸਹੀ” ਮੌਡੀਊਲ ਨਾਂ ਤੋਂ ਇੰਪੋਰਟ ਕਰ ਸਕਦਾ ਹੈ।
ਤੀਜਾ, ਸਮੇਂ ਨਾਲ ਭਟਕਾਵ। ਵੱਡੇ ਕੋਡਬੇਸ ਅਕਸਰ ਇੱਕੋ ਕੰਮ ਦੇ ਪੁਰਾਣੇ ਅਤੇ ਨਵੇਂ ਢੰਗ ਰੱਖਦੇ ਹਨ। ਜੇ Claude ਸਿਰਫ ਪੁਰਾਣੀਆਂ ਫਾਈਲਾਂ ਵੇਖਦਾ ਹੈ, ਤਾਂ ਇਹ ਪੁਰਾਣੇ ਪੈਟਰਨ (deprecated ਕੌਨਫਿਗ ਵਿਕਲਪ, ਵਿਰਾਸਤੀ APIs) ਨਕਲ ਕਰ ਸਕਦਾ ਹੈ ਭਾਵੇਂ ਟੀਮ ਪਹਿਲਾਂ ਹੀ ਅੱਗੇ ਚਲੀ ਗਈ ਹੋਵੇ।
ਇੱਕ ਆਮ ਹਕੀਕਤੀ ਉਦਾਹਰਨ: ਤੁਸੀਂ ਬਿਲਿੰਗ UI ਵਿੱਚ ਇੱਕ ਛੋਟਾ ਬਦਲਾਅ ਮੰਗਦੇ ਹੋ, ਅਤੇ Claude ਇੱਕ ਸਾਂਝੇ payments ਕੰਪੋਨੇਟ ਨੂੰ ਸੋਧ ਦਿੰਦਾ ਹੈ ਜੋ ਹੋਰ ਐਪਸ ਦੁਆਰਾ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ ਕਿਉਂਕਿ ਇਸਨੇ ਓਹ ਐਪ-ਵਿਸ਼ੇਸ਼ ਰੈਪਰ ਨਹੀਂ ਵੇਖਿਆ ਜੋ ਬਦਲਣਾ ਚਾਹੀਦਾ ਸੀ।
ਮਕਸਦ ਇਹ ਨਹੀਂ ਹੈ ਕਿ Claude ਨੂੰ ਪੂਰਾ monorepo ਦਿਖਾਇਆ ਜਾਵੇ। ਮਕਸਦ ਇਹ ਹੈ ਕਿ ਛੋਟੇ, ਜਾਣ-ਬੁਝ ਕੇ ਇਨਪੁੱਟ ਦਿਤੇ ਜਾਣ ਜੋ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦੇ ਸਕਣ: ਜਿਹੜਾ ਪੈਕੇਜ ਤੁਸੀਂ ਬਦਲ ਰਹੇ ਹੋ, ਉਸ ਦੀਆਂ ਸਿੱਧੀਆਂ ਨਿਰਭਰਤਾਵਾਂ, ਅਤੇ ਇੱਕ ਜਾਂ ਦੋ “ਸਰੋਤ-ਅਫ-ਸੱਚ” ਦਰਜ ਬਾਰੇ ਟਾਇਪ ਅਤੇ ਕੌਨਫਿਗ। ਨਾਲ ਹੀ “ਹੱਥ ਨਾ ਲਾਉ” ਖੇਤਰ (ਹੋਰ ਐਪਸ, ਇੰਫਰਾ, ਜੇਨਰੇਟ ਕੀਤੀ ਫਾਈਲਾਂ) ਦਰਸਾਓ ਅਤੇ ਕਨਫਰਮ ਕਰੋ ਕਿ ਕਿਹੜਾ ਪੈਕੇਜ ਇਸ ਵਿਹਾਰ ਦਾ ਮਾਲਕ ਹੈ।
ਸਹੀਤਾ ਇਸ ਤੇ ਨਿਰਭਰ ਨਹੀਂ ਹੁੰਦੀ ਕਿ ਤੁਸੀਂ ਕਿੰਨਾ ਕੋਡ ਪੇਸਟ ਕਰਦੇ ਹੋ, ਪਰ ਇਸ ਤੇ ਕਿ ਤੁਸੀਂ ਕੰਮ ਨੂੰ ਕਿੰਨਾ ਸਪਸ਼ਟ ਤਰੀਕੇ ਨਾਲ ਵਰਣਨ ਕਰਦੇ ਹੋ।
ਸ਼ੁਰੂਆਤ ਉਸ ਨਤੀਜੇ ਨਾਲ ਕਰੋ ਜੋ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ: ਇੱਕ ਵਿਸ਼ੇਸ਼ ਫਿਕਸ, ਰਿਫੈਕਟਰ, ਜਾਂ ਜਵਾਬ। "ਕੋਡ ਬਾਰੇ ਸਵਾਲ" ਉੱਚ-ਸਤਹ ਤੇ ਰਹਿ ਸਕਦਾ ਹੈ। "ਬਦਲਾਅ ਕਰੋ" ਦੀ ਬੇਨਤੀ ਨੂੰ ਹੱਦਾਂ, ਇਨਪੁੱਟਸ ਅਤੇ ਸਫਲਤਾ ਚੈੱਕ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
ਕਿਸੇ ਵੀ ਚੀਜ਼ ਨੂੰ ਸਾਂਝਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਵਾਕ ਬਣਾਓ ਜੋ ਇਸ ਵਾਕ ਨੂੰ ਪੂਰਾ ਕਰੇ: “ਤੁਸੀਂ ਖਤਮ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਮੈਂ ਸਮਰੱਥ ਹੋਵਾਂਗਾ ਕਿ…”。 ਉਦਾਹਰਨ: “package X ਲਈ unit tests ਵਿਫਲ ਨਹੀਂ ਹੋਣੇ ਚਾਹੀਦੇ” ਜਾਂ “endpoint Y ਲਈ API response ਤੇ ਨਵਾਂ field ਵੇਖਣਾ।” ਉਹ ਵਾਕ ਵੱਡੇ ਰੇਪੋ ਵਿੱਚ ਨਾਰਥ ਸਟਾਰ ਬਣ ਜਾਵੇਗਾ।
ਬਦਲਾਅ ਲਈ, ਸਰੂਚੀਨ ਦੇ ਉਹ ਚੋਟੇ-ਸੈੱਟ ਸਾਂਝੇ ਕਰੋ ਜੋ ਦਿਖਾ ਸਕੇ ਕਿ ਬਦਲਾਅ ਸਹੀ ਹੈ: ਐਂਟਰੀ ਪੁਆਇੰਟ(ਸ), ਸਮਬੰਧਿਤ types/interfaces ਜਾਂ schema, ਇੱਕ failing test ਜਾਂ repro step ਨਾਲ ਉਮੀਦ ਕੀਤੀ ਨਤੀਜਾ, ਅਤੇ ਕੋਈ ਵੀ ਕੌਨਫਿਗ ਜੋ ਇਸ ਰਸਤੇ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੋਵੇ (routing, feature flags, build, ਜਾਂ lint ਨਿਯਮ)। ਜੇ ਲੋੜ ਹੋਵੇ ਤਾਂ ਪੈਕੇਜ ਦਾ ਛੋਟਾ ਫੋਲਡਰ ਮੈਪ ਦੇ ਦਿਓ ਤਾਂ ਕਿ Claude ਨੂੰ ਹਰ ਡਾਇਰੈਕਟਰੀ ਦਾ ਉਦੇਸ਼ ਪਤਾ ਲੱਗ ਜਾਵੇ।
ਕਰਕੇ ਦੱਸੋ ਕਿ ਕਿਹੜੀਆਂ ਚੀਜ਼ਾਂ ਦੇਖਣ ਵਾਲੀ ਨਹੀਂ ਹਨ। ਕਹੋ: “ਜਨਰੇਟ ਕੀਤੀਆਂ ਫਾਈਲਾਂ, vendor ਫੋਲਡਰ, build outputs, snapshots, ਅਤੇ lockfiles ਨੂੰ ਹਟਾਓ ਜਦ ਤਕ ਮੈਂ ਨਾ ਪੁੱਛਾਂ।” ਇਸ ਨਾਲ ਬੇਕਾਰ ਸਮਾਂ ਅਤੇ ਅਣਚਾਹੇ ਸੋਧ ਰੋਕੇ ਜਾਂਦੇ ਹਨ।
ਅਣੀਸ਼ਚਿਤਤਾ ਲਈ ਉਮੀਦਾਂ ਵੀ ਸੈੱਟ ਕਰੋ। Claude ਨੂੰ ਕਹੋ ਕਿ ਅਨੁਮਾਨ ਅਤੇ ਅਣਜਾਣੀਆਂ ਨੂੰ ਫਲੈਗ ਕਰੇ ਨਾ ਕਿ ਅਨੁਮਾਨ ਲਗਾਏ। ਉਦਾਹਰਨ: “ਜੇ ਤੁਸੀਂ ਨਹੀਂ ਦੇਖ ਸਕਦੇ ਕਿ ਇਹ ਫੰਕਸ਼ਨ ਕਿੱਥੇ ਕਾਲ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਐਸਾ ਕਹੋ ਅਤੇ 2 ਤਰੀਕੇ ਸੁਝਾਓ ਜਿਨ੍ਹਾਂ ਨਾਲ ਇਹ ਲੱਭ ਸਕੀਦਾ ਹੈ।”
ਵੱਡੇ monorepo ਵਿੱਚ, ਸਹੀਤਾ ਘੱਟ ਹੁੰਦੀ ਹੈ ਜਦ ਮਾਡਲ ਨੇੜਲੇ ਕੋਡ ਨੂੰ "ਮਦਦਗਾਰ" ਤਰੀਕੇ ਨਾਲ ਖਿੱਚਣ ਲੱਗਦਾ ਹੈ ਜੋ ਟਾਸਕ ਦਾ ਹਿੱਸਾ ਨਹੀਂ। ਇੱਸਦਾ ਹੱਲ ਸਿੱਧਾ ਹੈ: ਬਦਲਾਅ ਮੰਗਣ ਤੋ ਪਹਿਲਾਂ ਇਹ ਨਿਰਧਾਰਤ ਕਰੋ ਕਿ ਕੀ in-scope ਹੈ ਅਤੇ ਕੀ out-of-scope।
ਇੱਕ ਹੱਦ ਚੁਣੋ ਜੋ ਤੁਹਾਡੇ repo ਦੀ ਸੰਗਠਨ ਦੇ مطابق ਹੋਵੇ: ਇੱਕ ਪੈਕੇਜ, ਇੱਕ ਸਰਵਿਸ, ਇੱਕ ਐਪ, ਜਾਂ ਇੱਕ ਸਾਂਝੀ ਲਾਇਬ੍ਰੇਰੀ। ਉਦਾਹਰਨ: ਜੇ ਟਾਸਕ “checkout UI ਅਪਡੇਟ” ਹੈ, ਤਾਂ ਹੱਦ ਸੰਭਵਤ: ਇੱਕ ਐਪ ਪੈਕੇਜ ਹੈ, ਹਰ ਥਾਂ "checkout" ਲੱਭਣ ਨਾ ਕਰੋ।
ਜਿਹੜੇ ਸੰਗੇਤ Claude ਨੂੰ ਰੁਕਣ ਵਿੱਚ ਮਦਦਗਾਰ ਹਨ: ਫੋਲਡਰ ਰਿਵਾਜ (apps/, services/, packages/, libs/), package manifests (exports ਅਤੇ dependencies), ਪਬਲਿਕ ਐਂਟਰੀ ਪੁਆਇੰਟ (index ਫਾਈਲਾਂ, exported components, handlers), ਅਤੇ ਟੈਸਟ (ਉਹ ਅਕਸਰ ਇਰਾਦੇ ਦੀ ਸਰਫੇਸ ਦਿਖਾਉਂਦੇ ਹਨ)। ਇਕ ਫੋਲਡਰ ਦੇ README ਨੂੰ ਛੇਤੀ ਹੱਦ ਨਿਸ਼ਾਨ ਬਣਾਉਣ ਲਈ ਵਰਤੋ।
ਹੱਦਾਂ ਸਭ ਤੋਂ ਵਧੀਆ ਕੰਮ ਕਰਦੀਆਂ ਹਨ ਜਦ ਤੁਸੀਂ ਉਹਨਾਂ ਦੇ ਦਰਮਿਆਨ ਬ੍ਰਿਜ-ਇੰਟਰਫੇਸ ਦਰਸਾਉਂਦੇ ਹੋ। ਨਿਰਧਾਰਤ ਕਰੋ ਕਿ ਕਿੱੜੇ ਇੰਟਰਫੇਸ Claude ਛੂਹ ਸਕਦਾ/ਛੂਹਣਗਾ ਅਤੇ ਬਾਕੀ ਨੂੰ off-limits ਮੰਨੋ। ਆਮ ਬ੍ਰਿਜ HTTP API contracts, event topics ਅਤੇ payloads, ਸਾਂਝੇ types, ਜਾਂ ਇੱਕ ਛੋਟੇ ਸੈੱਟ exported functions ਹੁੰਦੇ ਹਨ।
ਜਦੋਂ ਬਦਲਾਅ ਕਿਸੇ ਖੇਤਰ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ, ਤਾਂ “do not touch” ਜ਼ੋਨ ਵੀ ਨਾਮ ਕਰੋ। ਆਮ ਤੌਰ ਤੇ ਇਹ ਇੰਫਰਾ ਅਤੇ ਡਿਪਲੋਇਮੈਂਟ ਕੌਨਫਿਗ, ਸੁਰੱਖਿਆ ਅਤੇ auth ਲੋਜਿਕ, ਬਿਲਿੰਗ ਅਤੇ payments, ਡੇਟਾ ਮਾਈਗ੍ਰੇਸ਼ਨ ਅਤੇ ਪ੍ਰੋਡਕਸ਼ਨ.schemas, ਅਤੇ ਕਈ ਟੀਮਾਂ ਵੱਲੋਂ ਵਰਤੀ ਜਾਣ ਵਾਲੀਆਂ ਸਾਂਝੀਆਂ ਲਾਇਬ੍ਰੇਰੀਆਂ ਹੁੰਦੀਆਂ ਹਨ।
ਇਕ ਸੰਪ੍ਰਤ ਪ੍ਰੌਂਪਟ ਦਾ ਉਦਾਹਰਨ ਜੋ ਮਦਦ ਕਰਦਾ ਹੈ:
“ਕੇਵਲ packages/cart/ ਅਤੇ ਇਸਦੇ ਟੈਸਟਾਂ ਦੇ ਅੰਦਰ ਸੋਧ ਕਰੋ। ਤੁਸੀਂ packages/types/ ਵਿੱਚ ਸਾਂਝੇ ਟਾਇਪ ਪੜ੍ਹ ਸਕਦੇ ਹੋ ਪਰ ਉਨ੍ਹਾਂ ਨੂੰ ਸੋਧੋ ਨਾ। infra, auth, ਜਾਂ billing ਨੂੰ ਸੋਧੋ ਨਾ।”
ਸਹੀਤਾ ਉਦੋਂ ਬਹਿਤਰ ਹੁੰਦੀ ਹੈ ਜਦ ਤੁਸੀਂ ਉਸ ਖੇਤਰ ਦਾ ਇੱਕ ਛੋਟਾ, ਸਥਿਰ ਨਕਸ਼ਾ ਦਿੰਦੇ ਹੋ ਜਿਸ ਤੇ ਤੁਸੀਂ ਸੋਧ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ। “ਲੋਕਲ ਸੰਖੇਪ” ਓਹ ਨਕਸ਼ਾ ਹੈ: ਤੇਜ਼ੀ ਨਾਲ ਪੜ੍ਹਨ ਯੋਗ ਛੋਟਾ, ਅੰਦਾਜ਼ਾ ਰੋਕਣ ਲਈ ਪਰਯਾਪਤ ਨਿਰਦੇਸ਼ੀ।
ਹਰ ਸੰਖੇਪ 10 ਤੋਂ 20 ਲਾਈਨਾਂ ਦੇ ਅੰਦਰ ਰੱਖੋ। ਇਸਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਲਿਖੋ ਜਿਵੇਂ ਤੁਸੀਂ ਕੋਡ ਇੱਕ ਨਵੇਂ ਟੀਮਮੇਟ ਨੂੰ ਦੇ ਰਹੇ ਹੋ ਜਿਸਨੂੰ ਸਿਰਫ਼ ਇਸ ਹੱਦ ਨੂੰ ਛੇਡਣਾ ਹੈ, ਨਾ ਕਿ ਪੂਰਾ ਰੇਪੋ। ਸਾਧਾ ਭਾਸ਼ਾ ਅਤੇ ਕੋਡ ਵਿੱਚੋਂ ਅਸਲੀ ਨਾਂ ਵਰਤੋਂ: ਫੋਲਡਰ, ਪੈਕੇਜ, exported functions।
ਇੱਕ ਉਪਯੋਗੀ ਲੋਕਲ ਸੰਖੇਪ ਪੰਜ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦਿੰਦਾ ਹੈ:
ਇੱਕ “gotchas” ਲਾਈਨ ਜੋ ਮਹਿੰਗੀਆਂ ਗਲਤੀਆਂ ਤੋਂ ਬਚਾਵੇ: ਲੁਕਿਆCaching, feature flags, migration steps, ਜਾਂ ਕੋਈ ਵੀ ਚੀਜ਼ ਜੋ ਚੁੱਪਚਾਪ ਟੁੱਟ ਸਕਦੀ ਹੈ।
ਇੱਥੇ ਇੱਕ ਕੰਪੈਕਟ ਟੈਮਪਲੇਟ ਹੈ ਜੋ ਤੁਸੀਂ ਕਾਪੀ ਕਰ ਸਕਦੇ ਹੋ:
Local summary: \u003cpackage/service name\u003e
Purpose: \u003c1 sentence\u003e
Scope: \u003cwhat to touch\u003e | Not: \u003cwhat not to change\u003e
Entry points: \u003cfiles/routes/commands\u003e
Public surface: \u003cexports/endpoints/events\u003e
Data sources: \u003ctables/collections/queues/caches\u003e
Conventions: errors=\u003chow\u003e, logging=\u003chow\u003e, tests=\u003cwhere/how\u003e
Gotchas: \u003cflags/caching/migrations/edge cases\u003e
ਉਦਾਹਰਨ: ਜੇ ਤੁਸੀਂ billing ਪੈਕੇਜ ਸੋਧ ਰਹੇ ਹੋ, ਤਾਂ ਉਹ ਸਹੀ ਫੰਕਸ਼ਨ ਨੋਟ ਕਰੋ ਜੋ ਇਨਵਾਇਸ ਬਣਾਉਂਦਾ ਹੈ, ਜਿਹੜੇ ਟੇਬਲਾਂ ਵਿੱਚ ਇਹ ਲਿਖਦਾ ਹੈ, ਅਤੇ retryable errors ਲਈ ਨਿਯਮ। ਫਿਰ Claude ਉਸ ਹੱਦ 'ਤੇ ਧਿਆਨ ਕੇਂਦ੍ਰਿਤ ਕਰ ਸਕਦਾ ਹੈ ਨਾ ਕਿ shared auth ਜਾਂ unrelated packages ਵਿੱਚ ਘੁੱਸੇ।
ਸਭ ਤੋਂ ਵਧੀਆ ਸੰਖੇਪ ਉਹ ਹੈ ਜੋ Claude ਨੂੰ ਜਦੋਂ ਲੋੜ ਹੋਵੇ ਵੇਖਣ ਨੂੰ ਮਿਲੇ। ਇਸਨੂੰ ਉਸ ਕੋਡ ਦੇ ਕੋਲ ਰੱਖੋ ਜਿਸਦਾ ਇਹ ਵੇਰਵਾ ਦਿੰਦਾ ਹੈ ਤਾਂ ਕਿ ਇਹ ਅਣਡਿੱਠਾ ਨਾ ਰਹਿ ਜਾਏ ਅਤੇ ਅਪਡੇਟ ਕਰਨਾ ਆਸਾਨ ਹੋਵੇ। ਉਦਾਹਰਨ ਲਈ, ਹਰ package/ਸਰਵਿਸ/ਐਪ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਇੱਕ ਛੋਟਾ SUMMARY.md (ਜਾਂ README.md ਦਾ ਇੱਕ ਹਿੱਸਾ) ਰੱਖੋ ਨਾ ਕਿ ਰੇਪੋ ਰੂਟ ਤੇ ਇੱਕ ਵੱਡਾ ਦਸਤਾਵੇਜ਼।
ਇੱਕ ਸਧਾਰਨ, ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲਾ ਸਟ੍ਰਕਚਰ ਮਦਦ ਕਰਦਾ ਹੈ। ਇਸਨੂੰ ਓਤਨਾ ਛੋਟਾ ਰੱਖੋ ਕਿ ਲੋਕ ਇਸਨੂੰ ਸੰਭਾਲਣ:
YYYY-MM-DD - \u003cwhat changed in one sentence\u003eਸੰਖੇਪ ਦਾਖਲਾ ਹੋ ਜਾਦਾ ਹੈ ਕੁਝ ਪੇਸ਼ਗੀ ਕਾਰਨਾਂ ਕਰਕੇ। ਇਨ੍ਹਾਂ ਨੂੰ ਕਿਸੇ ਟਾਇਪ ਡੈਫਿਨਿਸ਼ਨ ਅੱਪਡੇਟ ਦੇ ਤਰ੍ਹਾਂ ਪ੍ਰਵੈਸ ਕਰੋ: ਜਦੋਂ ਰਿਫੈਕਟਰ ਸਟ੍ਰਕਚਰ ਜਾਂ ਨਾਂ ਬਦਲਦਾ ਹੈ, ਨਵਾਂ ਮੋਡੀਊਲ ਮੁੱਖ ਤਰੀਕੇ ਨਾਲ ਆਉਂਦਾ ਹੈ, API/event/schema ਬਦਲਦੇ ਹਨ, boundaries shift ਹੁੰਦੀਆਂ ਹਨ, ਜਾਂ ਕੋਈ dependency ਹਟਾਈ ਜਾਂ ਬਦਲੀ ਜਾਂਦੀ ਹੈ।
ਇਕ व्यवहारਿਕ ਆਦਤ: ਜਦ ਤੁਸੀਂ ਇੱਕ ਚੇੰਜ ਮਰਜ ਕਰੋ, ਇੱਕ “Last updated” ਲਾਈਨ ਜੋੜੋ ਜੋ ਦੱਸੇ ਕਿ ਕੀ ਬਦਲਿਆ। Koder.ai ਵਰਗੇ ਟੂਲ ਤੁਹਾਨੂੰ ਕੋਡ ਚੇੰਜ ਤੇਜ਼ੀ ਨਾਲ ਕਰਨ ਵਿੱਚ ਮਦਦ ਦੇ ਸਕਦੇ ਹਨ, ਪਰ ਸੰਖੇਪ ਹੀ ਭਵਿੱਖੀ ਬਦਲਾਅ ਨੂੰ ਸਹੀ ਰੱਖਦਾ ਹੈ।
ਅਕਸਰ ਸਹੀਤਾ ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ ਕਿ ਤੁਸੀਂ ਗੱਲਬਾਤ ਦੀ ਰਫਤਾਰ ਕਿਵੇਂ ਰੱਖਦੇ ਹੋ। Claude ਨੂੰ ਵੱਡੇ ਸਨੈਪਸ਼ੌਟ ਤੋਂ ਅਨੁਮਾਨ ਲਗਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਨਾ ਦਿਓ — ਇਸਦੀ ਥਾਂ ਛੋਟੇ ਟੁਕੜਿਆਂ ਵਿੱਚ ਸੰਦਰਭ ਕਮਾਈ ਕਰਵਾਓ।
ਕਿਸੇ ਵੀ ਸੋਧ ਤੋਂ ਪਹਿਲਾਂ, Claude ਨੂੰ ਪੁੱਛੋ ਕਿ ਇਹ ਜੋ ਦੇਖਦਾ ਹੈ ਉਹ ਕੀ ਹੈ ਅਤੇ ਉਹਨੂੰ ਕਿਸ ਚੀਜ਼ ਦੀ ਲੋੜ ਹੈ। ਵਧੀਆ ਨਕਸ਼ਾ ਛੋਟੀ ਹੁੰਦੀ ਹੈ: ਜਿੱਕੇ ਪੈਕੇਜ ਸ਼ਾਮਲ ਹਨ, ਫਲੋ ਦਾ ਐਂਟਰੀ ਪੁਆਇੰਟ, ਅਤੇ ਟੈਸਟ ਜਾਂ types ਕਿੱਥੇ ਹਨ।
ਪ੍ਰੌਂਪਟ:
“Create a map of this change: packages involved, main flow, and likely touch points. Do not propose code yet.”
ਇੱਕ ਨੈਰੋ slice ਚੁਣੋ: ਇੱਕ ਫੀਚਰ, ਇੱਕ ਪੈਕੇਜ, ਇੱਕ ਯੂਜ਼ਰ ਫਲੋ। ਹੱਦ ਨੂੰ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਦਰਸਾਓ (ਉਦਾਹਰਨ: “ਕੇਵਲ packages/billing-api ਨੂੰ ਬਦਲੋ। shared-ui ਜਾਂ infra ਨੂੰ ਛੇਡੋ ਨਹੀਂ।”)।
ਇੱਕ ਵਰਕਫਲੋ ਜੋ ਤੁਹਾਨੂੰ ਕੰਟਰੋਲ ਵਿੱਚ ਰੱਖਦਾ ਹੈ:
ਜੇ Claude ਕਿਸੇ ਚੀਜ਼ ਤੋਂ ਵਾਂਝਾ ਹੈ, ਤਾਂ ਇਹ ਆਖਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਸਨੂੰ ਲਿਖਣ ਲਈ ਕਹੋ: (1) ਇਹ ਜੋ assumptions ਇਹ ਲਾ ਰਿਹਾ ਹੈ, (2) ਕੀ ਉਹਨਾਂ ਨੂੰ ਖੰਡਿਤ ਕਰੇਗਾ, ਅਤੇ (3) ਅਗਲੇ ਕਿਹੜੇ ਫਾਈਲਾਂ ਦੀ ਲੋੜ ਹੈ।
ਉਦਾਹਰਨ: ਤੁਸੀਂ Invoice response ਵਿੱਚ ਇੱਕ ਫ਼ੀਲਡ ਜੋੜਨਾ ਚਾਹੁੰਦੇ ਹੋ। Claude ਹੈਂਡਲਰ, DTO/type definition, ਅਤੇ ਇੱਕ ਟੈਸਟ ਮੰਗਦਾ ਹੈ। ਤੁਸੀਂ ਸਿਰਫ਼ ਉਹੀ ਸਾਂਝੇ ਕਰੋ। ਜੇ ਤੁਸੀਂ ਚੈਟ-ਅਧਾਰਤ ਬਿਲਡਰ ਵਰਤ ਰਹੇ ਹੋ ਜਿਵੇਂ Koder.ai, ਤਾਂ ਓਥੇ ਵੀ ਇਹੀ ਨਿਯਮ ਲਾਗੂ ਹੁੰਦਾ ਹੈ: ਸਭ ਤੋਂ ਛੋਟਾ ਸੈੱਟ ਸੋর্স ਫਾਈਲ ਦਿਓ, ਫਿਰ ਜਦ ਲੋੜ ਹੋਵੇ ਹੀ ਵਧਾਓ।
ਗਲਤ ਸੋਧਾਂ ਦੇ ਵਿਰੁੱਧ ਤੁਹਾਡੀ ਸਭ ਤੋਂ ਵਧੀਆ ਰੱਖਿਆ ਇੱਕ ਛੋਟਾ “ਕਾਂਟ੍ਰੈਕਟ” ਹੈ ਜੋ ਪ੍ਰੌਂਪਟ ਵਿੱਚ ਲਿਖਿਆ ਹੈ: ਕੀ ਛੇਡ ਸਕਦੇ ਹੋ, ਸਫਲਤਾ ਨੂੰ ਕਿਸ ਤਰ੍ਹਾਂ ਅੰਕਿਤ ਕੀਤਾ ਜਾਵੇ, ਅਤੇ ਕਿਹੜੇ ਨਿਯਮਾਂ ਦੀ ਪਾਲਣਾ ਕਰਨੀ ਹੈ।
ਅਸਾਨ-ਪਾਲਣ ਯੋਗ boundary ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਸੋਧਾਂ ਦੀ ਇਜਾਜ਼ਤ ਵਾਲੀ ਥਾਂ ਸਪਸ਼ਟ ਕਰੋ, ਅਤੇ “do not touch” ਖੇਤਰਾਂ ਨੂੰ ਨਾਮ ਦਿਓ ਤਾਂ ਕਿ ਘੁਮਣ ਦੀ ਲਾਲਚ ਨਾ ਹੋਵੇ।
ਕਾਂਟ੍ਰੈਕਟ ਟੈਮਪਲੇਟ:
packages/payments/ ਹੇਠਾਂ ਫਾਈਲਾਂ ਹੀ ਸੋਧੋ।packages/auth/, infra/, ਜਾਂ ਕਿਸੇ ਸਾਂਝੇ ਕੌਨਫਿਗ ਨੂੰ ਸੋਧੋ ਨਾ।ਫਿਰ acceptance checks ਨਿਰਧਾਰਤ ਕਰੋ। ਬਿਨਾਂ ਉਨ੍ਹਾਂ ਦੇ, Claude ਐਸਾ ਕੋਡ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ ਜੋ ਦਿੱਖ ਵਿੱਚ ਠੀਕ ਲੱਗੇ ਪਰ ਰੇਪੋ ਦੇ ਅਸਲ ਨਿਯਮਾਂ ਨੂੰ ਤੋੜ ਦੇਵੇ।
ਸਟਾਈਲ constraints ਵੀ ਜਰੂਰੀ ਹਨ। ਦੱਸੋ ਕਿ ਕਿਸ ਪੈਟਰਨ ਦੀ ਪਾਲਣਾ ਕਰਨੀਂ ਹੈ ਅਤੇ ਕੀ ਟਾਲਣਾ ਹੈ, ਜੋ ਤੁਹਾਡੇ ਕੋਡਬੇਸ ਵਿੱਚ ਪਹਿਲਾਂ ਤੋਂ ਹੈ। ਉਦਾਹਰਨ: “ਇਸ ਪੈਕੇਜ ਵਿੱਚ ਮੌਜੂਦਾ error helpers ਵਰਤੋਂ; ਨਵੇਂ dependencies ਨਾ ਜੋੜੋ; function ਨਾਂ camelCase ਰੱਖੋ; ਨਵੀਂ ਆਰਕੀਟੈਕਚਰ ਲੇਅਰ ਨਾ ਪੇਦਾ ਕਰੋ।”
ਅਖੀਰ ਵਿੱਚ, ਕਿਸੇ ਵੀ ਸੋਧ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਛੋਟੀ ਯੋਜਨਾ ਮੰਗੋ:
“ਸੋਧ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, 3–5 ਫਾਈਲਾਂ ਲਿਸਟ ਕਰੋ ਜੋ ਤੁਸੀਂ ਛੇਡਣ ਦੀ ਉਮੀਦ ਕਰਦੇ ਹੋ ਅਤੇ ਸਹੀ ਵਿਹਾਰ ਦੱਸੋ। ਮਨਜ਼ੂਰੀ ਦੇ ਬਾਅਦ ਹੀ ਸੋਧ ਦਿਓ।”
ਉਦਾਹਰਨ:
“Invoice totals ਵਿੱਚ rounding ਫਿਕਸ ਕਰੋ। ਕੇਵਲ packages/billing/src/ ਅਤੇ packages/billing/test/ ਹੇਠਾਂ ਸੋਧ ਕਰੋ। Acceptance: pnpm -C packages/billing test ਅਤੇ typecheck. ਮੌਜੂਦਾ money utils ਵਰਤੋ; API types ਨੂੰ ਮੁੜ ਲਿਖੋ ਨਾ. ਪਹਿਲਾਂ 4-ਕਦਮੀ ਯੋਜਨਾ ਦਿਓ।”
Claude ਨੂੰ ਇੱਕ ਵੱਡਾ ਕੋਡ ਢੇਰ ਦੇ ਕੇ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਹੈ ਗਲਤ ਸੋਧਾਂ ਪ੍ਰਾਪਤ ਕਰਨ ਦਾ। ਜਦ ਤੁਸੀਂ ਇੱਕ ਵੱਡਾ ਪੈਕੇਟ ਪੇਸਟ ਕਰ ਦਿੰਦੇ ਹੋ, ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਜਨਰਿਕ ਪੈਟਰਨਾਂ 'ਤੇ ਆਧਾਰ ਕਰ ਲੈਂਦਾ ਬਜਾਏ ਤੁਹਾਡੇ ਰੇਪੋ ਦੇ ਵਿਸ਼ੇਸ਼ ਡਿਜ਼ਾਈਨ ਦੇ।
ਇੱਕ ਹੋਰ ਫੰਦਾ ਹੈ ਆਰਕੀਟੈਕਚਰ ਦੀ ਅਨੁਮਾਨ ਲੈਣਾ। ਜੇ ਤੁਸੀਂ ਅਸਲ ਐਂਟਰੀ ਪੁਆਇੰਟ ਨਹੀਂ ਦਿਖਾਉਂਦੇ ਤਾਂ ਇਹ ਪਹਿਲੀ ਫਾਈਲ ਚੁਨ ਸਕਦਾ ਹੈ ਜੋ ਉਪਯੁਕਤ ਲੱਗਦੀ ਹੈ ਅਤੇ ਓਥੇ ਲਾਜਿਕ ਨੂੰ ਵਾਇਰ ਕਰ ਦੇਵੇ। ਅਮਲ ਵਿੱਚ, ਸਹੀਤਾ ਇੱਕ ਛੋਟੇ ਸੈੱਟ "source of truth" ਫਾਈਲਾਂ (entry modules, routers, service registries, package boundary docs) 'ਤੇ ਆਧਾਰ ਹੁੰਦੀ ਹੈ। ਜੇ ਉਹ ਸੰਦਰਭ ਵਿੱਚ ਨਹੀਂ ਹਨ ਤਾਂ ਮਾਡਲ ਖਾਲੀਆਂ ਭਰਨ ਲੱਗਦਾ ਹੈ।
ਨਾਂ ਵੀ ਠੱਗ ਸਕਦੀਆਂ ਹਨ। ਮੋਨੋਰੇਪੋਅਜ਼ ਵਿੱਚ ਅਕਸਰ ui, ui-kit, shared-ui ਜਿਹੇ ਪੈਕੇਜ ਹਨ ਜਾਂ ਇੱਕੋ ਨਾਂ ਵਾਲੇ ਹੇਲਪਰ ਦੋ ਥਾਂਆਂ date.ts ਵਰਗੇ। ਜੇ ਤੁਸੀਂ ਦੋਹਾਂ ਦਾ ਸਨਿੱਪੇਟ ਮਿਲਾ ਦੇਂਦੇ ਹੋ, Claude ਇੱਕ ਫਾਈਲ ਨੂੰ ਸੋਧ ਕਰ ਸਕਦਾ ਹੈ ਜਦ ਕਿ ਉਹ ਦੂਜੀ 'ਤੇ ਸੋਚ ਰਿਹਾ ਸੀ। ਉਦਾਹਰਨ: ਤੁਸੀਂ ਇੱਕ ਬਟਨ ਸਟਾਈਲ ਬਦਲਵਾਉਣ ਲਈ ਕਹਿੰਦੇ ਹੋ, ਇਹ packages/ui/Button.tsx ਸੋਧ ਦਿੰਦਾ ਹੈ, ਪਰ ਐਪ packages/ui-kit/Button.tsx ਤੋਂ ਇੰਪੋਰਟ ਕਰਦੀ ਹੈ। diff ਠੀਕ ਲੱਗੇਗਾ, ਪਰ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਕੁਝ ਵੀ ਬਦਲੇਗਾ ਨਹੀਂ।
ਕੌਨਫਿਗ ਵੀ ਇੱਕ ਸ਼ਾਂਤ drift ਦਾ ਸਰੋਤ ਹੈ। ਵਿਹਾਰ env vars, feature flags, build settings, ਜਾਂ workspace tooling 'ਤੇ ਨਿਰਭਰ ਹੋ ਸਕਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਇਹਨਾਂ ਦਾ ਜਿਕਰ ਨਹੀਂ ਕਰੋਗੇ ਤਾਂ Claude ਕੋਈ “ਅਜੀਬ” ਚੈੱਕ ਹਟਾ ਸਕਦਾ ਹੈ ਜੋ ਕੇਵਲ ਇੱਕ ਫਲੈਗ 'ਤੇ ਹੋਣ ਤੇ ਹੀ ਘਟਦਾ, ਜਾਂ ਇਹ ਐਸਾ ਕੋਡ ਜੋ build step ਨੂੰ ਤੋੜ ਦੇਵੇ, ਸ਼ਾਮਲ ਕਰ ਸਕਦਾ ਹੈ।
ਇਹ ਨਿਸ਼ਾਨ ਹਨ ਕਿ ਤੁਸੀਂ drift ਕਰ ਰਹੇ ਹੋ:
ਕ੍ਰਾਸ-ਪੈਕੇਜ imports ਨੂੰ ਇੱਕ ਫੈਸਲਾ ਸਮਝੋ, ਡਿਫੌਲਟ ਨਹੀਂ। ਸੋਧਾਂ ਨੂੰ ਲੋਕਲ ਰੱਖੋ ਜਦ ਤੱਕ ਤੁਸੀ ਅਰਪਿਤ ਤੌਰ 'ਤੇ ਸਕੋਪ ਫੈਲਾ ਰਹੇ ਹੋ।
ਸਹੀ ਸੋਧਾਂ ਪ੍ਰਾਪਤ ਕਰਨ ਦਾ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਸੀਮਾਵਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਨਾ ਕਿ ਵਾਲੀਯਮ ਨਾਲ। ਇੱਕ ਚੰਗਾ ਪ੍ਰੌਂਪਟ ਥੋੜ੍ਹਾ ਕਠੋਰ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ: ਇਹ Claude ਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਕਿੱਥੇ ਦੇਖਣਾ ਹੈ, ਕੀ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨਾ ਹੈ, ਅਤੇ “ਹੋ ਗਿਆ” ਦਾ ਕੀ ਮਤਲਬ ਹੈ।
ਪਸੰਦ ਦੀ ਚੈੱਕਲਿਸਟ:
\u003cpackage\u003e/\u003cpath\u003e 'ਚ ਕੰਮ ਕਰੋ। Goal: \u003cone sentence\u003e. ਹੋਰ ਸਭ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰੋ ਜਦ ਤਕ ਨਾ ਪੁੱਛਾਂ।\u003c5-10 lines\u003e. ਐਂਟਰੀ ਫਾਇਲ: \u003cpath/to/file\u003e。\u003c...\u003e. ਬਦਲਣ ਯੋਗ ਨਹੀਂ: \u003cfolders/files or APIs\u003e. ਵਿਹਾਰ ਇਹ ਰਹੇ: \u003cwhat must stay true\u003e。ਜੇ Claude ਤੁਹਾਡੇ boundary ਤੋਂ ਬਾਹਰ ਸੋਧ ਸੁਝਾਏ, ਤਾਂ ਇਸਨੂੰ ਇੱਕ ਸਿਗਨਲ ਵਜੋਂ ਲਓ: ਜਾਂ ਤਾਂ ਪ੍ਰੌਂਪਟ ਨੂੰ ਹੋਰ ਕਸੋ, ਜਾਂ ਜਾਣ-ਬੂਝ ਕੇ ਸਕੋਪ ਫੈਲਾਓ ਅਤੇ ਇਸਨੂੰ ਫਿਰ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਮੁੜ ਕਹੋ।
ਮੰਨੋ ਤੁਹਾਡੇ monorepo ਵਿੱਚ apps/web-store (React ਐਪ) ਅਤੇ packages/ui-kit (ਸਾਂਝੇ ਬਟਨ, ਇਨਪੁੱਟ, ਅਤੇ ਸਟਾਈਲ) ਹਨ। ਤੁਸੀਂ ਇੱਕ ਛੋਟੀ ਫੀਚਰ ਚਾਹੁੰਦੇ ਹੋ: cart ਪੇਜ ਵਿੱਚ “Save for later” ਬਟਨ ਜੋੜੋ, ui-kit ਤੋਂ ਨਵਾਂ SaveIcon ਵਰਤ ਕੇ। ਹੋਰ ਕੁਝ ਨਹੀਂ ਬਦਲਣਾ।
ਪਹਿਲਾਂ ਤੁਸੀਂ ਦੋ ਲੋਕਲ ਸੰਖੇਪ ਬਣਾਓ ਜੋ ਹੱਦਾਂ ਵਾਂਗ ਕੰਮ ਕਰਨ। ਇਹਨਾਂ ਨੂੰ ਛੋਟੇ, ਵਿਸ਼ੇਸ਼, ਅਤੇ ਜਿਹੜਾ ਮੱਦੇਨਜ਼ਰ ਹੈ ਉਸ ਬਾਰੇ ਸਪਸ਼ਟ ਰੱਖੋ।
# apps/web-store/LOCAL_SUMMARY.md
Purpose: Customer shopping UI.
Entry points: src/routes.tsx, src/pages/cart/CartPage.tsx
Cart rules: cart state lives in src/cart/useCart.ts
Do not touch: checkout flow (src/pages/checkout), payments, auth.
Tests: npm test -w apps/web-store
# packages/ui-kit/LOCAL_SUMMARY.md
Purpose: shared UI components.
Exports: src/index.ts
Icons: src/icons/*, add new icons by exporting from index.
Do not touch: theming tokens, build config.
Tests: npm test -w packages/ui-kit
ਫਿਰ ਲੂਪ ਨੂੰ ਤੰਗ ਰੱਖੋ:
CartPage ਅਤੇ ui-kit icons ਤੱਕ ਸੀਮਿਤ ਹੈ। ਕੋਈ checkout/auth ਸੋਧ ਨਹੀਂ।”CartPage, useCart, ui-kit icons, ui-kit index)।ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ, ਦਸਤਾਵੇਜ਼ ਕਰਨਾ ਨਾ ਭੁੱਲੋ ਤਾਂ ਭਵਿੱਖੀ ਸੰਦਰਭ ਛੋਟਾ ਰਹੇ:
ਜੇ ਇਹ ਇਕ ਲੋਕ ਲਈ ਚੰਗਾ ਕੰਮ ਕਰਦਾ ਹੈ ਪਰ ਟੀਮ ਲਈ ਨਹੀਂ, ਤਾਂ ਅਕਸਰ ਗੁਮ ਹੋਈ ਚੀਜ਼ ਦੁਹਰਾਏ ਜਾਣਯੋਗ ਪ੍ਰਕਿਰਿਆ ਹੈ। “ਚੰਗੀ ਸੰਦਰਭ ਹਾਈਜੀਨ” ਨੂੰ ਡਿਫਾਲਟ ਬਣਾਓ, ਨਾਂ ਕਿ ਕੋਈ ਨਿਜੀ ਆਦਤ।
ਇੱਕ ਪ੍ਰੌਂਪਟ skeleton ਸੇਵ ਕਰੋ ਜੋ ਹਰ ਕੋਈ ਕਾਪੀ ਕਰਕੇ ਭਰ ਸਕੇ। ਇਸਨੂੰ ਛੋਟਾ ਪਰ ਕਠੋਰ ਰੱਖੋ। Goal ("done" ਕਿਵੇਂ ਲਗਦਾ ਹੈ), ਆਗਿਆਤ ਸਕੋਪ, ਕਠੋਰ ਹੱਦਾਂ (ਅਤੇ ਕਿਉਂ), ਇੱਕ ਲੋਕਲ ਸੰਖੇਪ, ਅਤੇ ਇੱਕ ਆਉਟਪੁਟ ਕਾਂਟ੍ਰੈਕਟ (ਪਹਿਲਾਂ ਯੋਜਨਾ, ਫਿਰ diff-ਸਟਾਈਲ ਸੋਝੇ ਅਤੇ ਟੈਸਟ) ਸ਼ਾਮਲ ਕਰੋ।
ਵੱਡੇ ਮਾਸਿਕ ਸਮੀਖਿਆਵਾਂ ਛੱਡ ਦਿਓ ਜੋ ਕੋਈ ਨਹੀਂ ਕਰਦਾ। summary ਅਪਡੇਟ ਨੂੰ ਨਾਰਮਲ ਕੰਮ ਦਾ ਹਿੱਸਾ ਬਣਾਓ: ਜਦੋ ਕੋਈ ਚੇੰਜ ਵਿਹਾਰ, ਨਿਰਭਰਤਾ, ਜਾਂ API ਤਬਦੀਲ ਕਰੇ, summary ਨੂੰ ਉਸੇ PR ਵਿੱਚ ਅਪਡੇਟ ਕਰੋ।
ਸਧਾਰਨ ਨਿਯਮ: ਜੇ ਕੋਈ ਸਾਥੀ ਪੁੱਛੇ “ਇਹ ਕਿੱਥੇ ਰਹਿੰਦਾ ਹੈ?” ਜਾਂ “ਇਸ ਤੇ ਕਿਹੜਾ ਨਿਰਭਰ ਹੈ?”, ਤਾਂ summary ਦੇ ਕੋਸ਼-ਕੋਰਬਾਰੀ ਹੁਣ outdated ਹੈ।
ਜੇ ਤੁਸੀਂ ਚੈਟ-ਪਹਿਲਾਂ ਵਰਕਫਲੋ ਵਰਤਦੇ ਹੋ, ਤਾਂ Koder.ai ਤੁਹਾਨੂੰ ਇਸ ਸ਼ैली ਦੀ ਇਤਰਾਟਿਵਨੂੰ ਸੁਰੱਖਿਅਤ ਬਣਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ। Planning mode ਹੱਦਾਂ ਅਤੇ ਸਕੋਪ 'ਤੇ ਸਹਿਮਤੀ ਬਣਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ, ਅਤੇ snapshots ਨਾਲ ਰੋਲਬੈਕ ਤੁਹਾਨੂੰ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਦੀ ਆਜ਼ਾਦੀ ਦਿੰਦੇ ਹਨ ਬਿਨਾਂ ਫਸਣ ਦੇ ਜਦ ਕੋਈ ਅਨੁਮਾਨ ਗਲਤ ਨਿਕਲੇ।
Claude ਅਸਲ ਸਰੋਤ-ਸੱਚ ਨੂੰ “ਦੇਖ” ਨਹੀਂ ਸਕਦਾ ਤਾਂ ਇਹ ਘੱਟ ਸਹੀ ਹੋ ਜਾਂਦਾ ਹੈ।
ਵੱਡੇ monorepo ਵਿੱਚ ਮਾਡਲ ਅਕਸਰ ਇੱਕ ਨਿਰਭਰਤਾ ਫਾਈਲ ਨੂੰ ਮਿਸ ਕਰਦਾ ਹੈ, ਦੋ ਮਿਲਦੇ-ਜੁਲਦੇ ਪੈਕੇਜਾਂ ਨੂੰ ਗਲਤ ਤਰੀਕੇ ਨਾਲ ਮਿਲਾ ਦਿੰਦਾ ਹੈ, ਜਾਂ ਉਹ ਪੁਰਾਣੇ ਪੈਟਰਨ ਨਕਲ ਕਰ ਲੈਂਦਾ ਹੈ ਕਿਉਂਕਿ ਉਹੀ ਹੀ ਸੰਦਰਭ ਵਿੱਚ ਸੀ।
ਸਧਾਰਨ ਨਿਯਮ: ਪੂਰਾ ਰੇਪੋ ਪੇਸਟ ਨਾ ਕਰੋ। ਉਹ ਸਭ ਤੋਂ ਛੋਟਾ ਸੈੱਟ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਬਦਲਾਅ ਦੀ ਸਹੀਅਤਾ ਸਾਬਤ ਕਰਦਾ ਹੈ।
ਇੱਕ ਚੰਗਾ ਡਿਫਾਲਟ:
ਉਸ ਫਾਈਲ ਨੂੰ ਸਾਂਝਾ ਕਰੋ ਜੋ ਵਿਹਾਰ ਨੂੰ ਐਂਕਰ ਕਰਦੀ ਹੈ, ਨਾਂ ਕਿ ਨਾਮ ਦੇ ਆਧਾਰ 'ਤੇ ਸਾਰਾ ਕੁਝ।
ਇੱਕ ਵਿਆਵਹਾਰਿਕ ਸੈਟ:
ਇਸ ਨੂੰ ਆਪਣੀ repo ਰਚਨਾ ਦੇ ਅਨੁਸਾਰ ਇੱਕ boundary ਚੁਣੋ: ਇੱਕ package, app, ਜਾਂ service.
ਫਿਰ ਇਸਨੂੰ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਲਿਖੋ, ਸਮੇਤ ਕੀ ਚੀਜ਼ਾਂ ਆਉਟ-ਆਫ-ਸਕੋਪ ਹਨ. ਉਦਾਹਰਨ constraints:
packages/cart/ ਅਤੇ ਇਸਦੇ ਟੈਸਟ ਨੂੰ ਬਦਲੋ।”ਕਈ ਵਾਰੀ monorepo ਵਿੱਚ ਮਿਲਦੇ-ਜੁਲਦੇ ਮੌਡੀਊਲ (ਜਿਵੇਂ ui, ui-kit, shared-ui) ਜਾਂ ਇੱਕੋ-ਤਰ੍ਹਾਂ ਦੇ ਹੇਲਪਰੇਜ਼ (date.ts) ਹੁੰਦੇ ਹਨ।
Claude ਸਹੀ ਵਿਚਾਰ ਨੂੰ ਗਲਤ ਪੈਕੇਜ 'ਤੇ ਲਾ ਸਕਦਾ ਹੈ ਜਾਂ “ਕਰੀਬੀ ਸਹੀ” ਮੌਡੀਊਲ ਨਾਂਮ ਤੋਂ ਇੰਪੋਰਟ ਕਰ ਸਕਦਾ ਹੈ। ਉਸਨੂੰ ਰੋਕਣ ਲਈ ਤੁਸੀਂ ਠੀਕ ਪੈਕੇਜ ਅਤੇ ਐਂਟਰੀ ਪੁਆਇੰਟਾਂ ਨੂੰ ਨਾਮ ਨਾਲ ਦੱਸੋ।
ਲੋਕਲ ਸੰਖੇਪ ਇੱਕ ਛੋਟਾ ਨਕਸ਼ਾ ਹੈ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਉਸ ਖੇਤਰ ਲਈ ਦਿੰਦੇ ਹੋ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਬਦਲਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਆਮ ਤੌਰ 'ਤੇ 10–20 ਲਾਈਨਾਂ.
ਸ਼ਾਮਲ ਕਰੋ:
ਉਸਦੇ ਕੋਡ ਦੇ ਬगल SUMMARY.md ਜਾਂ package README.md ਦੇ ਇੱਕ ਹਿੱਸੇ ਵਜੋਂ ਰੱਖੋ ਤਾਂ ਕਿ ਇਹ ਆਸਾਨੀ ਨਾਲ ਮਿਲੇ ਅਤੇ ਅੱਪਡੇਟ ਹੋ ਸਕੇ.
ਸਧਾਰਨ ਡਿਫਾਲਟ:
Claude ਨੂੰ ਆਗੇ ਦੱਸੋ ਕਿ ਅਣਜਾਣੇ ਅਤੇ ਧਾਰਾਣਾਵਾਂ (assumptions) ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਕੇ ਦੱਸੇ — ਅਨੁਮਾਨ ਲਗਾਉਣ ਦੀ ਥਾਂ.
ਇਕ ਕਾਰਗਰ ਨਿਯਮ:
ਛੋਟੇ-ਛੋਟੇ ਹਿੱਸਿਆਂ ਵਿੱਚ ਸੰਦਰਭ ਦੀ ਮੰਗ ਕਰੋ ਤਾਂ ਕਿ Claude ਵੱਡੇ ਸਨੈਪਸ਼ੌਟ ਤੋਂ ਅਨੁਮਾਨ ਨਾ ਲਗਾਏ:
ਪ੍ਰੰਪਟ ਵਿੱਚ ਇੱਕ ਛੋਟਾ “ਕਾਂਟ੍ਰੈਕਟ” ਲਿਖੋ ਅਤੇ ਇਸਨੂੰ ਲਾਗੂ ਕਰਨ ਯੋਗ ਬਣਾਓ:
ਇਸ ਨਾਲ review ਆਸਾਨ ਹੁੰਦਾ ਹੈ ਅਤੇ ਗਲਤ-ਮੁਕਾਬਲੇ ਦੇ ਸੰਭਾਵਨਾ ਘਟਦੀ ਹੈ।