AI ഉപയോഗിച്ച് പ്രോഡക്റ്റ് റിക്വയർമെന്റ്സ് ഡോക് എങ്ങനെ എഴുതാം (സൗജന്യ ടെംപ്ലേറ്റ്)

പ്രോഡക്റ്റ് റിക്വയർമെന്റ്സ് ഡോക്യുമെന്റ് (PRD) എന്നത് നിങ്ങൾ എന്താണ് നിർമ്മിക്കുന്നത്, ആർക്കുവേണ്ടിയാണ്, അത് എന്ത് ചെയ്യണം, അത് പ്രവർത്തിക്കുന്നു എന്ന് എങ്ങനെ അറിയാം എന്നിവ ലളിതമായ ഭാഷയിൽ വിവരിക്കുന്ന ഹ്രസ്വ രേഖയാണ്. AI ഉപയോഗിച്ചാൽ ഇത് വളരെ വേഗത്തിൽ എഴുതാം: പരുക്കൻ കുറിപ്പുകൾ നൽകിയാൽ അത് ഘടനയുള്ള വിഭാഗങ്ങളും ഉപയോക്തൃ കഥകളും അപവാദ കേസുകളും ഉണ്ടാക്കും. AI-ക്ക് എടുക്കാനാകാത്ത തീരുമാനങ്ങൾ — ലക്ഷ്യം, വ്യാപ്തി, ഒഴിവാക്കുന്നത് എന്നിവ — നൽകുന്നതും അത് ചേർക്കുന്നത് പരിശോധിക്കുന്നതും നിങ്ങളുടെ ജോലിയാണ്.

ഈ ഗൈഡ് PRD-യിൽ എന്തൊക്കെ വേണം, ഏത് AI അസിസ്റ്റന്റിലും ഡ്രാഫ്റ്റ് ചെയ്യാനുള്ള ഘട്ടം ഘട്ടമായ വഴി, ഓരോ ഭാഗത്തിനുമുള്ള പ്രോംപ്റ്റുകൾ, പകർത്താവുന്ന പൂരിപ്പിക്കൽ ടെംപ്ലേറ്റ് എന്നിവ വിവരിക്കുന്നു.

PRD എന്തിനാണ് (എന്തല്ല)

PRD നാല് ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകുന്നു:

1. എന്തുകൊണ്ട് ഇത് നിർമ്മിക്കുന്നു? ഏത് പ്രശ്നം, ആർക്കുവേണ്ടി?
2. എന്ത് ആദ്യ പതിപ്പിൽ ചെയ്യണം?
3. എന്ത് ചെയ്യില്ല ഇപ്പോൾ?
4. എങ്ങനെ അത് പ്രവർത്തിച്ചു എന്ന് അറിയും?

ഇത് സാങ്കേതിക ഡിസൈൻ അല്ല. ഏത് ഡാറ്റാബേസോ ഫ്രെയിംവർക്കോ ഉപയോഗിക്കണമെന്ന് ഇത് പറയുന്നില്ല — അതിന് ആവശ്യമെങ്കിൽ പ്രത്യേക ടെക്നിക്കൽ സ്പെക് വേണം. മാർക്കറ്റിംഗ് ബ്രീഫോ ബിസിനസ് പ്ലാനോ അല്ല ഇത്. PRD-യെ പ്രോഡക്റ്റിന്റെ പെരുമാറ്റത്തിൽ മാത്രം നിർത്തുന്നതാണ് അത് ഉപയോഗപ്രദമാക്കുന്നത്: ഡിസൈനർക്കും ഡെവലപ്പർക്കും, അംഗീകരിക്കുന്ന പങ്കാളിക്കും, അല്ലെങ്കിൽ അതിനെ കോഡാക്കുന്ന AI ആപ്പ് ബിൽഡറിനും.

ആർക്കാണ് ഇത് വേണ്ടത്

• സോളോ സ്ഥാപകർ സ്കോപ്പ് വളരുന്നത് ആരംഭത്തിൽ തന്നെ തടയാൻ.
• ചെറിയ ടീമുകൾ "നമ്മൾ സമ്മതിച്ചത്" എന്നത് ഒരിടത്ത് സൂക്ഷിക്കാൻ.
• ഫ്രീലാൻസറെയോ ഏജൻസിയെയോ നിയമിക്കുന്നവർ, കാരണം വ്യക്തമായ PRD വ്യക്തമായ ഉദ്ധരണികൾ നൽകും. ഒരു ഡെവലപ്പറെ നിയമിക്കുകയോ AI ഉപയോഗിച്ച് നിർമ്മിക്കുകയോ ചെയ്യുക കാണുക.
• AI ഉപയോഗിച്ച് നിർമ്മിക്കുന്നവർ, കാരണം PRD-യിലെ ഉപയോക്തൃ കഥകളും ഡാറ്റാ പട്ടികയും ഘടനയില്ലാത്ത ആഗ്രഹപ്പട്ടികയേക്കാൾ നല്ല പ്രോംപ്റ്റുകളാണ്.

AI നല്ലതാക്കുന്നത്, അല്ലാത്തത്

ഏറ്റവും സാധാരണ പരാജയം മുകളിലെ രണ്ടാമത്തെ-അവസാന വരി തലകീഴായി മാറുന്നതാണ്: വിടവുകൾ നിറയ്ക്കാൻ AI ഉപയോക്താക്കളെക്കുറിച്ച് വിശ്വസനീയമെന്ന് തോന്നുന്ന ഊഹങ്ങൾ എഴുതും. ഉപയോക്താക്കൾ, വിപണി വലുപ്പം, പെരുമാറ്റം എന്നിവയെക്കുറിച്ച് അത് എഴുതുന്നതെന്തും വസ്തുതയല്ല, പരിശോധിക്കേണ്ട ചോദ്യമായി കണക്കാക്കുക.

ഘട്ടം 1: നിങ്ങൾക്കറിയാവുന്നതെല്ലാം ഇടുക

എന്തെങ്കിലും പ്രോംപ്റ്റ് ചെയ്യുന്നതിന് മുമ്പ് പരുക്കൻ കുറിപ്പുകൾ എഴുതുക. ബുള്ളറ്റ് പോയിന്റുകൾ മതി. ഇവ ഉൾപ്പെടുത്തുക:

• പ്രശ്നം, ഒന്നോ രണ്ടോ വാക്യങ്ങളിൽ, ഉപയോക്താവിന്റെ കാഴ്ചപ്പാടിൽ നിന്ന്.
• അത് ആർക്കുണ്ട്. നിർദ്ദിഷ്ടമായിരിക്കുക: "10–40 ക്ലയന്റുകളുള്ള ഫ്രീലാൻസ് ബുക്ക്കീപ്പർമാർ", "ചെറുകിട ബിസിനസുകൾ" എന്നല്ല.
• ഇപ്പോൾ അവർ പകരം എന്ത് ചെയ്യുന്നു (ഒരു സ്പ്രെഡ്ഷീറ്റ്, ഇമെയിൽ, ഇഷ്ടമില്ലാത്ത ഒരു ടൂൾ).
• പതിപ്പ് ഒന്ന് വിജയമാകാൻ ഒറ്റ ഫലം.
• ചെയ്യില്ലെന്ന് ഇതിനകം അറിയാവുന്നത്.
• കർശനമായ പരിമിതികൾ: സമയപരിധി, ബജറ്റ്, ഫോണിൽ പ്രവർത്തിക്കണം, നിങ്ങൾ ഇതിനകം ഉപയോഗിക്കുന്ന ഒരു ടൂളുമായി ബന്ധിപ്പിക്കണം.

പ്രശ്നമുള്ള ആരോടും സംസാരിച്ചിട്ടില്ലെങ്കിൽ അത് ആദ്യം ചെയ്യുക. ഒരു ആപ്പ് ആശയം എങ്ങനെ സാധൂകരിക്കാം എന്നതിൽ പ്രായോഗിക വഴിയുണ്ട്. ഊഹങ്ങളിൽ അധിഷ്ഠിതമായ PRD നന്നായി ഫോർമാറ്റ് ചെയ്ത ഒരു ഊഹം മാത്രമാണ്.

ഘട്ടം 2: AI-യോട് ആദ്യ ഡ്രാഫ്റ്റ് ആവശ്യപ്പെടുക

നിങ്ങളുടെ കുറിപ്പുകൾ ഒട്ടിച്ച്, ഒരു നിശ്ചിത ഘടനയിൽ ഡ്രാഫ്റ്റ് ആവശ്യപ്പെടുക. നന്നായി പ്രവർത്തിക്കുന്ന ഒരു പ്രോംപ്റ്റ്:

ഒരു പ്രോഡക്റ്റിനെക്കുറിച്ചുള്ള എന്റെ കുറിപ്പുകൾ ഇതാ. അവയെ ഇപ്പോൾ പറയുന്ന വിഭാഗങ്ങൾ മാത്രം ഉപയോഗിച്ച് ഒരു പ്രോഡക്റ്റ് റിക്വയർമെന്റ്സ് ഡോക്യുമെന്റാക്കുക: Summary, Problem, Users, Goals and success metrics, Scope (in / out), User stories with acceptance criteria, Data, Permissions, Edge cases, Open questions. രണ്ട് പേജിൽ താഴെ നിർത്തുക. ഉപയോക്താക്കളെയോ വിപണിയെയോ കുറിച്ച് വസ്തുതകൾ കണ്ടുപിടിക്കരുത് — എന്റെ കുറിപ്പുകൾ പറയാത്തത് Open questions-ൽ ചോദ്യമായി എഴുതുക.

അവസാന നിർദ്ദേശം പ്രധാനമാണ്. അറിയാത്തവ നിറയ്ക്കാതെ "Open questions"-ലേക്ക് മാറ്റാൻ AI-യോട് പറയുന്നത് വളരെ സത്യസന്ധമായ ഡ്രാഫ്റ്റ് നൽകും.

ഘട്ടം 3: ഓരോ ഭാഗവും മുറുക്കുക

ഡ്രാഫ്റ്റ് ഭാഗം ഭാഗമായി പരിശോധിക്കുക. ഈ തുടർ പ്രോംപ്റ്റുകൾ സഹായിക്കും:

പ്രശ്നവും ഉപയോക്താക്കളും

പ്രശ്ന പ്രസ്താവന ഉപയോക്താവിന്റെ കാഴ്ചപ്പാടിൽ ഒന്നോ രണ്ടോ വാക്യങ്ങളിൽ വീണ്ടും എഴുതുക. പരിഹാര വാക്കുകൾ വേണ്ട.

പ്രശ്ന പ്രസ്താവന നിങ്ങളുടെ പ്രോഡക്റ്റിനെ പരാമർശിക്കുന്നുവെങ്കിൽ, അത് പ്രശ്നത്തെയല്ല, പരിഹാരത്തെയാണ് വിവരിക്കുന്നത്.

ലക്ഷ്യങ്ങളും വിജയ അളവുകോലുകളും

പതിപ്പ് ഒന്നിന് മൂന്ന് വിജയ അളവുകോലുകൾ നിർദ്ദേശിക്കുക, ഒരു ചെറിയ കൂട്ടം ഉപയോക്താക്കളുമായി ആദ്യ മാസത്തിൽ എനിക്ക് അളക്കാവുന്നവ. ഓരോന്നിനും എങ്ങനെ അളക്കുമെന്നും പറയുക.

ഒന്നോ രണ്ടോ തിരഞ്ഞെടുക്കുക. "ഇരുപത് ബുക്ക്കീപ്പർമാർ ഒരു മാസം ആഴ്ചതോറും ഉപയോഗിക്കുന്നു" അളക്കാവുന്നതാണ്. "ഉൽപ്പാദനക്ഷമത മെച്ചപ്പെടുത്തുക" അല്ല.

വ്യാപ്തി

ഈ PRD-യിലുള്ള, പ്രധാന ഫ്ലോ തകരാതെ പിന്നീടുള്ള പതിപ്പിലേക്ക് മാറ്റാവുന്ന എല്ലാം പട്ടികപ്പെടുത്തുക.

AI ടൂളുകൾ ഫീച്ചറുകൾ ചേർക്കാൻ ഒരു പ്രവണത കാണിക്കുന്നു. ഈ പ്രോംപ്റ്റ് അതിന് വിപരീതമായി ചെയ്യിപ്പിക്കുന്നു. കടുപ്പത്തോടെ വെട്ടിക്കുറയ്ക്കുക: മിക്ക പതിപ്പ്-ഒന്ന് PRD-കളും വളരെ വലുതാണ്. എന്താണ് MVP ചെറിയ ആദ്യ പതിപ്പുകൾ കൂടുതൽ പഠിപ്പിക്കുന്നത് എന്തുകൊണ്ടെന്ന് വിശദീകരിക്കുന്നു.

ഉപയോക്തൃ കഥകളും സ്വീകാര്യതാ മാനദണ്ഡങ്ങളും

ഓരോ ആവശ്യകതയും ഒരു ഉപയോക്തൃ കഥയായി എഴുതുക ("[ഉപയോക്താവ്] ആയി, എനിക്ക് [പ്രവർത്തനം] വേണം, അങ്ങനെ [ഫലം]") രണ്ട് മുതൽ നാല് വരെ Given / When / Then സ്വീകാര്യതാ മാനദണ്ഡങ്ങളോടെ.

സ്വീകാര്യതാ മാനദണ്ഡങ്ങളാണ് പിന്നീട് പരിശോധിക്കുന്ന ചെക്ക്‌ലിസ്റ്റ്. "ഒരു ബുക്ക് ചെയ്ത സ്ലോട്ട്, മറ്റൊരു ക്ലയന്റ് കലണ്ടർ കാണുമ്പോൾ, ആ സ്ലോട്ട് കാണിക്കുന്നില്ല" പരിശോധിക്കാവുന്നതാണ്. "ബുക്കിംഗ് നന്നായി പ്രവർത്തിക്കുന്നു" അല്ല.

അപവാദ കേസുകളും അനുമതികളും

ഓരോ ഉപയോക്തൃ കഥയ്ക്കും, ശൂന്യ ഡാറ്റ, തെറ്റായ ഇൻപുട്ട്, മന്ദഗതിയിലോ പരാജയപ്പെട്ടോ ഉള്ള നെറ്റ്‌വർക്ക് അഭ്യർത്ഥന, ആക്സസ് ഇല്ലാത്ത ഉപയോക്താവ് എന്നിവയിൽ എന്ത് സംഭവിക്കുമെന്ന് പട്ടികപ്പെടുത്തുക.

ആളുകൾ മറക്കുന്ന ശൂന്യ അവസ്ഥകളും അനുമതി വിടവുകളും കണ്ടെത്തുന്നതിൽ AI വേഗമുള്ളതാണ്. ഇവിടെയാണ് AI-യുടെ പ്രയോജനം.

ഘട്ടം 4: ഒരു സംശയാലുവിനെപ്പോലെ വായിക്കുക

മുഴുവൻ രേഖയും ഒരിക്കൽ കൂടി വായിച്ച് ഇവ പരിശോധിക്കുക:

• ഉപയോക്താക്കളെക്കുറിച്ചുള്ള ഓരോ അവകാശവാദവും നിങ്ങളിൽ നിന്നോ ഗവേഷണത്തിൽ നിന്നോ വന്നതാണ്, AI-യിൽ നിന്നല്ല.
• വ്യാപ്തി "പുറത്ത്" കുറഞ്ഞത് "അകത്ത്" പോലെ നീളമുള്ളതാണ്.
• ഓരോ ഉപയോക്തൃ കഥയ്ക്കും നിങ്ങളോട് ചോദിക്കാതെ ആർക്കും പരിശോധിക്കാവുന്ന സ്വീകാര്യതാ മാനദണ്ഡങ്ങളുണ്ട്.
• ഡാറ്റാ വിഭാഗം ആപ്പ് സൂക്ഷിക്കുന്ന എല്ലാ തരം രേഖകളും, അവ ആർക്ക് കാണാമെന്നും പട്ടികപ്പെടുത്തുന്നു.
• Open questions-ന് ഒരു ഉത്തരവാദിയും തീയതിയുമുണ്ട്.
• യഥാർത്ഥ പരിമിതിയല്ലാതെ സാങ്കേതികമായ ഒന്നും കടന്നുകൂടിയിട്ടില്ല ("ഓഫ്‌ലൈനായി പ്രവർത്തിക്കണം" ഒരു ആവശ്യകതയാണ്; "Redis ഉപയോഗിക്കുക" അല്ല).

അതിനുശേഷം ഉൽപ്പന്നം ഉപയോഗിക്കുകയോ നിർമ്മിക്കുകയോ ചെയ്യുന്ന ഒരാളുമായി പങ്കിട്ട്, എന്താണ് വ്യക്തമല്ലാത്തതെന്ന് ചോദിക്കുക. അവരുടെ ചോദ്യങ്ങളാണ് വിടവുകൾ.

പൂരിപ്പിക്കാവുന്ന PRD ടെംപ്ലേറ്റ്

ഇത് ഒരു രേഖയിലേക്ക് പകർത്തി ബ്രായ്ക്കറ്റുകൾ മാറ്റുക. യഥാർത്ഥത്തിൽ ബാധകമല്ലാത്ത വിഭാഗങ്ങൾ ഒഴിവാക്കുക.

പ്രോഡക്റ്റിന്റെ പേര്: [പേര്] ഉടമ: [തീരുമാനങ്ങൾക്ക് ഉത്തരവാദിയായ വ്യക്തി] നില: [ഡ്രാഫ്റ്റ് / പരിശോധനയിൽ / അംഗീകരിച്ചത്] — അവസാനം പുതുക്കിയത്: [തീയതി]

1. സംഗ്രഹം

[രണ്ടോ മൂന്നോ വാക്യങ്ങൾ: ഇത് എന്താണ്, ആർക്കുവേണ്ടി, പ്രധാന ഫലം.]

2. പ്രശ്നം

[ഉപയോക്താവിന്റെ കാഴ്ചപ്പാടിൽ പ്രശ്നം. അവർ ഇന്ന് എന്ത് ചെയ്യുന്നു, അത് എന്തുകൊണ്ട് വേദനിപ്പിക്കുന്നു.]

3. ഉപയോക്താക്കൾ

4. ലക്ഷ്യങ്ങളും വിജയ അളവുകോലുകളും

• ലക്ഷ്യം: [പതിപ്പ് ഒന്ന് നേടേണ്ട ഫലം]
• അളവുകോൽ: [എങ്ങനെ അളക്കും, ലക്ഷ്യം എത്ര]
• ലക്ഷ്യമല്ലാത്തത്: [ആളുകൾ കരുതാനിടയുള്ള, ഈ പതിപ്പ് ചെയ്യാൻ ശ്രമിക്കാത്ത ഒന്ന്]

5. വ്യാപ്തി

പതിപ്പ് ഒന്നിൽ:

• [ഫീച്ചർ]
• [ഫീച്ചർ]

പതിപ്പ് ഒന്നിൽ ഇല്ലാത്തത്:

• [ഫീച്ചർ, അത് പിന്നീടാകാൻ കാരണം]
• [ഫീച്ചർ, അത് പിന്നീടാകാൻ കാരണം]

6. ഉപയോക്തൃ കഥകൾ

കഥ 1: [ഉപയോക്താവ്] ആയി, എനിക്ക് [പ്രവർത്തനം] വേണം, അങ്ങനെ [ഫലം].

• Given [സാഹചര്യം], when [പ്രവർത്തനം], then [ഫലം].
• Given [സാഹചര്യം], when [പ്രവർത്തനം], then [ഫലം].

കഥ 2: [ഉപയോക്താവ്] ആയി, എനിക്ക് [പ്രവർത്തനം] വേണം, അങ്ങനെ [ഫലം].

• Given [സാഹചര്യം], when [പ്രവർത്തനം], then [ഫലം].

7. ഡാറ്റ

8. അനുമതികൾ

[ആർക്ക് ലോഗിൻ ചെയ്യാം, എന്തെല്ലാം റോളുകളുണ്ട്, ഓരോ റോളിനും എന്ത് കാണാനും മാറ്റാനും കഴിയും.]

9. അപവാദ കേസുകൾ

• [ശൂന്യ അവസ്ഥ: ഇതുവരെ ഡാറ്റയില്ലെങ്കിൽ എന്ത് കാണിക്കും]
• [തെറ്റായ ഇൻപുട്ട്: തെറ്റായ ഇമെയിലോ നഷ്ടപ്പെട്ട ഫീൽഡോ ഉണ്ടെങ്കിൽ എന്ത് സംഭവിക്കും]
• [ആക്സസ്: അനുവദനീയമല്ലാത്ത പേജ് ആരെങ്കിലും തുറന്നാൽ എന്ത് സംഭവിക്കും]

10. സംയോജനങ്ങളും പരിമിതികളും

[പേയ്‌മെന്റുകൾ, ഇമെയിൽ, നിലവിലുള്ള ടൂളുകൾ, സമയപരിധി, ബജറ്റ്, പ്രവർത്തിക്കേണ്ട ഉപകരണങ്ങൾ.]

11. Open questions

PRD-യിൽ നിന്ന് പ്രോംപ്റ്റുകളിലേക്ക്

നല്ല PRD ഏതാണ്ട് നേരിട്ട് AI ആപ്പ് ബിൽഡറിനുള്ള പ്രോംപ്റ്റുകളായി മാറുന്നു:

• സംഗ്രഹം, ഉപയോക്താക്കൾ, ഡാറ്റാ പട്ടിക നിങ്ങളുടെ ആദ്യ പ്രോംപ്റ്റാകുന്നു.
• ഓരോ ഉപയോക്തൃ കഥയും ഒരു തുടർ പ്രോംപ്റ്റാകുന്നു.
• ഓരോ സ്വീകാര്യതാ മാനദണ്ഡവും പ്രിവ്യൂവിൽ നിങ്ങൾ പരിശോധിക്കുന്ന ഒന്നാകുന്നു.
• "പതിപ്പ് ഒന്നിൽ ഇല്ല" പട്ടിക നിങ്ങൾ ഇപ്പോൾ ആവശ്യപ്പെടാത്തത് ആണ്.

PRD മുഴുവൻ ഒട്ടിച്ച് എല്ലാം ആവശ്യപ്പെടുന്നതിനേക്കാൾ, ഒരു സമയം ഒരു കഥ നിർമ്മിച്ച്, മുന്നോട്ട് പോകുന്നതിന് മുമ്പ് അതിന്റെ സ്വീകാര്യതാ മാനദണ്ഡങ്ങൾ പരിശോധിക്കുന്നതാണ് വളരെ വിശ്വസനീയം. AI ആപ്പ് ബിൽഡറുകൾക്ക് പ്രോംപ്റ്റ് എഴുതുന്ന വിധം പ്രോംപ്റ്റിംഗ് വശം കൂടുതൽ വിശദീകരിക്കുന്നു.

സാധാരണ തെറ്റുകൾ

• പ്രശ്നമായി പരിഹാരം എഴുതുന്നത്. "ഉപയോക്താക്കൾക്ക് ഒരു ഡാഷ്‌ബോർഡ് വേണം" ഒരു പരിഹാരമാണ്. "ഏത് ഇൻവോയ്സുകൾ കാലഹരണപ്പെട്ടു എന്ന് ഓരോന്നും തുറക്കാതെ ഉടമയ്ക്ക് കാണാനാകുന്നില്ല" ആണ് പ്രശ്നം.
• "പുറത്ത്" വിഭാഗം ഇല്ലാത്തത്. അത് ഇല്ലെങ്കിൽ ഓരോ സംഭാഷണവും വ്യാപ്തി വീണ്ടും തുറക്കും.
• AI ഉപയോക്താക്കളെ കണ്ടുപിടിക്കാൻ അനുവദിക്കുന്നത്. AI ഉണ്ടാക്കിയ വ്യക്തിത്വങ്ങൾ യഥാർത്ഥമെന്ന് തോന്നും, പക്ഷേ അവ യഥാർത്ഥമല്ല.
• എണ്ണാനാവാത്ത അളവുകോലുകൾ. എണ്ണാൻ വഴിയില്ലെങ്കിൽ അത് അളവുകോൽ അല്ല.
• ഒരിക്കലും പുതുക്കാത്തത്. ഇപ്പോൾ നിർമ്മിക്കുന്നതുമായി ചേരാത്ത PRD ഒന്നുമില്ലാതെയുള്ളതിനേക്കാൾ മോശമാണ്. "അവസാനം പുതുക്കിയത്" തീയതി സൂക്ഷിക്കുക, തീരുമാനങ്ങൾ മാറുമ്പോൾ അത് മാറ്റുക.

Mythex-ൽ PRD ഉപയോഗിക്കുന്നത്

നിങ്ങൾ Mythex-ൽ നിർമ്മിക്കുന്നുവെങ്കിൽ, നിങ്ങളുടെ PRD നേരിട്ട് ചാറ്റിൽ ഒട്ടിക്കാം. PRD-ക്ക് Plan മോഡ് നല്ല യോജിപ്പാണ്: ഏജന്റ് അത് വായിക്കുന്നു, സമീപനവും ഘട്ട പട്ടികയും നിർദ്ദേശിക്കുന്നു, അത് പ്ലാൻ ടാബിൽ നിങ്ങൾക്ക് അവലോകനം ചെയ്യാം, Build അമർത്തുന്നതുവരെ ഫയലുകൾ മാറ്റുന്നില്ല. എപ്പോഴും ബാധകമാകേണ്ട ഭാഗങ്ങൾ — പ്രേക്ഷകർ, ബ്രാൻഡ്, നിയമങ്ങൾ — പ്രോജക്റ്റ് വിജ്ഞാനമായി സൂക്ഷിക്കാം, അങ്ങനെ എല്ലാ ചാറ്റിലും ആവർത്തിക്കേണ്ടതില്ല. Build, Plan, Ask മോഡുകൾ ചാറ്റ് ഡോക്സ് വിശദീകരിക്കുന്നു, കൂടാതെ ടെംപ്ലേറ്റുകൾ ഒരു ആദ്യ പതിപ്പ് എങ്ങനെയിരിക്കുമെന്ന് മുഴുവൻ രേഖ എഴുതുന്നതിന് മുമ്പ് കാണാൻ വേഗമാർഗമാണ്.

ചോദ്യങ്ങൾ