@willbooster/shared-lib 11.0.0 → 11.1.1
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/README.md +6 -0
- package/dist/githubTemplates.cjs +1 -1
- package/dist/githubTemplates.cjs.map +1 -1
- package/dist/githubTemplates.d.ts +1 -1
- package/dist/githubTemplates.js +1 -1
- package/dist/githubTemplates.js.map +1 -1
- package/dist/index.cjs +1 -1
- package/dist/index.js +1 -1
- package/dist/promptFormatters.cjs +2 -2
- package/dist/promptFormatters.cjs.map +1 -1
- package/dist/promptFormatters.js +2 -2
- package/package.json +7 -7
package/README.md
CHANGED
|
@@ -1,3 +1,9 @@
|
|
|
1
|
+
---
|
|
2
|
+
purpose: WillBooster projects on any JavaScript runtime share one implementation of general-purpose code instead of each writing its own.
|
|
3
|
+
goals:
|
|
4
|
+
- The package runs on every JavaScript runtime WillBooster uses, with no runtime dependencies.
|
|
5
|
+
---
|
|
6
|
+
|
|
1
7
|
# @willbooster/shared-lib
|
|
2
8
|
|
|
3
9
|
`recoverJson(response)` extracts JSON candidates from text and Markdown without runtime dependencies. It repairs common syntax errors and recovers partial strings and containers. Each candidate includes its parsed `value`, serialized `json`, original `start`/`end` offsets, and `repairs` with original UTF-16 offsets. The range includes consumed source, such as trailing whitespace and removed comments; use `json` or `value`, not the source slice, for parsing.
|
package/dist/githubTemplates.cjs
CHANGED
|
@@ -2,5 +2,5 @@
|
|
|
2
2
|
- Start the body with \`Close #<n>\` only when the PR resolves an existing issue.\n${t}`,r=[{heading:`Problem`,requirement:`what happens, and what should happen instead`},{heading:`Evidence`,requirement:`reproduction steps, logs, run IDs, or links`},{heading:`Impact`,requirement:`who or what is affected, and how badly`},{heading:`Proposal`,requirement:`the fix you have in mind, and the root cause if known`}],i=[{heading:`Background and goal`,requirement:`the problem being solved, for whom, and what outcome counts as success`},{heading:`Behavior`,requirement:`every user- or caller-observable behavior, including inputs, outputs, error cases, edge cases, and interactions with existing behavior, stated precisely enough that two implementers would build the same thing`},{heading:`Acceptance criteria`,requirement:`checkable conditions (Given/When/Then or an equivalent) that decide whether the implementation is done`},{heading:`Scope and non-goals`,requirement:`what the change covers and what it deliberately leaves out, so an implementer knows where to stop`},{heading:`Design constraints`,requirement:`the data, API, schema, UI, and configuration changes, naming, and the existing code or conventions the implementation must fit — as far as the writer intends to constrain them, with everything else explicitly left to the implementer`},{heading:`Compatibility and migration`,requirement:`what existing data, users, callers, or configurations are affected and how the transition happens`},{heading:`Verification`,requirement:`how the change is tested or demonstrated, including what needs no test and why`},{heading:`Open questions`,requirement:`undecided points, each with its options; empty once the specification is implementable`}];function a(e){return e.map(e=>`- **${e.heading}**: ${e.requirement}`).join(`
|
|
3
3
|
`)}function o(e){return e.map(e=>`## ${e.heading}\n\n<!-- ${e.requirement.charAt(0).toUpperCase()}${e.requirement.slice(1)}. -->`).join(`
|
|
4
4
|
|
|
5
|
-
`)}exports.BUG_ISSUE_SECTIONS=r,exports.CHANGE_ISSUE_SECTIONS=i,exports.ISSUE_TEMPLATE_RULES="- Follow the closest template under `.github/ISSUE_TEMPLATE/`: `bug.md` for wrong behavior, `change.md` for anything to build or alter; a question or note fitting neither, or a repository without templates, needs no template.\n- Title: a Conventional Commits prefix for the type that fits the change (`feat:`, `fix:`, `refactor:`, `docs:`, `chore:`, ...)
|
|
5
|
+
`)}exports.BUG_ISSUE_SECTIONS=r,exports.CHANGE_ISSUE_SECTIONS=i,exports.ISSUE_TEMPLATE_RULES="- Follow the closest template under `.github/ISSUE_TEMPLATE/`: `bug.md` for wrong behavior, `change.md` for anything to build or alter; a question or note fitting neither, or a repository without templates, needs no template.\n- Title: a Conventional Commits prefix for the type that fits the change (`feat:`, `fix:`, `refactor:`, `docs:`, `chore:`, ...).\n- The YAML front matter between the `---` lines is metadata, not body text: submit only the content below the closing `---` as the body.",exports.PULL_REQUEST_BODY_RULES=n,exports.PULL_REQUEST_REQUIREMENTS_RULES=t,exports.PULL_REQUEST_SECTIONS=e,exports.renderSectionChecklist=a,exports.renderSectionTemplate=o;
|
|
6
6
|
//# sourceMappingURL=githubTemplates.cjs.map
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"githubTemplates.cjs","names":["PULL_REQUEST_SECTIONS","PULL_REQUEST_REQUIREMENTS_RULES","PULL_REQUEST_BODY_RULES","BUG_ISSUE_SECTIONS","CHANGE_ISSUE_SECTIONS","renderSectionChecklist","sections","section","renderSectionTemplate"],"sources":["../src/githubTemplates.ts"],"sourcesContent":["/**\n * A section of a PR or issue body: its heading and what the section must state. `requirement`\n * starts lowercase and ends without punctuation, so that it reads both as a placeholder sentence\n * (capitalized, with a period appended) and as a checklist clause after the heading.\n */\nexport interface TemplateSection {\n readonly heading: string;\n readonly requirement: string;\n}\n\n/** Sections of a pull request body, in the order they appear in the PR template. */\nexport const PULL_REQUEST_SECTIONS: readonly TemplateSection[] = [\n {\n heading: 'Why',\n requirement: 'the problem, with the numbers or observations behind it, and why this approach over the alternatives',\n },\n {\n heading: 'Requirements',\n requirement:\n \"the requirements the change must satisfy and the guarantees it must keep as they stand now, one per line, each marked `required` (asked for by the requester, or an existing contract callers depend on) or `chosen` (the implementer's own decision with the reason that decided it, which a simpler design may replace); state the requester's instructions in the requester's terms, whether they came from an issue or a conversation, and keep each line as it is until the requester overrides or withdraws the instruction behind it or the decision behind it changes, and then rewrite or remove that line instead of adding one beside it\",\n },\n {\n heading: 'Customer Summary',\n requirement:\n 'behavior, workflow, or user-visible changes, written for readers who know nothing about the implementation',\n },\n {\n heading: 'Technical Summary',\n requirement:\n 'decisions and their reasons, data flow, where to look (the files that matter most), and what to check hardest: the parts whose correctness is argued rather than proven',\n },\n {\n heading: 'Testing',\n requirement: 'commands run, tests added, and what was NOT exercised and why',\n },\n {\n heading: 'Notes',\n requirement: 'known limitations, compatibility and migration, follow-up work; delete this section if there is none',\n },\n];\n\n/**\n * How a tool that writes or rewrites a PR body derives it from the repository's PR template, as\n * markdown bullets for an agent's instructions. Stated once here and rendered by every writer (the\n * generated agent instructions, the PR-drafting skills) so the writers cannot drift apart; the\n * template-less branch lets the same text serve repositories outside the organization.\n */\nconst PULL_REQUEST_TEMPLATE_RULES = `- Base the PR body on \\`.github/pull_request_template.md\\` when creating or updating a PR, even when a skill or workflow supplies its own skeleton: keep the template's headings in order, fill each section with what its placeholder comment asks for at a length fitting the change (a sentence for a small change, numbered subsections for a large one), and delete the placeholder comments and an empty Notes section. Without a template, use no fixed headings: state the scope, the motivation, and the verification concisely.\n- Start the body with \\`Close #<n>\\` only when the PR resolves an existing issue.`;\n\n/**\n * How a tool that writes or rewrites a PR body fills the Requirements section of\n * `PULL_REQUEST_SECTIONS`, as markdown bullets for an agent's instructions. Skills that draft PR\n * bodies render this text instead of restating it, so the writers and the reviewers that read the\n * section as the boundary a fix must keep never disagree on what a line means.\n */\nexport const PULL_REQUEST_REQUIREMENTS_RULES = `- Requirements section: the requirements in force now, one line per requirement, taken from the requester's instructions in the requester's terms (the issue, the conversation that asked for the change), each marked \\`required\\` (asked for, or an existing contract callers depend on) or \\`chosen\\` (your own decision with the reason that decided it, which a simpler design may replace). Never infer a requirement from the diff: when no issue, PR message, or conversation states the request, write \\`required: not recorded — ask the requester\\` as the only request-derived line (\\`required\\` lines for existing contracts may still be listed) and say so in Notes.\n- When updating an existing section, keep each line until the requester overrides or withdraws the instruction behind it or the decision behind it changes, then rewrite or remove that line in place, never appending one beside it or marking when a line was added (e.g., \"(added)\"); with no instructions available, keep the requester-derived lines unchanged. When the current design cannot be understood without the change of direction, state it in one sentence in Notes. Write afresh by the rule above a section that merely describes the implementation or holds only the template's placeholder or a \\`required: not recorded\\` line.\n- Place the section where the template puts it; when the template has no such heading, right after the issue-closing line, or at the top of the body when there is none.\n- Never drop or weaken a \\`required\\` line to fit what was implemented: when one cannot hold in the diff, keep it and say so in Notes.`;\n\n/** The complete rules for writing a PR body: the template rules followed by the Requirements rules. */\nexport const PULL_REQUEST_BODY_RULES = `${PULL_REQUEST_TEMPLATE_RULES}\\n${PULL_REQUEST_REQUIREMENTS_RULES}`;\n\n/**\n * How a tool that creates an issue derives it from the repository's issue templates, as markdown\n * bullets for an agent's instructions; shared by the same writers as `PULL_REQUEST_BODY_RULES`.\n * Guidance the templates state in their own placeholder comments (which sections to keep, deleting\n * the comments) is deliberately not repeated here, since the writer reads the template anyway.\n */\nexport const ISSUE_TEMPLATE_RULES = `- Follow the closest template under \\`.github/ISSUE_TEMPLATE/\\`: \\`bug.md\\` for wrong behavior, \\`change.md\\` for anything to build or alter; a question or note fitting neither, or a repository without templates, needs no template.\n- Title: a Conventional Commits prefix for the type that fits the change (\\`feat:\\`, \\`fix:\\`, \\`refactor:\\`, \\`docs:\\`, \\`chore:\\`, ...); when it differs from the template's \\`title\\` prefix, replace the template's type label (\\`t: ...\\`) with the one matching the type.\n- The YAML front matter between the \\`---\\` lines is metadata, not body text: pass its \\`labels\\` via \\`--label\\` and submit only the content below the closing \\`---\\` as the body.`;\n\n/** Sections of a bug report, in the order they appear in the issue template. */\nexport const BUG_ISSUE_SECTIONS: readonly TemplateSection[] = [\n { heading: 'Problem', requirement: 'what happens, and what should happen instead' },\n { heading: 'Evidence', requirement: 'reproduction steps, logs, run IDs, or links' },\n { heading: 'Impact', requirement: 'who or what is affected, and how badly' },\n { heading: 'Proposal', requirement: 'the fix you have in mind, and the root cause if known' },\n];\n\n/**\n * Sections a change specification must settle before a third party can implement it, defined\n * once so that the issue template and any tool that drafts or reviews specifications against\n * these sections cannot drift apart; checklist consumers render it with `renderSectionChecklist`.\n * The first three sections suffice for a small change, so they come first.\n */\nexport const CHANGE_ISSUE_SECTIONS: readonly TemplateSection[] = [\n {\n heading: 'Background and goal',\n requirement: 'the problem being solved, for whom, and what outcome counts as success',\n },\n {\n heading: 'Behavior',\n requirement:\n 'every user- or caller-observable behavior, including inputs, outputs, error cases, edge cases, and interactions with existing behavior, stated precisely enough that two implementers would build the same thing',\n },\n {\n heading: 'Acceptance criteria',\n requirement:\n 'checkable conditions (Given/When/Then or an equivalent) that decide whether the implementation is done',\n },\n {\n heading: 'Scope and non-goals',\n requirement: 'what the change covers and what it deliberately leaves out, so an implementer knows where to stop',\n },\n {\n heading: 'Design constraints',\n requirement:\n 'the data, API, schema, UI, and configuration changes, naming, and the existing code or conventions the implementation must fit — as far as the writer intends to constrain them, with everything else explicitly left to the implementer',\n },\n {\n heading: 'Compatibility and migration',\n requirement: 'what existing data, users, callers, or configurations are affected and how the transition happens',\n },\n {\n heading: 'Verification',\n requirement: 'how the change is tested or demonstrated, including what needs no test and why',\n },\n {\n heading: 'Open questions',\n requirement: 'undecided points, each with its options; empty once the specification is implementable',\n },\n];\n\n/** Renders sections as markdown bullets (`- **Heading**: requirement`). */\nexport function renderSectionChecklist(sections: readonly TemplateSection[]): string {\n return sections.map((section) => `- **${section.heading}**: ${section.requirement}`).join('\\n');\n}\n\n/** Renders sections as markdown headings, each followed by its requirement as a placeholder comment. */\nexport function renderSectionTemplate(sections: readonly TemplateSection[]): string {\n return sections\n .map(\n (section) =>\n `## ${section.heading}\\n\\n<!-- ${section.requirement.charAt(0).toUpperCase()}${section.requirement.slice(1)}. -->`\n )\n .join('\\n\\n');\n}\n"],"mappings":"A,aAWA,MAAaA,EAAoD,CAC/D,CACE,QAAS,MACT,YAAa,sGACf,EACA,CACE,QAAS,eACT,YACE,qnBACJ,EACA,CACE,QAAS,mBACT,YACE,4GACJ,EACA,CACE,QAAS,oBACT,YACE,yKACJ,EACA,CACE,QAAS,UACT,YAAa,+DACf,EACA,CACE,QAAS,QACT,YAAa,sGACf,CACF,EAiBaC,EAAkC,ujDAMlCC,EAA0B;qFAAmCD,IAa7DE,EAAiD,CAC5D,CAAE,QAAS,UAAW,YAAa,8CAA+C,EAClF,CAAE,QAAS,WAAY,YAAa,6CAA8C,EAClF,CAAE,QAAS,SAAU,YAAa,wCAAyC,EAC3E,CAAE,QAAS,WAAY,YAAa,uDAAwD,CAC9F,EAQaC,EAAoD,CAC/D,CACE,QAAS,sBACT,YAAa,wEACf,EACA,CACE,QAAS,WACT,YACE,kNACJ,EACA,CACE,QAAS,sBACT,YACE,wGACJ,EACA,CACE,QAAS,sBACT,YAAa,mGACf,EACA,CACE,QAAS,qBACT,YACE,0OACJ,EACA,CACE,QAAS,8BACT,YAAa,mGACf,EACA,CACE,QAAS,eACT,YAAa,gFACf,EACA,CACE,QAAS,iBACT,YAAa,wFACf,CACF,EAGA,SAAgBC,EAAuB,EAA8C,CACnF,OAAOC,EAAS,IAAK,GAAY,OAAOC,EAAQ,QAAQ,MAAMA,EAAQ,aAAa,CAAC,CAAC,KAAK;CAAI,CAChG,CAGA,SAAgBC,EAAsB,EAA8C,CAClF,OAAOF,EACJ,IACE,GACC,MAAMC,EAAQ,QAAQ,WAAWA,EAAQ,YAAY,OAAO,CAAC,CAAC,CAAC,YAAY,IAAIA,EAAQ,YAAY,MAAM,CAAC,EAAE,MAChH,CAAC,CACA,KAAK;;CAAM,CAChB,C"}
|
|
1
|
+
{"version":3,"file":"githubTemplates.cjs","names":["PULL_REQUEST_SECTIONS","PULL_REQUEST_REQUIREMENTS_RULES","PULL_REQUEST_BODY_RULES","BUG_ISSUE_SECTIONS","CHANGE_ISSUE_SECTIONS","renderSectionChecklist","sections","section","renderSectionTemplate"],"sources":["../src/githubTemplates.ts"],"sourcesContent":["/**\n * A section of a PR or issue body: its heading and what the section must state. `requirement`\n * starts lowercase and ends without punctuation, so that it reads both as a placeholder sentence\n * (capitalized, with a period appended) and as a checklist clause after the heading.\n */\nexport interface TemplateSection {\n readonly heading: string;\n readonly requirement: string;\n}\n\n/** Sections of a pull request body, in the order they appear in the PR template. */\nexport const PULL_REQUEST_SECTIONS: readonly TemplateSection[] = [\n {\n heading: 'Why',\n requirement: 'the problem, with the numbers or observations behind it, and why this approach over the alternatives',\n },\n {\n heading: 'Requirements',\n requirement:\n \"the requirements the change must satisfy and the guarantees it must keep as they stand now, one per line, each marked `required` (asked for by the requester, or an existing contract callers depend on) or `chosen` (the implementer's own decision with the reason that decided it, which a simpler design may replace); state the requester's instructions in the requester's terms, whether they came from an issue or a conversation, and keep each line as it is until the requester overrides or withdraws the instruction behind it or the decision behind it changes, and then rewrite or remove that line instead of adding one beside it\",\n },\n {\n heading: 'Customer Summary',\n requirement:\n 'behavior, workflow, or user-visible changes, written for readers who know nothing about the implementation',\n },\n {\n heading: 'Technical Summary',\n requirement:\n 'decisions and their reasons, data flow, where to look (the files that matter most), and what to check hardest: the parts whose correctness is argued rather than proven',\n },\n {\n heading: 'Testing',\n requirement: 'commands run, tests added, and what was NOT exercised and why',\n },\n {\n heading: 'Notes',\n requirement: 'known limitations, compatibility and migration, follow-up work; delete this section if there is none',\n },\n];\n\n/**\n * How a tool that writes or rewrites a PR body derives it from the repository's PR template, as\n * markdown bullets for an agent's instructions. Stated once here and rendered by every writer (the\n * generated agent instructions, the PR-drafting skills) so the writers cannot drift apart; the\n * template-less branch lets the same text serve repositories outside the organization.\n */\nconst PULL_REQUEST_TEMPLATE_RULES = `- Base the PR body on \\`.github/pull_request_template.md\\` when creating or updating a PR, even when a skill or workflow supplies its own skeleton: keep the template's headings in order, fill each section with what its placeholder comment asks for at a length fitting the change (a sentence for a small change, numbered subsections for a large one), and delete the placeholder comments and an empty Notes section. Without a template, use no fixed headings: state the scope, the motivation, and the verification concisely.\n- Start the body with \\`Close #<n>\\` only when the PR resolves an existing issue.`;\n\n/**\n * How a tool that writes or rewrites a PR body fills the Requirements section of\n * `PULL_REQUEST_SECTIONS`, as markdown bullets for an agent's instructions. Skills that draft PR\n * bodies render this text instead of restating it, so the writers and the reviewers that read the\n * section as the boundary a fix must keep never disagree on what a line means.\n */\nexport const PULL_REQUEST_REQUIREMENTS_RULES = `- Requirements section: the requirements in force now, one line per requirement, taken from the requester's instructions in the requester's terms (the issue, the conversation that asked for the change), each marked \\`required\\` (asked for, or an existing contract callers depend on) or \\`chosen\\` (your own decision with the reason that decided it, which a simpler design may replace). Never infer a requirement from the diff: when no issue, PR message, or conversation states the request, write \\`required: not recorded — ask the requester\\` as the only request-derived line (\\`required\\` lines for existing contracts may still be listed) and say so in Notes.\n- When updating an existing section, keep each line until the requester overrides or withdraws the instruction behind it or the decision behind it changes, then rewrite or remove that line in place, never appending one beside it or marking when a line was added (e.g., \"(added)\"); with no instructions available, keep the requester-derived lines unchanged. When the current design cannot be understood without the change of direction, state it in one sentence in Notes. Write afresh by the rule above a section that merely describes the implementation or holds only the template's placeholder or a \\`required: not recorded\\` line.\n- Place the section where the template puts it; when the template has no such heading, right after the issue-closing line, or at the top of the body when there is none.\n- Never drop or weaken a \\`required\\` line to fit what was implemented: when one cannot hold in the diff, keep it and say so in Notes.`;\n\n/** The complete rules for writing a PR body: the template rules followed by the Requirements rules. */\nexport const PULL_REQUEST_BODY_RULES = `${PULL_REQUEST_TEMPLATE_RULES}\\n${PULL_REQUEST_REQUIREMENTS_RULES}`;\n\n/**\n * How a tool that creates an issue derives it from the repository's issue templates, as markdown\n * bullets for an agent's instructions; shared by the same writers as `PULL_REQUEST_BODY_RULES`.\n * Guidance the templates state in their own placeholder comments (which sections to keep, deleting\n * the comments) is deliberately not repeated here, since the writer reads the template anyway.\n */\nexport const ISSUE_TEMPLATE_RULES = `- Follow the closest template under \\`.github/ISSUE_TEMPLATE/\\`: \\`bug.md\\` for wrong behavior, \\`change.md\\` for anything to build or alter; a question or note fitting neither, or a repository without templates, needs no template.\n- Title: a Conventional Commits prefix for the type that fits the change (\\`feat:\\`, \\`fix:\\`, \\`refactor:\\`, \\`docs:\\`, \\`chore:\\`, ...).\n- The YAML front matter between the \\`---\\` lines is metadata, not body text: submit only the content below the closing \\`---\\` as the body.`;\n\n/** Sections of a bug report, in the order they appear in the issue template. */\nexport const BUG_ISSUE_SECTIONS: readonly TemplateSection[] = [\n { heading: 'Problem', requirement: 'what happens, and what should happen instead' },\n { heading: 'Evidence', requirement: 'reproduction steps, logs, run IDs, or links' },\n { heading: 'Impact', requirement: 'who or what is affected, and how badly' },\n { heading: 'Proposal', requirement: 'the fix you have in mind, and the root cause if known' },\n];\n\n/**\n * Sections a change specification must settle before a third party can implement it, defined\n * once so that the issue template and any tool that drafts or reviews specifications against\n * these sections cannot drift apart; checklist consumers render it with `renderSectionChecklist`.\n * The first three sections suffice for a small change, so they come first.\n */\nexport const CHANGE_ISSUE_SECTIONS: readonly TemplateSection[] = [\n {\n heading: 'Background and goal',\n requirement: 'the problem being solved, for whom, and what outcome counts as success',\n },\n {\n heading: 'Behavior',\n requirement:\n 'every user- or caller-observable behavior, including inputs, outputs, error cases, edge cases, and interactions with existing behavior, stated precisely enough that two implementers would build the same thing',\n },\n {\n heading: 'Acceptance criteria',\n requirement:\n 'checkable conditions (Given/When/Then or an equivalent) that decide whether the implementation is done',\n },\n {\n heading: 'Scope and non-goals',\n requirement: 'what the change covers and what it deliberately leaves out, so an implementer knows where to stop',\n },\n {\n heading: 'Design constraints',\n requirement:\n 'the data, API, schema, UI, and configuration changes, naming, and the existing code or conventions the implementation must fit — as far as the writer intends to constrain them, with everything else explicitly left to the implementer',\n },\n {\n heading: 'Compatibility and migration',\n requirement: 'what existing data, users, callers, or configurations are affected and how the transition happens',\n },\n {\n heading: 'Verification',\n requirement: 'how the change is tested or demonstrated, including what needs no test and why',\n },\n {\n heading: 'Open questions',\n requirement: 'undecided points, each with its options; empty once the specification is implementable',\n },\n];\n\n/** Renders sections as markdown bullets (`- **Heading**: requirement`). */\nexport function renderSectionChecklist(sections: readonly TemplateSection[]): string {\n return sections.map((section) => `- **${section.heading}**: ${section.requirement}`).join('\\n');\n}\n\n/** Renders sections as markdown headings, each followed by its requirement as a placeholder comment. */\nexport function renderSectionTemplate(sections: readonly TemplateSection[]): string {\n return sections\n .map(\n (section) =>\n `## ${section.heading}\\n\\n<!-- ${section.requirement.charAt(0).toUpperCase()}${section.requirement.slice(1)}. -->`\n )\n .join('\\n\\n');\n}\n"],"mappings":"A,aAWA,MAAaA,EAAoD,CAC/D,CACE,QAAS,MACT,YAAa,sGACf,EACA,CACE,QAAS,eACT,YACE,qnBACJ,EACA,CACE,QAAS,mBACT,YACE,4GACJ,EACA,CACE,QAAS,oBACT,YACE,yKACJ,EACA,CACE,QAAS,UACT,YAAa,+DACf,EACA,CACE,QAAS,QACT,YAAa,sGACf,CACF,EAiBaC,EAAkC,ujDAMlCC,EAA0B;qFAAmCD,IAa7DE,EAAiD,CAC5D,CAAE,QAAS,UAAW,YAAa,8CAA+C,EAClF,CAAE,QAAS,WAAY,YAAa,6CAA8C,EAClF,CAAE,QAAS,SAAU,YAAa,wCAAyC,EAC3E,CAAE,QAAS,WAAY,YAAa,uDAAwD,CAC9F,EAQaC,EAAoD,CAC/D,CACE,QAAS,sBACT,YAAa,wEACf,EACA,CACE,QAAS,WACT,YACE,kNACJ,EACA,CACE,QAAS,sBACT,YACE,wGACJ,EACA,CACE,QAAS,sBACT,YAAa,mGACf,EACA,CACE,QAAS,qBACT,YACE,0OACJ,EACA,CACE,QAAS,8BACT,YAAa,mGACf,EACA,CACE,QAAS,eACT,YAAa,gFACf,EACA,CACE,QAAS,iBACT,YAAa,wFACf,CACF,EAGA,SAAgBC,EAAuB,EAA8C,CACnF,OAAOC,EAAS,IAAK,GAAY,OAAOC,EAAQ,QAAQ,MAAMA,EAAQ,aAAa,CAAC,CAAC,KAAK;CAAI,CAChG,CAGA,SAAgBC,EAAsB,EAA8C,CAClF,OAAOF,EACJ,IACE,GACC,MAAMC,EAAQ,QAAQ,WAAWA,EAAQ,YAAY,OAAO,CAAC,CAAC,CAAC,YAAY,IAAIA,EAAQ,YAAY,MAAM,CAAC,EAAE,MAChH,CAAC,CACA,KAAK;;CAAM,CAChB,C"}
|
|
@@ -24,7 +24,7 @@ export declare const PULL_REQUEST_BODY_RULES = "- Base the PR body on `.github/p
|
|
|
24
24
|
* Guidance the templates state in their own placeholder comments (which sections to keep, deleting
|
|
25
25
|
* the comments) is deliberately not repeated here, since the writer reads the template anyway.
|
|
26
26
|
*/
|
|
27
|
-
export declare const ISSUE_TEMPLATE_RULES = "- Follow the closest template under `.github/ISSUE_TEMPLATE/`: `bug.md` for wrong behavior, `change.md` for anything to build or alter; a question or note fitting neither, or a repository without templates, needs no template.\n- Title: a Conventional Commits prefix for the type that fits the change (`feat:`, `fix:`, `refactor:`, `docs:`, `chore:`, ...)
|
|
27
|
+
export declare const ISSUE_TEMPLATE_RULES = "- Follow the closest template under `.github/ISSUE_TEMPLATE/`: `bug.md` for wrong behavior, `change.md` for anything to build or alter; a question or note fitting neither, or a repository without templates, needs no template.\n- Title: a Conventional Commits prefix for the type that fits the change (`feat:`, `fix:`, `refactor:`, `docs:`, `chore:`, ...).\n- The YAML front matter between the `---` lines is metadata, not body text: submit only the content below the closing `---` as the body.";
|
|
28
28
|
/** Sections of a bug report, in the order they appear in the issue template. */
|
|
29
29
|
export declare const BUG_ISSUE_SECTIONS: readonly TemplateSection[];
|
|
30
30
|
/**
|
package/dist/githubTemplates.js
CHANGED
|
@@ -1,5 +1,5 @@
|
|
|
1
1
|
const e=[{heading:`Why`,requirement:`the problem, with the numbers or observations behind it, and why this approach over the alternatives`},{heading:`Requirements`,requirement:"the requirements the change must satisfy and the guarantees it must keep as they stand now, one per line, each marked `required` (asked for by the requester, or an existing contract callers depend on) or `chosen` (the implementer's own decision with the reason that decided it, which a simpler design may replace); state the requester's instructions in the requester's terms, whether they came from an issue or a conversation, and keep each line as it is until the requester overrides or withdraws the instruction behind it or the decision behind it changes, and then rewrite or remove that line instead of adding one beside it"},{heading:`Customer Summary`,requirement:`behavior, workflow, or user-visible changes, written for readers who know nothing about the implementation`},{heading:`Technical Summary`,requirement:`decisions and their reasons, data flow, where to look (the files that matter most), and what to check hardest: the parts whose correctness is argued rather than proven`},{heading:`Testing`,requirement:`commands run, tests added, and what was NOT exercised and why`},{heading:`Notes`,requirement:`known limitations, compatibility and migration, follow-up work; delete this section if there is none`}],t="- Requirements section: the requirements in force now, one line per requirement, taken from the requester's instructions in the requester's terms (the issue, the conversation that asked for the change), each marked `required` (asked for, or an existing contract callers depend on) or `chosen` (your own decision with the reason that decided it, which a simpler design may replace). Never infer a requirement from the diff: when no issue, PR message, or conversation states the request, write `required: not recorded — ask the requester` as the only request-derived line (`required` lines for existing contracts may still be listed) and say so in Notes.\n- When updating an existing section, keep each line until the requester overrides or withdraws the instruction behind it or the decision behind it changes, then rewrite or remove that line in place, never appending one beside it or marking when a line was added (e.g., \"(added)\"); with no instructions available, keep the requester-derived lines unchanged. When the current design cannot be understood without the change of direction, state it in one sentence in Notes. Write afresh by the rule above a section that merely describes the implementation or holds only the template's placeholder or a `required: not recorded` line.\n- Place the section where the template puts it; when the template has no such heading, right after the issue-closing line, or at the top of the body when there is none.\n- Never drop or weaken a `required` line to fit what was implemented: when one cannot hold in the diff, keep it and say so in Notes.",n=`- Base the PR body on \`.github/pull_request_template.md\` when creating or updating a PR, even when a skill or workflow supplies its own skeleton: keep the template's headings in order, fill each section with what its placeholder comment asks for at a length fitting the change (a sentence for a small change, numbered subsections for a large one), and delete the placeholder comments and an empty Notes section. Without a template, use no fixed headings: state the scope, the motivation, and the verification concisely.
|
|
2
|
-
- Start the body with \`Close #<n>\` only when the PR resolves an existing issue.\n${t}`,r="- Follow the closest template under `.github/ISSUE_TEMPLATE/`: `bug.md` for wrong behavior, `change.md` for anything to build or alter; a question or note fitting neither, or a repository without templates, needs no template.\n- Title: a Conventional Commits prefix for the type that fits the change (`feat:`, `fix:`, `refactor:`, `docs:`, `chore:`, ...)
|
|
2
|
+
- Start the body with \`Close #<n>\` only when the PR resolves an existing issue.\n${t}`,r="- Follow the closest template under `.github/ISSUE_TEMPLATE/`: `bug.md` for wrong behavior, `change.md` for anything to build or alter; a question or note fitting neither, or a repository without templates, needs no template.\n- Title: a Conventional Commits prefix for the type that fits the change (`feat:`, `fix:`, `refactor:`, `docs:`, `chore:`, ...).\n- The YAML front matter between the `---` lines is metadata, not body text: submit only the content below the closing `---` as the body.",i=[{heading:`Problem`,requirement:`what happens, and what should happen instead`},{heading:`Evidence`,requirement:`reproduction steps, logs, run IDs, or links`},{heading:`Impact`,requirement:`who or what is affected, and how badly`},{heading:`Proposal`,requirement:`the fix you have in mind, and the root cause if known`}],a=[{heading:`Background and goal`,requirement:`the problem being solved, for whom, and what outcome counts as success`},{heading:`Behavior`,requirement:`every user- or caller-observable behavior, including inputs, outputs, error cases, edge cases, and interactions with existing behavior, stated precisely enough that two implementers would build the same thing`},{heading:`Acceptance criteria`,requirement:`checkable conditions (Given/When/Then or an equivalent) that decide whether the implementation is done`},{heading:`Scope and non-goals`,requirement:`what the change covers and what it deliberately leaves out, so an implementer knows where to stop`},{heading:`Design constraints`,requirement:`the data, API, schema, UI, and configuration changes, naming, and the existing code or conventions the implementation must fit — as far as the writer intends to constrain them, with everything else explicitly left to the implementer`},{heading:`Compatibility and migration`,requirement:`what existing data, users, callers, or configurations are affected and how the transition happens`},{heading:`Verification`,requirement:`how the change is tested or demonstrated, including what needs no test and why`},{heading:`Open questions`,requirement:`undecided points, each with its options; empty once the specification is implementable`}];function o(e){return e.map(e=>`- **${e.heading}**: ${e.requirement}`).join(`
|
|
3
3
|
`)}function s(e){return e.map(e=>`## ${e.heading}\n\n<!-- ${e.requirement.charAt(0).toUpperCase()}${e.requirement.slice(1)}. -->`).join(`
|
|
4
4
|
|
|
5
5
|
`)}export{i as BUG_ISSUE_SECTIONS,a as CHANGE_ISSUE_SECTIONS,r as ISSUE_TEMPLATE_RULES,n as PULL_REQUEST_BODY_RULES,t as PULL_REQUEST_REQUIREMENTS_RULES,e as PULL_REQUEST_SECTIONS,o as renderSectionChecklist,s as renderSectionTemplate};
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"githubTemplates.js","names":["PULL_REQUEST_SECTIONS","PULL_REQUEST_REQUIREMENTS_RULES","PULL_REQUEST_BODY_RULES","ISSUE_TEMPLATE_RULES","BUG_ISSUE_SECTIONS","CHANGE_ISSUE_SECTIONS","renderSectionChecklist","sections","section","renderSectionTemplate"],"sources":["../src/githubTemplates.ts"],"sourcesContent":["/**\n * A section of a PR or issue body: its heading and what the section must state. `requirement`\n * starts lowercase and ends without punctuation, so that it reads both as a placeholder sentence\n * (capitalized, with a period appended) and as a checklist clause after the heading.\n */\nexport interface TemplateSection {\n readonly heading: string;\n readonly requirement: string;\n}\n\n/** Sections of a pull request body, in the order they appear in the PR template. */\nexport const PULL_REQUEST_SECTIONS: readonly TemplateSection[] = [\n {\n heading: 'Why',\n requirement: 'the problem, with the numbers or observations behind it, and why this approach over the alternatives',\n },\n {\n heading: 'Requirements',\n requirement:\n \"the requirements the change must satisfy and the guarantees it must keep as they stand now, one per line, each marked `required` (asked for by the requester, or an existing contract callers depend on) or `chosen` (the implementer's own decision with the reason that decided it, which a simpler design may replace); state the requester's instructions in the requester's terms, whether they came from an issue or a conversation, and keep each line as it is until the requester overrides or withdraws the instruction behind it or the decision behind it changes, and then rewrite or remove that line instead of adding one beside it\",\n },\n {\n heading: 'Customer Summary',\n requirement:\n 'behavior, workflow, or user-visible changes, written for readers who know nothing about the implementation',\n },\n {\n heading: 'Technical Summary',\n requirement:\n 'decisions and their reasons, data flow, where to look (the files that matter most), and what to check hardest: the parts whose correctness is argued rather than proven',\n },\n {\n heading: 'Testing',\n requirement: 'commands run, tests added, and what was NOT exercised and why',\n },\n {\n heading: 'Notes',\n requirement: 'known limitations, compatibility and migration, follow-up work; delete this section if there is none',\n },\n];\n\n/**\n * How a tool that writes or rewrites a PR body derives it from the repository's PR template, as\n * markdown bullets for an agent's instructions. Stated once here and rendered by every writer (the\n * generated agent instructions, the PR-drafting skills) so the writers cannot drift apart; the\n * template-less branch lets the same text serve repositories outside the organization.\n */\nconst PULL_REQUEST_TEMPLATE_RULES = `- Base the PR body on \\`.github/pull_request_template.md\\` when creating or updating a PR, even when a skill or workflow supplies its own skeleton: keep the template's headings in order, fill each section with what its placeholder comment asks for at a length fitting the change (a sentence for a small change, numbered subsections for a large one), and delete the placeholder comments and an empty Notes section. Without a template, use no fixed headings: state the scope, the motivation, and the verification concisely.\n- Start the body with \\`Close #<n>\\` only when the PR resolves an existing issue.`;\n\n/**\n * How a tool that writes or rewrites a PR body fills the Requirements section of\n * `PULL_REQUEST_SECTIONS`, as markdown bullets for an agent's instructions. Skills that draft PR\n * bodies render this text instead of restating it, so the writers and the reviewers that read the\n * section as the boundary a fix must keep never disagree on what a line means.\n */\nexport const PULL_REQUEST_REQUIREMENTS_RULES = `- Requirements section: the requirements in force now, one line per requirement, taken from the requester's instructions in the requester's terms (the issue, the conversation that asked for the change), each marked \\`required\\` (asked for, or an existing contract callers depend on) or \\`chosen\\` (your own decision with the reason that decided it, which a simpler design may replace). Never infer a requirement from the diff: when no issue, PR message, or conversation states the request, write \\`required: not recorded — ask the requester\\` as the only request-derived line (\\`required\\` lines for existing contracts may still be listed) and say so in Notes.\n- When updating an existing section, keep each line until the requester overrides or withdraws the instruction behind it or the decision behind it changes, then rewrite or remove that line in place, never appending one beside it or marking when a line was added (e.g., \"(added)\"); with no instructions available, keep the requester-derived lines unchanged. When the current design cannot be understood without the change of direction, state it in one sentence in Notes. Write afresh by the rule above a section that merely describes the implementation or holds only the template's placeholder or a \\`required: not recorded\\` line.\n- Place the section where the template puts it; when the template has no such heading, right after the issue-closing line, or at the top of the body when there is none.\n- Never drop or weaken a \\`required\\` line to fit what was implemented: when one cannot hold in the diff, keep it and say so in Notes.`;\n\n/** The complete rules for writing a PR body: the template rules followed by the Requirements rules. */\nexport const PULL_REQUEST_BODY_RULES = `${PULL_REQUEST_TEMPLATE_RULES}\\n${PULL_REQUEST_REQUIREMENTS_RULES}`;\n\n/**\n * How a tool that creates an issue derives it from the repository's issue templates, as markdown\n * bullets for an agent's instructions; shared by the same writers as `PULL_REQUEST_BODY_RULES`.\n * Guidance the templates state in their own placeholder comments (which sections to keep, deleting\n * the comments) is deliberately not repeated here, since the writer reads the template anyway.\n */\nexport const ISSUE_TEMPLATE_RULES = `- Follow the closest template under \\`.github/ISSUE_TEMPLATE/\\`: \\`bug.md\\` for wrong behavior, \\`change.md\\` for anything to build or alter; a question or note fitting neither, or a repository without templates, needs no template.\n- Title: a Conventional Commits prefix for the type that fits the change (\\`feat:\\`, \\`fix:\\`, \\`refactor:\\`, \\`docs:\\`, \\`chore:\\`, ...); when it differs from the template's \\`title\\` prefix, replace the template's type label (\\`t: ...\\`) with the one matching the type.\n- The YAML front matter between the \\`---\\` lines is metadata, not body text: pass its \\`labels\\` via \\`--label\\` and submit only the content below the closing \\`---\\` as the body.`;\n\n/** Sections of a bug report, in the order they appear in the issue template. */\nexport const BUG_ISSUE_SECTIONS: readonly TemplateSection[] = [\n { heading: 'Problem', requirement: 'what happens, and what should happen instead' },\n { heading: 'Evidence', requirement: 'reproduction steps, logs, run IDs, or links' },\n { heading: 'Impact', requirement: 'who or what is affected, and how badly' },\n { heading: 'Proposal', requirement: 'the fix you have in mind, and the root cause if known' },\n];\n\n/**\n * Sections a change specification must settle before a third party can implement it, defined\n * once so that the issue template and any tool that drafts or reviews specifications against\n * these sections cannot drift apart; checklist consumers render it with `renderSectionChecklist`.\n * The first three sections suffice for a small change, so they come first.\n */\nexport const CHANGE_ISSUE_SECTIONS: readonly TemplateSection[] = [\n {\n heading: 'Background and goal',\n requirement: 'the problem being solved, for whom, and what outcome counts as success',\n },\n {\n heading: 'Behavior',\n requirement:\n 'every user- or caller-observable behavior, including inputs, outputs, error cases, edge cases, and interactions with existing behavior, stated precisely enough that two implementers would build the same thing',\n },\n {\n heading: 'Acceptance criteria',\n requirement:\n 'checkable conditions (Given/When/Then or an equivalent) that decide whether the implementation is done',\n },\n {\n heading: 'Scope and non-goals',\n requirement: 'what the change covers and what it deliberately leaves out, so an implementer knows where to stop',\n },\n {\n heading: 'Design constraints',\n requirement:\n 'the data, API, schema, UI, and configuration changes, naming, and the existing code or conventions the implementation must fit — as far as the writer intends to constrain them, with everything else explicitly left to the implementer',\n },\n {\n heading: 'Compatibility and migration',\n requirement: 'what existing data, users, callers, or configurations are affected and how the transition happens',\n },\n {\n heading: 'Verification',\n requirement: 'how the change is tested or demonstrated, including what needs no test and why',\n },\n {\n heading: 'Open questions',\n requirement: 'undecided points, each with its options; empty once the specification is implementable',\n },\n];\n\n/** Renders sections as markdown bullets (`- **Heading**: requirement`). */\nexport function renderSectionChecklist(sections: readonly TemplateSection[]): string {\n return sections.map((section) => `- **${section.heading}**: ${section.requirement}`).join('\\n');\n}\n\n/** Renders sections as markdown headings, each followed by its requirement as a placeholder comment. */\nexport function renderSectionTemplate(sections: readonly TemplateSection[]): string {\n return sections\n .map(\n (section) =>\n `## ${section.heading}\\n\\n<!-- ${section.requirement.charAt(0).toUpperCase()}${section.requirement.slice(1)}. -->`\n )\n .join('\\n\\n');\n}\n"],"mappings":"AAWA,MAAaA,EAAoD,CAC/D,CACE,QAAS,MACT,YAAa,sGACf,EACA,CACE,QAAS,eACT,YACE,qnBACJ,EACA,CACE,QAAS,mBACT,YACE,4GACJ,EACA,CACE,QAAS,oBACT,YACE,yKACJ,EACA,CACE,QAAS,UACT,YAAa,+DACf,EACA,CACE,QAAS,QACT,YAAa,sGACf,CACF,EAiBaC,EAAkC,ujDAMlCC,EAA0B;qFAAmCD,IAQ7DE,EAAuB,qpBAKvBC,EAAiD,CAC5D,CAAE,QAAS,UAAW,YAAa,8CAA+C,EAClF,CAAE,QAAS,WAAY,YAAa,6CAA8C,EAClF,CAAE,QAAS,SAAU,YAAa,wCAAyC,EAC3E,CAAE,QAAS,WAAY,YAAa,uDAAwD,CAC9F,EAQaC,EAAoD,CAC/D,CACE,QAAS,sBACT,YAAa,wEACf,EACA,CACE,QAAS,WACT,YACE,kNACJ,EACA,CACE,QAAS,sBACT,YACE,wGACJ,EACA,CACE,QAAS,sBACT,YAAa,mGACf,EACA,CACE,QAAS,qBACT,YACE,0OACJ,EACA,CACE,QAAS,8BACT,YAAa,mGACf,EACA,CACE,QAAS,eACT,YAAa,gFACf,EACA,CACE,QAAS,iBACT,YAAa,wFACf,CACF,EAGA,SAAgBC,EAAuB,EAA8C,CACnF,OAAOC,EAAS,IAAK,GAAY,OAAOC,EAAQ,QAAQ,MAAMA,EAAQ,aAAa,CAAC,CAAC,KAAK;CAAI,CAChG,CAGA,SAAgBC,EAAsB,EAA8C,CAClF,OAAOF,EACJ,IACE,GACC,MAAMC,EAAQ,QAAQ,WAAWA,EAAQ,YAAY,OAAO,CAAC,CAAC,CAAC,YAAY,IAAIA,EAAQ,YAAY,MAAM,CAAC,EAAE,MAChH,CAAC,CACA,KAAK;;CAAM,CAChB,C"}
|
|
1
|
+
{"version":3,"file":"githubTemplates.js","names":["PULL_REQUEST_SECTIONS","PULL_REQUEST_REQUIREMENTS_RULES","PULL_REQUEST_BODY_RULES","ISSUE_TEMPLATE_RULES","BUG_ISSUE_SECTIONS","CHANGE_ISSUE_SECTIONS","renderSectionChecklist","sections","section","renderSectionTemplate"],"sources":["../src/githubTemplates.ts"],"sourcesContent":["/**\n * A section of a PR or issue body: its heading and what the section must state. `requirement`\n * starts lowercase and ends without punctuation, so that it reads both as a placeholder sentence\n * (capitalized, with a period appended) and as a checklist clause after the heading.\n */\nexport interface TemplateSection {\n readonly heading: string;\n readonly requirement: string;\n}\n\n/** Sections of a pull request body, in the order they appear in the PR template. */\nexport const PULL_REQUEST_SECTIONS: readonly TemplateSection[] = [\n {\n heading: 'Why',\n requirement: 'the problem, with the numbers or observations behind it, and why this approach over the alternatives',\n },\n {\n heading: 'Requirements',\n requirement:\n \"the requirements the change must satisfy and the guarantees it must keep as they stand now, one per line, each marked `required` (asked for by the requester, or an existing contract callers depend on) or `chosen` (the implementer's own decision with the reason that decided it, which a simpler design may replace); state the requester's instructions in the requester's terms, whether they came from an issue or a conversation, and keep each line as it is until the requester overrides or withdraws the instruction behind it or the decision behind it changes, and then rewrite or remove that line instead of adding one beside it\",\n },\n {\n heading: 'Customer Summary',\n requirement:\n 'behavior, workflow, or user-visible changes, written for readers who know nothing about the implementation',\n },\n {\n heading: 'Technical Summary',\n requirement:\n 'decisions and their reasons, data flow, where to look (the files that matter most), and what to check hardest: the parts whose correctness is argued rather than proven',\n },\n {\n heading: 'Testing',\n requirement: 'commands run, tests added, and what was NOT exercised and why',\n },\n {\n heading: 'Notes',\n requirement: 'known limitations, compatibility and migration, follow-up work; delete this section if there is none',\n },\n];\n\n/**\n * How a tool that writes or rewrites a PR body derives it from the repository's PR template, as\n * markdown bullets for an agent's instructions. Stated once here and rendered by every writer (the\n * generated agent instructions, the PR-drafting skills) so the writers cannot drift apart; the\n * template-less branch lets the same text serve repositories outside the organization.\n */\nconst PULL_REQUEST_TEMPLATE_RULES = `- Base the PR body on \\`.github/pull_request_template.md\\` when creating or updating a PR, even when a skill or workflow supplies its own skeleton: keep the template's headings in order, fill each section with what its placeholder comment asks for at a length fitting the change (a sentence for a small change, numbered subsections for a large one), and delete the placeholder comments and an empty Notes section. Without a template, use no fixed headings: state the scope, the motivation, and the verification concisely.\n- Start the body with \\`Close #<n>\\` only when the PR resolves an existing issue.`;\n\n/**\n * How a tool that writes or rewrites a PR body fills the Requirements section of\n * `PULL_REQUEST_SECTIONS`, as markdown bullets for an agent's instructions. Skills that draft PR\n * bodies render this text instead of restating it, so the writers and the reviewers that read the\n * section as the boundary a fix must keep never disagree on what a line means.\n */\nexport const PULL_REQUEST_REQUIREMENTS_RULES = `- Requirements section: the requirements in force now, one line per requirement, taken from the requester's instructions in the requester's terms (the issue, the conversation that asked for the change), each marked \\`required\\` (asked for, or an existing contract callers depend on) or \\`chosen\\` (your own decision with the reason that decided it, which a simpler design may replace). Never infer a requirement from the diff: when no issue, PR message, or conversation states the request, write \\`required: not recorded — ask the requester\\` as the only request-derived line (\\`required\\` lines for existing contracts may still be listed) and say so in Notes.\n- When updating an existing section, keep each line until the requester overrides or withdraws the instruction behind it or the decision behind it changes, then rewrite or remove that line in place, never appending one beside it or marking when a line was added (e.g., \"(added)\"); with no instructions available, keep the requester-derived lines unchanged. When the current design cannot be understood without the change of direction, state it in one sentence in Notes. Write afresh by the rule above a section that merely describes the implementation or holds only the template's placeholder or a \\`required: not recorded\\` line.\n- Place the section where the template puts it; when the template has no such heading, right after the issue-closing line, or at the top of the body when there is none.\n- Never drop or weaken a \\`required\\` line to fit what was implemented: when one cannot hold in the diff, keep it and say so in Notes.`;\n\n/** The complete rules for writing a PR body: the template rules followed by the Requirements rules. */\nexport const PULL_REQUEST_BODY_RULES = `${PULL_REQUEST_TEMPLATE_RULES}\\n${PULL_REQUEST_REQUIREMENTS_RULES}`;\n\n/**\n * How a tool that creates an issue derives it from the repository's issue templates, as markdown\n * bullets for an agent's instructions; shared by the same writers as `PULL_REQUEST_BODY_RULES`.\n * Guidance the templates state in their own placeholder comments (which sections to keep, deleting\n * the comments) is deliberately not repeated here, since the writer reads the template anyway.\n */\nexport const ISSUE_TEMPLATE_RULES = `- Follow the closest template under \\`.github/ISSUE_TEMPLATE/\\`: \\`bug.md\\` for wrong behavior, \\`change.md\\` for anything to build or alter; a question or note fitting neither, or a repository without templates, needs no template.\n- Title: a Conventional Commits prefix for the type that fits the change (\\`feat:\\`, \\`fix:\\`, \\`refactor:\\`, \\`docs:\\`, \\`chore:\\`, ...).\n- The YAML front matter between the \\`---\\` lines is metadata, not body text: submit only the content below the closing \\`---\\` as the body.`;\n\n/** Sections of a bug report, in the order they appear in the issue template. */\nexport const BUG_ISSUE_SECTIONS: readonly TemplateSection[] = [\n { heading: 'Problem', requirement: 'what happens, and what should happen instead' },\n { heading: 'Evidence', requirement: 'reproduction steps, logs, run IDs, or links' },\n { heading: 'Impact', requirement: 'who or what is affected, and how badly' },\n { heading: 'Proposal', requirement: 'the fix you have in mind, and the root cause if known' },\n];\n\n/**\n * Sections a change specification must settle before a third party can implement it, defined\n * once so that the issue template and any tool that drafts or reviews specifications against\n * these sections cannot drift apart; checklist consumers render it with `renderSectionChecklist`.\n * The first three sections suffice for a small change, so they come first.\n */\nexport const CHANGE_ISSUE_SECTIONS: readonly TemplateSection[] = [\n {\n heading: 'Background and goal',\n requirement: 'the problem being solved, for whom, and what outcome counts as success',\n },\n {\n heading: 'Behavior',\n requirement:\n 'every user- or caller-observable behavior, including inputs, outputs, error cases, edge cases, and interactions with existing behavior, stated precisely enough that two implementers would build the same thing',\n },\n {\n heading: 'Acceptance criteria',\n requirement:\n 'checkable conditions (Given/When/Then or an equivalent) that decide whether the implementation is done',\n },\n {\n heading: 'Scope and non-goals',\n requirement: 'what the change covers and what it deliberately leaves out, so an implementer knows where to stop',\n },\n {\n heading: 'Design constraints',\n requirement:\n 'the data, API, schema, UI, and configuration changes, naming, and the existing code or conventions the implementation must fit — as far as the writer intends to constrain them, with everything else explicitly left to the implementer',\n },\n {\n heading: 'Compatibility and migration',\n requirement: 'what existing data, users, callers, or configurations are affected and how the transition happens',\n },\n {\n heading: 'Verification',\n requirement: 'how the change is tested or demonstrated, including what needs no test and why',\n },\n {\n heading: 'Open questions',\n requirement: 'undecided points, each with its options; empty once the specification is implementable',\n },\n];\n\n/** Renders sections as markdown bullets (`- **Heading**: requirement`). */\nexport function renderSectionChecklist(sections: readonly TemplateSection[]): string {\n return sections.map((section) => `- **${section.heading}**: ${section.requirement}`).join('\\n');\n}\n\n/** Renders sections as markdown headings, each followed by its requirement as a placeholder comment. */\nexport function renderSectionTemplate(sections: readonly TemplateSection[]): string {\n return sections\n .map(\n (section) =>\n `## ${section.heading}\\n\\n<!-- ${section.requirement.charAt(0).toUpperCase()}${section.requirement.slice(1)}. -->`\n )\n .join('\\n\\n');\n}\n"],"mappings":"AAWA,MAAaA,EAAoD,CAC/D,CACE,QAAS,MACT,YAAa,sGACf,EACA,CACE,QAAS,eACT,YACE,qnBACJ,EACA,CACE,QAAS,mBACT,YACE,4GACJ,EACA,CACE,QAAS,oBACT,YACE,yKACJ,EACA,CACE,QAAS,UACT,YAAa,+DACf,EACA,CACE,QAAS,QACT,YAAa,sGACf,CACF,EAiBaC,EAAkC,ujDAMlCC,EAA0B;qFAAmCD,IAQ7DE,EAAuB,gfAKvBC,EAAiD,CAC5D,CAAE,QAAS,UAAW,YAAa,8CAA+C,EAClF,CAAE,QAAS,WAAY,YAAa,6CAA8C,EAClF,CAAE,QAAS,SAAU,YAAa,wCAAyC,EAC3E,CAAE,QAAS,WAAY,YAAa,uDAAwD,CAC9F,EAQaC,EAAoD,CAC/D,CACE,QAAS,sBACT,YAAa,wEACf,EACA,CACE,QAAS,WACT,YACE,kNACJ,EACA,CACE,QAAS,sBACT,YACE,wGACJ,EACA,CACE,QAAS,sBACT,YAAa,mGACf,EACA,CACE,QAAS,qBACT,YACE,0OACJ,EACA,CACE,QAAS,8BACT,YAAa,mGACf,EACA,CACE,QAAS,eACT,YAAa,gFACf,EACA,CACE,QAAS,iBACT,YAAa,wFACf,CACF,EAGA,SAAgBC,EAAuB,EAA8C,CACnF,OAAOC,EAAS,IAAK,GAAY,OAAOC,EAAQ,QAAQ,MAAMA,EAAQ,aAAa,CAAC,CAAC,KAAK;CAAI,CAChG,CAGA,SAAgBC,EAAsB,EAA8C,CAClF,OAAOF,EACJ,IACE,GACC,MAAMC,EAAQ,QAAQ,WAAWA,EAAQ,YAAY,OAAO,CAAC,CAAC,CAAC,YAAY,IAAIA,EAAQ,YAAY,MAAM,CAAC,EAAE,MAChH,CAAC,CACA,KAAK;;CAAM,CAChB,C"}
|
package/dist/index.cjs
CHANGED
|
@@ -1 +1 @@
|
|
|
1
|
-
"use strict";Object.defineProperty(exports,Symbol.toStringTag,{value:`Module`});const e=require("./appEnv.cjs"),t=require("./array.cjs"),n=require("./assert.cjs"),r=require("./concurrency.cjs"),i=require("./crypto.cjs"),a=require("./githubTemplates.cjs"),o=require("./
|
|
1
|
+
"use strict";Object.defineProperty(exports,Symbol.toStringTag,{value:`Module`});const e=require("./appEnv.cjs"),t=require("./array.cjs"),n=require("./assert.cjs"),r=require("./concurrency.cjs"),i=require("./crypto.cjs"),a=require("./githubTemplates.cjs"),o=require("./error.cjs"),s=require("./filePath.cjs"),c=require("./formatIsoDate.cjs"),l=require("./github.cjs"),u=require("./http.cjs"),d=require("./foreignCjk.cjs"),f=require("./humanize.cjs"),p=require("./mail.cjs"),m=require("./object.cjs"),h=require("./markdown.cjs"),g=require("./parseIsoDate.cjs"),_=require("./parseCommandLineArgs.cjs"),v=require("./number.cjs"),y=require("./prompt.cjs"),b=require("./promptFormatters.cjs"),x=require("./shuffle.cjs"),S=require("./recoverJson.cjs"),C=require("./sleep.cjs"),w=require("./sqlite.cjs"),T=require("./text.cjs"),E=require("./testingRules.cjs"),D=require("./throttledFetch.cjs"),O=require("./timeout.cjs"),k=require("./url.cjs"),A=require("./yaml.cjs"),j=require("./zenkaku.cjs");exports.BUG_ISSUE_SECTIONS=a.BUG_ISSUE_SECTIONS,exports.CHANGE_ISSUE_SECTIONS=a.CHANGE_ISSUE_SECTIONS,exports.ISSUE_TEMPLATE_RULES=a.ISSUE_TEMPLATE_RULES,exports.PULL_REQUEST_BODY_RULES=a.PULL_REQUEST_BODY_RULES,exports.PULL_REQUEST_REQUIREMENTS_RULES=a.PULL_REQUEST_REQUIREMENTS_RULES,exports.PULL_REQUEST_SECTIONS=a.PULL_REQUEST_SECTIONS,exports.TEST_WRITING_RULES=E.TEST_WRITING_RULES,exports.chunk=t.chunk,exports.clamp=v.clamp,exports.createThrottledFetch=D.createThrottledFetch,exports.detectForeignCjkInJapanese=d.detectForeignCjkInJapanese,exports.ensureTruthy=n.ensureTruthy,exports.errorify=o.errorify,exports.escapeHtml=T.escapeHtml,exports.escapeLikePattern=w.escapeLikePattern,exports.escapePromptTag=y.escapePromptTag,exports.escapeRegExp=T.escapeRegExp,exports.extractCodeBlocks=h.extractCodeBlocks,exports.extractIfSingleOutermostCodeBlock=h.extractIfSingleOutermostCodeBlock,exports.extractSections=h.extractSections,exports.extractTaggedCodeBlock=h.extractTaggedCodeBlock,exports.findForeignCjkCharactersInJapanese=d.findForeignCjkCharactersInJapanese,exports.forEachConcurrently=r.forEachConcurrently,exports.formatDuration=f.formatDuration,exports.formatElapsedTimeInJapanese=f.formatElapsedTimeInJapanese,exports.formatFilesForPrompt=b.formatFilesForPrompt,exports.formatIsoDateInTimeZone=c.formatIsoDateInTimeZone,exports.formatMessagesForPrompt=b.formatMessagesForPrompt,exports.formatPrompt=y.formatPrompt,exports.getAppEnv=e.getAppEnv,exports.getConnectionLevelSqlitePragmas=w.getConnectionLevelSqlitePragmas,exports.getErrorMessage=o.getErrorMessage,exports.getFileExtension=s.getFileExtension,exports.getFormString=u.getFormString,exports.getPersistentSqlitePragmas=w.getPersistentSqlitePragmas,exports.getSafeRedirectPath=k.getSafeRedirectPath,exports.getTildeFence=T.getTildeFence,exports.hasErrorCode=o.hasErrorCode,exports.humanizeNumber=f.humanizeNumber,exports.ignoreEnoent=o.ignoreEnoent,exports.ignoreEnoentAsync=o.ignoreEnoentAsync,exports.ignoreError=o.ignoreError,exports.ignoreErrorAsync=o.ignoreErrorAsync,exports.isRecord=m.isRecord,exports.mailTemplates=p.mailTemplates,exports.mapConcurrently=r.mapConcurrently,exports.omitUndefined=m.omitUndefined,exports.parseBearerToken=u.parseBearerToken,exports.parseCommandLineArgs=_.parseCommandLineArgs,exports.parseGitHubRepositoryFullName=l.parseGitHubRepositoryFullName,exports.parseIsoDate=g.parseIsoDate,exports.parseMarkdownSections=h.parseMarkdownSections,exports.parsePositiveInteger=v.parsePositiveInteger,exports.quoteForShell=T.quoteForShell,exports.raceWithTimeout=O.raceWithTimeout,exports.recoverJson=S.recoverJson,exports.renderSectionChecklist=a.renderSectionChecklist,exports.renderSectionTemplate=a.renderSectionTemplate,exports.serializeForPrompt=y.serializeForPrompt,exports.serializeForPromptInTag=y.serializeForPromptInTag,exports.sha256HexAsync=i.sha256HexAsync,exports.shuffle=x.shuffle,exports.shuffleWithSeed=x.shuffleWithSeed,exports.sleep=C.sleep,exports.timingSafeEqualStringAsync=i.timingSafeEqualStringAsync,exports.toCodeBlock=T.toCodeBlock,exports.toTildeCodeBlock=T.toTildeCodeBlock,exports.truncate=T.truncate,exports.truncateForPrompt=y.truncateForPrompt,exports.unwrapFencedReply=T.unwrapFencedReply,exports.withRetry=o.withRetry,exports.yamlStringifyOptions=A.yamlStringifyOptions,exports.zenkakuAlphanumericalsToHankaku=j.zenkakuAlphanumericalsToHankaku;
|
package/dist/index.js
CHANGED
|
@@ -1 +1 @@
|
|
|
1
|
-
import{getAppEnv as e}from"./appEnv.js";import{chunk as t}from"./array.js";import{ensureTruthy as n}from"./assert.js";import{forEachConcurrently as r,mapConcurrently as i}from"./concurrency.js";import{sha256HexAsync as a,timingSafeEqualStringAsync as o}from"./crypto.js";import{BUG_ISSUE_SECTIONS as s,CHANGE_ISSUE_SECTIONS as c,ISSUE_TEMPLATE_RULES as l,PULL_REQUEST_BODY_RULES as u,PULL_REQUEST_REQUIREMENTS_RULES as d,PULL_REQUEST_SECTIONS as f,renderSectionChecklist as p,renderSectionTemplate as m}from"./githubTemplates.js";import{
|
|
1
|
+
import{getAppEnv as e}from"./appEnv.js";import{chunk as t}from"./array.js";import{ensureTruthy as n}from"./assert.js";import{forEachConcurrently as r,mapConcurrently as i}from"./concurrency.js";import{sha256HexAsync as a,timingSafeEqualStringAsync as o}from"./crypto.js";import{BUG_ISSUE_SECTIONS as s,CHANGE_ISSUE_SECTIONS as c,ISSUE_TEMPLATE_RULES as l,PULL_REQUEST_BODY_RULES as u,PULL_REQUEST_REQUIREMENTS_RULES as d,PULL_REQUEST_SECTIONS as f,renderSectionChecklist as p,renderSectionTemplate as m}from"./githubTemplates.js";import{errorify as h,getErrorMessage as g,hasErrorCode as _,ignoreEnoent as v,ignoreEnoentAsync as y,ignoreError as b,ignoreErrorAsync as x,withRetry as S}from"./error.js";import{getFileExtension as C}from"./filePath.js";import{formatIsoDateInTimeZone as w}from"./formatIsoDate.js";import{parseGitHubRepositoryFullName as T}from"./github.js";import{getFormString as E,parseBearerToken as D}from"./http.js";import{detectForeignCjkInJapanese as O,findForeignCjkCharactersInJapanese as k}from"./foreignCjk.js";import{formatDuration as A,formatElapsedTimeInJapanese as j,humanizeNumber as M}from"./humanize.js";import{mailTemplates as N}from"./mail.js";import{isRecord as P,omitUndefined as F}from"./object.js";import{extractCodeBlocks as I,extractIfSingleOutermostCodeBlock as L,extractSections as R,extractTaggedCodeBlock as z,parseMarkdownSections as B}from"./markdown.js";import{parseIsoDate as V}from"./parseIsoDate.js";import{parseCommandLineArgs as H}from"./parseCommandLineArgs.js";import{clamp as U,parsePositiveInteger as W}from"./number.js";import{escapePromptTag as G,formatPrompt as K,serializeForPrompt as q,serializeForPromptInTag as J,truncateForPrompt as Y}from"./prompt.js";import{formatFilesForPrompt as X,formatMessagesForPrompt as Z}from"./promptFormatters.js";import{shuffle as Q,shuffleWithSeed as $}from"./shuffle.js";import{recoverJson as ee}from"./recoverJson.js";import{sleep as te}from"./sleep.js";import{escapeLikePattern as ne,getConnectionLevelSqlitePragmas as re,getPersistentSqlitePragmas as ie}from"./sqlite.js";import{escapeHtml as ae,escapeRegExp as oe,getTildeFence as se,quoteForShell as ce,toCodeBlock as le,toTildeCodeBlock as ue,truncate as de,unwrapFencedReply as fe}from"./text.js";import{TEST_WRITING_RULES as pe}from"./testingRules.js";import{createThrottledFetch as me}from"./throttledFetch.js";import{raceWithTimeout as he}from"./timeout.js";import{getSafeRedirectPath as ge}from"./url.js";import{yamlStringifyOptions as _e}from"./yaml.js";import{zenkakuAlphanumericalsToHankaku as ve}from"./zenkaku.js";export{s as BUG_ISSUE_SECTIONS,c as CHANGE_ISSUE_SECTIONS,l as ISSUE_TEMPLATE_RULES,u as PULL_REQUEST_BODY_RULES,d as PULL_REQUEST_REQUIREMENTS_RULES,f as PULL_REQUEST_SECTIONS,pe as TEST_WRITING_RULES,t as chunk,U as clamp,me as createThrottledFetch,O as detectForeignCjkInJapanese,n as ensureTruthy,h as errorify,ae as escapeHtml,ne as escapeLikePattern,G as escapePromptTag,oe as escapeRegExp,I as extractCodeBlocks,L as extractIfSingleOutermostCodeBlock,R as extractSections,z as extractTaggedCodeBlock,k as findForeignCjkCharactersInJapanese,r as forEachConcurrently,A as formatDuration,j as formatElapsedTimeInJapanese,X as formatFilesForPrompt,w as formatIsoDateInTimeZone,Z as formatMessagesForPrompt,K as formatPrompt,e as getAppEnv,re as getConnectionLevelSqlitePragmas,g as getErrorMessage,C as getFileExtension,E as getFormString,ie as getPersistentSqlitePragmas,ge as getSafeRedirectPath,se as getTildeFence,_ as hasErrorCode,M as humanizeNumber,v as ignoreEnoent,y as ignoreEnoentAsync,b as ignoreError,x as ignoreErrorAsync,P as isRecord,N as mailTemplates,i as mapConcurrently,F as omitUndefined,D as parseBearerToken,H as parseCommandLineArgs,T as parseGitHubRepositoryFullName,V as parseIsoDate,B as parseMarkdownSections,W as parsePositiveInteger,ce as quoteForShell,he as raceWithTimeout,ee as recoverJson,p as renderSectionChecklist,m as renderSectionTemplate,q as serializeForPrompt,J as serializeForPromptInTag,a as sha256HexAsync,Q as shuffle,$ as shuffleWithSeed,te as sleep,o as timingSafeEqualStringAsync,le as toCodeBlock,ue as toTildeCodeBlock,de as truncate,Y as truncateForPrompt,fe as unwrapFencedReply,S as withRetry,_e as yamlStringifyOptions,ve as zenkakuAlphanumericalsToHankaku};
|
|
@@ -1,7 +1,7 @@
|
|
|
1
|
-
"use strict";const e=require("./
|
|
1
|
+
"use strict";const e=require("./prompt.cjs"),t=require("./text.cjs");function n(e,n=1){let i=`#`.repeat(n);return e.map(e=>`${i} ${r(e.path)}\n\n${t.toCodeBlock(e.data.replaceAll(/\r\n?/gu,`
|
|
2
2
|
`).trimEnd())}`).join(`
|
|
3
3
|
|
|
4
|
-
`)}function r(e){let t=1;for(let n of e.matchAll(/`+/gu))t=Math.max(t,n[0].length+1);let n="`".repeat(t);return`${n} ${e} ${n}`}function i(
|
|
4
|
+
`)}function r(e){let t=1;for(let n of e.matchAll(/`+/gu))t=Math.max(t,n[0].length+1);let n="`".repeat(t);return`${n} ${e} ${n}`}function i(t){let n=[.../* @__PURE__ */ new Set([`system`,`developer`,`user`,`assistant`,`tool`,...t.map(e=>e.role)])];return t.map(t=>{let r=t.content;for(let t of n)r=e.escapePromptTag(r,t);return`<${t.role}>\n${r}\n</${t.role}>`}).join(`
|
|
5
5
|
|
|
6
6
|
`)}exports.formatFilesForPrompt=n,exports.formatMessagesForPrompt=i;
|
|
7
7
|
//# sourceMappingURL=promptFormatters.cjs.map
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"promptFormatters.cjs","names":["toCodeBlock","escapePromptTag","
|
|
1
|
+
{"version":3,"file":"promptFormatters.cjs","names":["toCodeBlock","escapePromptTag","require_prompt","require_text","formatFilesForPrompt","headingMarker","headingLevel","files","formatPath","file","length","match","path","delimiter","formatMessagesForPrompt","roles","messages","message","content","role"],"sources":["../src/promptFormatters.ts"],"sourcesContent":["import { escapePromptTag } from './prompt.js';\nimport { toCodeBlock } from './text.js';\n\n/**\n * Renders files as Markdown sections for an LLM prompt: a heading holding the single-line path in inline code,\n * followed by the file contents in a code block whose fence the contents cannot close. Line endings are normalized\n * to LF and trailing whitespace is removed.\n * The output reads back with `extractSections` (keyed by path) and `extractIfSingleOutermostCodeBlock`, so an\n * LLM can be asked to answer in the same format.\n */\nexport function formatFilesForPrompt(files: readonly { path: string; data: string }[], headingLevel = 1): string {\n const headingMarker = '#'.repeat(headingLevel);\n return files\n .map(\n (file) =>\n `${headingMarker} ${formatPath(file.path)}\\n\\n${toCodeBlock(file.data.replaceAll(/\\r\\n?/gu, '\\n').trimEnd())}`\n )\n .join('\\n\\n');\n}\n\nfunction formatPath(path: string): string {\n let length = 1;\n for (const match of path.matchAll(/`+/gu)) length = Math.max(length, match[0].length + 1);\n const delimiter = '`'.repeat(length);\n return `${delimiter} ${path} ${delimiter}`;\n}\n\n/**\n * Renders chat messages as `<role>` elements separated by blank lines, e.g. to embed a conversation log in a prompt.\n * Escapes system, developer, user, assistant, tool, and every supplied role's tags in message contents.\n * Roles must be trusted literal tag names supplied by the caller. This preserves delimiters, not instruction priority.\n * To wrap the result in another element, escape that tag in the result with `escapePromptTag`.\n */\nexport function formatMessagesForPrompt(messages: readonly { role: string; content: string }[]): string {\n const roles = [\n ...new Set(['system', 'developer', 'user', 'assistant', 'tool', ...messages.map((message) => message.role)]),\n ];\n return messages\n .map((message) => {\n let content = message.content;\n for (const role of roles) content = escapePromptTag(content, role);\n return `<${message.role}>\\n${content}\\n</${message.role}>`;\n })\n .join('\\n\\n');\n}\n"],"mappings":"A,qEAUA,SAAgBI,EAAqB,EAAkD,EAAe,EAAW,CAC/G,IAAMC,EAAgB,IAAI,OAAOC,CAAY,EAC7C,OAAOC,EACJ,IACE,GACC,GAAGF,EAAc,GAAGG,EAAWC,EAAK,IAAI,EAAE,MAAMT,EAAAA,YAAYS,EAAK,KAAK,WAAW,UAAW;CAAI,CAAC,CAAC,QAAQ,CAAC,GAC/G,CAAC,CACA,KAAK;;CAAM,CAChB,CAEA,SAASD,EAAW,EAAsB,CACxC,IAAIE,EAAS,EACb,IAAK,IAAMC,KAASC,EAAK,SAAS,MAAM,EAAG,EAAS,KAAK,IAAIF,EAAQC,EAAM,EAAE,CAAC,OAAS,CAAC,EACxF,IAAME,EAAY,IAAI,OAAOH,CAAM,EACnC,MAAO,GAAGG,EAAU,GAAGD,EAAK,GAAGC,GACjC,CAQA,SAAgBC,EAAwB,EAAgE,CACtG,IAAMC,EAAQ,CACZ,mBAAG,IAAI,IAAI,CAAC,SAAU,YAAa,OAAQ,YAAa,OAAQ,GAAGC,EAAS,IAAK,GAAYC,EAAQ,IAAI,CAAC,CAAC,CAC7G,EACA,OAAOD,EACJ,IAAK,GAAY,CAChB,IAAIE,EAAUD,EAAQ,QACtB,IAAK,IAAME,KAAQJ,EAAO,EAAUd,EAAAA,gBAAgBiB,EAASC,CAAI,EACjE,MAAO,IAAIF,EAAQ,KAAK,KAAKC,EAAQ,MAAMD,EAAQ,KAAK,EAC1D,CAAC,CAAC,CACD,KAAK;;CAAM,CAChB,C"}
|
package/dist/promptFormatters.js
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
|
-
import{
|
|
1
|
+
import{escapePromptTag as e}from"./prompt.js";import{toCodeBlock as t}from"./text.js";function n(e,n=1){let i=`#`.repeat(n);return e.map(e=>`${i} ${r(e.path)}\n\n${t(e.data.replaceAll(/\r\n?/gu,`
|
|
2
2
|
`).trimEnd())}`).join(`
|
|
3
3
|
|
|
4
|
-
`)}function r(e){let t=1;for(let n of e.matchAll(/`+/gu))t=Math.max(t,n[0].length+1);let n="`".repeat(t);return`${n} ${e} ${n}`}function i(
|
|
4
|
+
`)}function r(e){let t=1;for(let n of e.matchAll(/`+/gu))t=Math.max(t,n[0].length+1);let n="`".repeat(t);return`${n} ${e} ${n}`}function i(t){let n=[.../* @__PURE__ */ new Set([`system`,`developer`,`user`,`assistant`,`tool`,...t.map(e=>e.role)])];return t.map(t=>{let r=t.content;for(let t of n)r=e(r,t);return`<${t.role}>\n${r}\n</${t.role}>`}).join(`
|
|
5
5
|
|
|
6
6
|
`)}export{n as formatFilesForPrompt,i as formatMessagesForPrompt};
|
|
7
7
|
//# sourceMappingURL=promptFormatters.js.map
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@willbooster/shared-lib",
|
|
3
|
-
"version": "11.
|
|
3
|
+
"version": "11.1.1",
|
|
4
4
|
"description": "Shared library for WillBooster projects",
|
|
5
5
|
"license": "Apache-2.0",
|
|
6
6
|
"author": "WillBooster Inc.",
|
|
@@ -50,13 +50,13 @@
|
|
|
50
50
|
"@tsconfig/bun": "1.0.11",
|
|
51
51
|
"@tsconfig/node-lts": "24.0.1",
|
|
52
52
|
"@tsconfig/node-ts": "23.6.4",
|
|
53
|
-
"@types/bun": "1.4.
|
|
54
|
-
"@types/node": "26.6.
|
|
53
|
+
"@types/bun": "1.4.4",
|
|
54
|
+
"@types/node": "26.6.6",
|
|
55
55
|
"@willbooster/oxlint-config": "1.4.9",
|
|
56
|
-
"@willbooster/wb": "
|
|
57
|
-
"build-ts": "21.0.
|
|
58
|
-
"oxlint": "1.
|
|
59
|
-
"oxlint-tsgolint": "7.0.
|
|
56
|
+
"@willbooster/wb": "23.4.0",
|
|
57
|
+
"build-ts": "21.0.33",
|
|
58
|
+
"oxlint": "1.92.0",
|
|
59
|
+
"oxlint-tsgolint": "7.0.2006",
|
|
60
60
|
"yaml": "2.9.1"
|
|
61
61
|
}
|
|
62
62
|
}
|