@autobe/agent 0.4.1 → 0.4.3

package/lib/factory/createAutoBeApplication.js

@@ -166,8 +166,7 @@ const claude = {
                         type: "string"
                     },
                     userPlanningRequirements: {
-                        title: "This prompt defines how to convert a user's planning-oriented requirements into a structured message for an internal agent",
-                        description: "This prompt defines how to convert a user's planning-oriented requirements into a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if some parts of the user's input are inappropriate or insufficient from a planning standpoint, you are allowed to add **supplementary remarks**\u2014but only under strict rules.\n\n<Supplementary Remark Rules>\n\n1. **Definition**\nA supplementary remark is additional information that may differ from the user's original intent. Because of this, **you must clearly indicate that it is *not* part of the user\u2019s thinking**.\n\n2. **When to Supplement**\n- If the user's input reveals a lack of technical understanding (e.g., suggesting \"put all data into one table\"), and the plan is not an MVP or PoC, it's encouraged to make reasonable additions for a more scalable or robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement the content to ensure completeness.\n\n3. **When Not to Supplement**\n- If the user's input is vague or ambiguous, **do not assume or add extra details**. Instead, it\u2019s better to ask the user follow-up questions to clarify their intent.\n- If the user has made no comment on design, **do not impose design-related decisions** (e.g., colors, fonts, tone). However, you may state explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds value, as such goals are assumed in all services.\n\n</Supplementary Remark Rules>",
+                        description: "# Define prompts to translate user planning requirements into messages for internal agents\n\nThis prompt defines how to convert a user's planning-oriented requirements\ninto a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if\nsome parts of the user's input are inappropriate or insufficient from a\nplanning standpoint, you are allowed to add **supplementary remarks**\u2014but\nonly under strict rules.\n\n# Supplementary Remark Rules\n\n1. **Definition** A supplementary remark is additional information that may\n   differ from the user's original intent. Because of this, **you must\n   clearly indicate that it is _not_ part of the user\u2019s thinking**.\n2. **When to Supplement**\n\n- If the user's input reveals a lack of technical understanding (e.g.,\n  suggesting \"put all data into one table\"), and the plan is not an MVP or\n  PoC, it's encouraged to make reasonable additions for a more scalable or\n  robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement\n  the content to ensure completeness.\n\n3. **When Not to Supplement**\n\n- If the user's input is vague or ambiguous, **do not assume or add extra\n  details**. Instead, it\u2019s better to ask the user follow-up questions to\n  clarify their intent.\n- If the user has made no comment on design, **do not impose design-related\n  decisions** (e.g., colors, fonts, tone). However, you may state\n  explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds\n  value, as such goals are assumed in all services.\n\n# Style Guidelines\n\nThis prompt is delivered to the sub-agent, and several are created for\nparallel processing of the sub-agent. Additionally, there should be a guide\nto style, since sub-agents cannot create different styles of documents due\nto the disconnection of their conversations with each other.\n\nFor example, there should be a hyperlink to the previous document, the next\ndocument, before or after the document, or there should be no more than N\nheadings. The entire content of the document will have requirements, such\nas maintaining informal or formal language.\n\n# Limiting the volume of a document\n\nHowever, do not go beyond the volume guide; each agent only needs to create\none page because the agent receiving this document will be created as many\nas the number of pages.",
                         type: "string"
                     }
                 },
@@ -259,8 +258,7 @@ const claude = {
                         type: "string"
                     },
                     userPlanningRequirements: {
-                        title: "This prompt defines how to convert a user's planning-oriented requirements into a structured message for an internal agent",
-                        description: "This prompt defines how to convert a user's planning-oriented requirements into a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if some parts of the user's input are inappropriate or insufficient from a planning standpoint, you are allowed to add **supplementary remarks**\u2014but only under strict rules.\n\n<Supplementary Remark Rules>\n\n1. **Definition**\nA supplementary remark is additional information that may differ from the user's original intent. Because of this, **you must clearly indicate that it is *not* part of the user\u2019s thinking**.\n\n2. **When to Supplement**\n- If the user's input reveals a lack of technical understanding (e.g., suggesting \"put all data into one table\"), and the plan is not an MVP or PoC, it's encouraged to make reasonable additions for a more scalable or robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement the content to ensure completeness.\n\n3. **When Not to Supplement**\n- If the user's input is vague or ambiguous, **do not assume or add extra details**. Instead, it\u2019s better to ask the user follow-up questions to clarify their intent.\n- If the user has made no comment on design, **do not impose design-related decisions** (e.g., colors, fonts, tone). However, you may state explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds value, as such goals are assumed in all services.\n\n</Supplementary Remark Rules>",
+                        description: "# Define prompts to translate user planning requirements into messages for internal agents\n\nThis prompt defines how to convert a user's planning-oriented requirements\ninto a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if\nsome parts of the user's input are inappropriate or insufficient from a\nplanning standpoint, you are allowed to add **supplementary remarks**\u2014but\nonly under strict rules.\n\n# Supplementary Remark Rules\n\n1. **Definition** A supplementary remark is additional information that may\n   differ from the user's original intent. Because of this, **you must\n   clearly indicate that it is _not_ part of the user\u2019s thinking**.\n2. **When to Supplement**\n\n- If the user's input reveals a lack of technical understanding (e.g.,\n  suggesting \"put all data into one table\"), and the plan is not an MVP or\n  PoC, it's encouraged to make reasonable additions for a more scalable or\n  robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement\n  the content to ensure completeness.\n\n3. **When Not to Supplement**\n\n- If the user's input is vague or ambiguous, **do not assume or add extra\n  details**. Instead, it\u2019s better to ask the user follow-up questions to\n  clarify their intent.\n- If the user has made no comment on design, **do not impose design-related\n  decisions** (e.g., colors, fonts, tone). However, you may state\n  explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds\n  value, as such goals are assumed in all services.\n\n# Style Guidelines\n\nThis prompt is delivered to the sub-agent, and several are created for\nparallel processing of the sub-agent. Additionally, there should be a guide\nto style, since sub-agents cannot create different styles of documents due\nto the disconnection of their conversations with each other.\n\nFor example, there should be a hyperlink to the previous document, the next\ndocument, before or after the document, or there should be no more than N\nheadings. The entire content of the document will have requirements, such\nas maintaining informal or formal language.\n\n# Limiting the volume of a document\n\nHowever, do not go beyond the volume guide; each agent only needs to create\none page because the agent receiving this document will be created as many\nas the number of pages.",
                         type: "string"
                     }
                 },
@@ -352,8 +350,7 @@ const claude = {
                         type: "string"
                     },
                     userPlanningRequirements: {
-                        title: "This prompt defines how to convert a user's planning-oriented requirements into a structured message for an internal agent",
-                        description: "This prompt defines how to convert a user's planning-oriented requirements into a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if some parts of the user's input are inappropriate or insufficient from a planning standpoint, you are allowed to add **supplementary remarks**\u2014but only under strict rules.\n\n<Supplementary Remark Rules>\n\n1. **Definition**\nA supplementary remark is additional information that may differ from the user's original intent. Because of this, **you must clearly indicate that it is *not* part of the user\u2019s thinking**.\n\n2. **When to Supplement**\n- If the user's input reveals a lack of technical understanding (e.g., suggesting \"put all data into one table\"), and the plan is not an MVP or PoC, it's encouraged to make reasonable additions for a more scalable or robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement the content to ensure completeness.\n\n3. **When Not to Supplement**\n- If the user's input is vague or ambiguous, **do not assume or add extra details**. Instead, it\u2019s better to ask the user follow-up questions to clarify their intent.\n- If the user has made no comment on design, **do not impose design-related decisions** (e.g., colors, fonts, tone). However, you may state explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds value, as such goals are assumed in all services.\n\n</Supplementary Remark Rules>",
+                        description: "# Define prompts to translate user planning requirements into messages for internal agents\n\nThis prompt defines how to convert a user's planning-oriented requirements\ninto a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if\nsome parts of the user's input are inappropriate or insufficient from a\nplanning standpoint, you are allowed to add **supplementary remarks**\u2014but\nonly under strict rules.\n\n# Supplementary Remark Rules\n\n1. **Definition** A supplementary remark is additional information that may\n   differ from the user's original intent. Because of this, **you must\n   clearly indicate that it is _not_ part of the user\u2019s thinking**.\n2. **When to Supplement**\n\n- If the user's input reveals a lack of technical understanding (e.g.,\n  suggesting \"put all data into one table\"), and the plan is not an MVP or\n  PoC, it's encouraged to make reasonable additions for a more scalable or\n  robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement\n  the content to ensure completeness.\n\n3. **When Not to Supplement**\n\n- If the user's input is vague or ambiguous, **do not assume or add extra\n  details**. Instead, it\u2019s better to ask the user follow-up questions to\n  clarify their intent.\n- If the user has made no comment on design, **do not impose design-related\n  decisions** (e.g., colors, fonts, tone). However, you may state\n  explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds\n  value, as such goals are assumed in all services.\n\n# Style Guidelines\n\nThis prompt is delivered to the sub-agent, and several are created for\nparallel processing of the sub-agent. Additionally, there should be a guide\nto style, since sub-agents cannot create different styles of documents due\nto the disconnection of their conversations with each other.\n\nFor example, there should be a hyperlink to the previous document, the next\ndocument, before or after the document, or there should be no more than N\nheadings. The entire content of the document will have requirements, such\nas maintaining informal or formal language.\n\n# Limiting the volume of a document\n\nHowever, do not go beyond the volume guide; each agent only needs to create\none page because the agent receiving this document will be created as many\nas the number of pages.",
                         type: "string"
                     }
                 },
@@ -445,8 +442,7 @@ const claude = {
                         type: "string"
                     },
                     userPlanningRequirements: {
-                        title: "This prompt defines how to convert a user's planning-oriented requirements into a structured message for an internal agent",
-                        description: "This prompt defines how to convert a user's planning-oriented requirements into a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if some parts of the user's input are inappropriate or insufficient from a planning standpoint, you are allowed to add **supplementary remarks**\u2014but only under strict rules.\n\n<Supplementary Remark Rules>\n\n1. **Definition**\nA supplementary remark is additional information that may differ from the user's original intent. Because of this, **you must clearly indicate that it is *not* part of the user\u2019s thinking**.\n\n2. **When to Supplement**\n- If the user's input reveals a lack of technical understanding (e.g., suggesting \"put all data into one table\"), and the plan is not an MVP or PoC, it's encouraged to make reasonable additions for a more scalable or robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement the content to ensure completeness.\n\n3. **When Not to Supplement**\n- If the user's input is vague or ambiguous, **do not assume or add extra details**. Instead, it\u2019s better to ask the user follow-up questions to clarify their intent.\n- If the user has made no comment on design, **do not impose design-related decisions** (e.g., colors, fonts, tone). However, you may state explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds value, as such goals are assumed in all services.\n\n</Supplementary Remark Rules>",
+                        description: "# Define prompts to translate user planning requirements into messages for internal agents\n\nThis prompt defines how to convert a user's planning-oriented requirements\ninto a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if\nsome parts of the user's input are inappropriate or insufficient from a\nplanning standpoint, you are allowed to add **supplementary remarks**\u2014but\nonly under strict rules.\n\n# Supplementary Remark Rules\n\n1. **Definition** A supplementary remark is additional information that may\n   differ from the user's original intent. Because of this, **you must\n   clearly indicate that it is _not_ part of the user\u2019s thinking**.\n2. **When to Supplement**\n\n- If the user's input reveals a lack of technical understanding (e.g.,\n  suggesting \"put all data into one table\"), and the plan is not an MVP or\n  PoC, it's encouraged to make reasonable additions for a more scalable or\n  robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement\n  the content to ensure completeness.\n\n3. **When Not to Supplement**\n\n- If the user's input is vague or ambiguous, **do not assume or add extra\n  details**. Instead, it\u2019s better to ask the user follow-up questions to\n  clarify their intent.\n- If the user has made no comment on design, **do not impose design-related\n  decisions** (e.g., colors, fonts, tone). However, you may state\n  explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds\n  value, as such goals are assumed in all services.\n\n# Style Guidelines\n\nThis prompt is delivered to the sub-agent, and several are created for\nparallel processing of the sub-agent. Additionally, there should be a guide\nto style, since sub-agents cannot create different styles of documents due\nto the disconnection of their conversations with each other.\n\nFor example, there should be a hyperlink to the previous document, the next\ndocument, before or after the document, or there should be no more than N\nheadings. The entire content of the document will have requirements, such\nas maintaining informal or formal language.\n\n# Limiting the volume of a document\n\nHowever, do not go beyond the volume guide; each agent only needs to create\none page because the agent receiving this document will be created as many\nas the number of pages.",
                         type: "string"
                     }
                 },
@@ -538,8 +534,7 @@ const claude = {
                         type: "string"
                     },
                     userPlanningRequirements: {
-                        title: "This prompt defines how to convert a user's planning-oriented requirements into a structured message for an internal agent",
-                        description: "This prompt defines how to convert a user's planning-oriented requirements into a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if some parts of the user's input are inappropriate or insufficient from a planning standpoint, you are allowed to add **supplementary remarks**\u2014but only under strict rules.\n\n<Supplementary Remark Rules>\n\n1. **Definition**\nA supplementary remark is additional information that may differ from the user's original intent. Because of this, **you must clearly indicate that it is *not* part of the user\u2019s thinking**.\n\n2. **When to Supplement**\n- If the user's input reveals a lack of technical understanding (e.g., suggesting \"put all data into one table\"), and the plan is not an MVP or PoC, it's encouraged to make reasonable additions for a more scalable or robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement the content to ensure completeness.\n\n3. **When Not to Supplement**\n- If the user's input is vague or ambiguous, **do not assume or add extra details**. Instead, it\u2019s better to ask the user follow-up questions to clarify their intent.\n- If the user has made no comment on design, **do not impose design-related decisions** (e.g., colors, fonts, tone). However, you may state explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds value, as such goals are assumed in all services.\n\n</Supplementary Remark Rules>",
+                        description: "# Define prompts to translate user planning requirements into messages for internal agents\n\nThis prompt defines how to convert a user's planning-oriented requirements\ninto a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if\nsome parts of the user's input are inappropriate or insufficient from a\nplanning standpoint, you are allowed to add **supplementary remarks**\u2014but\nonly under strict rules.\n\n# Supplementary Remark Rules\n\n1. **Definition** A supplementary remark is additional information that may\n   differ from the user's original intent. Because of this, **you must\n   clearly indicate that it is _not_ part of the user\u2019s thinking**.\n2. **When to Supplement**\n\n- If the user's input reveals a lack of technical understanding (e.g.,\n  suggesting \"put all data into one table\"), and the plan is not an MVP or\n  PoC, it's encouraged to make reasonable additions for a more scalable or\n  robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement\n  the content to ensure completeness.\n\n3. **When Not to Supplement**\n\n- If the user's input is vague or ambiguous, **do not assume or add extra\n  details**. Instead, it\u2019s better to ask the user follow-up questions to\n  clarify their intent.\n- If the user has made no comment on design, **do not impose design-related\n  decisions** (e.g., colors, fonts, tone). However, you may state\n  explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds\n  value, as such goals are assumed in all services.\n\n# Style Guidelines\n\nThis prompt is delivered to the sub-agent, and several are created for\nparallel processing of the sub-agent. Additionally, there should be a guide\nto style, since sub-agents cannot create different styles of documents due\nto the disconnection of their conversations with each other.\n\nFor example, there should be a hyperlink to the previous document, the next\ndocument, before or after the document, or there should be no more than N\nheadings. The entire content of the document will have requirements, such\nas maintaining informal or formal language.\n\n# Limiting the volume of a document\n\nHowever, do not go beyond the volume guide; each agent only needs to create\none page because the agent receiving this document will be created as many\nas the number of pages.",
                         type: "string"
                     }
                 },
@@ -642,8 +637,7 @@ const collection = {
                             type: "string"
                         },
                         userPlanningRequirements: {
-                            title: "This prompt defines how to convert a user's planning-oriented requirements into a structured message for an internal agent",
-                            description: "This prompt defines how to convert a user's planning-oriented requirements into a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if some parts of the user's input are inappropriate or insufficient from a planning standpoint, you are allowed to add **supplementary remarks**\u2014but only under strict rules.\n\n<Supplementary Remark Rules>\n\n1. **Definition**\nA supplementary remark is additional information that may differ from the user's original intent. Because of this, **you must clearly indicate that it is *not* part of the user\u2019s thinking**.\n\n2. **When to Supplement**\n- If the user's input reveals a lack of technical understanding (e.g., suggesting \"put all data into one table\"), and the plan is not an MVP or PoC, it's encouraged to make reasonable additions for a more scalable or robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement the content to ensure completeness.\n\n3. **When Not to Supplement**\n- If the user's input is vague or ambiguous, **do not assume or add extra details**. Instead, it\u2019s better to ask the user follow-up questions to clarify their intent.\n- If the user has made no comment on design, **do not impose design-related decisions** (e.g., colors, fonts, tone). However, you may state explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds value, as such goals are assumed in all services.\n\n</Supplementary Remark Rules>",
+                            description: "# Define prompts to translate user planning requirements into messages for internal agents\n\nThis prompt defines how to convert a user's planning-oriented requirements\ninto a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if\nsome parts of the user's input are inappropriate or insufficient from a\nplanning standpoint, you are allowed to add **supplementary remarks**\u2014but\nonly under strict rules.\n\n# Supplementary Remark Rules\n\n1. **Definition** A supplementary remark is additional information that may\n   differ from the user's original intent. Because of this, **you must\n   clearly indicate that it is _not_ part of the user\u2019s thinking**.\n2. **When to Supplement**\n\n- If the user's input reveals a lack of technical understanding (e.g.,\n  suggesting \"put all data into one table\"), and the plan is not an MVP or\n  PoC, it's encouraged to make reasonable additions for a more scalable or\n  robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement\n  the content to ensure completeness.\n\n3. **When Not to Supplement**\n\n- If the user's input is vague or ambiguous, **do not assume or add extra\n  details**. Instead, it\u2019s better to ask the user follow-up questions to\n  clarify their intent.\n- If the user has made no comment on design, **do not impose design-related\n  decisions** (e.g., colors, fonts, tone). However, you may state\n  explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds\n  value, as such goals are assumed in all services.\n\n# Style Guidelines\n\nThis prompt is delivered to the sub-agent, and several are created for\nparallel processing of the sub-agent. Additionally, there should be a guide\nto style, since sub-agents cannot create different styles of documents due\nto the disconnection of their conversations with each other.\n\nFor example, there should be a hyperlink to the previous document, the next\ndocument, before or after the document, or there should be no more than N\nheadings. The entire content of the document will have requirements, such\nas maintaining informal or formal language.\n\n# Limiting the volume of a document\n\nHowever, do not go beyond the volume guide; each agent only needs to create\none page because the agent receiving this document will be created as many\nas the number of pages.",
                             type: "string"
                         }
                     },
@@ -726,8 +720,7 @@ const collection = {
                             type: "string"
                         },
                         userPlanningRequirements: {
-                            title: "This prompt defines how to convert a user's planning-oriented requirements into a structured message for an internal agent",
-                            description: "This prompt defines how to convert a user's planning-oriented requirements into a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if some parts of the user's input are inappropriate or insufficient from a planning standpoint, you are allowed to add **supplementary remarks**\u2014but only under strict rules.\n\n<Supplementary Remark Rules>\n\n1. **Definition**\nA supplementary remark is additional information that may differ from the user's original intent. Because of this, **you must clearly indicate that it is *not* part of the user\u2019s thinking**.\n\n2. **When to Supplement**\n- If the user's input reveals a lack of technical understanding (e.g., suggesting \"put all data into one table\"), and the plan is not an MVP or PoC, it's encouraged to make reasonable additions for a more scalable or robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement the content to ensure completeness.\n\n3. **When Not to Supplement**\n- If the user's input is vague or ambiguous, **do not assume or add extra details**. Instead, it\u2019s better to ask the user follow-up questions to clarify their intent.\n- If the user has made no comment on design, **do not impose design-related decisions** (e.g., colors, fonts, tone). However, you may state explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds value, as such goals are assumed in all services.\n\n</Supplementary Remark Rules>",
+                            description: "# Define prompts to translate user planning requirements into messages for internal agents\n\nThis prompt defines how to convert a user's planning-oriented requirements\ninto a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if\nsome parts of the user's input are inappropriate or insufficient from a\nplanning standpoint, you are allowed to add **supplementary remarks**\u2014but\nonly under strict rules.\n\n# Supplementary Remark Rules\n\n1. **Definition** A supplementary remark is additional information that may\n   differ from the user's original intent. Because of this, **you must\n   clearly indicate that it is _not_ part of the user\u2019s thinking**.\n2. **When to Supplement**\n\n- If the user's input reveals a lack of technical understanding (e.g.,\n  suggesting \"put all data into one table\"), and the plan is not an MVP or\n  PoC, it's encouraged to make reasonable additions for a more scalable or\n  robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement\n  the content to ensure completeness.\n\n3. **When Not to Supplement**\n\n- If the user's input is vague or ambiguous, **do not assume or add extra\n  details**. Instead, it\u2019s better to ask the user follow-up questions to\n  clarify their intent.\n- If the user has made no comment on design, **do not impose design-related\n  decisions** (e.g., colors, fonts, tone). However, you may state\n  explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds\n  value, as such goals are assumed in all services.\n\n# Style Guidelines\n\nThis prompt is delivered to the sub-agent, and several are created for\nparallel processing of the sub-agent. Additionally, there should be a guide\nto style, since sub-agents cannot create different styles of documents due\nto the disconnection of their conversations with each other.\n\nFor example, there should be a hyperlink to the previous document, the next\ndocument, before or after the document, or there should be no more than N\nheadings. The entire content of the document will have requirements, such\nas maintaining informal or formal language.\n\n# Limiting the volume of a document\n\nHowever, do not go beyond the volume guide; each agent only needs to create\none page because the agent receiving this document will be created as many\nas the number of pages.",
                             type: "string"
                         }
                     },
@@ -810,8 +803,7 @@ const collection = {
                             type: "string"
                         },
                         userPlanningRequirements: {
-                            title: "This prompt defines how to convert a user's planning-oriented requirements into a structured message for an internal agent",
-                            description: "This prompt defines how to convert a user's planning-oriented requirements into a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if some parts of the user's input are inappropriate or insufficient from a planning standpoint, you are allowed to add **supplementary remarks**\u2014but only under strict rules.\n\n<Supplementary Remark Rules>\n\n1. **Definition**\nA supplementary remark is additional information that may differ from the user's original intent. Because of this, **you must clearly indicate that it is *not* part of the user\u2019s thinking**.\n\n2. **When to Supplement**\n- If the user's input reveals a lack of technical understanding (e.g., suggesting \"put all data into one table\"), and the plan is not an MVP or PoC, it's encouraged to make reasonable additions for a more scalable or robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement the content to ensure completeness.\n\n3. **When Not to Supplement**\n- If the user's input is vague or ambiguous, **do not assume or add extra details**. Instead, it\u2019s better to ask the user follow-up questions to clarify their intent.\n- If the user has made no comment on design, **do not impose design-related decisions** (e.g., colors, fonts, tone). However, you may state explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds value, as such goals are assumed in all services.\n\n</Supplementary Remark Rules>",
+                            description: "# Define prompts to translate user planning requirements into messages for internal agents\n\nThis prompt defines how to convert a user's planning-oriented requirements\ninto a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if\nsome parts of the user's input are inappropriate or insufficient from a\nplanning standpoint, you are allowed to add **supplementary remarks**\u2014but\nonly under strict rules.\n\n# Supplementary Remark Rules\n\n1. **Definition** A supplementary remark is additional information that may\n   differ from the user's original intent. Because of this, **you must\n   clearly indicate that it is _not_ part of the user\u2019s thinking**.\n2. **When to Supplement**\n\n- If the user's input reveals a lack of technical understanding (e.g.,\n  suggesting \"put all data into one table\"), and the plan is not an MVP or\n  PoC, it's encouraged to make reasonable additions for a more scalable or\n  robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement\n  the content to ensure completeness.\n\n3. **When Not to Supplement**\n\n- If the user's input is vague or ambiguous, **do not assume or add extra\n  details**. Instead, it\u2019s better to ask the user follow-up questions to\n  clarify their intent.\n- If the user has made no comment on design, **do not impose design-related\n  decisions** (e.g., colors, fonts, tone). However, you may state\n  explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds\n  value, as such goals are assumed in all services.\n\n# Style Guidelines\n\nThis prompt is delivered to the sub-agent, and several are created for\nparallel processing of the sub-agent. Additionally, there should be a guide\nto style, since sub-agents cannot create different styles of documents due\nto the disconnection of their conversations with each other.\n\nFor example, there should be a hyperlink to the previous document, the next\ndocument, before or after the document, or there should be no more than N\nheadings. The entire content of the document will have requirements, such\nas maintaining informal or formal language.\n\n# Limiting the volume of a document\n\nHowever, do not go beyond the volume guide; each agent only needs to create\none page because the agent receiving this document will be created as many\nas the number of pages.",
                             type: "string"
                         }
                     },
@@ -894,8 +886,7 @@ const collection = {
                             type: "string"
                         },
                         userPlanningRequirements: {
-                            title: "This prompt defines how to convert a user's planning-oriented requirements into a structured message for an internal agent",
-                            description: "This prompt defines how to convert a user's planning-oriented requirements into a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if some parts of the user's input are inappropriate or insufficient from a planning standpoint, you are allowed to add **supplementary remarks**\u2014but only under strict rules.\n\n<Supplementary Remark Rules>\n\n1. **Definition**\nA supplementary remark is additional information that may differ from the user's original intent. Because of this, **you must clearly indicate that it is *not* part of the user\u2019s thinking**.\n\n2. **When to Supplement**\n- If the user's input reveals a lack of technical understanding (e.g., suggesting \"put all data into one table\"), and the plan is not an MVP or PoC, it's encouraged to make reasonable additions for a more scalable or robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement the content to ensure completeness.\n\n3. **When Not to Supplement**\n- If the user's input is vague or ambiguous, **do not assume or add extra details**. Instead, it\u2019s better to ask the user follow-up questions to clarify their intent.\n- If the user has made no comment on design, **do not impose design-related decisions** (e.g., colors, fonts, tone). However, you may state explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds value, as such goals are assumed in all services.\n\n</Supplementary Remark Rules>",
+                            description: "# Define prompts to translate user planning requirements into messages for internal agents\n\nThis prompt defines how to convert a user's planning-oriented requirements\ninto a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if\nsome parts of the user's input are inappropriate or insufficient from a\nplanning standpoint, you are allowed to add **supplementary remarks**\u2014but\nonly under strict rules.\n\n# Supplementary Remark Rules\n\n1. **Definition** A supplementary remark is additional information that may\n   differ from the user's original intent. Because of this, **you must\n   clearly indicate that it is _not_ part of the user\u2019s thinking**.\n2. **When to Supplement**\n\n- If the user's input reveals a lack of technical understanding (e.g.,\n  suggesting \"put all data into one table\"), and the plan is not an MVP or\n  PoC, it's encouraged to make reasonable additions for a more scalable or\n  robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement\n  the content to ensure completeness.\n\n3. **When Not to Supplement**\n\n- If the user's input is vague or ambiguous, **do not assume or add extra\n  details**. Instead, it\u2019s better to ask the user follow-up questions to\n  clarify their intent.\n- If the user has made no comment on design, **do not impose design-related\n  decisions** (e.g., colors, fonts, tone). However, you may state\n  explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds\n  value, as such goals are assumed in all services.\n\n# Style Guidelines\n\nThis prompt is delivered to the sub-agent, and several are created for\nparallel processing of the sub-agent. Additionally, there should be a guide\nto style, since sub-agents cannot create different styles of documents due\nto the disconnection of their conversations with each other.\n\nFor example, there should be a hyperlink to the previous document, the next\ndocument, before or after the document, or there should be no more than N\nheadings. The entire content of the document will have requirements, such\nas maintaining informal or formal language.\n\n# Limiting the volume of a document\n\nHowever, do not go beyond the volume guide; each agent only needs to create\none page because the agent receiving this document will be created as many\nas the number of pages.",
                             type: "string"
                         }
                     },
@@ -978,8 +969,7 @@ const collection = {
                             type: "string"
                         },
                         userPlanningRequirements: {
-                            title: "This prompt defines how to convert a user's planning-oriented requirements into a structured message for an internal agent",
-                            description: "This prompt defines how to convert a user's planning-oriented requirements into a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if some parts of the user's input are inappropriate or insufficient from a planning standpoint, you are allowed to add **supplementary remarks**\u2014but only under strict rules.\n\n<Supplementary Remark Rules>\n\n1. **Definition**\nA supplementary remark is additional information that may differ from the user's original intent. Because of this, **you must clearly indicate that it is *not* part of the user\u2019s thinking**.\n\n2. **When to Supplement**\n- If the user's input reveals a lack of technical understanding (e.g., suggesting \"put all data into one table\"), and the plan is not an MVP or PoC, it's encouraged to make reasonable additions for a more scalable or robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement the content to ensure completeness.\n\n3. **When Not to Supplement**\n- If the user's input is vague or ambiguous, **do not assume or add extra details**. Instead, it\u2019s better to ask the user follow-up questions to clarify their intent.\n- If the user has made no comment on design, **do not impose design-related decisions** (e.g., colors, fonts, tone). However, you may state explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds value, as such goals are assumed in all services.\n\n</Supplementary Remark Rules>",
+                            description: "# Define prompts to translate user planning requirements into messages for internal agents\n\nThis prompt defines how to convert a user's planning-oriented requirements\ninto a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if\nsome parts of the user's input are inappropriate or insufficient from a\nplanning standpoint, you are allowed to add **supplementary remarks**\u2014but\nonly under strict rules.\n\n# Supplementary Remark Rules\n\n1. **Definition** A supplementary remark is additional information that may\n   differ from the user's original intent. Because of this, **you must\n   clearly indicate that it is _not_ part of the user\u2019s thinking**.\n2. **When to Supplement**\n\n- If the user's input reveals a lack of technical understanding (e.g.,\n  suggesting \"put all data into one table\"), and the plan is not an MVP or\n  PoC, it's encouraged to make reasonable additions for a more scalable or\n  robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement\n  the content to ensure completeness.\n\n3. **When Not to Supplement**\n\n- If the user's input is vague or ambiguous, **do not assume or add extra\n  details**. Instead, it\u2019s better to ask the user follow-up questions to\n  clarify their intent.\n- If the user has made no comment on design, **do not impose design-related\n  decisions** (e.g., colors, fonts, tone). However, you may state\n  explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds\n  value, as such goals are assumed in all services.\n\n# Style Guidelines\n\nThis prompt is delivered to the sub-agent, and several are created for\nparallel processing of the sub-agent. Additionally, there should be a guide\nto style, since sub-agents cannot create different styles of documents due\nto the disconnection of their conversations with each other.\n\nFor example, there should be a hyperlink to the previous document, the next\ndocument, before or after the document, or there should be no more than N\nheadings. The entire content of the document will have requirements, such\nas maintaining informal or formal language.\n\n# Limiting the volume of a document\n\nHowever, do not go beyond the volume guide; each agent only needs to create\none page because the agent receiving this document will be created as many\nas the number of pages.",
                             type: "string"
                         }
                     },
@@ -1076,8 +1066,7 @@ const collection = {
                         },
                         userPlanningRequirements: {
                             type: "string",
-                            title: "This prompt defines how to convert a user's planning-oriented requirements into a structured message for an internal agent",
-                            description: "This prompt defines how to convert a user's planning-oriented requirements into a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if some parts of the user's input are inappropriate or insufficient from a planning standpoint, you are allowed to add **supplementary remarks**\u2014but only under strict rules.\n\n<Supplementary Remark Rules>\n\n1. **Definition**\nA supplementary remark is additional information that may differ from the user's original intent. Because of this, **you must clearly indicate that it is *not* part of the user\u2019s thinking**.\n\n2. **When to Supplement**\n- If the user's input reveals a lack of technical understanding (e.g., suggesting \"put all data into one table\"), and the plan is not an MVP or PoC, it's encouraged to make reasonable additions for a more scalable or robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement the content to ensure completeness.\n\n3. **When Not to Supplement**\n- If the user's input is vague or ambiguous, **do not assume or add extra details**. Instead, it\u2019s better to ask the user follow-up questions to clarify their intent.\n- If the user has made no comment on design, **do not impose design-related decisions** (e.g., colors, fonts, tone). However, you may state explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds value, as such goals are assumed in all services.\n\n</Supplementary Remark Rules>"
+                            description: "# Define prompts to translate user planning requirements into messages for internal agents\n\nThis prompt defines how to convert a user's planning-oriented requirements\ninto a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if\nsome parts of the user's input are inappropriate or insufficient from a\nplanning standpoint, you are allowed to add **supplementary remarks**\u2014but\nonly under strict rules.\n\n# Supplementary Remark Rules\n\n1. **Definition** A supplementary remark is additional information that may\n   differ from the user's original intent. Because of this, **you must\n   clearly indicate that it is _not_ part of the user\u2019s thinking**.\n2. **When to Supplement**\n\n- If the user's input reveals a lack of technical understanding (e.g.,\n  suggesting \"put all data into one table\"), and the plan is not an MVP or\n  PoC, it's encouraged to make reasonable additions for a more scalable or\n  robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement\n  the content to ensure completeness.\n\n3. **When Not to Supplement**\n\n- If the user's input is vague or ambiguous, **do not assume or add extra\n  details**. Instead, it\u2019s better to ask the user follow-up questions to\n  clarify their intent.\n- If the user has made no comment on design, **do not impose design-related\n  decisions** (e.g., colors, fonts, tone). However, you may state\n  explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds\n  value, as such goals are assumed in all services.\n\n# Style Guidelines\n\nThis prompt is delivered to the sub-agent, and several are created for\nparallel processing of the sub-agent. Additionally, there should be a guide\nto style, since sub-agents cannot create different styles of documents due\nto the disconnection of their conversations with each other.\n\nFor example, there should be a hyperlink to the previous document, the next\ndocument, before or after the document, or there should be no more than N\nheadings. The entire content of the document will have requirements, such\nas maintaining informal or formal language.\n\n# Limiting the volume of a document\n\nHowever, do not go beyond the volume guide; each agent only needs to create\none page because the agent receiving this document will be created as many\nas the number of pages."
                         }
                     },
                     required: [
@@ -1160,8 +1149,7 @@ const collection = {
                         },
                         userPlanningRequirements: {
                             type: "string",
-                            title: "This prompt defines how to convert a user's planning-oriented requirements into a structured message for an internal agent",
-                            description: "This prompt defines how to convert a user's planning-oriented requirements into a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if some parts of the user's input are inappropriate or insufficient from a planning standpoint, you are allowed to add **supplementary remarks**\u2014but only under strict rules.\n\n<Supplementary Remark Rules>\n\n1. **Definition**\nA supplementary remark is additional information that may differ from the user's original intent. Because of this, **you must clearly indicate that it is *not* part of the user\u2019s thinking**.\n\n2. **When to Supplement**\n- If the user's input reveals a lack of technical understanding (e.g., suggesting \"put all data into one table\"), and the plan is not an MVP or PoC, it's encouraged to make reasonable additions for a more scalable or robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement the content to ensure completeness.\n\n3. **When Not to Supplement**\n- If the user's input is vague or ambiguous, **do not assume or add extra details**. Instead, it\u2019s better to ask the user follow-up questions to clarify their intent.\n- If the user has made no comment on design, **do not impose design-related decisions** (e.g., colors, fonts, tone). However, you may state explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds value, as such goals are assumed in all services.\n\n</Supplementary Remark Rules>"
+                            description: "# Define prompts to translate user planning requirements into messages for internal agents\n\nThis prompt defines how to convert a user's planning-oriented requirements\ninto a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if\nsome parts of the user's input are inappropriate or insufficient from a\nplanning standpoint, you are allowed to add **supplementary remarks**\u2014but\nonly under strict rules.\n\n# Supplementary Remark Rules\n\n1. **Definition** A supplementary remark is additional information that may\n   differ from the user's original intent. Because of this, **you must\n   clearly indicate that it is _not_ part of the user\u2019s thinking**.\n2. **When to Supplement**\n\n- If the user's input reveals a lack of technical understanding (e.g.,\n  suggesting \"put all data into one table\"), and the plan is not an MVP or\n  PoC, it's encouraged to make reasonable additions for a more scalable or\n  robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement\n  the content to ensure completeness.\n\n3. **When Not to Supplement**\n\n- If the user's input is vague or ambiguous, **do not assume or add extra\n  details**. Instead, it\u2019s better to ask the user follow-up questions to\n  clarify their intent.\n- If the user has made no comment on design, **do not impose design-related\n  decisions** (e.g., colors, fonts, tone). However, you may state\n  explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds\n  value, as such goals are assumed in all services.\n\n# Style Guidelines\n\nThis prompt is delivered to the sub-agent, and several are created for\nparallel processing of the sub-agent. Additionally, there should be a guide\nto style, since sub-agents cannot create different styles of documents due\nto the disconnection of their conversations with each other.\n\nFor example, there should be a hyperlink to the previous document, the next\ndocument, before or after the document, or there should be no more than N\nheadings. The entire content of the document will have requirements, such\nas maintaining informal or formal language.\n\n# Limiting the volume of a document\n\nHowever, do not go beyond the volume guide; each agent only needs to create\none page because the agent receiving this document will be created as many\nas the number of pages."
                         }
                     },
                     required: [
@@ -1244,8 +1232,7 @@ const collection = {
                         },
                         userPlanningRequirements: {
                             type: "string",
-                            title: "This prompt defines how to convert a user's planning-oriented requirements into a structured message for an internal agent",
-                            description: "This prompt defines how to convert a user's planning-oriented requirements into a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if some parts of the user's input are inappropriate or insufficient from a planning standpoint, you are allowed to add **supplementary remarks**\u2014but only under strict rules.\n\n<Supplementary Remark Rules>\n\n1. **Definition**\nA supplementary remark is additional information that may differ from the user's original intent. Because of this, **you must clearly indicate that it is *not* part of the user\u2019s thinking**.\n\n2. **When to Supplement**\n- If the user's input reveals a lack of technical understanding (e.g., suggesting \"put all data into one table\"), and the plan is not an MVP or PoC, it's encouraged to make reasonable additions for a more scalable or robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement the content to ensure completeness.\n\n3. **When Not to Supplement**\n- If the user's input is vague or ambiguous, **do not assume or add extra details**. Instead, it\u2019s better to ask the user follow-up questions to clarify their intent.\n- If the user has made no comment on design, **do not impose design-related decisions** (e.g., colors, fonts, tone). However, you may state explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds value, as such goals are assumed in all services.\n\n</Supplementary Remark Rules>"
+                            description: "# Define prompts to translate user planning requirements into messages for internal agents\n\nThis prompt defines how to convert a user's planning-oriented requirements\ninto a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if\nsome parts of the user's input are inappropriate or insufficient from a\nplanning standpoint, you are allowed to add **supplementary remarks**\u2014but\nonly under strict rules.\n\n# Supplementary Remark Rules\n\n1. **Definition** A supplementary remark is additional information that may\n   differ from the user's original intent. Because of this, **you must\n   clearly indicate that it is _not_ part of the user\u2019s thinking**.\n2. **When to Supplement**\n\n- If the user's input reveals a lack of technical understanding (e.g.,\n  suggesting \"put all data into one table\"), and the plan is not an MVP or\n  PoC, it's encouraged to make reasonable additions for a more scalable or\n  robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement\n  the content to ensure completeness.\n\n3. **When Not to Supplement**\n\n- If the user's input is vague or ambiguous, **do not assume or add extra\n  details**. Instead, it\u2019s better to ask the user follow-up questions to\n  clarify their intent.\n- If the user has made no comment on design, **do not impose design-related\n  decisions** (e.g., colors, fonts, tone). However, you may state\n  explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds\n  value, as such goals are assumed in all services.\n\n# Style Guidelines\n\nThis prompt is delivered to the sub-agent, and several are created for\nparallel processing of the sub-agent. Additionally, there should be a guide\nto style, since sub-agents cannot create different styles of documents due\nto the disconnection of their conversations with each other.\n\nFor example, there should be a hyperlink to the previous document, the next\ndocument, before or after the document, or there should be no more than N\nheadings. The entire content of the document will have requirements, such\nas maintaining informal or formal language.\n\n# Limiting the volume of a document\n\nHowever, do not go beyond the volume guide; each agent only needs to create\none page because the agent receiving this document will be created as many\nas the number of pages."
                         }
                     },
                     required: [
@@ -1328,8 +1315,7 @@ const collection = {
                         },
                         userPlanningRequirements: {
                             type: "string",
-                            title: "This prompt defines how to convert a user's planning-oriented requirements into a structured message for an internal agent",
-                            description: "This prompt defines how to convert a user's planning-oriented requirements into a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if some parts of the user's input are inappropriate or insufficient from a planning standpoint, you are allowed to add **supplementary remarks**\u2014but only under strict rules.\n\n<Supplementary Remark Rules>\n\n1. **Definition**\nA supplementary remark is additional information that may differ from the user's original intent. Because of this, **you must clearly indicate that it is *not* part of the user\u2019s thinking**.\n\n2. **When to Supplement**\n- If the user's input reveals a lack of technical understanding (e.g., suggesting \"put all data into one table\"), and the plan is not an MVP or PoC, it's encouraged to make reasonable additions for a more scalable or robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement the content to ensure completeness.\n\n3. **When Not to Supplement**\n- If the user's input is vague or ambiguous, **do not assume or add extra details**. Instead, it\u2019s better to ask the user follow-up questions to clarify their intent.\n- If the user has made no comment on design, **do not impose design-related decisions** (e.g., colors, fonts, tone). However, you may state explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds value, as such goals are assumed in all services.\n\n</Supplementary Remark Rules>"
+                            description: "# Define prompts to translate user planning requirements into messages for internal agents\n\nThis prompt defines how to convert a user's planning-oriented requirements\ninto a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if\nsome parts of the user's input are inappropriate or insufficient from a\nplanning standpoint, you are allowed to add **supplementary remarks**\u2014but\nonly under strict rules.\n\n# Supplementary Remark Rules\n\n1. **Definition** A supplementary remark is additional information that may\n   differ from the user's original intent. Because of this, **you must\n   clearly indicate that it is _not_ part of the user\u2019s thinking**.\n2. **When to Supplement**\n\n- If the user's input reveals a lack of technical understanding (e.g.,\n  suggesting \"put all data into one table\"), and the plan is not an MVP or\n  PoC, it's encouraged to make reasonable additions for a more scalable or\n  robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement\n  the content to ensure completeness.\n\n3. **When Not to Supplement**\n\n- If the user's input is vague or ambiguous, **do not assume or add extra\n  details**. Instead, it\u2019s better to ask the user follow-up questions to\n  clarify their intent.\n- If the user has made no comment on design, **do not impose design-related\n  decisions** (e.g., colors, fonts, tone). However, you may state\n  explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds\n  value, as such goals are assumed in all services.\n\n# Style Guidelines\n\nThis prompt is delivered to the sub-agent, and several are created for\nparallel processing of the sub-agent. Additionally, there should be a guide\nto style, since sub-agents cannot create different styles of documents due\nto the disconnection of their conversations with each other.\n\nFor example, there should be a hyperlink to the previous document, the next\ndocument, before or after the document, or there should be no more than N\nheadings. The entire content of the document will have requirements, such\nas maintaining informal or formal language.\n\n# Limiting the volume of a document\n\nHowever, do not go beyond the volume guide; each agent only needs to create\none page because the agent receiving this document will be created as many\nas the number of pages."
                         }
                     },
                     required: [
@@ -1412,8 +1398,7 @@ const collection = {
                         },
                         userPlanningRequirements: {
                             type: "string",
-                            title: "This prompt defines how to convert a user's planning-oriented requirements into a structured message for an internal agent",
-                            description: "This prompt defines how to convert a user's planning-oriented requirements into a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if some parts of the user's input are inappropriate or insufficient from a planning standpoint, you are allowed to add **supplementary remarks**\u2014but only under strict rules.\n\n<Supplementary Remark Rules>\n\n1. **Definition**\nA supplementary remark is additional information that may differ from the user's original intent. Because of this, **you must clearly indicate that it is *not* part of the user\u2019s thinking**.\n\n2. **When to Supplement**\n- If the user's input reveals a lack of technical understanding (e.g., suggesting \"put all data into one table\"), and the plan is not an MVP or PoC, it's encouraged to make reasonable additions for a more scalable or robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement the content to ensure completeness.\n\n3. **When Not to Supplement**\n- If the user's input is vague or ambiguous, **do not assume or add extra details**. Instead, it\u2019s better to ask the user follow-up questions to clarify their intent.\n- If the user has made no comment on design, **do not impose design-related decisions** (e.g., colors, fonts, tone). However, you may state explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds value, as such goals are assumed in all services.\n\n</Supplementary Remark Rules>"
+                            description: "# Define prompts to translate user planning requirements into messages for internal agents\n\nThis prompt defines how to convert a user's planning-oriented requirements\ninto a structured message for an internal agent.\n\nAll content the user provides must be included in the message. However, if\nsome parts of the user's input are inappropriate or insufficient from a\nplanning standpoint, you are allowed to add **supplementary remarks**\u2014but\nonly under strict rules.\n\n# Supplementary Remark Rules\n\n1. **Definition** A supplementary remark is additional information that may\n   differ from the user's original intent. Because of this, **you must\n   clearly indicate that it is _not_ part of the user\u2019s thinking**.\n2. **When to Supplement**\n\n- If the user's input reveals a lack of technical understanding (e.g.,\n  suggesting \"put all data into one table\"), and the plan is not an MVP or\n  PoC, it's encouraged to make reasonable additions for a more scalable or\n  robust structure.\n- If there are clear gaps in the user's planning logic, you may supplement\n  the content to ensure completeness.\n\n3. **When Not to Supplement**\n\n- If the user's input is vague or ambiguous, **do not assume or add extra\n  details**. Instead, it\u2019s better to ask the user follow-up questions to\n  clarify their intent.\n- If the user has made no comment on design, **do not impose design-related\n  decisions** (e.g., colors, fonts, tone). However, you may state\n  explicitly that no design requirements were provided.\n- Generic advice like \"UX should be good\" can be omitted unless it adds\n  value, as such goals are assumed in all services.\n\n# Style Guidelines\n\nThis prompt is delivered to the sub-agent, and several are created for\nparallel processing of the sub-agent. Additionally, there should be a guide\nto style, since sub-agents cannot create different styles of documents due\nto the disconnection of their conversations with each other.\n\nFor example, there should be a hyperlink to the previous document, the next\ndocument, before or after the document, or there should be no more than N\nheadings. The entire content of the document will have requirements, such\nas maintaining informal or formal language.\n\n# Limiting the volume of a document\n\nHowever, do not go beyond the volume guide; each agent only needs to create\none page because the agent receiving this document will be created as many\nas the number of pages."
                         }
                     },
                     required: [

package/lib/factory/createAutoBeApplication.js.map

@@ -1 +1 @@
-{"version":3,"file":"createAutoBeApplication.js","sourceRoot":"","sources":["../../src/factory/createAutoBeApplication.ts"],"names":[],"mappings":";;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;AAEA,kDAA0B;AAI1B,oEAAiE;AACjE,wFAAqF;AACrF,0EAAuE;AACvE,0EAAuE;AACvE,oEAAiE;AACjE,+EAA4E;AAC5E,oDAAiD;AAE1C,MAAM,sBAAsB,GAAG,CAAiC,KAGtE,EAAqC,EAAE;IACtC,IAAA,qCAAiB,EAAC,KAAK,CAAC,KAAK,CAAC,CAAC;IAC/B,MAAM,WAAW,GAA2B,UAAU,CACpD,KAAK,CAAC,KAAK,CACyB,CAAC;IACvC,OAAO;QACL,QAAQ,EAAE,OAAO;QACjB,IAAI,EAAE,QAAQ;QACd,WAAW;QACX,OAAO,EAAE;YACP,OAAO,EAAE,CAAO,IAAI,EAAE,EAAE;gBACtB,MAAM,CAAC,GAAG,MAAM,IAAA,uCAAkB,EAAC,KAAK,CAAC,OAAO,CAAC,CAAC,IAAI,CAAC,CAAC;gBACxD,IAAI,CAAC,CAAC,IAAI,KAAK,SAAS;oBACtB,OAAO;wBACL,IAAI,EAAE,SAAS;wBACf,WAAW,EACT,iEAAiE;qBACpE,CAAC;;oBAEF,OAAO;wBACL,IAAI,EAAE,aAAa;wBACnB,WAAW,EAAE,uBAAU,CAAC,IAAI,CAAA;;;aAG3B;qBACF,CAAC;YACN,CAAC,CAAA;YACD,MAAM,EAAE,CAAO,IAAI,EAAE,EAAE;gBACrB,MAAM,CAAC,GAAG,MAAM,IAAA,qCAAiB,EAAC,KAAK,CAAC,OAAO,CAAC,CAAC,IAAI,CAAC,CAAC;gBACvD,IAAI,CAAC,CAAC,IAAI,KAAK,QAAQ;oBACrB,OAAO;wBACL,IAAI,EAAE,CAAC,CAAC,QAAQ,CAAC,IAAI;wBACrB,WAAW,EACT,CAAC,CAAC,QAAQ,CAAC,IAAI,KAAK,SAAS;4BAC3B,CAAC,CAAC,kDAAkD;4BACpD,CAAC,CAAC,CAAC,CAAC,MAAM,CAAC,OAAO,KAAK,KAAK,IAAI,CAAC,CAAC,QAAQ,CAAC,IAAI,KAAK,SAAS;gCAC3D,CAAC,CAAC,uDAAuD;gCACzD,CAAC,CAAC,4DAA4D;qBACrE,CAAC;;oBAEF,OAAO;wBACL,IAAI,EAAE,6BAA6B;wBACnC,WAAW,EAAE,4CAA4C;qBAC1D,CAAC;YACN,CAAC,CAAA;YACD,SAAS,EAAE,CAAO,IAAI,EAAE,EAAE;gBACxB,MAAM,CAAC,GAAG,MAAM,IAAA,2CAAoB,EAAC,KAAK,CAAC,OAAO,CAAC,CAAC,IAAI,CAAC,CAAC;gBAC1D,IAAI,CAAC,CAAC,IAAI,KAAK,WAAW;oBACxB,OAAO;wBACL,IAAI,EAAE,SAAS;wBACf,WAAW,EAAE,iDAAiD;qBAC/D,CAAC;;oBAEF,OAAO;wBACL,IAAI,EAAE,6BAA6B;wBACnC,WAAW,EAAE,uCAAuC;qBACrD,CAAC;YACN,CAAC,CAAA;YACD,IAAI,EAAE,CAAO,IAAI,EAAE,EAAE;gBACnB,MAAM,CAAC,GAAG,MAAM,IAAA,iCAAe,EAAC,KAAK,CAAC,OAAO,CAAC,CAAC,IAAI,CAAC,CAAC;gBACrD,IAAI,CAAC,CAAC,IAAI,KAAK,MAAM;oBACnB,OAAO;wBACL,IAAI,EAAE,CAAC,CAAC,QAAQ,CAAC,IAAI;wBACrB,WAAW,EACT,CAAC,CAAC,QAAQ,CAAC,IAAI,KAAK,SAAS;4BAC3B,CAAC,CAAC,kDAAkD;4BACpD,CAAC,CAAC,CAAC,CAAC,QAAQ,CAAC,IAAI,KAAK,SAAS;gCAC7B,CAAC,CAAC,qDAAqD;gCACvD,CAAC,CAAC,yDAAyD;qBAClE,CAAC;;oBAEF,OAAO;wBACL,IAAI,EAAE,6BAA6B;wBACnC,WAAW,EAAE,uCAAuC;qBACrD,CAAC;YACN,CAAC,CAAA;YACD,OAAO,EAAE,CAAO,IAAI,EAAE,EAAE;gBACtB,MAAM,CAAC,GAAG,MAAM,IAAA,uCAAkB,EAAC,KAAK,CAAC,OAAO,CAAC,CAAC,IAAI,CAAC,CAAC;gBACxD,IAAI,CAAC,CAAC,IAAI,KAAK,SAAS;oBACtB,OAAO;wBACL,IAAI,EAAE,CAAC,CAAC,QAAQ,CAAC,IAAI;wBACrB,WAAW,EACT,CAAC,CAAC,QAAQ,CAAC,IAAI,KAAK,SAAS;4BAC3B,CAAC,CAAC,4DAA4D;4BAC9D,CAAC,CAAC,CAAC,CAAC,QAAQ,CAAC,IAAI,KAAK,SAAS;gCAC7B,CAAC,CAAC,4DAA4D;gCAC9D,CAAC,CAAC,+DAA+D;qBACxE,CAAC;;oBAEF,OAAO;wBACL,IAAI,EAAE,6BAA6B;wBACnC,WAAW,EAAE,uCAAuC;qBACrD,CAAC;YACN,CAAC,CAAA;SAC2B;KAC/B,CAAC;AACJ,CAAC,CAAC;AAnGW,QAAA,sBAAsB,0BAmGjC;AAEF,MAAM,MAAM;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAIT,CAAC;AACJ,MAAM,UAAU,GAAG;IACjB,OAAO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;KAIJ;IACH,MAAM;IACN,KAAK,EAAE,MAAM;IACb,QAAQ,EAAE,MAAM;IAChB,KAAK,EAAE,MAAM;IACb,KAAK;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;KAAoD;CAC1D,CAAC"}
+{"version":3,"file":"createAutoBeApplication.js","sourceRoot":"","sources":["../../src/factory/createAutoBeApplication.ts"],"names":[],"mappings":";;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;AAEA,kDAA0B;AAI1B,oEAAiE;AACjE,wFAAqF;AACrF,0EAAuE;AACvE,0EAAuE;AACvE,oEAAiE;AACjE,+EAA4E;AAC5E,oDAAiD;AAE1C,MAAM,sBAAsB,GAAG,CAAiC,KAGtE,EAAqC,EAAE;IACtC,IAAA,qCAAiB,EAAC,KAAK,CAAC,KAAK,CAAC,CAAC;IAC/B,MAAM,WAAW,GAA2B,UAAU,CACpD,KAAK,CAAC,KAAK,CACyB,CAAC;IACvC,OAAO;QACL,QAAQ,EAAE,OAAO;QACjB,IAAI,EAAE,QAAQ;QACd,WAAW;QACX,OAAO,EAAE;YACP,OAAO,EAAE,CAAO,IAAI,EAAE,EAAE;gBACtB,MAAM,CAAC,GAAG,MAAM,IAAA,uCAAkB,EAAC,KAAK,CAAC,OAAO,CAAC,CAAC,IAAI,CAAC,CAAC;gBACxD,IAAI,CAAC,CAAC,IAAI,KAAK,SAAS;oBACtB,OAAO;wBACL,IAAI,EAAE,SAAS;wBACf,WAAW,EACT,iEAAiE;qBACpE,CAAC;;oBAEF,OAAO;wBACL,IAAI,EAAE,aAAa;wBACnB,WAAW,EAAE,uBAAU,CAAC,IAAI,CAAA;;;aAG3B;qBACF,CAAC;YACN,CAAC,CAAA;YACD,MAAM,EAAE,CAAO,IAAI,EAAE,EAAE;gBACrB,MAAM,CAAC,GAAG,MAAM,IAAA,qCAAiB,EAAC,KAAK,CAAC,OAAO,CAAC,CAAC,IAAI,CAAC,CAAC;gBACvD,IAAI,CAAC,CAAC,IAAI,KAAK,QAAQ;oBACrB,OAAO;wBACL,IAAI,EAAE,CAAC,CAAC,QAAQ,CAAC,IAAI;wBACrB,WAAW,EACT,CAAC,CAAC,QAAQ,CAAC,IAAI,KAAK,SAAS;4BAC3B,CAAC,CAAC,kDAAkD;4BACpD,CAAC,CAAC,CAAC,CAAC,MAAM,CAAC,OAAO,KAAK,KAAK,IAAI,CAAC,CAAC,QAAQ,CAAC,IAAI,KAAK,SAAS;gCAC3D,CAAC,CAAC,uDAAuD;gCACzD,CAAC,CAAC,4DAA4D;qBACrE,CAAC;;oBAEF,OAAO;wBACL,IAAI,EAAE,6BAA6B;wBACnC,WAAW,EAAE,4CAA4C;qBAC1D,CAAC;YACN,CAAC,CAAA;YACD,SAAS,EAAE,CAAO,IAAI,EAAE,EAAE;gBACxB,MAAM,CAAC,GAAG,MAAM,IAAA,2CAAoB,EAAC,KAAK,CAAC,OAAO,CAAC,CAAC,IAAI,CAAC,CAAC;gBAC1D,IAAI,CAAC,CAAC,IAAI,KAAK,WAAW;oBACxB,OAAO;wBACL,IAAI,EAAE,SAAS;wBACf,WAAW,EAAE,iDAAiD;qBAC/D,CAAC;;oBAEF,OAAO;wBACL,IAAI,EAAE,6BAA6B;wBACnC,WAAW,EAAE,uCAAuC;qBACrD,CAAC;YACN,CAAC,CAAA;YACD,IAAI,EAAE,CAAO,IAAI,EAAE,EAAE;gBACnB,MAAM,CAAC,GAAG,MAAM,IAAA,iCAAe,EAAC,KAAK,CAAC,OAAO,CAAC,CAAC,IAAI,CAAC,CAAC;gBACrD,IAAI,CAAC,CAAC,IAAI,KAAK,MAAM;oBACnB,OAAO;wBACL,IAAI,EAAE,CAAC,CAAC,QAAQ,CAAC,IAAI;wBACrB,WAAW,EACT,CAAC,CAAC,QAAQ,CAAC,IAAI,KAAK,SAAS;4BAC3B,CAAC,CAAC,kDAAkD;4BACpD,CAAC,CAAC,CAAC,CAAC,QAAQ,CAAC,IAAI,KAAK,SAAS;gCAC7B,CAAC,CAAC,qDAAqD;gCACvD,CAAC,CAAC,yDAAyD;qBAClE,CAAC;;oBAEF,OAAO;wBACL,IAAI,EAAE,6BAA6B;wBACnC,WAAW,EAAE,uCAAuC;qBACrD,CAAC;YACN,CAAC,CAAA;YACD,OAAO,EAAE,CAAO,IAAI,EAAE,EAAE;gBACtB,MAAM,CAAC,GAAG,MAAM,IAAA,uCAAkB,EAAC,KAAK,CAAC,OAAO,CAAC,CAAC,IAAI,CAAC,CAAC;gBACxD,IAAI,CAAC,CAAC,IAAI,KAAK,SAAS;oBACtB,OAAO;wBACL,IAAI,EAAE,CAAC,CAAC,QAAQ,CAAC,IAAI;wBACrB,WAAW,EACT,CAAC,CAAC,QAAQ,CAAC,IAAI,KAAK,SAAS;4BAC3B,CAAC,CAAC,4DAA4D;4BAC9D,CAAC,CAAC,CAAC,CAAC,QAAQ,CAAC,IAAI,KAAK,SAAS;gCAC7B,CAAC,CAAC,4DAA4D;gCAC9D,CAAC,CAAC,+DAA+D;qBACxE,CAAC;;oBAEF,OAAO;wBACL,IAAI,EAAE,6BAA6B;wBACnC,WAAW,EAAE,uCAAuC;qBACrD,CAAC;YACN,CAAC,CAAA;SAC2B;KAC/B,CAAC;AACJ,CAAC,CAAC;AAnGW,QAAA,sBAAsB,0BAmGjC;AAEF,MAAM,MAAM;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAIT,CAAC;AACJ,MAAM,UAAU,GAAG;IACjB,OAAO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;KAIJ;IACH,MAAM;IACN,KAAK,EAAE,MAAM;IACb,QAAQ,EAAE,MAAM;IAChB,KAAK,EAAE,MAAM;IACb,KAAK;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;KAAoD;CAC1D,CAAC"}