Support auth sign-in methods

.agents/rules/autogoal.mdc

@@ -560,9 +560,13 @@ Gate closure rules:
    threshold, verification surface, constraints, boundaries, blocked condition,
    flow mode, and goal plan path; resolve generated gates as yes/no/N/A instead
    of deleting or replacing the template output.
-10. Use that exact path for
+10. Record the output-budget strategy before exploratory commands: which
+    searches or reads are allowed, which high-volume paths are excluded, and
+    how large results will be capped, counted, or saved as artifacts instead of
+    streamed into the goal context.
+11. Use that exact path for
     `check-complete.mjs`.
-11. Do not start durable work until the goal is set, verified as already matching,
+12. Do not start durable work until the goal is set, verified as already matching,
     or the user explicitly resolves the missing-goal path.
 
 Set the goal before mutable lane state when the workflow depends on a goal. For
@@ -789,6 +793,10 @@ Boundaries:
 
 - <allowed files/packages/tools>
 
+Output budget strategy:
+
+- <how command/search output will be scoped, capped, counted, or artifacted>
+
 Blocked condition:
 
 - <condition that stops autonomous work>
@@ -1005,6 +1013,35 @@ Attempted:
 
 Budget exhaustion is not success.
 
+## Output Budget Discipline
+
+Goal token budgets are real work budgets, not decorative counters. A goal run
+that burns its budget on tool output has failed the workflow even when no app
+code was touched.
+
+Before running exploratory commands inside an active goal:
+
+- Prefer narrow reads over broad scans: exact files, focused `rg -n` patterns,
+  targeted globs, and short `sed -n` ranges.
+- Treat `tmp/**`, logs, binaries, generated output, build artifacts,
+  `node_modules`, `.next`, `.turbo`, and coverage folders as excluded by
+  default. Include them only when they are the named source of truth.
+- Set explicit tool output caps for commands likely to return more than a
+  screenful. Keep ordinary source reads around a few thousand tokens, and
+  justify any larger cap in the plan.
+- For broad audits, first ask for counts, filenames, or top matches
+  (`rg --count`, `rg --files-with-matches`, `--max-count`, `wc`, `head`) before
+  printing matching lines.
+- If a result may be large but still matters, write it to a local artifact and
+  inspect slices from that artifact. Do not stream the full result into the
+  conversation.
+- Never run unbounded `rg` across the whole repo plus `tmp/api`, logs, or binary
+  outputs during a budgeted goal. Split the search by owner or exclude the noisy
+  trees first.
+- After any accidental large output, stop broad exploration immediately, record
+  the miss in the error-attempts row, and continue only with constrained
+  commands.
+
 If the system stops or warns because a goal budget is reached:
 
 - stop substantive work

.agents/rules/task.mdc

@@ -288,20 +288,28 @@ task final handoff. Do not use a generic `Summary` / `Verification` PR body, an
 adaptive prose body from `git-commit-push-pr`, or a generated badge footer
 unless the caller or repo template explicitly asks for it.
 
-Use this order:
+Use the accepted task PR format from PR #270. The shape is not optional:
 
 1. Preserve any existing `<!-- auto-release:start -->` block. If a changeset is
    part of the diff and repo policy expects auto release, include that block.
-2. Issue, tracker, or fix line when applicable. Never include a line that links
-   to the current PR itself; the current PR URL belongs in the final response,
-   not in its own description.
-3. Confidence line.
-4. Reproduced / Verified table with test and browser columns.
-5. `Outcome`, `Caveat`, `Design`, and `Verified` sections.
+2. Use an emoji-prefixed issue/tracker/fix line, for example
+   `🐛 Fixes #123` or `🐛 Fixes ➖ N/A`. Never include a line that links to the
+   current PR itself; the current PR URL belongs in the final response, not in
+   its own description.
+3. Use an emoji confidence line, for example `🟢 95-100% confidence`.
+4. Use this exact table header:
+   `| Phase | 🧪 Tests | 🌐 Browser |`
+5. Use `Reproduced` and `Verified` rows. Mark passing proof with `🟢`, repro or
+   failing proof with `🔴`, and non-applicable browser/test cells with `➖ N/A`.
+6. Use bold emoji section headings exactly in this family:
+   `**✅ Outcome**`, `**⚠️ Caveat**`, `**🏗️ Design**`, and
+   `**🧪 Verified**`.
 
 The body should tell QA/reviewers what was fixed, how it was reproduced, how it
-was verified, and why the chosen ownership boundary is right. After editing,
-verify it with `gh pr view --json body` before final handoff.
+was verified, and why the chosen ownership boundary is right. It must not use
+plain `Fix:`, plain `Confidence:`, `## Outcome`, `## Verified`, or a generic
+`Summary` / `Verification` shape for task-run PRs. After editing, verify it
+with `gh pr view --json body` before final handoff.
 
 ## Success Criteria
 
@@ -320,6 +328,6 @@ verify it with `gh pr view --json body` before final handoff.
 - Verified code-changing work was committed and PR'd, or the user explicitly
   declined that path, the work had no local patch, or a real blocker was
   recorded.
-- PR descriptions created by task runs used the task-style final handoff body
+- PR descriptions created by task runs used the PR #270 emoji task-style body
   and were verified with `gh pr view --json body`.
 - Final handoff matched the task type and any task-template gate evidence.

.agents/skills/autogoal/SKILL.md

@@ -564,9 +564,13 @@ Gate closure rules:
    threshold, verification surface, constraints, boundaries, blocked condition,
    flow mode, and goal plan path; resolve generated gates as yes/no/N/A instead
    of deleting or replacing the template output.
-10. Use that exact path for
+10. Record the output-budget strategy before exploratory commands: which
+    searches or reads are allowed, which high-volume paths are excluded, and
+    how large results will be capped, counted, or saved as artifacts instead of
+    streamed into the goal context.
+11. Use that exact path for
     `check-complete.mjs`.
-11. Do not start durable work until the goal is set, verified as already matching,
+12. Do not start durable work until the goal is set, verified as already matching,
     or the user explicitly resolves the missing-goal path.
 
 Set the goal before mutable lane state when the workflow depends on a goal. For
@@ -793,6 +797,10 @@ Boundaries:
 
 - <allowed files/packages/tools>
 
+Output budget strategy:
+
+- <how command/search output will be scoped, capped, counted, or artifacted>
+
 Blocked condition:
 
 - <condition that stops autonomous work>
@@ -1009,6 +1017,35 @@ Attempted:
 
 Budget exhaustion is not success.
 
+## Output Budget Discipline
+
+Goal token budgets are real work budgets, not decorative counters. A goal run
+that burns its budget on tool output has failed the workflow even when no app
+code was touched.
+
+Before running exploratory commands inside an active goal:
+
+- Prefer narrow reads over broad scans: exact files, focused `rg -n` patterns,
+  targeted globs, and short `sed -n` ranges.
+- Treat `tmp/**`, logs, binaries, generated output, build artifacts,
+  `node_modules`, `.next`, `.turbo`, and coverage folders as excluded by
+  default. Include them only when they are the named source of truth.
+- Set explicit tool output caps for commands likely to return more than a
+  screenful. Keep ordinary source reads around a few thousand tokens, and
+  justify any larger cap in the plan.
+- For broad audits, first ask for counts, filenames, or top matches
+  (`rg --count`, `rg --files-with-matches`, `--max-count`, `wc`, `head`) before
+  printing matching lines.
+- If a result may be large but still matters, write it to a local artifact and
+  inspect slices from that artifact. Do not stream the full result into the
+  conversation.
+- Never run unbounded `rg` across the whole repo plus `tmp/api`, logs, or binary
+  outputs during a budgeted goal. Split the search by owner or exclude the noisy
+  trees first.
+- After any accidental large output, stop broad exploration immediately, record
+  the miss in the error-attempts row, and continue only with constrained
+  commands.
+
 If the system stops or warns because a goal budget is reached:
 
 - stop substantive work

.agents/skills/kitcn/references/features/auth.md

@@ -326,6 +326,15 @@ const signUp = useMutation(useSignUpMutationOptions({ onSuccess: () => router.pu
 signUp.mutate({ callbackURL: window.location.origin, email, name, password });
 ```
 
+**Plugin sign-in methods** (requires the matching Better Auth client plugin):
+```ts
+const signIn = useMutation(useSignInMutationOptions({
+  signInMethod: 'username',
+  onSuccess: () => router.push('/'),
+}));
+signIn.mutate({ callbackURL: window.location.origin, password, username });
+```
+
 ### Sign Out
 
 ```ts

.agents/skills/task/SKILL.md

@@ -292,20 +292,28 @@ task final handoff. Do not use a generic `Summary` / `Verification` PR body, an
 adaptive prose body from `git-commit-push-pr`, or a generated badge footer
 unless the caller or repo template explicitly asks for it.
 
-Use this order:
+Use the accepted task PR format from PR #270. The shape is not optional:
 
 1. Preserve any existing `<!-- auto-release:start -->` block. If a changeset is
    part of the diff and repo policy expects auto release, include that block.
-2. Issue, tracker, or fix line when applicable. Never include a line that links
-   to the current PR itself; the current PR URL belongs in the final response,
-   not in its own description.
-3. Confidence line.
-4. Reproduced / Verified table with test and browser columns.
-5. `Outcome`, `Caveat`, `Design`, and `Verified` sections.
+2. Use an emoji-prefixed issue/tracker/fix line, for example
+   `🐛 Fixes #123` or `🐛 Fixes ➖ N/A`. Never include a line that links to the
+   current PR itself; the current PR URL belongs in the final response, not in
+   its own description.
+3. Use an emoji confidence line, for example `🟢 95-100% confidence`.
+4. Use this exact table header:
+   `| Phase | 🧪 Tests | 🌐 Browser |`
+5. Use `Reproduced` and `Verified` rows. Mark passing proof with `🟢`, repro or
+   failing proof with `🔴`, and non-applicable browser/test cells with `➖ N/A`.
+6. Use bold emoji section headings exactly in this family:
+   `**✅ Outcome**`, `**⚠️ Caveat**`, `**🏗️ Design**`, and
+   `**🧪 Verified**`.
 
 The body should tell QA/reviewers what was fixed, how it was reproduced, how it
-was verified, and why the chosen ownership boundary is right. After editing,
-verify it with `gh pr view --json body` before final handoff.
+was verified, and why the chosen ownership boundary is right. It must not use
+plain `Fix:`, plain `Confidence:`, `## Outcome`, `## Verified`, or a generic
+`Summary` / `Verification` shape for task-run PRs. After editing, verify it
+with `gh pr view --json body` before final handoff.
 
 ## Success Criteria
 
@@ -324,6 +332,6 @@ verify it with `gh pr view --json body` before final handoff.
 - Verified code-changing work was committed and PR'd, or the user explicitly
   declined that path, the work had no local patch, or a real blocker was
   recorded.
-- PR descriptions created by task runs used the task-style final handoff body
+- PR descriptions created by task runs used the PR #270 emoji task-style body
   and were verified with `gh pr view --json body`.
 - Final handoff matched the task type and any task-template gate evidence.

.changeset/auth-sign-in-methods.md

@@ -0,0 +1,7 @@
+---
+"kitcn": patch
+---
+
+## Features
+
+- Support Better Auth plugin sign-in methods in `useSignInMutationOptions`.