@phamvuhoang/otto-core 0.2.0 → 0.4.0

package/templates/linearprompt.md

@@ -0,0 +1,39 @@
+# ISSUES
+
+Two views of open Linear issues are provided at the start of context:
+
+- `<issues-summary>` — the `otto-linear list` command for the lean index
+  (identifier, title, state, url). Run it to triage and pick a task.
+- `<issues-full-file>` — path to a spilled JSON file containing full issue
+  detail (bodies + comments). `Read` that file (with `offset`/`limit` if it is
+  large) once you have picked an issue you want to act on.
+
+Issue selection is already filtered to open Linear issues carrying the `otto`
+label (override via `OTTO_LINEAR_LABEL`, narrow to a team via `OTTO_LINEAR_TEAM`).
+
+You've also been passed a file containing the last few commits. Review these to
+understand what work has been done.
+
+If all AFK tasks are complete, output <promise>NO MORE TASKS</promise>.
+
+# TASK SELECTION
+
+Pick the next task. Prioritize tasks in this order:
+
+1. Critical bugfixes
+2. Development infrastructure
+
+Getting development infrastructure like tests and types and dev scripts ready is an important precursor to building features.
+
+3. Tracer bullets for new features
+
+Tracer bullets are small slices of functionality that go through all layers of the system, allowing you to test and validate your approach early. This helps in identifying potential issues and ensures that the overall architecture is sound before investing significant time in development.
+
+TL;DR - build a tiny, end-to-end slice of the feature first, then expand it out.
+
+4. Polish and quick wins
+5. Refactors
+
+@include:ghprompt-workflow.md
+
+@include:linear-completion.md

package/templates/prompt.md

@@ -92,6 +92,10 @@ If, while doing the task, you discover a NEW durable, reusable learning — a re
 
 Dedupe against existing entries and prune anything no longer true. This file is committed WITH your task commit (it is git-tracked) — do NOT make a separate commit for it. The bar is durable AND reusable: do NOT record routine or one-off task details.
 
+# FINISHING THE RUN
+
+Committing the code is NOT necessarily the end of the run. How work "ships" depends on THIS repo's conventions — consult `<learnings>` / `./.otto/LEARNINGS.md`. If the repo ships via pull request, keep all work (including later review-fix rounds) on the SAME feature branch, and when it is complete `git push` the branch and open or refresh a single PR into the default branch — never spin up a second branch per round. Otherwise, committing to the working branch is the end-state.
+
 # FINAL RULES
 
 ONLY WORK ON A SINGLE TASK.