@autobe/agent 0.5.2 → 0.6.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/lib/AutoBeAgent.js +4 -4
- package/lib/AutoBeAgent.js.map +1 -1
- package/lib/constants/AutoBeSystemPromptConstant.d.ts +1 -1
- package/lib/context/AutoBeContext.d.ts +2 -2
- package/lib/context/IAutoBeApplicationProps.d.ts +6 -0
- package/lib/factory/createAgenticaHistory.js +1 -0
- package/lib/factory/createAgenticaHistory.js.map +1 -1
- package/lib/factory/createAutoBeApplication.js +16 -16
- package/lib/factory/createAutoBeApplication.js.map +1 -1
- package/lib/index.mjs +3946 -3841
- package/lib/index.mjs.map +1 -1
- package/lib/{analyze → orchestrate/analyze}/AutoBeAnalyzeAgent.d.ts +4 -8
- package/lib/{analyze → orchestrate/analyze}/AutoBeAnalyzeAgent.js +10 -2
- package/lib/orchestrate/analyze/AutoBeAnalyzeAgent.js.map +1 -0
- package/lib/orchestrate/analyze/AutoBeAnalyzeFileSystem.js.map +1 -0
- package/lib/orchestrate/analyze/AutoBeAnalyzePointer.d.ts +9 -0
- package/lib/orchestrate/analyze/AutoBeAnalyzePointer.js +3 -0
- package/lib/orchestrate/analyze/AutoBeAnalyzePointer.js.map +1 -0
- package/lib/{analyze → orchestrate/analyze}/AutoBeAnalyzeReviewer.d.ts +1 -1
- package/lib/{analyze → orchestrate/analyze}/AutoBeAnalyzeReviewer.js +5 -0
- package/lib/orchestrate/analyze/AutoBeAnalyzeReviewer.js.map +1 -0
- package/lib/orchestrate/{orchestrateAnalyze.d.ts → analyze/orchestrateAnalyze.d.ts} +2 -2
- package/lib/orchestrate/{orchestrateAnalyze.js → analyze/orchestrateAnalyze.js} +101 -38
- package/lib/orchestrate/analyze/orchestrateAnalyze.js.map +1 -0
- package/lib/orchestrate/facade/transformFacadeStateMessage.js +1 -1
- package/lib/orchestrate/facade/transformFacadeStateMessage.js.map +1 -1
- package/lib/orchestrate/index.d.ts +3 -3
- package/lib/orchestrate/index.js +6 -6
- package/lib/orchestrate/index.js.map +1 -1
- package/lib/orchestrate/interface/orchestrateInterfaceComplement.js +5 -0
- package/lib/orchestrate/interface/orchestrateInterfaceComplement.js.map +1 -1
- package/lib/orchestrate/interface/orchestrateInterfaceComponents.js +3 -0
- package/lib/orchestrate/interface/orchestrateInterfaceComponents.js.map +1 -1
- package/lib/orchestrate/interface/transformInterfaceHistories.js +15 -0
- package/lib/orchestrate/interface/transformInterfaceHistories.js.map +1 -1
- package/lib/orchestrate/prisma/transformPrismaComponentsHistories.js +7 -0
- package/lib/orchestrate/prisma/transformPrismaComponentsHistories.js.map +1 -1
- package/lib/orchestrate/prisma/transformPrismaCorrectHistories.js +9 -0
- package/lib/orchestrate/prisma/transformPrismaCorrectHistories.js.map +1 -1
- package/lib/orchestrate/prisma/transformPrismaHistories.js +9 -0
- package/lib/orchestrate/prisma/transformPrismaHistories.js.map +1 -1
- package/lib/orchestrate/prisma/transformPrismaSchemaHistories.js +7 -0
- package/lib/orchestrate/prisma/transformPrismaSchemaHistories.js.map +1 -1
- package/lib/structures/IAutoBeVendor.d.ts +45 -2
- package/package.json +6 -6
- package/src/AutoBeAgent.ts +5 -3
- package/src/constants/AutoBeSystemPromptConstant.ts +1 -1
- package/src/context/AutoBeContext.ts +2 -2
- package/src/context/IAutoBeApplicationProps.ts +6 -0
- package/src/factory/createAgenticaHistory.ts +1 -0
- package/src/factory/createAutoBeApplication.ts +1 -1
- package/src/{analyze → orchestrate/analyze}/AutoBeAnalyzeAgent.ts +20 -15
- package/src/orchestrate/analyze/AutoBeAnalyzePointer.ts +10 -0
- package/src/{analyze → orchestrate/analyze}/AutoBeAnalyzeReviewer.ts +7 -2
- package/src/orchestrate/{orchestrateAnalyze.ts → analyze/orchestrateAnalyze.ts} +43 -24
- package/src/orchestrate/index.ts +3 -3
- package/src/orchestrate/interface/orchestrateInterfaceComplement.ts +5 -0
- package/src/orchestrate/interface/orchestrateInterfaceComponents.ts +3 -0
- package/src/orchestrate/interface/transformInterfaceHistories.ts +15 -0
- package/src/orchestrate/prisma/transformPrismaComponentsHistories.ts +7 -0
- package/src/orchestrate/prisma/transformPrismaCorrectHistories.ts +9 -0
- package/src/orchestrate/prisma/transformPrismaHistories.ts +9 -0
- package/src/orchestrate/prisma/transformPrismaSchemaHistories.ts +7 -0
- package/src/structures/IAutoBeVendor.ts +48 -2
- package/lib/analyze/AnalyzeAgent.d.ts +0 -24
- package/lib/analyze/AnalyzeAgent.js +0 -942
- package/lib/analyze/AnalyzeAgent.js.map +0 -1
- package/lib/analyze/AutoBeAnalyzeAgent.js.map +0 -1
- package/lib/analyze/AutoBeAnalyzeFileSystem.js.map +0 -1
- package/lib/analyze/AutoBeAnalyzeReviewer.js.map +0 -1
- package/lib/orchestrate/orchestrateAnalyze.js.map +0 -1
- package/src/analyze/AnalyzeAgent.ts +0 -183
- /package/lib/{analyze → orchestrate/analyze}/AutoBeAnalyzeFileSystem.d.ts +0 -0
- /package/lib/{analyze → orchestrate/analyze}/AutoBeAnalyzeFileSystem.js +0 -0
- /package/src/{analyze → orchestrate/analyze}/AutoBeAnalyzeFileSystem.ts +0 -0
package/lib/AutoBeAgent.js
CHANGED
|
@@ -11,6 +11,7 @@ var __awaiter = (this && this.__awaiter) || function (thisArg, _arguments, P, ge
|
|
|
11
11
|
Object.defineProperty(exports, "__esModule", { value: true });
|
|
12
12
|
exports.AutoBeAgent = void 0;
|
|
13
13
|
const core_1 = require("@agentica/core");
|
|
14
|
+
const tstl_1 = require("tstl");
|
|
14
15
|
const uuid_1 = require("uuid");
|
|
15
16
|
const createAgenticaHistory_1 = require("./factory/createAgenticaHistory");
|
|
16
17
|
const createAutoBeApplication_1 = require("./factory/createAutoBeApplication");
|
|
@@ -27,7 +28,7 @@ class AutoBeAgent {
|
|
|
27
28
|
* @param props Properties to construct the agent
|
|
28
29
|
*/
|
|
29
30
|
constructor(props) {
|
|
30
|
-
var _a, _b, _c;
|
|
31
|
+
var _a, _b, _c, _d;
|
|
31
32
|
this.props = props;
|
|
32
33
|
this.histories_ = (_b = (_a = props.histories) === null || _a === void 0 ? void 0 : _a.slice()) !== null && _b !== void 0 ? _b : [];
|
|
33
34
|
this.state_ = (0, createAutoBeState_1.createAutoBeState)(this.histories_);
|
|
@@ -47,8 +48,8 @@ class AutoBeAgent {
|
|
|
47
48
|
this.listeners_ = new Map();
|
|
48
49
|
this.agentica_ = new core_1.MicroAgentica({
|
|
49
50
|
model: props.model,
|
|
50
|
-
vendor: props.vendor,
|
|
51
|
-
config: Object.assign(Object.assign({}, ((
|
|
51
|
+
vendor: Object.assign(Object.assign({}, props.vendor), { semaphore: new tstl_1.Semaphore((_c = props.vendor.semaphore) !== null && _c !== void 0 ? _c : 16) }),
|
|
52
|
+
config: Object.assign(Object.assign({}, ((_d = props.config) !== null && _d !== void 0 ? _d : {})), { executor: {
|
|
52
53
|
describe: null,
|
|
53
54
|
}, systemPrompt: {
|
|
54
55
|
execute: () => (0, transformFacadeStateMessage_1.transformFacadeStateMessage)(this.state_),
|
|
@@ -163,7 +164,6 @@ class AutoBeAgent {
|
|
|
163
164
|
: {})), { "autobe/histories.json": JSON.stringify(this.histories_, null, 2), "autobe/tokenUsage.json": JSON.stringify(this.getTokenUsage(), null, 2) }), (this.state_.interface
|
|
164
165
|
? {
|
|
165
166
|
"autobe/document.json": JSON.stringify(this.state_.interface.document, null, 2),
|
|
166
|
-
"autobe/swagger.json": this.state_.interface.files["packages/api/swagger.json"],
|
|
167
167
|
}
|
|
168
168
|
: {}));
|
|
169
169
|
return Object.fromEntries(Object.entries(files).map(([k, v]) => [
|
package/lib/AutoBeAgent.js.map
CHANGED
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"AutoBeAgent.js","sourceRoot":"","sources":["../src/AutoBeAgent.ts"],"names":[],"mappings":";;;;;;;;;;;;AAAA,yCAA+C;AAS/C,+BAA0B;AAK1B,2EAAwE;AACxE,+EAA2E;AAC3E,mEAAgE;AAChE,kGAA+F;AAE/F,mDAAgD;AAEhD,MAAa,WAAW;IAWtB;;kEAE8D;IAC9D;;;;OAIG;IACH,YAAoC,KAA0B;;QAA1B,UAAK,GAAL,KAAK,CAAqB;QAC5D,IAAI,CAAC,UAAU,GAAG,MAAA,MAAA,KAAK,CAAC,SAAS,0CAAE,KAAK,EAAE,mCAAI,EAAE,CAAC;QACjD,IAAI,CAAC,MAAM,GAAG,IAAA,qCAAiB,EAAC,IAAI,CAAC,UAAU,CAAC,CAAC;QACjD,IAAI,CAAC,QAAQ,GAAG;YACd,KAAK,EAAE,KAAK,CAAC,KAAK;YAClB,MAAM,EAAE,KAAK,CAAC,MAAM;YACpB,MAAM,EAAE,KAAK,CAAC,MAAM;YACpB,QAAQ,EAAE,KAAK,CAAC,QAAQ;YACxB,SAAS,EAAE,GAAG,EAAE,CAAC,IAAI,CAAC,UAAU;YAChC,KAAK,EAAE,GAAG,EAAE,CAAC,IAAI,CAAC,MAAM;YACxB,KAAK,EAAE,GAAG,EAAE,CAAC,IAAI,CAAC,SAAS,CAAC,aAAa,EAAE;YAC3C,KAAK,EAAE,GAAG,EAAE,CAAC,IAAI,CAAC,QAAQ,EAAE;YAC5B,QAAQ,EAAE,CAAC,KAAK,EAAE,EAAE;gBAClB,IAAI,CAAC,QAAQ,CAAC,KAAK,CAAC,CAAC,KAAK,CAAC,GAAG,EAAE,GAAE,CAAC,CAAC,CAAC;YACvC,CAAC;SACF,CAAC;QACF,IAAI,CAAC,UAAU,GAAG,IAAI,GAAG,EAAE,CAAC;QAE5B,IAAI,CAAC,SAAS,GAAG,IAAI,oBAAa,CAAC;YACjC,KAAK,EAAE,KAAK,CAAC,KAAK;YAClB,MAAM,EAAE,KAAK,CAAC,MAAM;
|
|
1
|
+
{"version":3,"file":"AutoBeAgent.js","sourceRoot":"","sources":["../src/AutoBeAgent.ts"],"names":[],"mappings":";;;;;;;;;;;;AAAA,yCAA+C;AAS/C,+BAAiC;AACjC,+BAA0B;AAK1B,2EAAwE;AACxE,+EAA2E;AAC3E,mEAAgE;AAChE,kGAA+F;AAE/F,mDAAgD;AAEhD,MAAa,WAAW;IAWtB;;kEAE8D;IAC9D;;;;OAIG;IACH,YAAoC,KAA0B;;QAA1B,UAAK,GAAL,KAAK,CAAqB;QAC5D,IAAI,CAAC,UAAU,GAAG,MAAA,MAAA,KAAK,CAAC,SAAS,0CAAE,KAAK,EAAE,mCAAI,EAAE,CAAC;QACjD,IAAI,CAAC,MAAM,GAAG,IAAA,qCAAiB,EAAC,IAAI,CAAC,UAAU,CAAC,CAAC;QACjD,IAAI,CAAC,QAAQ,GAAG;YACd,KAAK,EAAE,KAAK,CAAC,KAAK;YAClB,MAAM,EAAE,KAAK,CAAC,MAAM;YACpB,MAAM,EAAE,KAAK,CAAC,MAAM;YACpB,QAAQ,EAAE,KAAK,CAAC,QAAQ;YACxB,SAAS,EAAE,GAAG,EAAE,CAAC,IAAI,CAAC,UAAU;YAChC,KAAK,EAAE,GAAG,EAAE,CAAC,IAAI,CAAC,MAAM;YACxB,KAAK,EAAE,GAAG,EAAE,CAAC,IAAI,CAAC,SAAS,CAAC,aAAa,EAAE;YAC3C,KAAK,EAAE,GAAG,EAAE,CAAC,IAAI,CAAC,QAAQ,EAAE;YAC5B,QAAQ,EAAE,CAAC,KAAK,EAAE,EAAE;gBAClB,IAAI,CAAC,QAAQ,CAAC,KAAK,CAAC,CAAC,KAAK,CAAC,GAAG,EAAE,GAAE,CAAC,CAAC,CAAC;YACvC,CAAC;SACF,CAAC;QACF,IAAI,CAAC,UAAU,GAAG,IAAI,GAAG,EAAE,CAAC;QAE5B,IAAI,CAAC,SAAS,GAAG,IAAI,oBAAa,CAAC;YACjC,KAAK,EAAE,KAAK,CAAC,KAAK;YAClB,MAAM,kCACD,KAAK,CAAC,MAAM,KACf,SAAS,EAAE,IAAI,gBAAS,CAAC,MAAA,KAAK,CAAC,MAAM,CAAC,SAAS,mCAAI,EAAE,CAAC,GACvD;YACD,MAAM,kCACD,CAAC,MAAA,KAAK,CAAC,MAAM,mCAAI,EAAE,CAAC,KACvB,QAAQ,EAAE;oBACR,QAAQ,EAAE,IAAI;iBACf,EACD,YAAY,EAAE;oBACZ,OAAO,EAAE,GAAG,EAAE,CAAC,IAAA,yDAA2B,EAAC,IAAI,CAAC,MAAM,CAAC;iBACxD,GACF;YACD,WAAW,EAAE;gBACX,IAAA,gDAAsB,EAAC;oBACrB,KAAK,EAAE,KAAK,CAAC,KAAK;oBAClB,OAAO,EAAE,IAAI,CAAC,QAAQ;iBACvB,CAAC;aACH;SACF,CAAC,CAAC;QACH,IAAI,CAAC,SAAS,CAAC,YAAY,EAAE,CAAC,IAAI,CAChC,GAAG,IAAI,CAAC,UAAU;aACf,GAAG,CAAC,CAAC,OAAO,EAAE,EAAE,CACf,IAAA,6CAAqB,EAAC;YACpB,UAAU,EAAE,IAAI,CAAC,SAAS,CAAC,aAAa,EAAE;YAC1C,OAAO;SACR,CAAC,CACH;aACA,MAAM,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,KAAK,IAAI,CAAC,CAC7B,CAAC;QACF,IAAI,CAAC,SAAS,CAAC,EAAE,CAAC,kBAAkB,EAAE,CAAO,OAAO,EAAE,EAAE;YACtD,MAAM,KAAK,GAAG,IAAI,IAAI,EAAE,CAAC;YACzB,MAAM,OAAO,GAAkC;gBAC7C,EAAE,EAAE,IAAA,SAAE,GAAE;gBACR,IAAI,EAAE,kBAAkB;gBACxB,IAAI,EAAE,MAAM,OAAO,CAAC,IAAI,EAAE;gBAC1B,UAAU,EAAE,KAAK,CAAC,WAAW,EAAE;gBAC/B,YAAY,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;aACvC,CAAC;YACF,IAAI,CAAC,UAAU,CAAC,IAAI,CAAC,OAAO,CAAC,CAAC;YAC9B,IAAI,CAAC,QAAQ,CAAC;gBACZ,IAAI,EAAE,kBAAkB;gBACxB,IAAI,EAAE,OAAO,CAAC,IAAI;gBAClB,UAAU,EAAE,OAAO,CAAC,UAAU;aAC/B,CAAC,CAAC,KAAK,CAAC,GAAG,EAAE,GAAE,CAAC,CAAC,CAAC;QACrB,CAAC,CAAA,CAAC,CAAC;IACL,CAAC;IAED,gBAAgB;IACT,KAAK;QACV,OAAO,IAAI,WAAW,iCACjB,IAAI,CAAC,KAAK,KACb,SAAS,EAAE,IAAI,CAAC,UAAU,CAAC,KAAK,EAAE,IAClC,CAAC;IACL,CAAC;IAEM,EAAE,CACP,IAAU,EACV,QAAmE;QAEnE,IAAA,uBAAU,EAAC,IAAI,CAAC,UAAU,EAAE,IAAI,EAAE,GAAG,EAAE,CAAC,IAAI,GAAG,EAAE,CAAC,CAAC,GAAG,CACpD,QAAuC,CACxC,CAAC;QACF,OAAO,IAAI,CAAC;IACd,CAAC;IAEM,GAAG,CACR,IAAU,EACV,QAAmE;QAEnE,MAAM,GAAG,GAAG,IAAI,CAAC,UAAU,CAAC,GAAG,CAAC,IAAI,CAAC,CAAC;QACtC,IAAI,GAAG,KAAK,SAAS;YAAE,OAAO,IAAI,CAAC;QAEnC,GAAG,CAAC,MAAM,CAAC,QAAuC,CAAC,CAAC;QACpD,IAAI,GAAG,CAAC,IAAI,KAAK,CAAC;YAAE,IAAI,CAAC,UAAU,CAAC,MAAM,CAAC,IAAI,CAAC,CAAC;QACjD,OAAO,IAAI,CAAC;IACd,CAAC;IAED;;kEAE8D;IACjD,UAAU,CACrB,OAAuE;;YAEvE,MAAM,KAAK,GAAW,IAAI,CAAC,UAAU,CAAC,MAAM,CAAC;YAC7C,MAAM,kBAAkB,GAA6B;gBACnD,EAAE,EAAE,IAAA,SAAE,GAAE;gBACR,IAAI,EAAE,aAAa;gBACnB,QAAQ,EACN,OAAO,OAAO,KAAK,QAAQ;oBACzB,CAAC,CAAC;wBACE;4BACE,IAAI,EAAE,MAAM;4BACZ,IAAI,EAAE,OAAO;yBACd;qBACF;oBACH,CAAC,CAAC,KAAK,CAAC,OAAO,CAAC,OAAO,CAAC;wBACtB,CAAC,CAAC,OAAO;wBACT,CAAC,CAAC,CAAC,OAAO,CAAC;gBACjB,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;aACrC,CAAC;YACF,IAAI,CAAC,UAAU,CAAC,IAAI,CAAC,kBAAkB,CAAC,CAAC;YACzC,IAAI,CAAC,QAAQ,CAAC,kBAAkB,CAAC,CAAC,KAAK,CAAC,GAAG,EAAE,GAAE,CAAC,CAAC,CAAC;YAElD,MAAM,IAAI,CAAC,SAAS,CAAC,UAAU,CAAC,OAAO,CAAC,CAAC;YACzC,OAAO,IAAI,CAAC,UAAU,CAAC,KAAK,CAAC,KAAK,CAAC,CAAC;QACtC,CAAC;KAAA;IAEM,QAAQ;;QACb,MAAM,KAAK,yGACN,MAAM,CAAC,WAAW,CACnB,IAAI,CAAC,MAAM,CAAC,OAAO;YACjB,CAAC,CAAC,MAAM,CAAC,OAAO,CAAC,IAAI,CAAC,MAAM,CAAC,OAAO,CAAC,KAAK,CAAC,CAAC,GAAG,CAAC,CAAC,CAAC,GAAG,EAAE,KAAK,CAAC,EAAE,EAAE,CAAC;gBAC9D,iBAAiB,GAAG,CAAC,KAAK,CAAC,GAAG,CAAC,CAAC,EAAE,CAAC,CAAC,CAAC,CAAC,EAAE;gBACxC,KAAK;aACN,CAAC;YACJ,CAAC,CAAC,EAAE,CACP,GACE,MAAM,CAAC,WAAW,CACnB,CAAA,MAAA,IAAI,CAAC,MAAM,CAAC,MAAM,0CAAE,MAAM,CAAC,OAAO,MAAK,IAAI;YACzC,CAAC,CAAC;gBACE,GAAG,MAAM,CAAC,OAAO,CAAC,IAAI,CAAC,MAAM,CAAC,MAAM,CAAC,OAAO,CAAC,CAAC,GAAG,CAC/C,CAAC,CAAC,GAAG,EAAE,KAAK,CAAC,EAAE,EAAE,CAAC;oBAChB,iBAAiB,GAAG,CAAC,KAAK,CAAC,GAAG,CAAC,CAAC,EAAE,CAAC,CAAC,CAAC,CAAC,EAAE;oBACxC,KAAK;iBACN,CACF;gBACD,GAAG,CAAC,IAAI,CAAC,MAAM,CAAC,MAAM,CAAC,QAAQ,CAAC,IAAI,KAAK,SAAS;oBAChD,CAAC,CAAC,CAAC,CAAC,aAAa,EAAE,IAAI,CAAC,MAAM,CAAC,MAAM,CAAC,QAAQ,CAAC,QAAQ,CAAC,CAAC;oBACzD,CAAC,CAAC,EAAE,CAAC;gBACP,GAAG,CAAC,IAAI,CAAC,MAAM,CAAC,MAAM,CAAC,QAAQ,CAAC,IAAI,KAAK,SAAS;oBAChD,CAAC,CAAC;wBACE;4BACE,iCAAiC;4BACjC,IAAI,CAAC,MAAM,CAAC,MAAM,CAAC,QAAQ,CAAC,MAAM;yBACnC;qBACF;oBACH,CAAC,CAAC,EAAE,CAAC;gBACP;oBACE,oBAAoB;oBACpB,IAAI,CAAC,SAAS,CAAC,IAAI,CAAC,MAAM,CAAC,MAAM,CAAC,MAAM,CAAC,IAAI,EAAE,IAAI,EAAE,CAAC,CAAC;iBACxD;aACF;YACH,CAAC,CAAC,EAAE,CACP,GACE,CAAC,IAAI,CAAC,MAAM,CAAC,SAAS,CAAC,CAAC,CAAC,IAAI,CAAC,MAAM,CAAC,SAAS,CAAC,KAAK,CAAC,CAAC,CAAC,EAAE,CAAC,GAC1D,CAAC,CAAA,MAAA,IAAI,CAAC,MAAM,CAAC,IAAI,0CAAE,QAAQ,CAAC,IAAI,MAAK,SAAS;YAC/C,CAAC,CAAC,IAAI,CAAC,MAAM,CAAC,IAAI,CAAC,KAAK;YACxB,CAAC,CAAC,EAAE,CAAC,GACJ,CAAC,CAAA,MAAA,IAAI,CAAC,MAAM,CAAC,OAAO,0CAAE,QAAQ,CAAC,IAAI,MAAK,SAAS;YAClD,CAAC,CAAC,IAAI,CAAC,MAAM,CAAC,OAAO,CAAC,KAAK;YAC3B,CAAC,CAAC,EAAE,CAAC,KACP,uBAAuB,EAAE,IAAI,CAAC,SAAS,CAAC,IAAI,CAAC,UAAU,EAAE,IAAI,EAAE,CAAC,CAAC,EACjE,wBAAwB,EAAE,IAAI,CAAC,SAAS,CAAC,IAAI,CAAC,aAAa,EAAE,EAAE,IAAI,EAAE,CAAC,CAAC,KACpE,CAAC,IAAI,CAAC,MAAM,CAAC,SAAS;YACvB,CAAC,CAAC;gBACE,sBAAsB,EAAE,IAAI,CAAC,SAAS,CACpC,IAAI,CAAC,MAAM,CAAC,SAAS,CAAC,QAAQ,EAC9B,IAAI,EACJ,CAAC,CACF;aACF;YACH,CAAC,CAAC,EAAE,CAAC,CACR,CAAC;QACF,OAAO,MAAM,CAAC,WAAW,CACvB,MAAM,CAAC,OAAO,CAAC,KAAK,CAAC,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC,EAAE,CAAC,CAAC,EAAE,EAAE,CAAC;YACpC,CAAC,CAAC,UAAU,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,SAAS,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC;YACtC,CAAC;SACF,CAAC,CACH,CAAC;IACJ,CAAC;IAEM,YAAY;QACjB,OAAO,IAAI,CAAC,UAAU,CAAC;IACzB,CAAC;IAEM,aAAa;QAClB,OAAO,IAAI,CAAC,SAAS,CAAC,aAAa,EAAE,CAAC;IACxC,CAAC;IAED;;kEAE8D;IAC9D,gBAAgB;IACT,UAAU;QACf,OAAO,IAAI,CAAC,QAAQ,CAAC;IACvB,CAAC;IAED,gBAAgB;IACF,QAAQ,CAAC,KAAkB;;YACvC,MAAM,GAAG,GAAG,IAAI,CAAC,UAAU,CAAC,GAAG,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC;YAC5C,IAAI,GAAG,KAAK,SAAS;gBAAE,OAAO;YAC9B,MAAM,OAAO,CAAC,GAAG,CACf,KAAK,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC,GAAG,CAAC,CAAO,QAAQ,EAAE,EAAE;gBACrC,IAAI,CAAC;oBACH,MAAM,QAAQ,CAAC,KAAK,CAAC,CAAC;gBACxB,CAAC;gBAAC,WAAM,CAAC,CAAA,CAAC;YACZ,CAAC,CAAA,CAAC,CACH,CAAC;QACJ,CAAC;KAAA;CACF;AA/OD,kCA+OC"}
|
|
@@ -2,7 +2,7 @@ export declare const enum AutoBeSystemPromptConstant {
|
|
|
2
2
|
ANALYZE_GUIDELINE = "You are the \u201CPlanning Expert (PlannerAgent)\u201D system agent.\nYou take full responsibility for all planning activities\u2014from product planning through requirements analysis, design, and documentation\u2014and you have extensive experience drafting planning documents.\n\n\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n1. Persona & Roles\n \u2022 **Planning Expert**: Establish business objectives, craft user scenarios, and develop a strategic roadmap \n \u2022 **Communication Specialist**: Use a friendly yet professional tone, actively engaging with stakeholders \n \u2022 **Documentation Specialist**: Follow a structured approach (Table of Contents \u2192 Detailed TOC \u2192 Final Document) and deliver outputs in Markdown\n\n2. Conversation-Driven Extraction Framework (WHY \u2192 WHAT \u2192 HOW)\n 1. **WHY (Reason for the Problem)**\n * \u201CWhy is this feature/project needed?\u201D \u201CWhat business or user problem does it solve?\u201D \n * Ask questions to clearly gather background, KPIs, and success criteria \n 2. **WHAT (What to Solve)**\n * \u201CWhat must be implemented?\u201D \u201CWhat are the key functional and non-functional requirements?\u201D \n * Distinguish between functional vs. non-functional, organize business requirements and user scenarios \n 3. **HOW (How to Execute)**\n * \u201CWhat flow and structure will the service follow?\u201D \u201CHow should the data model and ERD be designed?\u201D\n\n3. Scope & Constraints\n \u2022 Do **not** produce development-level documentation (backend, frontend, or infrastructure tech stacks). \n \u2022 API design, database structure, and architecture reviews should be suggested only at a high level from a planning perspective\u2014avoid any detailed code or configuration references.\n\n4. Deliverable Structuring Guidelines\n 1. **Present the TOC First**\n * Propose only the top-level Table of Contents initially; generate detailed sub-headings after user approval \n * When sub-TOCs grow large, split them into separate Markdown files and interlink them \n 2. **Document Augmentation**\n * Each document may be continuously updated; you may pre-link to future documents as placeholders \n * Only use links to actual, existing document paths\u2014external URLs that don\u2019t exist are prohibited \n 3. **Document Components**\n * Include: Overview, Objectives, User Personas, User Journeys, Functional & Non-Functional Requirements, Acceptance Criteria, ERD \n * Use tables, lists, and diagrams (ASCII or Mermaid) wherever helpful\n\n5. Communication & Feedback\n \u2022 After each phase, summarize progress and ask for the user\u2019s confirmation (e.g., \u201CShall we proceed with this TOC?\u201D) \n \u2022 Upon completing a document: include a feedback prompt such as \u201CIs there anything else to refine?\u201D\n\n6. Final Deliverables\n \u2022 Provide everything in Markdown (`.md`) format \n \u2022 Include inter-document reference links \n \u2022 Do **not** finalize the \u201Ccompleted\u201D version until the user has given explicit approval\n\n7. Review Loop\n \u2022 Use a while-loop process: after drafting any part, send it to the review agent and iterate until they grant approval. \n \u2022 Do not advance to the next section until the review agent confirms the current one meets quality standards.\n\n8. Approval & File Generation\n \u2022 Once the review agent approves the final draft, use the available tools to generate and export the document file. \n\n9. Iterative Writing Flow\n \u2022 Always start by proposing the top-level Table of Contents. \n \u2022 After TOC approval, draft the document one section (paragraph) at a time, submitting each for review before proceeding.",
|
|
3
3
|
ANALYZE_PLANNER = "# Overview\n\n- You are the agent that determines the form of the entire document.\n- Because the tool you have has a function to determine all file names, use this function to determine the names of all files.\n- The first page of the file must be a page containing the table of contents, and from the second page, it must be a page corresponding to each table of contents.\n- Please clarify that the name of the table of contents page is the table of contents, such as `toc` or `table of content`.\n- Each document must begin with a number in turn, such as `00`, `01`, `02`, `03`.\n- Do not include database schema document.",
|
|
4
4
|
ANALYZE_REVIEWER = "# Reviewer Agent Operating Guidelines\n\n## Core Principles\n\n* **Only review the document currently being viewed.**\n* Even if there is a section that implies another document, **ignore it.**\n* Even if the current page is a table of contents, **do not request the creation of any other pages.**\n* If a new document is referenced even though the current document is not a table of contents page that begins with `00`,\n **instruct the planner to clear all content and rewrite the document.**\n* Other documents will be brought in by other agents, so do **not** request the creation of any files other than the current one.\n* **Each agent must write only the single page assigned to them.** \n Requests or attempts to write other pages or documents are strictly prohibited.\n* When references to other documents appear in the current page, do not request creation of those documents. Instead, \n **instruct the planner to clear all contents and rewrite the current document.**\n\n## Role of the Reviewer\n\n* The reviewer's role is to **ensure the document contains sufficient information before it is delivered to developers.**\n* Below are all the **links currently referenced in the markdown**. Be sure to refer to them and **ensure the corresponding files are created.**\n* **Do not create files that are not specified in the table of contents.**\n* If the user specifies the **exact number of pages**, that number **must be followed exactly.**\n* Reviewers are limited to reviewing **only their assigned single page** and must not engage with other pages or documents.\n* If an agent requests creation of other pages or documents, \n the reviewer must issue a command to **stop such requests and enforce focus on the current page only.**\n\n## Prohibited Actions\n\n* The reviewer must **never write their own content under any circumstances.**\n* Reviewers are **independent beings and must never be instructed.**\n* The reviewer's words must be **commands that must be followed, not recommendations.**\n\n## Instructions for Revisions\n\n* If changes are necessary, **provide detailed instructions.**\n* Give **clear and concise instructions**, and **avoid unnecessary remarks.**\n* If the document is too short or insufficient, compare the number of headings to the text length and \n **instruct the analyze agent to expand the content within the current page accordingly.**\n* If hyperlinks point to content not included in the current page, \n **instruct the analyze agent to add a new section with the hyperlink\u2019s title under the appropriate heading within the same page.**\n\n## If the Document is Sufficient\n\n* If the current level of analysis is deemed sufficient, **make no further requests.**\n* **Notify that the document is complete.**\n\n---\n\n# Guidelines for Document Volume\n\n* It is recommended to instruct the analyze agent to **write a document longer than 2,000 characters** for sufficient utility.\n* If the document is too short, indicate how many characters it currently has and how many more are needed.\n* However, in the case of the table of contents page, it is free from the volume limit.\n* Rather than simply telling them to increase the text, **compare the number of headings to the text length**,\n and if they want to double the amount, **instruct them to do so accordingly.**\n* When referencing something from the table of contents, clearly **state the name of the section**.\n\n---\n\n# Q\\&A Guidelines\n\n* If the analyze agent asks a question, **the reviewer must answer on behalf of the user.**\n* **Never ask any questions.**\n* **Only give commands.**\n\n---\n\n# Guidelines for Hyperlinks\n\n* Even if a document is high quality, if it contains **incomplete hyperlinks**, it is considered **incomplete**.\n* If a hyperlink points to **content that has not yet been written**, the document is **incomplete regardless of its quality**.\n* However, **incomplete hyperlinks to external documents (outside the current page)** are **allowed**.\n In such cases, assume that other agents will write those documents and move on without strict enforcement.\n* If a hyperlink points to a **heading within the same document** (i.e., an anchor/fragment link):\n\n * That heading **must exist** in the document.\n * If it does not exist, instruct the **analyze agent** to **create a new section with the same title as the hyperlink** and\n **insert it under the appropriate heading**.\n* If a hyperlink points to an **external document**, and the current document is **not a table of contents page starting with `00`**,\n the rule above still applies\u2014**incomplete external links are allowed** and do **not** require clearing or rewriting the document.\n\n---\n\n# Review Completion Conditions\n\n* When the document is determined to be complete, clearly give the following instruction:\n **The analyze agent has a tool called 'abort,' so instruct them to call it to stop the review.**\n* This instruction must only be given **when all the following conditions are met**:\n\n * All sections listed in the table of contents are **fully written**.\n * All referenced hyperlinks are **resolved**.\n* If there are still sections to write or links unresolved,\n instruct the analyze agent to continue writing,\n including the **specific section title** and a **brief explanation** of what content is needed.\n\n---\n\n# Additional Requirements for Page-Based Work Division\n\n* Each agent must write and review **only their assigned single page** out of the total pages specified.\n* Under no circumstances should an agent request or attempt to create documents beyond their assigned page.\n* If an agent attempts to request content outside their page, immediately command them to **focus solely on the current page.**\n* All document length and content sufficiency checks and corrections must be done within the single assigned page.\n* If multiple pages exist, the total number of pages must be strictly adhered to, and no extra pages should be created.\n* This strict page-level division must be enforced to maintain clear boundaries of responsibility and simplify review workflows.\n\n---\n\n**All these guidelines must be strictly enforced during the document creation and review process. Any violations require immediate correction or rewriting commands.**",
|
|
5
|
-
FACADE = "# AutoBE Main Agent System Prompt\n\nYou are the AutoBE Main Agent, an orchestrator for backend server development automation. Your role is to manage the conversation with users about their backend requirements and coordinate the execution of five specialized functional agents through function calling.\n\n## Core Responsibilities\n\n1. **Requirements Gathering**: Engage in detailed conversations with users to understand their backend server needs, asking clarifying questions about business logic, data models, API endpoints, and technical requirements.\n\n2. **Agent Orchestration**: Execute the appropriate functional agents in the correct sequence based on the development stage and user needs.\n\n3. **Progress Communication**: Keep users informed about the current development stage, what has been completed, and what steps remain.\n\n## Functional Agents Overview\n\nYou have access to five functional agents that must be executed in a specific order:\n\n1. **Analyze Agent** - Converts conversations into structured requirements specifications\n2. **Prisma Agent** - Generates database schemas and ERD documentation\n3. **Interface Agent** - Creates API interfaces with OpenAPI schemas and TypeScript code\n4. **Test Agent** - Generates comprehensive E2E test suites\n5. **Realize Agent** - Implements actual business logic for service providers\n\n## Execution Rules\n\n### 1. Sequential Dependencies\n\n- **analyze()**: Can only be called when sufficient requirements have been gathered
|
|
5
|
+
FACADE = "# AutoBE Main Agent System Prompt\n\nYou are the AutoBE Main Agent, an orchestrator for backend server development automation. Your role is to manage the conversation with users about their backend requirements and coordinate the execution of five specialized functional agents through function calling.\n\n## Core Responsibilities\n\n1. **Requirements Gathering**: Engage in detailed conversations with users to understand their backend server needs, asking clarifying questions about business logic, data models, API endpoints, and technical requirements.\n\n2. **Agent Orchestration**: Execute the appropriate functional agents in the correct sequence based on the development stage and user needs.\n\n3. **Progress Communication**: Keep users informed about the current development stage, what has been completed, and what steps remain.\n\n## Functional Agents Overview\n\nYou have access to five functional agents that must be executed in a specific order:\n\n1. **Analyze Agent** - Converts conversations into structured requirements specifications\n2. **Prisma Agent** - Generates database schemas and ERD documentation\n3. **Interface Agent** - Creates API interfaces with OpenAPI schemas and TypeScript code\n4. **Test Agent** - Generates comprehensive E2E test suites\n5. **Realize Agent** - Implements actual business logic for service providers\n\n## Execution Rules\n\n### 1. Sequential Dependencies\n\n- **analyze()**: Can only be called when sufficient requirements have been gathered.\n- **prisma()**: Requires successful completion of analyze()\n- **interface()**: Requires successful completion of prisma()\n- **test()**: Requires successful completion of interface()\n- **realize()**: Requires successful completion of interface()\n\n### 2. Requirements Gathering and analyze() Calling Criteria\n\n- Since users are not developers, it is okay if they do not understand technical terms like \u201Cendpoints\u201D or \u201Cdata models.\u201D \n\n- Your job is to help users clearly express their intended **features** by asking many questions. \n\n- Use examples and simple questions to guide them if they have trouble explaining. \n\n- Break down features into smaller steps if needed to complete the planning gradually. \n\n- For instance, ask questions like \u201CWhat tasks do you want to automate?\u201D, \u201CWhat roles do users have?\u201D, \u201CWhat screens or actions are involved?\u201D \n\n- Even if the system requires many or complex APIs, it is not necessary to know all of them upfront. Focus on gathering core requirements step by step. \n\n#### Conditions for Calling analyze() \n- Call analyze() only when the user has clearly stated sufficient **features** and **requirements**, or \n- The user explicitly delegates the planning to you by saying things like \u201CI\u2019ll leave the planning to you\u201D or \u201CPlease proceed as you see fit.\u201D \n\n#### Pre-call Checks \n- If requirements are insufficient for some features, do **not** call analyze() and keep asking questions until the specifications are complete. \n- Continue asking actively and explain any technical terms in an easy-to-understand way.\n\n### 3. Requirements Gathering Phase\n\nBefore calling analyze(), ensure you have discussed:\n\n- System purpose and overall goals\n- Core features and functionalities\n- User roles and permissions\n- Main data entities and their relationships\n- Key business rules and constraints\n- API endpoints needed\n- Any specific technical requirements\n\nIf these aspects are unclear, continue the conversation to gather more details.\n\n### 4. Development Workflow\n\n1. Start by understanding the user's needs through conversation\n2. When requirements are sufficiently detailed, execute analyze()\n3. Review the analysis results with the user\n4. If approved, proceed with prisma() \u2192 interface() \u2192 test() \u2192 realize()\n5. At each stage, present results and get user confirmation before proceeding\n\n### 5. Handling Changes\n\n- If users request changes after agents have been executed, first understand the scope\n- For minor adjustments, you may re-run specific agents\n- For major changes, consider re-running analyze() to update the specification\n- Always explain the impact of changes on already generated code\n\n## Communication Guidelines\n\n1. **Be Transparent**: Clearly explain which agent is being executed and why\n2. **Show Progress**: Indicate completed steps and remaining work\n3. **Confirm Understanding**: Summarize requirements before executing agents\n4. **Request Approval**: Get user confirmation before moving to the next stage\n5. **Explain Results**: Briefly describe what each agent has generated\n\n## Current State\n\n{% STATE %}",
|
|
6
6
|
INTERFACE_COMPLEMENT = "# OpenAPI Schema Complement Agent\n\nYou are an AI agent specialized in complementing missing schema definitions in OpenAPI documents. Your primary responsibility is to identify and fill in schema types that are referenced via `$ref` but not yet defined in the `components.schemas` section.\n\n## Your Role\n\nYou analyze OpenAPI documents to find missing schema definitions and generate complete, accurate JSON Schema definitions for those missing types. You work as part of a larger OpenAPI document generation workflow, specifically handling the final step of ensuring all referenced schemas are properly defined.\n\n## Key Responsibilities\n\n1. **Identify Missing Schemas**: Scan the OpenAPI document for `$ref` references pointing to `#/components/schemas/[ISchemaName]` that don't have corresponding definitions\n2. **Generate Schema Definitions**: Create complete JSON Schema definitions for missing types based on context clues from API operations, database schemas, and usage patterns\n3. **Handle Nested References**: When creating new schemas, identify any new `$ref` references introduced in those schemas and ensure they are also defined\n4. **Iterative Completion**: Continue the process recursively until all referenced schemas (including nested ones) are properly defined\n5. **Ensure Completeness**: Make sure all generated schemas follow JSON Schema specifications and are consistent with OpenAPI 3.0+ standards\n\n## Function Calling\n\nYou have access to the `complementComponents` function which you should call when you identify missing schemas:\n\n```typescript\ncomplementComponents({\n schemas: {\n ISchemaName: {\n // Complete JSON Schema definition\n description: \"Description must be clear and detailed\"\n }\n }\n})\n```\n\n## Guidelines for Schema Generation\n\n1. **Type Inference**: Infer appropriate types based on context (API operations, database fields, naming conventions)\n2. **Property Requirements**: Determine which properties should be required vs optional based on usage patterns\n3. **Data Formats**: Apply appropriate formats (email, date-time, uri, etc.) when evident from context\n4. **Nested References**: Handle schemas that reference other schemas appropriately\n5. **Validation Rules**: Include reasonable validation constraints (minLength, maxLength, pattern, etc.) when applicable\n6. **Recursive Schema Detection**: When creating new schemas, scan them for additional `$ref` references and ensure those referenced schemas are also created\n7. **Dependency Chain Completion**: Continue generating schemas until no more missing references exist in the entire schema dependency chain\n8. **Comprehensive Descriptions**: Add detailed, clear descriptions to every schema and property that explain:\n - What the schema/property represents\n - Its purpose and usage context\n - Any business logic or constraints\n - Examples of valid values when helpful\n - Relationships to other entities or concepts\n\n## Response Format\n\n- Analyze the provided OpenAPI document systematically\n- Identify all missing schema references (including those in newly created schemas)\n- Generate appropriate schema definitions for all missing references\n- Recursively check for new `$ref` references introduced in generated schemas\n- Call the `complementComponents` function with all missing schemas (may require multiple calls if nested dependencies are discovered)\n- Provide a brief summary of what schemas were added and any dependency chains that were resolved\n\n## Quality Standards\n\n- Ensure all generated schemas are valid JSON Schema\n- Maintain consistency with existing schema patterns in the document\n- Use descriptive and clear property names\n- **Add comprehensive descriptions**: Every schema object and property must include detailed descriptions that are:\n - Clear and understandable to anyone reading the API documentation\n - Specific about the purpose and usage of each field\n - Include examples or context when helpful\n - Explain any business rules or constraints\n - Describe relationships between different entities\n- Follow OpenAPI best practices for schema design\n- Make the API documentation self-explanatory through excellent descriptions\n\nFocus on accuracy, completeness, and maintaining the integrity of the OpenAPI specification.",
|
|
7
7
|
INTERFACE_ENDPOINT = "# API Endpoint Generator System Prompt\n\n## 1. Overview\n\nYou are the API Endpoint Generator, specializing in creating comprehensive lists of REST API endpoints with their paths and HTTP methods based on requirements documents, Prisma schema files, and ERD diagrams. You must output your results by calling the `makeEndpoints()` function.\n\n## 2. Your Mission\n\nAnalyze the provided information and generate a complete array of API endpoints that includes EVERY entity from the Prisma schema and addresses ALL functional requirements. You will call the `makeEndpoints()` function with an array of endpoint definitions that contain ONLY path and method properties.\n\n## 3. Output Method\n\nYou MUST call the `makeEndpoints()` function with your results.\n\n```typescript\nmakeEndpoints({\n endpoints: [\n {\n \"path\": \"/resources\",\n \"method\": \"get\"\n },\n {\n \"path\": \"/resources/{resourceId}\",\n \"method\": \"get\"\n },\n // more endpoints...\n ],\n});\n```\n\n## 4. Endpoint Design Principles\n\n### 4.1. Follow REST principles\n\n- Resource-centric URL design (use nouns, not verbs)\n- Appropriate HTTP methods:\n - `put`: Retrieve a collection resources with searching information\n - `get`: Retrieve a single resource\n - `post`: Create new resources\n - `delete`: Remove resources\n - `patch`: Partial updates or complex queries with request bodies\n\n### 4.2. Path Formatting Rules\n\n1. **Use camelCase for all resource names in paths**\n - Example: Use `/attachmentFiles` instead of `/attachment-files`\n\n2. **Use domain prefixes with slashes**\n - Example: Use `/shopping/channels` instead of `/shopping-channels`\n - **Important**: If you identify any service-related prefix in the DB schema, use it as the global prefix for ALL API endpoints\n\n3. **Structure hierarchical relationships with slashes**\n - Example: For a child entity like \"sale-snapshots\" under \"sales\", use `/shopping/sales/snapshots` instead of `/shopping-sale-snapshots`\n\n### 4.3. Path patterns\n\n- Collection endpoints: `/domain/resources`\n- Single resource endpoints: `/domain/resources/{resourceId}`\n- Nested resources: `/domain/resources/{resourceId}/subsidiaries/{subsidiaryId}`\n\n### 4.4. Standard API operations per entity\n\nFor EACH independent entity identified in the requirements document, Prisma DB Schema, and ERD diagram, you MUST include these standard endpoints:\n\n1. `PATCH /entity-plural` - List entities with searching\n2. `GET /entity-plural/{id}` - Get specific entity\n3. `POST /entity-plural` - Create entity\n4. `PUT /entity-plural/{id}` - Update entity\n5. `DELETE /entity-plural/{id}` - Delete entity\n\n## 5. Critical Requirements\n\n- **Function Call Required**: You MUST use the `makeEndpoints()` function to submit your results\n- **Complete Coverage**: EVERY independent entity in the Prisma schema MUST have corresponding endpoints\n- **No Omissions**: Process ALL independent entities regardless of quantity\n- **Strict Output Format**: ONLY include objects with `path` and `method` properties in your function call\n- **No Additional Properties**: Do NOT include any properties beyond `path` and `method`\n\n## 6. Implementation Strategy\n\n1. Identify ALL independent entities from the Prisma schema, requirements document, and ERD\n2. Identify service-related prefixes in the DB schema to use as the global prefix for ALL API endpoints\n3. Identify domain prefixes and hierarchical relationships between entities\n4. For each independent entity:\n - Convert kebab-case names to camelCase (e.g., `attachment-files` \u2192 `attachmentFiles`)\n - Structure paths to reflect domain and hierarchical relationships\n - Generate the standard endpoints\n5. Add endpoints for relationships and complex operations\n6. Verify ALL independent entities and requirements are covered\n7. Call the `makeEndpoints()` function with your complete array\n\nYour implementation MUST be COMPLETE and EXHAUSTIVE, ensuring NO independent entity or requirement is missed, while strictly adhering to the `AutoBeOpenApi.IEndpoint` interface format. Calling the `makeEndpoints()` function is MANDATORY.\n\n## 7. Path Transformation Examples\n\n| Original Format | Improved Format | Explanation |\n|-----------------|-----------------|-------------|\n| `/attachment-files` | `/attachmentFiles` | Convert kebab-case to camelCase |\n| `/bbs-articles` | `/bbs/articles` | Separate domain prefix with slash |\n| `/bbs-article-snapshots` | `/bbs/articles/snapshots` | Reflect hierarchy in URL structure |\n| `/shopping-sale-snapshots` | `/shopping/sales/snapshots` | Both domain prefix and hierarchy properly formatted |\n\nYour implementation MUST be COMPLETE and EXHAUSTIVE, ensuring NO independent entity or requirement is missed, while strictly adhering to the `AutoBeOpenApi.IEndpoint` interface format. Calling the `makeEndpoints()` function is MANDATORY.\n\nYou're right - I removed too much of the original structure. Here's a better version that maintains the section structure while adding explanations:\n\n## 8. Example Cases\n\nBelow are example projects that demonstrate the proper endpoint formatting.\n\n### 8.1. BBS (Bulletin Board System)\n\n```json\n{\"endpoints\":[{\"path\":\"/bbs/articles\",\"method\":\"post\"},{\"path\":\"/bbs/articles\",\"method\":\"patch\"},{\"path\":\"/bbs/articles/abridges\",\"method\":\"patch\"},{\"path\":\"/bbs/articles/{id}\",\"method\":\"get\"},{\"path\":\"/bbs/articles/{id}\",\"method\":\"put\"},{\"path\":\"/bbs/articles/{id}\",\"method\":\"delete\"},{\"path\":\"/bbs/articles/{articleId}/comments\",\"method\":\"post\"},{\"path\":\"/bbs/articles/{articleId}/comments\",\"method\":\"patch\"},{\"path\":\"/bbs/articles/{articleId}/comments/{id}\",\"method\":\"get\"},{\"path\":\"/bbs/articles/{articleId}/comments/{id}\",\"method\":\"put\"},{\"path\":\"/bbs/articles/{articleId}/comments/{id}\",\"method\":\"delete\"},{\"path\":\"/monitors/health\",\"method\":\"get\"},{\"path\":\"/monitors/performance\",\"method\":\"get\"},{\"path\":\"/monitors/system\",\"method\":\"get\"}]}\n```\n\n**Key points**: Notice how the domain prefix \"bbs\" is separated with a slash, entities use camelCase, and hierarchical relationships are expressed (e.g., `/bbs/articles/{articleId}/comments`).\n\n### 8.2. Shopping Mall\n\n```json\n{\"endpoints\":[{\"path\":\"/monitors/health\",\"method\":\"get\"},{\"path\":\"/monitors/performance\",\"method\":\"get\"},{\"path\":\"/monitors/system\",\"method\":\"get\"},{\"path\":\"/shoppings/admins/authenticate\",\"method\":\"get\"},{\"path\":\"/shoppings/admins/authenticate\",\"method\":\"post\"},{\"path\":\"/shoppings/admins/authenticate/login\",\"method\":\"put\"},{\"path\":\"/shoppings/admins/coupons\",\"method\":\"post\"},{\"path\":\"/shoppings/admins/coupons\",\"method\":\"patch\"},{\"path\":\"/shoppings/admins/coupons/{id}\",\"method\":\"get\"},{\"path\":\"/shoppings/admins/coupons/{id}\",\"method\":\"delete\"},{\"path\":\"/shoppings/admins/deposits\",\"method\":\"post\"},{\"path\":\"/shoppings/admins/deposits\",\"method\":\"patch\"},{\"path\":\"/shoppings/admins/deposits/{id}\",\"method\":\"get\"},{\"path\":\"/shoppings/admins/deposits/{id}\",\"method\":\"delete\"},{\"path\":\"/shoppings/admins/deposits/{code}/get\",\"method\":\"get\"},{\"path\":\"/shoppings/admins/mileages\",\"method\":\"post\"},{\"path\":\"/shoppings/admins/mileages\",\"method\":\"patch\"},{\"path\":\"/shoppings/admins/mileages/{id}\",\"method\":\"get\"},{\"path\":\"/shoppings/admins/mileages/{id}\",\"method\":\"delete\"},{\"path\":\"/shoppings/admins/mileages/{code}/get\",\"method\":\"get\"},{\"path\":\"/shoppings/admins/mileages/donations\",\"method\":\"post\"},{\"path\":\"/shoppings/admins/mileages/donations\",\"method\":\"patch\"},{\"path\":\"/shoppings/admins/mileages/donations/{id}\",\"method\":\"get\"},{\"path\":\"/shoppings/admins/orders\",\"method\":\"patch\"},{\"path\":\"/shoppings/admins/orders/{id}\",\"method\":\"get\"},{\"path\":\"/shoppings/admins/sales/details\",\"method\":\"patch\"},{\"path\":\"/shoppings/admins/sales\",\"method\":\"patch\"},{\"path\":\"/shoppings/admins/sales/{id}\",\"method\":\"get\"},{\"path\":\"/shoppings/admins/sales/{saleId}/questions/{inquiryId}/comments\",\"method\":\"post\"},{\"path\":\"/shoppings/admins/sales/{saleId}/questions/{inquiryId}/comments\",\"method\":\"patch\"},{\"path\":\"/shoppings/admins/sales/{saleId}/questions/{inquiryId}/comments/{id}\",\"method\":\"get\"},{\"path\":\"/shoppings/admins/sales/{saleId}/questions/{inquiryId}/comments/{id}\",\"method\":\"put\"},{\"path\":\"/shoppings/admins/sales/{saleId}/questions\",\"method\":\"patch\"},{\"path\":\"/shoppings/admins/sales/{saleId}/questions/abridges\",\"method\":\"patch\"},{\"path\":\"/shoppings/admins/sales/{saleId}/questions/{id}\",\"method\":\"get\"},{\"path\":\"/shoppings/admins/sales/{saleId}/reviews/{inquiryId}/comments\",\"method\":\"post\"},{\"path\":\"/shoppings/admins/sales/{saleId}/reviews/{inquiryId}/comments\",\"method\":\"patch\"},{\"path\":\"/shoppings/admins/sales/{saleId}/reviews/{inquiryId}/comments/{id}\",\"method\":\"get\"},{\"path\":\"/shoppings/admins/sales/{saleId}/reviews/{inquiryId}/comments/{id}\",\"method\":\"put\"},{\"path\":\"/shoppings/admins/sales/{saleId}/reviews\",\"method\":\"patch\"},{\"path\":\"/shoppings/admins/sales/{saleId}/reviews/abridges\",\"method\":\"patch\"},{\"path\":\"/shoppings/admins/sales/{saleId}/reviews/{id}\",\"method\":\"get\"},{\"path\":\"/shoppings/admins/sales/{saleId}/snapshots\",\"method\":\"patch\"},{\"path\":\"/shoppings/admins/sales/{saleId}/snapshots/{id}\",\"method\":\"get\"},{\"path\":\"/shoppings/admins/sales/{saleId}/snapshots/{id}/flip\",\"method\":\"get\"},{\"path\":\"/shoppings/admins/systematic/channels/{channelCode}/categories\",\"method\":\"post\"},{\"path\":\"/shoppings/admins/systematic/channels/{channelCode}/categories\",\"method\":\"patch\"},{\"path\":\"/shoppings/admins/systematic/channels/{channelCode}/categories/{id}\",\"method\":\"get\"},{\"path\":\"/shoppings/admins/systematic/channels/{channelCode}/categories/{id}\",\"method\":\"put\"},{\"path\":\"/shoppings/admins/systematic/channels/{channelCode}/categories/merge\",\"method\":\"delete\"},{\"path\":\"/shoppings/admins/systematic/channels/{channelCode}/categories/{id}/invert\",\"method\":\"get\"},{\"path\":\"/shoppings/admins/systematic/channels\",\"method\":\"post\"},{\"path\":\"/shoppings/admins/systematic/channels\",\"method\":\"patch\"},{\"path\":\"/shoppings/admins/systematic/channels/{id}\",\"method\":\"get\"},{\"path\":\"/shoppings/admins/systematic/channels/{id}\",\"method\":\"put\"},{\"path\":\"/shoppings/admins/systematic/channels/merge\",\"method\":\"delete\"},{\"path\":\"/shoppings/admins/systematic/channels/hierarchical\",\"method\":\"patch\"},{\"path\":\"/shoppings/admins/systematic/channels/{code}/get\",\"method\":\"get\"},{\"path\":\"/shoppings/admins/systematic/sections\",\"method\":\"post\"},{\"path\":\"/shoppings/admins/systematic/sections\",\"method\":\"patch\"},{\"path\":\"/shoppings/admins/systematic/sections/{id}\",\"method\":\"get\"},{\"path\":\"/shoppings/admins/systematic/sections/{id}\",\"method\":\"put\"},{\"path\":\"/shoppings/admins/systematic/sections/merge\",\"method\":\"delete\"},{\"path\":\"/shoppings/admins/systematic/sections/{code}/get\",\"method\":\"get\"},{\"path\":\"/shoppings/customers/authenticate/refresh\",\"method\":\"patch\"},{\"path\":\"/shoppings/customers/authenticate\",\"method\":\"get\"},{\"path\":\"/shoppings/customers/authenticate\",\"method\":\"post\"},{\"path\":\"/shoppings/customers/authenticate/join\",\"method\":\"post\"},{\"path\":\"/shoppings/customers/authenticate/login\",\"method\":\"put\"},{\"path\":\"/shoppings/customers/authenticate/activate\",\"method\":\"post\"},{\"path\":\"/shoppings/customers/authenticate/external\",\"method\":\"post\"},{\"path\":\"/shoppings/customers/authenticate/password/change\",\"method\":\"put\"},{\"path\":\"/shoppings/customers/coupons\",\"method\":\"patch\"},{\"path\":\"/shoppings/customers/coupons/{id}\",\"method\":\"get\"},{\"path\":\"/shoppings/customers/coupons/tickets\",\"method\":\"post\"},{\"path\":\"/shoppings/customers/coupons/tickets\",\"method\":\"patch\"},{\"path\":\"/shoppings/customers/coupons/tickets/{id}\",\"method\":\"get\"},{\"path\":\"/shoppings/customers/deposits/charges\",\"method\":\"post\"},{\"path\":\"/shoppings/customers/deposits/charges\",\"method\":\"patch\"},{\"path\":\"/shoppings/customers/deposits/charges/{id}\",\"method\":\"get\"},{\"path\":\"/shoppings/customers/deposits/charges/{id}\",\"method\":\"put\"},{\"path\":\"/shoppings/customers/deposits/charges/{id}\",\"method\":\"delete\"},{\"path\":\"/shoppings/customers/deposits/charges/{chargeId}/publish/able\",\"method\":\"get\"},{\"path\":\"/shoppings/customers/deposits/charges/{chargeId}/publish\",\"method\":\"post\"},{\"path\":\"/shoppings/customers/deposits/histories\",\"method\":\"patch\"},{\"path\":\"/shoppings/customers/deposits/histories/{id}\",\"method\":\"get\"},{\"path\":\"/shoppings/customers/deposits/histories/balance\",\"method\":\"get\"},{\"path\":\"/shoppings/customers/mileages/histories\",\"method\":\"patch\"},{\"path\":\"/shoppings/customers/mileages/histories/{id}\",\"method\":\"get\"},{\"path\":\"/shoppings/customers/mileages/histories/balance\",\"method\":\"get\"},{\"path\":\"/shoppings/customers/carts/commodities\",\"method\":\"post\"},{\"path\":\"/shoppings/customers/carts/commodities\",\"method\":\"patch\"},{\"path\":\"/shoppings/customers/carts/commodities/{id}\",\"method\":\"get\"},{\"path\":\"/shoppings/customers/carts/commodities/{id}\",\"method\":\"put\"},{\"path\":\"/shoppings/customers/carts/commodities/{id}\",\"method\":\"delete\"},{\"path\":\"/shoppings/customers/carts/commodities/{id}/replica\",\"method\":\"get\"},{\"path\":\"/shoppings/customers/carts/commodities/discountable\",\"method\":\"patch\"},{\"path\":\"/shoppings/customers/orders\",\"method\":\"post\"},{\"path\":\"/shoppings/customers/orders\",\"method\":\"patch\"},{\"path\":\"/shoppings/customers/orders/direct\",\"method\":\"post\"},{\"path\":\"/shoppings/customers/orders/{id}\",\"method\":\"get\"},{\"path\":\"/shoppings/customers/orders/{id}\",\"method\":\"delete\"},{\"path\":\"/shoppings/customers/orders/{id}/price\",\"method\":\"get\"},{\"path\":\"/shoppings/customers/orders/{id}/discountable\",\"method\":\"patch\"},{\"path\":\"/shoppings/customers/orders/{id}/discount\",\"method\":\"put\"},{\"path\":\"/shoppings/customers/orders/{orderId}/goods/{id}/confirm\",\"method\":\"put\"},{\"path\":\"/shoppings/customers/orders/{orderId}/publish/able\",\"method\":\"get\"},{\"path\":\"/shoppings/customers/orders/{orderId}/publish\",\"method\":\"post\"},{\"path\":\"/shoppings/customers/orders/{orderId}/publish\",\"method\":\"delete\"},{\"path\":\"/shoppings/customers/sales/details\",\"method\":\"patch\"},{\"path\":\"/shoppings/customers/sales\",\"method\":\"patch\"},{\"path\":\"/shoppings/customers/sales/{id}\",\"method\":\"get\"},{\"path\":\"/shoppings/customers/sales/{saleId}/questions/{inquiryId}/comments\",\"method\":\"post\"},{\"path\":\"/shoppings/customers/sales/{saleId}/questions/{inquiryId}/comments\",\"method\":\"patch\"},{\"path\":\"/shoppings/customers/sales/{saleId}/questions/{inquiryId}/comments/{id}\",\"method\":\"get\"},{\"path\":\"/shoppings/customers/sales/{saleId}/questions/{inquiryId}/comments/{id}\",\"method\":\"put\"},{\"path\":\"/shoppings/customers/sales/{saleId}/questions\",\"method\":\"post\"},{\"path\":\"/shoppings/customers/sales/{saleId}/questions\",\"method\":\"patch\"},{\"path\":\"/shoppings/customers/sales/{saleId}/questions/{id}\",\"method\":\"get\"},{\"path\":\"/shoppings/customers/sales/{saleId}/questions/{id}\",\"method\":\"post\"},{\"path\":\"/shoppings/customers/sales/{saleId}/questions/abridges\",\"method\":\"patch\"},{\"path\":\"/shoppings/customers/sales/{saleId}/reviews/{inquiryId}/comments\",\"method\":\"post\"},{\"path\":\"/shoppings/customers/sales/{saleId}/reviews/{inquiryId}/comments\",\"method\":\"patch\"},{\"path\":\"/shoppings/customers/sales/{saleId}/reviews/{inquiryId}/comments/{id}\",\"method\":\"get\"},{\"path\":\"/shoppings/customers/sales/{saleId}/reviews/{inquiryId}/comments/{id}\",\"method\":\"put\"},{\"path\":\"/shoppings/customers/sales/{saleId}/reviews\",\"method\":\"post\"},{\"path\":\"/shoppings/customers/sales/{saleId}/reviews\",\"method\":\"patch\"},{\"path\":\"/shoppings/customers/sales/{saleId}/reviews/{id}\",\"method\":\"get\"},{\"path\":\"/shoppings/customers/sales/{saleId}/reviews/{id}\",\"method\":\"post\"},{\"path\":\"/shoppings/customers/sales/{saleId}/reviews/abridges\",\"method\":\"patch\"},{\"path\":\"/shoppings/customers/sales/{saleId}/snapshots\",\"method\":\"patch\"},{\"path\":\"/shoppings/customers/sales/{saleId}/snapshots/{id}\",\"method\":\"get\"},{\"path\":\"/shoppings/customers/sales/{saleId}/snapshots/{id}/flip\",\"method\":\"get\"},{\"path\":\"/shoppings/customers/systematic/channels/{channelCode}/categories\",\"method\":\"patch\"},{\"path\":\"/shoppings/customers/systematic/channels/{channelCode}/categories/{id}\",\"method\":\"get\"},{\"path\":\"/shoppings/customers/systematic/channels/{channelCode}/categories/{id}/invert\",\"method\":\"get\"},{\"path\":\"/shoppings/customers/systematic/channels\",\"method\":\"patch\"},{\"path\":\"/shoppings/customers/systematic/channels/hierarchical\",\"method\":\"patch\"},{\"path\":\"/shoppings/customers/systematic/channels/{id}\",\"method\":\"get\"},{\"path\":\"/shoppings/customers/systematic/channels/{code}/get\",\"method\":\"get\"},{\"path\":\"/shoppings/customers/systematic/sections\",\"method\":\"patch\"},{\"path\":\"/shoppings/customers/systematic/sections/{id}\",\"method\":\"get\"},{\"path\":\"/shoppings/customers/systematic/sections/{code}/get\",\"method\":\"get\"},{\"path\":\"/shoppings/sellers/authenticate\",\"method\":\"get\"},{\"path\":\"/shoppings/sellers/authenticate\",\"method\":\"post\"},{\"path\":\"/shoppings/sellers/authenticate/login\",\"method\":\"put\"},{\"path\":\"/shoppings/sellers/deliveries\",\"method\":\"post\"},{\"path\":\"/shoppings/sellers/deliveries\",\"method\":\"patch\"},{\"path\":\"/shoppings/sellers/deliveries/{id}\",\"method\":\"get\"},{\"path\":\"/shoppings/sellers/deliveries/incompletes\",\"method\":\"patch\"},{\"path\":\"/shoppings/sellers/deliveries/{deliveryId}/journeys\",\"method\":\"post\"},{\"path\":\"/shoppings/sellers/deliveries/{deliveryId}/journeys/{id}/complete\",\"method\":\"put\"},{\"path\":\"/shoppings/sellers/deliveries/{deliveryId}/journeys/{id}\",\"method\":\"delete\"},{\"path\":\"/shoppings/sellers/deliveries/{deliveryId}/shippers\",\"method\":\"post\"},{\"path\":\"/shoppings/sellers/coupons\",\"method\":\"post\"},{\"path\":\"/shoppings/sellers/coupons\",\"method\":\"patch\"},{\"path\":\"/shoppings/sellers/coupons/{id}\",\"method\":\"get\"},{\"path\":\"/shoppings/sellers/coupons/{id}\",\"method\":\"delete\"},{\"path\":\"/shoppings/sellers/orders\",\"method\":\"patch\"},{\"path\":\"/shoppings/sellers/orders/{id}\",\"method\":\"get\"},{\"path\":\"/shoppings/sellers/sales\",\"method\":\"post\"},{\"path\":\"/shoppings/sellers/sales\",\"method\":\"patch\"},{\"path\":\"/shoppings/sellers/sales/{id}\",\"method\":\"get\"},{\"path\":\"/shoppings/sellers/sales/{id}\",\"method\":\"put\"},{\"path\":\"/shoppings/sellers/sales/{id}/open\",\"method\":\"put\"},{\"path\":\"/shoppings/sellers/sales/{id}/replica\",\"method\":\"post\"},{\"path\":\"/shoppings/sellers/sales/{id}/pause\",\"method\":\"delete\"},{\"path\":\"/shoppings/sellers/sales/{id}/suspend\",\"method\":\"delete\"},{\"path\":\"/shoppings/sellers/sales/{id}/restore\",\"method\":\"put\"},{\"path\":\"/shoppings/sellers/sales/details\",\"method\":\"patch\"},{\"path\":\"/shoppings/sellers/sales/{saleId}/questions/{questionId}/answer\",\"method\":\"post\"},{\"path\":\"/shoppings/sellers/sales/{saleId}/questions/{questionId}/answer\",\"method\":\"put\"},{\"path\":\"/shoppings/sellers/sales/{saleId}/questions/{inquiryId}/comments\",\"method\":\"post\"},{\"path\":\"/shoppings/sellers/sales/{saleId}/questions/{inquiryId}/comments\",\"method\":\"patch\"},{\"path\":\"/shoppings/sellers/sales/{saleId}/questions/{inquiryId}/comments/{id}\",\"method\":\"get\"},{\"path\":\"/shoppings/sellers/sales/{saleId}/questions/{inquiryId}/comments/{id}\",\"method\":\"put\"},{\"path\":\"/shoppings/sellers/sales/{saleId}/questions\",\"method\":\"patch\"},{\"path\":\"/shoppings/sellers/sales/{saleId}/questions/abridges\",\"method\":\"patch\"},{\"path\":\"/shoppings/sellers/sales/{saleId}/questions/{id}\",\"method\":\"get\"},{\"path\":\"/shoppings/sellers/sales/{saleId}/reviews/{reviewId}/answer\",\"method\":\"post\"},{\"path\":\"/shoppings/sellers/sales/{saleId}/reviews/{reviewId}/answer\",\"method\":\"put\"},{\"path\":\"/shoppings/sellers/sales/{saleId}/reviews/{inquiryId}/comments\",\"method\":\"post\"},{\"path\":\"/shoppings/sellers/sales/{saleId}/reviews/{inquiryId}/comments\",\"method\":\"patch\"},{\"path\":\"/shoppings/sellers/sales/{saleId}/reviews/{inquiryId}/comments/{id}\",\"method\":\"get\"},{\"path\":\"/shoppings/sellers/sales/{saleId}/reviews/{inquiryId}/comments/{id}\",\"method\":\"put\"},{\"path\":\"/shoppings/sellers/sales/{saleId}/reviews\",\"method\":\"patch\"},{\"path\":\"/shoppings/sellers/sales/{saleId}/reviews/abridges\",\"method\":\"patch\"},{\"path\":\"/shoppings/sellers/sales/{saleId}/reviews/{id}\",\"method\":\"get\"},{\"path\":\"/shoppings/sellers/sales/{saleId}/snapshots/{id}/replica\",\"method\":\"post\"},{\"path\":\"/shoppings/sellers/sales/{saleId}/snapshots\",\"method\":\"patch\"},{\"path\":\"/shoppings/sellers/sales/{saleId}/snapshots/{id}\",\"method\":\"get\"},{\"path\":\"/shoppings/sellers/sales/{saleId}/snapshots/{id}/flip\",\"method\":\"get\"},{\"path\":\"/shoppings/sellers/sales/{saleId}/units/{unitId}/stocks/{stockId}/supplements\",\"method\":\"post\"},{\"path\":\"/shoppings/sellers/sales/{saleId}/units/{unitId}/stocks/{stockId}/supplements\",\"method\":\"patch\"},{\"path\":\"/shoppings/sellers/sales/{saleId}/units/{unitId}/stocks/{stockId}/supplements/{id}\",\"method\":\"put\"},{\"path\":\"/shoppings/sellers/sales/{saleId}/units/{unitId}/stocks/{stockId}/supplements/{id}\",\"method\":\"delete\"},{\"path\":\"/shoppings/sellers/systematic/channels/{channelCode}/categories\",\"method\":\"patch\"},{\"path\":\"/shoppings/sellers/systematic/channels/{channelCode}/categories/{id}\",\"method\":\"get\"},{\"path\":\"/shoppings/sellers/systematic/channels/{channelCode}/categories/{id}/invert\",\"method\":\"get\"},{\"path\":\"/shoppings/sellers/systematic/channels\",\"method\":\"patch\"},{\"path\":\"/shoppings/sellers/systematic/channels/hierarchical\",\"method\":\"patch\"},{\"path\":\"/shoppings/sellers/systematic/channels/{id}\",\"method\":\"get\"},{\"path\":\"/shoppings/sellers/systematic/channels/{code}/get\",\"method\":\"get\"},{\"path\":\"/shoppings/sellers/systematic/sections\",\"method\":\"patch\"},{\"path\":\"/shoppings/sellers/systematic/sections/{id}\",\"method\":\"get\"},{\"path\":\"/shoppings/sellers/systematic/sections/{code}/get\",\"method\":\"get\"}]}\n```\n\n**Key points**: Observe how `/shopping` is used as domain prefix, hierarchical relationships are reflected in paths (e.g., `/shopping/sales/{saleId}/reviews/{reviewId}`), and consistent HTTP methods are applied across similar operations.",
|
|
8
8
|
INTERFACE_OPERATION = "# AutoAPI Operation Generator - System Prompt\n\nYou are AutoAPI Operation Generator.\n\nYour primary mission is to generate complete and detailed API operations based on path and method combinations identified in stage 1. In this process, you'll leverage Prisma schema description comments and requirement documents to create comprehensive specifications for each endpoint.\n\n## 1. Input Data Structure\n\nYou will receive the following inputs:\n\n1. List of path/method combinations to generate\n2. Prisma schema files (with detailed comments)\n3. Requirement analysis documents\n4. ERD (Entity Relationship Diagram)\n5. List of already generated API operations (if any)\n\n## 2. Work Process\n\n### 2.1. Progress Analysis\n\n- Identify path/method combinations for which API operations have not yet been created\n- Compare the number of operations already created with the total required to track progress\n- Prioritize missing operations for a systematic approach\n\n### 2.2. API Operation Creation Principles\n\n- **Create exactly one API operation for each path/method combination**\n- All operations must adhere to the design principles from the original AutoAPI system prompt\n- Each operation must include:\n - Detailed specification\n - Clear path and method\n - Detailed description in multiple paragraphs (referencing Prisma schema comments)\n - Concise summary\n - All necessary parameters\n - Appropriate requestBody (for POST, PUT, PATCH methods)\n - Appropriate responseBody\n\n### 2.3. Completeness Assurance Strategy\n\n- Create a checklist for each generated operation to ensure all required elements are included\n- Track the number of remaining path/method combinations after each generation step\n- Continue working until all path/method combinations are processed\n- If all operations cannot be generated in a single response, clearly distinguish between processed operations and remaining operations\n\n## 3. API Operation Quality Standards\n\n### 3.1. Detailed Descriptions\n\n- All descriptions must reference related table and column comments from Prisma schema\n- Descriptions must be organized in multiple paragraphs, each focusing on a specific aspect of the API\n- Clearly explain business logic, use cases, and relationships with other APIs\n\n### 3.2. Accurate Parameter Definitions\n\n- All parameters in paths (e.g., `{resourceId}`) must be clearly defined in the parameters array\n- Specify the exact type, format, and constraints for each parameter\n- Parameter descriptions should reference related Prisma schema column comments\n\n### 3.3. Appropriate Request/Response Bodies\n\n- All requestBody and responseBody must reference named types defined in components.schemas\n- Use appropriate `.ICreate` or `.IUpdate` types for POST/PUT/PATCH methods\n- Use appropriate response types (full entity or `.ISummary`) for GET methods\n- Include pagination, search, and sorting capabilities when retrieving lists with PATCH method\n\n## 4. Output Format\n\n```typescript\n{\n operations: [\n {\n specification: \"Detailed API specification with clear purpose and functionality\",\n path: \"/resources/{resourceId}\",\n method: \"get|post|put|delete|patch\",\n description: \"Extremely detailed description of API endpoint with multiple paragraphs,\\n\\neach focused on a specific aspect and referencing Prisma schema comments.\",\n summary: \"Concise one-sentence summary of the endpoint\",\n parameters: [\n {\n name: \"paramName\",\n description: \"Detailed parameter description referencing Prisma schema column comments\",\n schema: { type: \"string\", format: \"uuid\" }\n }\n ],\n requestBody: { // Only for POST, PUT, PATCH methods\n description: \"Detailed request body description with multiple paragraphs\",\n typeName: \"IEntityName.ICreate\",\n },\n responseBody: {\n description: \"Detailed response body description with multiple paragraphs\",\n typeName: \"IEntityName\",\n }\n },\n // ... additional operations\n ],\n // remainingPaths: [\n // // List of path/method combinations not yet processed\n // { path: \"/remaining-path\", method: \"get\" },\n // // ...\n // ],\n // progress: {\n // totalPathsRequired: 50, // example\n // pathsProcessed: 30, // example\n // completionPercentage: 60 // example\n // }\n}\n```\n\n## 5. Completeness Assurance Principles\n\n### 5.1. Processing Tracking Mechanism\n\n- Generate as many API operations as possible in each working session\n- Clearly report the number of operations processed and remaining after each session\n- Clearly distinguish between operations already processed and path/method combinations not yet processed\n\n### 5.2. Iterative Work Performance\n\n- If all path/method combinations cannot be processed in a single session, handle the remainder in the next request\n- Repeat this process until all path/method combinations are converted to operations\n- Track the number of operations generated in each iteration and the number of remaining path/method combinations\n\n### 5.3. Quality Maintenance\n\n- Prioritize quality over speed, but ensure all operations are eventually processed\n- Each operation must include all required elements and detailed descriptions, even if processing slows down\n- Never compromise quality to achieve numerical targets\n\n## 6. Critical Warnings\n\n- **Partial Implementation Prohibited**: All path/method combinations must be converted to API operations\n- **No Selective Processing**: All path/method combinations must be processed without exception\n- **Ignore Capacity Limitations**: Processing only some combinations due to their quantity is a serious error\n- **No Complexity Avoidance**: Complex relationships or features must not be simplified or omitted\n\nThis system will run iteratively until all required API operations are generated, converting some path/method combinations into complete API operations in each execution. It will clearly track and report progress, continuing until all operations are processed.\n\nI'll enhance the Example Cases section with more detailed explanations to make it more useful for the Operation Generator agent:",
|
|
@@ -1,12 +1,12 @@
|
|
|
1
|
+
import { IAgenticaVendor } from "@agentica/core";
|
|
1
2
|
import { AutoBeEvent, AutoBeHistory, IAutoBeCompiler } from "@autobe/interface";
|
|
2
3
|
import { ILlmSchema } from "@samchon/openapi";
|
|
3
4
|
import { IAutoBeConfig } from "../structures/IAutoBeConfig";
|
|
4
|
-
import { IAutoBeVendor } from "../structures/IAutoBeVendor";
|
|
5
5
|
import { AutoBeState } from "./AutoBeState";
|
|
6
6
|
import { AutoBeTokenUsage } from "./AutoBeTokenUsage";
|
|
7
7
|
export interface AutoBeContext<Model extends ILlmSchema.Model> {
|
|
8
8
|
model: Model;
|
|
9
|
-
vendor:
|
|
9
|
+
vendor: IAgenticaVendor;
|
|
10
10
|
config: IAutoBeConfig | undefined;
|
|
11
11
|
compiler: IAutoBeCompiler;
|
|
12
12
|
files: () => Record<string, string>;
|
|
@@ -49,6 +49,12 @@ export interface IAutoBeApplicationProps {
|
|
|
49
49
|
* headings. The entire content of the document will have requirements, such
|
|
50
50
|
* as maintaining informal or formal language.
|
|
51
51
|
*
|
|
52
|
+
* The style guide should include conventions for Markdown formatting elements
|
|
53
|
+
* such as headings, lists, and tables. Additionally, it should define
|
|
54
|
+
* expectations regarding document length and overall composition. When
|
|
55
|
+
* describing structural guidelines, include a template to illustrate the
|
|
56
|
+
* recommended format.
|
|
57
|
+
*
|
|
52
58
|
* # Limiting the volume of a document
|
|
53
59
|
*
|
|
54
60
|
* However, do not go beyond the volume guide; each agent only needs to create
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"createAgenticaHistory.js","sourceRoot":"","sources":["../../src/factory/createAgenticaHistory.ts"],"names":[],"mappings":";;AAQA,
|
|
1
|
+
{"version":3,"file":"createAgenticaHistory.js","sourceRoot":"","sources":["../../src/factory/createAgenticaHistory.ts"],"names":[],"mappings":";;AAQA,sDA2CC;AA3CD,SAAgB,qBAAqB,CAAiC,KAGrE;IACC,IAAI,KAAK,CAAC,OAAO,CAAC,IAAI,KAAK,aAAa;QACtC,uCACK,KAAK,CAAC,OAAO,KAChB,MAAM,EAAE,GAAG,EAAE,CAAC,KAAK,CAAC,OAAmC,IACvD;SACC,IAAI,KAAK,CAAC,OAAO,CAAC,IAAI,KAAK,kBAAkB;QAChD,uCACK,KAAK,CAAC,OAAO,KAChB,MAAM,EAAE,GAAG,EAAE,CAAC,KAAK,CAAC,OAAwC,IAC5D;IAEJ,MAAM,SAAS,GAAyC,KAAK,CAAC,UAAU,CAAC,IAAI,CAC3E,CAAC,EAAE,EAAE,EAAE,CAAC,EAAE,CAAC,QAAQ,CAAC,IAAI,KAAK,KAAK,CAAC,OAAO,CAAC,IAAI,CAChD,CAAC;IACF,IAAI,SAAS,KAAK,SAAS;QAAE,OAAO,IAAI,CAAC;IACzC,MAAM,OAAO,GAAG;QACd,EAAE,EAAE,KAAK,CAAC,OAAO,CAAC,EAAE;QACpB,UAAU,EAAE,KAAK,CAAC,OAAO,CAAC,UAAU;QACpC,IAAI,EAAE,SAAkB;QACxB,SAAS,EAAE;YACT,MAAM,EAAE,KAAK,CAAC,OAAO,CAAC,MAAM;SAC7B;QACD,KAAK,EAAE;YACL,OAAO,EACL,KAAK,CAAC,OAAO,CAAC,IAAI,KAAK,SAAS,IAAI,KAAK,CAAC,OAAO,CAAC,IAAI,KAAK,WAAW;gBACpE,CAAC,CAAC,IAAI;gBACN,CAAC,CAAC,KAAK,CAAC,OAAO,CAAC,QAAQ,CAAC,IAAI,KAAK,SAAS;SAChD;KACF,CAAC;IACF,uCACK,OAAO,KACV,QAAQ,EAAE,SAAS,CAAC,QAAmB,EACvC,SAAS,EAAE,SAA2C,EACtD,MAAM,EAAE,GAAG,EAAE,CAAC,iCACT,OAAO,KACV,QAAQ,EAAE,SAAS,CAAC,QAAmB,EACvC,SAAS,EAAE,SAAS,CAAC,MAAM,EAAE,IAC7B,IACF;AACJ,CAAC"}
|
|
@@ -49,8 +49,8 @@ exports.createAutoBeController = void 0;
|
|
|
49
49
|
const __typia_transform__validateReport = __importStar(require("typia/lib/internal/_validateReport.js"));
|
|
50
50
|
const typia_1 = __importDefault(require("typia"));
|
|
51
51
|
const assertSchemaModel_1 = require("../context/assertSchemaModel");
|
|
52
|
+
const orchestrateAnalyze_1 = require("../orchestrate/analyze/orchestrateAnalyze");
|
|
52
53
|
const orchestrateInterface_1 = require("../orchestrate/interface/orchestrateInterface");
|
|
53
|
-
const orchestrateAnalyze_1 = require("../orchestrate/orchestrateAnalyze");
|
|
54
54
|
const orchestrateRealize_1 = require("../orchestrate/orchestrateRealize");
|
|
55
55
|
const orchestrateTest_1 = require("../orchestrate/orchestrateTest");
|
|
56
56
|
const orchestratePrisma_1 = require("../orchestrate/prisma/orchestratePrisma");
|
|
@@ -166,7 +166,7 @@ const claude = {
|
|
|
166
166
|
type: "string"
|
|
167
167
|
},
|
|
168
168
|
userPlanningRequirements: {
|
|
169
|
-
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.",
|
|
169
|
+
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\nThe style guide should include conventions for Markdown formatting elements\nsuch as headings, lists, and tables. Additionally, it should define\nexpectations regarding document length and overall composition. When\ndescribing structural guidelines, include a template to illustrate the\nrecommended format.\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.",
|
|
170
170
|
type: "string"
|
|
171
171
|
}
|
|
172
172
|
},
|
|
@@ -258,7 +258,7 @@ const claude = {
|
|
|
258
258
|
type: "string"
|
|
259
259
|
},
|
|
260
260
|
userPlanningRequirements: {
|
|
261
|
-
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.",
|
|
261
|
+
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\nThe style guide should include conventions for Markdown formatting elements\nsuch as headings, lists, and tables. Additionally, it should define\nexpectations regarding document length and overall composition. When\ndescribing structural guidelines, include a template to illustrate the\nrecommended format.\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.",
|
|
262
262
|
type: "string"
|
|
263
263
|
}
|
|
264
264
|
},
|
|
@@ -350,7 +350,7 @@ const claude = {
|
|
|
350
350
|
type: "string"
|
|
351
351
|
},
|
|
352
352
|
userPlanningRequirements: {
|
|
353
|
-
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.",
|
|
353
|
+
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\nThe style guide should include conventions for Markdown formatting elements\nsuch as headings, lists, and tables. Additionally, it should define\nexpectations regarding document length and overall composition. When\ndescribing structural guidelines, include a template to illustrate the\nrecommended format.\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.",
|
|
354
354
|
type: "string"
|
|
355
355
|
}
|
|
356
356
|
},
|
|
@@ -442,7 +442,7 @@ const claude = {
|
|
|
442
442
|
type: "string"
|
|
443
443
|
},
|
|
444
444
|
userPlanningRequirements: {
|
|
445
|
-
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.",
|
|
445
|
+
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\nThe style guide should include conventions for Markdown formatting elements\nsuch as headings, lists, and tables. Additionally, it should define\nexpectations regarding document length and overall composition. When\ndescribing structural guidelines, include a template to illustrate the\nrecommended format.\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.",
|
|
446
446
|
type: "string"
|
|
447
447
|
}
|
|
448
448
|
},
|
|
@@ -534,7 +534,7 @@ const claude = {
|
|
|
534
534
|
type: "string"
|
|
535
535
|
},
|
|
536
536
|
userPlanningRequirements: {
|
|
537
|
-
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.",
|
|
537
|
+
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\nThe style guide should include conventions for Markdown formatting elements\nsuch as headings, lists, and tables. Additionally, it should define\nexpectations regarding document length and overall composition. When\ndescribing structural guidelines, include a template to illustrate the\nrecommended format.\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.",
|
|
538
538
|
type: "string"
|
|
539
539
|
}
|
|
540
540
|
},
|
|
@@ -637,7 +637,7 @@ const collection = {
|
|
|
637
637
|
type: "string"
|
|
638
638
|
},
|
|
639
639
|
userPlanningRequirements: {
|
|
640
|
-
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.",
|
|
640
|
+
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\nThe style guide should include conventions for Markdown formatting elements\nsuch as headings, lists, and tables. Additionally, it should define\nexpectations regarding document length and overall composition. When\ndescribing structural guidelines, include a template to illustrate the\nrecommended format.\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.",
|
|
641
641
|
type: "string"
|
|
642
642
|
}
|
|
643
643
|
},
|
|
@@ -720,7 +720,7 @@ const collection = {
|
|
|
720
720
|
type: "string"
|
|
721
721
|
},
|
|
722
722
|
userPlanningRequirements: {
|
|
723
|
-
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.",
|
|
723
|
+
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\nThe style guide should include conventions for Markdown formatting elements\nsuch as headings, lists, and tables. Additionally, it should define\nexpectations regarding document length and overall composition. When\ndescribing structural guidelines, include a template to illustrate the\nrecommended format.\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.",
|
|
724
724
|
type: "string"
|
|
725
725
|
}
|
|
726
726
|
},
|
|
@@ -803,7 +803,7 @@ const collection = {
|
|
|
803
803
|
type: "string"
|
|
804
804
|
},
|
|
805
805
|
userPlanningRequirements: {
|
|
806
|
-
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.",
|
|
806
|
+
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\nThe style guide should include conventions for Markdown formatting elements\nsuch as headings, lists, and tables. Additionally, it should define\nexpectations regarding document length and overall composition. When\ndescribing structural guidelines, include a template to illustrate the\nrecommended format.\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.",
|
|
807
807
|
type: "string"
|
|
808
808
|
}
|
|
809
809
|
},
|
|
@@ -886,7 +886,7 @@ const collection = {
|
|
|
886
886
|
type: "string"
|
|
887
887
|
},
|
|
888
888
|
userPlanningRequirements: {
|
|
889
|
-
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.",
|
|
889
|
+
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\nThe style guide should include conventions for Markdown formatting elements\nsuch as headings, lists, and tables. Additionally, it should define\nexpectations regarding document length and overall composition. When\ndescribing structural guidelines, include a template to illustrate the\nrecommended format.\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.",
|
|
890
890
|
type: "string"
|
|
891
891
|
}
|
|
892
892
|
},
|
|
@@ -969,7 +969,7 @@ const collection = {
|
|
|
969
969
|
type: "string"
|
|
970
970
|
},
|
|
971
971
|
userPlanningRequirements: {
|
|
972
|
-
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.",
|
|
972
|
+
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\nThe style guide should include conventions for Markdown formatting elements\nsuch as headings, lists, and tables. Additionally, it should define\nexpectations regarding document length and overall composition. When\ndescribing structural guidelines, include a template to illustrate the\nrecommended format.\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.",
|
|
973
973
|
type: "string"
|
|
974
974
|
}
|
|
975
975
|
},
|
|
@@ -1066,7 +1066,7 @@ const collection = {
|
|
|
1066
1066
|
},
|
|
1067
1067
|
userPlanningRequirements: {
|
|
1068
1068
|
type: "string",
|
|
1069
|
-
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."
|
|
1069
|
+
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\nThe style guide should include conventions for Markdown formatting elements\nsuch as headings, lists, and tables. Additionally, it should define\nexpectations regarding document length and overall composition. When\ndescribing structural guidelines, include a template to illustrate the\nrecommended format.\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."
|
|
1070
1070
|
}
|
|
1071
1071
|
},
|
|
1072
1072
|
required: [
|
|
@@ -1149,7 +1149,7 @@ const collection = {
|
|
|
1149
1149
|
},
|
|
1150
1150
|
userPlanningRequirements: {
|
|
1151
1151
|
type: "string",
|
|
1152
|
-
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."
|
|
1152
|
+
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\nThe style guide should include conventions for Markdown formatting elements\nsuch as headings, lists, and tables. Additionally, it should define\nexpectations regarding document length and overall composition. When\ndescribing structural guidelines, include a template to illustrate the\nrecommended format.\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."
|
|
1153
1153
|
}
|
|
1154
1154
|
},
|
|
1155
1155
|
required: [
|
|
@@ -1232,7 +1232,7 @@ const collection = {
|
|
|
1232
1232
|
},
|
|
1233
1233
|
userPlanningRequirements: {
|
|
1234
1234
|
type: "string",
|
|
1235
|
-
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."
|
|
1235
|
+
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\nThe style guide should include conventions for Markdown formatting elements\nsuch as headings, lists, and tables. Additionally, it should define\nexpectations regarding document length and overall composition. When\ndescribing structural guidelines, include a template to illustrate the\nrecommended format.\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."
|
|
1236
1236
|
}
|
|
1237
1237
|
},
|
|
1238
1238
|
required: [
|
|
@@ -1315,7 +1315,7 @@ const collection = {
|
|
|
1315
1315
|
},
|
|
1316
1316
|
userPlanningRequirements: {
|
|
1317
1317
|
type: "string",
|
|
1318
|
-
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."
|
|
1318
|
+
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\nThe style guide should include conventions for Markdown formatting elements\nsuch as headings, lists, and tables. Additionally, it should define\nexpectations regarding document length and overall composition. When\ndescribing structural guidelines, include a template to illustrate the\nrecommended format.\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."
|
|
1319
1319
|
}
|
|
1320
1320
|
},
|
|
1321
1321
|
required: [
|
|
@@ -1398,7 +1398,7 @@ const collection = {
|
|
|
1398
1398
|
},
|
|
1399
1399
|
userPlanningRequirements: {
|
|
1400
1400
|
type: "string",
|
|
1401
|
-
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."
|
|
1401
|
+
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\nThe style guide should include conventions for Markdown formatting elements\nsuch as headings, lists, and tables. Additionally, it should define\nexpectations regarding document length and overall composition. When\ndescribing structural guidelines, include a template to illustrate the\nrecommended format.\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."
|
|
1402
1402
|
}
|
|
1403
1403
|
},
|
|
1404
1404
|
required: [
|