framework/dist/prompts.generated.js

The (AI) Framework: turnkey, zero-config AI orchestration that wraps a coding-agent CLI (Claude Code) as a black box and takes you from an idea to a running app. Vite for AI.

// Generated from prompts/**/*.md by scripts/gen-prompts.mjs. Do not edit.
// Edit the markdown instead; this file is rebuilt on every build/test/typecheck.
/** `prompts/data_branch_protocol.md` */
export const DATA_BRANCH_PROTOCOL = "# The data branch\n\nThe framework's own data — `tickets/**.md` (plans and locks included), `TODO_AGENTS.md`, the session archives — lives on the dedicated branch `tf-data`, never on code branches. Your checkout does not contain these files.\n\nRead them off the branch (fetch first): `git show tf-data:<FILE>` — `origin/tf-data:` when the local branch doesn't exist.\n\nWrite them, only when the instructions say to edit tickets or the queue, as a commit on `tf-data` pushed immediately — rebase and retry on a rejected push. Never switch your checkout to the branch, and never put these files on your session branch: a data change is pushed directly, it does not ride your PR.";
/** `prompts/on_before_mergeable_prompt.md` */
export const ON_BEFORE_MERGEABLE_PROMPT = "TODO_FILE: `TODO_AGENTS.md`\n\n## Maintenance\n\nIf the changes introduced by ${{ tf.session_name }} aren't trivial and have refactor potential, add the following to <TODO_FILE>\n- `Apply ${{ tf.presets.maintainability.filePath }} with tf.params.what set to \"changes introduced by ${{ tf.session_name }}\"`\nIf the changes introduced by ${{ tf.session_name }} can potentially lead to security issues, add the following to <TODO_FILE>\n- `Apply ${{ tf.presets.security_audit.filePath }} with tf.params.what set to \"changes introduced by ${{ tf.session_name }}\"`\n\n\n## Business knowledge\n\nIf you didn't already, consider updating the following based on the changes and discussions of ${{ tf.session_name }} (you can create the files if they're missing):\n- `knowledge-base/DECISIONS.md` (decisions taken, and why)\n- `knowledge-base/FACTS.md` (non-obvious facts relevant to the project)\n- `knowledge-base/INSIGHTS.md` (insights relevant to the project)\n\nOnly write what a future agent would need and cannot get from the code itself.";
/** `prompts/presets/drain_queue.md` */
export const PRESETS_DRAIN_QUEUE = "Open TODO_AGENTS.md and work on the FIRST open entry only. When the work is done and published, check the entry off. Do not start any other entry.";
/** `prompts/presets/maintainability.md` */
export const PRESETS_MAINTAINABILITY = "Refactor ${{ tf.params.what }} to make it as maintainable as possible:\n- Look for maintainability red flags, and fix them.";
/** `prompts/presets/maintenance.md` */
export const PRESETS_MAINTENANCE = "Analyze ${{ tf.params.what }} and look for opportunities to refactor code.\n\nFor each codebase subset that needs it, add following entries to TODO_AGENTS.md (usually as low priority) and replace <CODEBASE_SUBSET> with a clear designation.\n- \"Apply ${{ tf.presets.maintainability.filePath }} with tf.params.what set to <CODEBASE_SUBSET>\"\n- \"Apply ${{ tf.presets.security_audit.filePath }} with tf.params.what set to <CODEBASE_SUBSET>\"";
/** `prompts/presets/market_research.md` */
export const PRESETS_MARKET_RESEARCH = "- Make a thorough market research\n- Write it to `knowledge-base/MARKET_RESEARCH.md`\n- Add TODO_AGENTS.md entry: \"Read <SESSION_NAME> then suggest new tickets\"\n\nSESSION_NAME: the name of the session";
/** `prompts/presets/plan_tickets.md` */
export const PRESETS_PLAN_TICKETS = "For the <COUNT> most important tickets `tickets/<TICKET>.md` without `<TICKET>.plan.md` and `<TICKET>.lock.md`, add the following to TODO_AGENTS.md\n- \"Create tickets/<TICKET>.plan.md\"\n\nPut the entries in the right `## Priority` following a mix of sensible criteria after reading `tickets/<TICKET>.md` (e.g. if ticket seems low effort => higher priority).\n\nCOUNT: 10";
/** `prompts/presets/readability.md` */
export const PRESETS_READABILITY = "Refactor ${{ tf.params.what }} to make it as easy as possible for humans to read:\n- Pinnacle architectural split\n  - Does each file and each <FUNCTION> represent a sensible and natural abstraction?\n  - Rate the *seams*, not just the boxes: for each call site, ask whether the responsibility sits on the right side of the boundary — should a caller's wrapper move down into the callee (or vice versa)? A <FUNCTION> can be clean, DRY and well-tested in isolation yet still be in the wrong place. \"Well-factored\" is not \"well-located\".\n- Linearity (for humans)\n  - Put yourself in the shoes of a human reader who reads everything in a linear fashion\n  - Top to bottom: place callers above callees so readers encounter high-level logic before implementation details (humans think high-level first)\n  - Altitude pass: for each entry-point / orchestration <FUNCTION>, read it top-to-bottom as prose. Flag any line that drops the reader into lower-level mechanism (a flag, a thunk, a log verb, error plumbing) in the middle of what should be a high-level narrative. For each, ask: can that mechanism move down into the callee so the caller reads at one consistent altitude? Prioritize the reading path of all the <FUNCTION> a reader hits first.\n- Before starting to work: list *ALL* files and *ALL* <FUNCTION> in this chat, rate them all (0: convoluted abstraction, hard to read, wrong place — 10: perfect), and give a reason for your rating\n  - DON'T skip any file nor any <FUNCTION> in your rating list — write an extra separated list in this chat of all files and all <FUNCTION> and put a ✅ tick to each entry to double check whether you forgot to rate something. So two lists: one list of ratings & explanation, and a second confirmation list.\n- Separate commit for each refactor\n- Work until it's exceptionally good. We as an expert team will check against every little detail.\n  - If we see that you gave mostly a 10/10 rating, that's a sign you've been lazy... so make sure you scrutinize everything and spend a substantial amount of time. We don't want to prompt you again and again to achieve quality — autonomously strive for quality on your own without us pushing you.\n- Give summary of what you worked on: print the lists again with old rating => new rating with link to commit(s)\n\nFUNCTION: an actual function or a class, procedure, etc. (anything that represents a unit of logic)";
/** `prompts/presets/research.md` */
export const PRESETS_RESEARCH = "Measure \"problem variability\" of ${{ tf.params.what }}\n- List all high-level flows the code implements, i.e. the list of all \"problems\" the code solves\n- Give a rating for each problem (from 0 to 10) following this criteria: does the code solves the problem in an obviously optimal way (10), or is it highly unclear whether the problem can be solved in a better way (0)?\n- Write down the ratings in a new file <REVIEW_FILE>\n- Show the list to the user and enable him to select problems via `showMultiSelect()`, <AWAIT>\n  - Set default to `true` for entries with low rating\n- For all problems the user selected, add a new entry to <TODO_FILE>\n  - The entry: \"Deep-dive research for alternative solutions, see <REVIEW_FILE>\"\n\nAWAIT: Stop, await user answer before resuming\nREVIEW_FILE: `REVIEW-PROBLEMS_<SESSION_NAME>.agent.md`\nTODO_FILE: `TODO_<SESSION_NAME>.agent.md`\nSESSION_NAME: the name of the current Git branch — sanitize it to be a SLUG, if name is generic (e.g. `main`) then create a succinct SLUG";
/** `prompts/presets/security_audit.md` */
export const PRESETS_SECURITY_AUDIT = "Security audit ${{ tf.params.what }}\n- Scrutinize the entire code for potential security issues\n- Make it exhaustive (100% coverage)\n- List every aspect you considered and, for each aspect, include a verdict as well as an explanation for non-obvious verdicts\n- If you see any security issue, fix each security issue in a separate commit";
/** `prompts/presets/suggest_new_features.md` */
export const PRESETS_SUGGEST_NEW_FEATURES = "1. Study what this product does today: skim the README, the docs, and the main user-facing surfaces, plus the existing `tickets/`\n2. Think like a product manager and propose net-new features the product should have next\n   - Net-new capabilities a user would want, not bugs, refactors, or chores\n   - Skip anything an existing ticket already covers, and anything already built\n   - Favour features that fit the product's direction and are worth building\n3. Write each proposed feature as a new ticket under `tickets/`, following the ticket format\n4. Show a short summary of what you proposed via `showMarkdown()`";
/** `prompts/presets/suggest_new_tickets.md` */
export const PRESETS_SUGGEST_NEW_TICKETS = "Suggest new tickets";
/** `prompts/presets/suggest_tickets_to_work_on.md` */
export const PRESETS_SUGGEST_TICKETS_TO_WORK_ON = "1. Look at all tickets and pick tickets to work on next\n2. Show the tickets you picked via `showMultiSelect()`\n  - For each ticket, if high confidence the ticket is a good candidate to work on next => set its default to `true`, otherwise `false`\n3. <AWAIT>\n4. Add approved tickets to `TODO_AGENTS.md`\n\nAWAIT: Stop, await user answer before resuming";
/** `prompts/presets/triage_consensual.md` */
export const PRESETS_TRIAGE_CONSENSUAL = "1. Look at all tickets and choose tickets to work on next\n   - Only pick tickets that are significant (no quick-wins) and consensual (zero open questions, zero variability, e.g. a single fairly obvious plan)\n2. Add tickets to TODO_AGENTS.md\n\nAlways set <SESSION_NAME> to triage-consensual\n- If branch tf-<SESSION_NAME> already exists, abort and tell user that the branch already exists and that triage is already pending.";
/** `prompts/presets/triage_quick.md` */
export const PRESETS_TRIAGE_QUICK = "Look at `tickets/*` and choose tickets to work on next:\n- Pick a ticket if it has a `.plan.md` that shows it's a quick-win (low `effort` value) with `uncertainty: 0`\n- Add tickets to TODO_AGENTS.md\n  - With sensible prioritization, and consider bumping the priority of lowest effort tickets (e.g. to make `effort: 0` the next tasks agents work on)\n\nAlways set <SESSION_NAME> to triage-quick\n- If branch tf-<SESSION_NAME> already exists, abort and tell user the branch already exists and triage is already pending.";
/** `prompts/presets/update_tickets.md` */
export const PRESETS_UPDATE_TICKETS = "Update `tickets/` from this repo's GitHub issues, bringing across what has changed since the last import rather than starting over — the whole update as one commit.\n\nNote the current UTC time before you fetch anything, in ISO 8601. That is the timestamp you will record at the end, and taking it first is deliberate: an issue edited while you work is then picked up by the next update instead of being missed.\n\nRead `tickets/meta.json` for `lastImportedAt`.\n\nDo one of the following:\n- [Error] If there are existing `tickets/*.md` but `lastImportedAt` is missing, or `gh` is missing or logged out, report the error — say which of those it is — and abort\n- [Empty] If `tickets/` is empty (or doesn't exist), treat it as a first import and bring every open issue across\n- [Update] Fetch only what changed: `gh issue list --state all --limit 500 --json number,title,body,state,labels,updatedAt --search \"updated:>=<lastImportedAt>\"`, and the discussion with `gh api --paginate \"repos/{owner}/{repo}/issues/comments?since=<lastImportedAt>\"`\n\nThen reconcile, one ticket file per issue:\n- An issue with no ticket yet gets one\n- An issue that already has a ticket has that ticket updated in place. Keep its filename, and keep its `.plan.md` but consider setting `outdated: yes`.\n- New comments are worth folding into the ticket only where they change what the work is. Do not paste the thread.\n- If an issue is now closed, remove its ticket, `.plan.md`, and `.lock.md`\n\nFinish by writing `tickets/meta.json` as `{\"lastImportedAt\": \"<the UTC time you noted at the start>\"}`, and say in one line how many tickets you added, updated and removed.";
/** `prompts/presets/ux.md` */
export const PRESETS_UX = "Review all UI flows of ${{ tf.params.what }}\n1. Before starting to work: list *ALL* UI flows\n   - DON'T skip any UI flow (100% coverage)\n2. Then, give a UX rating for each UI flow (10: perfect UX, 0: unusable UX), and give a reason for your rating\n3. Improve UI flows with bad UX rating\n   - Separate commit for each UI flow you improved\n   - Work until it's exceptionally good. We as an expert team will check against every little detail.\n     - If we see that you gave mostly a 10/10 rating, that's a sign you've been lazy... so make sure you scrutinize everything and spend a substantial amount of time. We don't want to prompt you again and again to achieve quality — autonomously strive for quality on your own without us pushing you.\n   - Give summary of what you worked on: print the UI flow list again with old rating => new rating with link to commits";
/** `prompts/protocols/await.md` */
export const PROTOCOLS_AWAIT = "## Awaiting a choice\nWhen these instructions tell you to showChoices() / showMultiSelect() / showMarkdown() and then AWAIT, do not decide for the user.\nEnd your turn with one fenced code block, then stop.\nTag it `await-choices`:\n```await-choices\n{ \"title\": \"<the question>\", \"options\": [{ \"label\": \"<option>\", \"detail\": \"<optional one-liner>\" }], \"recommended\": \"<the label to default to>\" }\n```\nEvery question you stop to ask is this one block, whatever it is about:\n- An approval is two options: `{ \"title\": \"Ship this?\", \"options\": [{ \"label\": \"Approve\" }, { \"label\": \"Decline\", \"stop\": true }], \"recommended\": \"Approve\" }`.\n- A plan or document you wrote and want signed off adds `\"file\": \"PLAN_<slug>.agent.md\"`, and the framework shows that file beside the question.\n- Several answers at once (showMultiSelect) adds `\"multi\": true`, and `\"default\": true` on the entries that start checked.\n- `recommended` is what the framework picks when nobody is there to answer, so name the option that is safe to take unattended — never an option marked `stop`.\n- `\"stop\": true` marks an answer that ends the session instead of resuming you: the user is taking over and will come back with fresh instructions. Mark the option that rejects your work — declining a plan, saying no to the approach — and leave it off everything else. You are not re-prompted with that answer, so do not plan around being told it.\n\nThe framework shows it, waits for the user, and re-prompts you with their answer. Do not continue past it on your own.\n\n## Handing the browser to a human\nWhen you are working in a browser and hit something you cannot or should not get past yourself — a login wall, a captcha, an SSO or 2FA step — stop and hand it over. Never type a password, never attempt a captcha, and never use a credential you found lying around in the repo or the environment. Ask with the same `await-choices` block, naming the page and recommending the option that is true when nobody is there:\n```await-choices\n{ \"title\": \"<what the human needs to do> (<the page you are stuck on>)\", \"options\": [{ \"label\": \"Handled it\" }, { \"label\": \"Could not handle it\" }], \"recommended\": \"Could not handle it\" }\n```\nThe user acts in that browser, then you are re-prompted. If their answer says it was not handled, do not retry the same page — say what you could not reach and work on what you can, or stop.\n\n## Showing a document without waiting\nTo display markdown in the side panel without blocking (a plan, a summary, a writeup) and keep working, put a `show-markdown` block anywhere in your turn. The first line is its title:\n```show-markdown\n# <title>\n<the markdown body>\n```\nThis just shows it; you do not stop. Re-emit the same title to update that view in place.";
/** `prompts/protocols/browser.md` */
export const PROTOCOLS_BROWSER = "## You have a real browser\n\nThis run has a real Chrome attached, through the `chrome-devtools` tools (`new_page`, `navigate_page`, `click`, `fill`, `take_snapshot`, `evaluate_script`). It is the same browser a human can watch and take over, so use it for anything you need to *see* or *act on*: pages that render their content with JavaScript, a flow you have to click through, a form to fill, an app you are checking actually works.\n\nWhen you only need to read a page, `WebFetch` is still the better tool: it is faster and hands you the text directly. Use the browser when `WebFetch` would come back with nothing useful, such as a page that is blank until its JavaScript runs.\n\nPrefer navigating within a single page rather than opening new pages, so the user can more easily watch you navigate.";
/** `prompts/protocols/hands_off.md` */
export const PROTOCOLS_HANDS_OFF = "## This session runs detached — decide alone, land everything\nIt was handed to a remote service: nothing that can answer a gate is attached to it, and no\nmachine sees its workspace. Two consequences:\n- Where these instructions say to showChoices() / showMultiSelect() / showMarkdown() and then\n  AWAIT: do not emit the await block and do not stop — take the most plausible interpretation,\n  the option you would have marked `recommended`, state in one line which assumption you made,\n  and carry the work through to the end. The non-blocking blocks (show-markdown,\n  set-session-name, ready-for-merge) are unaffected.\n- Before ending: commit your work on your session branch and open a pull request for it. If the\n  deliverable is analysis, a plan, or a decision, write it into committed files — a result that\n  lives only in this conversation, or in a gitignored file, reaches nobody. End without a pull\n  request only when the task genuinely required no repository change, and say so explicitly in\n  your final message.";
/** `prompts/protocols/signal.md` */
export const PROTOCOLS_SIGNAL = "## Session name\nWhen you call setSessionName(<name>) (after creating and checking out the `tf-<name>` branch), also emit a `set-session-name` block naming it, so the dashboard shows which session this is. The first non-empty line is the name (a `[a-z0-9-]` slug):\n```set-session-name\n<name>\n```\nYou do not stop; re-emit it if you rename the session.\n\n## Ready for merge\nWhen you call setReadyForMerge() — you believe the work is complete and ready for human review — emit an empty `ready-for-merge` block. This flips the dashboard status from building to ready; it does not stop your turn.\n```ready-for-merge\n```\n\n## Opening a pull request\nWhenever you emit `ready-for-merge`, emit an `open-pr` block too, naming and describing the work. The Framework opens the pull request for you — you do not need to run `gh pr create` yourself. Write it like a commit message: the first line is the title, the rest is the body.\n```open-pr\n<one line naming what the change does, under 100 characters>\n\n<what changed, and why — markdown, as long as it needs to be>\n```\nWithout it the pull request has no name for your work and can only repeat the prompt you were given, which does not say what the work turned out to be. The Framework supplies the rest: the ticket's issue reference where there is one, and recording the number so every surface shows the same pull request. You do not stop, and you can re-emit it as the work changes — the last one is used. Opening the pull request yourself instead still works; you then own all of the above.\n\n## Reporting an error\nWhen you hit something only the user can fix — a missing file you were told to read, a command that will not run, a login you do not have — emit an `error` block saying what is wrong, then carry on or stop as the task requires. The first line is the headline; anything below it is the detail.\n```error\n<what is wrong, in one line>\n\n<the detail: what you ran, what it said>\n```\nThe Framework marks it in the session log and counts it on the session, so the user sees it without reading the whole log. It does not stop your turn and it does not ask the user anything — use `AWAIT` for a question. Report the same thing once: a re-emitted identical block is ignored.";
/** `prompts/system_prompt.md` */
export const SYSTEM_PROMPT = "# System prompt\n\nSHOW_MD: Show it via `showMarkdown()`\nSHOW_CHOICES: Show it via `showChoices()`\nAWAIT: Stop, await user answer before resuming\nSESSION_NAME: the name of the session\nTODO_FILE: `TODO_AGENTS.md`\n\n## Analyze the user prompt\n\nAnalyze the user prompt and follow the instructions below.\n\n### Ambiguous prompt\n\nIf it isn't clear what you should do (e.g. unclear scope, unclear user prompt), make a list of interpretations sorted by plausibility, <SHOW_CHOICES>, <AWAIT>\n\n### Scope\n\n- If the scope of what you'll work on is *large*, create a `PLAN_<SESSION_NAME>.agent.md` of what you'll work on, <SHOW_MD>, <AWAIT>\n- If the scope is potentially *very large* (e.g. spans over many hours/days of work), consider adding entries to <TODO_FILE> (backlog of follow-up tasks) and show new entries <SHOW_MD>\n\n\n## Before starting changes\n\nDo the following before applying your first change.\n\n### Workspace\n\nYour working directory is the whole of your workspace. Every file you read or write is under it.\n\n- Address files relative to it. An absolute path is how you leave it without noticing\n- It may sit *inside* another checkout of the same repo. That outer copy is the user's own working tree — not another view of your files, and never yours to edit\n- The same file can therefore exist twice. The one under your working directory is yours; editing the other one puts your work somewhere your branch and your commits cannot reach it\n- If something you need is genuinely outside, say so and stop — do not reach for it\n\n### Session name\n\n1. Create a <SESSION_NAME> as a string [a-z0-9-]+ that succinctly represents the intention of the user prompt\n2. Create a new branch `tf-<SESSION_NAME>` and `$ git checkout` it — do all the work in that branch\n3. Call setSessionName(<SESSION_NAME>)\n\n\n## Before applying changes\n\nDo the following before applying changes — do it again anytime you make new changes.\n\n### Alternatives\n\nMeasure \"variability\":\n- List all high-level problems that you're about to solve\n- Give a rating to each problem (from 0 to 10) following this criteria: is there an obviously optimal way to solve the problem (10), or is it highly unclear whether the problem can be solved in a better way (0)?\n- Explore and suggest alternatives for problems with a low rating\n- For each problem that has alternatives: list all alternatives sorted in a sensible order, <SHOW_CHOICES>, <AWAIT>\n\n\n## After applying changes\n\nAfter you're done, decide: is <SESSION_NAME> finished, with no work left to do?\n- Yes: call setReadyForMerge() — required, the work is never merged without it\n- No: don't call it; say what's left instead\n\n\n\n# User prompt\n\n${{tf.prompt}}";
/** `prompts/ticketing_format.md` */
export const TICKETING_FORMAT = "# Ticketing format\n\n\n## tickets/<DATE>_<SLUG>.md\n\nDATE: yyyy-mm-dd\nSLUG: succinct kebab-case slug of the ticket title\nBody:\n```md\nPriority: 0-10 [optional, 10: critical — act immediately, 0: only if capacity]\nTopics: [list-of-topics] [optional]\nGitHub: [#42](https://github.com/org/repo/issues/42) [optional]\n\n# Ticket title\n\n## TLDR\n\n...\n\n## Why it matters\n\n...\n\n[optional: more info (any heading and format you want)]\n```\n\nWhen a ticket is closed, it should be removed from the repository (also its `.plan.md` and `.lock.md`), so that `tickets/*` only contains open tickets.\n\n\n## tickets/<DATE>_<SLUG>.lock.md\n\nBody:\n```md\nCLAIMED: <SESSION_ID> (<SESSION_NAME>)\n```\n\nWhenever an agent is working/planning a ticket, a `.lock.md` file must be created to avoid two agents working/planning the same ticket. If pushing the lock hits a conflict on that same `.lock.md`, another agent claimed the ticket first: back off and pick something else — never resolve the conflict in your favor.\n\n\n## tickets/<DATE>_<SLUG>.plan.md\n\nFor an existing ticket (e.g. `tickets/2042-01-01_some-ticket.md`), a plan can be created (`tickets/2042-01-01_some-ticket.plan.md`).\n\nBody:\n```md\nEffort: 0-10 [0: implementation is trivial, 10: implementation takes months]\nUncertainty: 0-10 [0: implementation without meaningful alternatives, 10: highly uncertain how to implement]\nOutdated: yes [optional, only if the ticket was updated in a way that makes the plan outdated]\n\n# [Plan] Ticket title\n\nSingle-sentence describing this file's content.\n\n## TLDR [optional]\n\nBrief overiew of this file's content.\n\n## Problems [optional]\n\nList of all significant aspects with low confidence on how to implement, with explanation why uncertain.\n\n## Solutions [optional]\n\nFor each problem, list of ways to solve the problem (including meaningful shortcuts, for quicker implementation).\n\n## Considerations [optional]\n\nExhaustive list of all significant aspects to be considered (including edge cases).\n\n## Implementation [optional]\n\nConcrete plan to implement the ticket.\n```\n\nNotes:\n- Covers both spiking (e.g. high-level research without implementation plan) and planning (e.g. concrete implementation proposal)\n- The `.plan.md` file can be modified multiple times over an extended period (e.g. a ticket requiring repeated human intervention, transitioning from spiking to concrete plan)\n- All sections are just proposals and optional: you can use any headings with any format\n- The uncertainty value:\n  - Gauges whether there are *significant* alternatives, minor variability such as syntax should be ignored\n  - Is used for evaluating whether human intervention is needed (0 => clearly no human intervention needed)\n- Example of how to gauge uncertainty and alternatives:\n  - List all aspects that need to be considered\n  - Give an uncertainty rating (0-10) to each aspect following this criteria: is there an obviously optimal way to implement it (0), or is it highly unclear whether it can be implemented in a better way (10)?\n  - Explore and suggest alternatives for each aspect with a low rating";
/** `prompts/todo_format.md` */
export const TODO_FORMAT = "# TODO_AGENTS.md\n\nContent:\n```md\n## Priority 10 (critical — act immediately)\n\n...\n\n## Priority 9\n\n- [Succinct description](/link-for-more-details)\n- Or self-contained TODO item with complete description of what should be done\n\n...\n\n## Priority 0 (only if capacity)\n\n...\n```\n\nThe TODO_AGENTS.md file lists *all* tasks AI will work on next, sorted by priority.\n\nTo remove an item (e.g. when done), simply remove it from `TODO_AGENTS.md`.\n\nPriority 10 is rarely used (e.g. critical production bugs) and should be treated as utmost priority.\n\nWithin a priority, the first tasks have higher priority (they're the \"next\" tasks within that \"priortiy queue\").";
//# sourceMappingURL=prompts.generated.js.map