AI coding agent को भरोसेमंद domain knowledge कैसे दें

General-purpose coding agent सही दिखने वाला उत्तर लिख सकता है और फिर भी आपके stack की जरूरी detail चूक सकता है: हाल में बदली API, ऐसी repository सीमा जिसे पार नहीं करना चाहिए, या production को स्थिर रखने वाली convention। समाधान हमेशा लंबा prompt नहीं है। छोटा, दोबारा उपयोग होने वाला domain guidance और जाँच योग्य definition of done बेहतर है।

1. Project rules और domain procedures अलग रखें

दो layers बनाएँ। पहली छोटी repository contract है: project क्या है, structure कैसी है, build और test commands क्या हैं, कौन-सी files off-limits हैं, और “done” का अर्थ क्या है। JetBrains का agent behavior documentation AGENTS.md और CLAUDE.md जैसे instruction files को repository के साथ चलने वाली guidance बताता है।

यह layer स्थिर और operational रखें। हर task के लिए बताए कि domain logic कहाँ है, checks कैसे चलाने हैं और क्या edit नहीं करना है। केवल एक workflow का rule अलग skill में रखें।

दूसरी layer domain knowledge है: बार-बार आने वाले task के लिए focused recipe, जैसे Android navigation migration, database schema change या release checklist। Skill में स्पष्ट trigger, छोटे steps और explicit validation होना चाहिए।

2. Knowledge gap के आसपास skill लिखें

अच्छी skill इसलिए होती है क्योंकि model बार-बार गलती करता है या वही जानकारी फिर खोजता है। Android Skills philosophy verifiable gaps पर ध्यान देने को कहती है, खासकर बदलती APIs और custom architecture में। यह trusted sources से skills लेने और untested collections से सावधान रहने की सलाह भी देती है।

एक छोटा उदाहरण:

---
name: navigation-upgrade
description: Use when changing the app's Navigation 3 setup or upgrading its related APIs.
---

Before editing:
1. Inspect the current dependency versions and existing navigation tests.
2. Read the project's navigation conventions.
3. Confirm the target API in the approved platform documentation.

While editing:
- Make the smallest vertical change that satisfies the requested behavior.
- Do not replace the navigation architecture without approval.
- Preserve existing deep-link and back-stack behavior unless the task says otherwise.

Done means:
- The focused tests pass.
- The relevant build or lint command passes.
- The response names changed files, checks run, and unresolved risks.

उदाहरण जानबूझकर छोटा है। यह पूरा framework manual हर prompt में नहीं डालता; यह बताता है कि procedure कब लागू है, क्या inspect करना है, boundaries क्या हैं और completion कैसे दिखानी है। इसे अपने repository के असली commands से बदलें।

3. Agent को action से पहले inspect कराएँ

Coding agents request को environment context से जोड़ते हैं, उस पर reasoning करते हैं और edits, tests तथा builds चलाते हैं। यही pattern AWS Prescriptive Guidance में है। Instructions में ये stages स्पष्ट करें।

एक practical request में चार भाग रखें:

1. Context: feature, directories और constraints।
2. Plan: edit से पहले files और checks की सूची।
3. Change: acceptance criteria पूरा करने वाला smallest implementation।
4. Evidence: tests, lint, build या manual checks।

इससे agent देर से architecture खोजकर बड़े rewrite की ओर नहीं जाता। Inspection वह तरीका है जिससे agent अपने निर्णयों के लिए जरूरी context पाता है।

4. Tight feedback loop दें

Domain guidance project का तरीका बताता है, लेकिन executable checks बताते हैं कि change काम करता है या नहीं। VS Code का current TDD guide red, green और refactor phases अलग करता है।

तीन complex agents जरूरी नहीं हैं। छोटे task में पहले failing या characterization test माँगें, फिर implementation करें, और focused test तथा normal quality gates चलाएँ। Check fail हो तो वह requirement या environment के बारे में सूचना है, छिपाने की चीज नहीं।

5. Guidance की समीक्षा और retirement

Skill को versioned engineering infrastructure मानें। Framework बदलने, agent की repeat mistake या noisy check पर इसे review करें। Android Skills guidance skills को deprecation candidates मानती है: models सुधरते हैं और नई APIs नए gaps बनाती हैं।

हल्का maintenance loop:

• Skill चलाने वाला example task रखें।
• Expected files और validation commands लिखें।
• Skill या model बदलने के बाद फिर चलाएँ।
• अनावश्यक instructions हटाएँ।
• Security-sensitive actions को optional और review योग्य रखें।

लक्ष्य agent को अधिक expert सुनाना नहीं, सही behavior को reproducible बनाना है: छोटा repository contract, focused domain procedure और executable done-definition context से change और evidence तक रास्ता देते हैं।