getaura 0.3.0 → 0.4.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "getaura",
-  "version": "0.3.0",
+  "version": "0.4.0",
   "description": "Aura helps you and your coding agent follow best practices while you vibe code.",
   "type": "module",
   "bin": {

package/plugin/skills/pr/SKILL.md

@@ -0,0 +1,18 @@
+---
+name: pr
+description: Wrap up the session: turn the uncommitted work into focused pull requests that follow good practice.
+disable-model-invocation: true
+allowed-tools: Bash
+---
+
+Run `aura pr --dry-run --json` from the repository root. If `aura` isn't found, run `npx getaura pr --dry-run --json` instead.
+
+It returns the pull requests Aura would open, in the order to merge them. Each has an `id`, `title`, `why` (why it's a pull request of its own), `files`, `lines`, `large` and `heldBack` (files that contain a secret). `leftOut` lists files that stay on the computer, and `blocker` says why nothing can be opened yet.
+
+1. If `blocker` is set, tell the user in plain words what to do first and stop.
+2. If a group has `heldBack` files, tell the user a secret was found (by file, never the value), move it into `.env.local` and read it with `process.env`, then run the dry run again.
+3. Write `.aura/tasks/pr-notes.json` with a note for each group you know about: `{ "<id>": { "title": "...", "summary": "...", "check": ["..."] } }`. The title says what changed in a few words. The summary explains, in plain language, what changed and why. `check` lists what the user should try before merging. Describe only work you did or can see in the files.
+4. Show the user the plan: one line per pull request with its title and file count, which ones are `large` (suggest splitting them by feature), and what's left out. Ask whether to open them.
+5. Only after they say yes, run `aura pr --yes --notes .aura/tasks/pr-notes.json`. To open only some, add `--only <id>,<id>`.
+
+Then tell the user which pull requests were opened, the order to merge them, and to run `git pull` after merging. Never merge a pull request yourself.

package/templates/skills/aura/SKILL.md

@@ -30,6 +30,7 @@ Always use the non-interactive flags below so nothing waits for input.
 | Get a task file for you to complete | `aura fix <finding id or action> --agent` |
 | Continue a large change the user approved | add `--approved` to the same `aura fix` or `aura apply` command |
 | Step-by-step guide for the user | `aura guide <topic>` (list topics with `aura guide --list`) |
+| Turn the session's uncommitted work into pull requests | `aura pr --dry-run --json`, then `aura pr --yes --notes <file>` once the user agrees |
 | Services, env vars and owners | `aura inventory --json` |
 | What kind of project Aura thinks each folder is | `aura config kind` |
 | Correct it, after the user confirms | `aura config kind <kind> [folder]` (kinds: web-app, website, api, mobile-app, desktop-app, extension, cli, library; `auto` undoes it) |
@@ -68,6 +69,15 @@ Always use the non-interactive flags below so nothing waits for input.
 3. Large changes (renames and restructures across many files) need the user's approval first. If `aura fix` or `aura apply` stops with exit code 3 and says the change is large, show the user the breakdown it printed (also in `.aura/plans/<id>.md`) in plain words: what will change, why, what won't change, the risk and the chunks. Ask whether to go ahead. Only after they clearly say yes, run the same command again with `--approved`; `--yes` doesn't count as their approval. Each run does one chunk in one pull request. Tell the user how many chunks are left and run it again with `--approved` for the next one when they want to continue.
 4. After any change, run `aura check --json` again and tell the user the new score.
 
+## Wrapping up a session
+
+When the user is done, or says to open pull requests, and `git status` shows uncommitted work (yours, the user's, or Aura's records such as `.aura/inventory.json`), run `aura pr --dry-run --json`. Aura groups the work into focused pull requests: one concern each, database changes first, Aura's records apart from code, files that only work together kept together, and local files and secrets left out.
+
+- If `blocker` is set, tell the user what to do first. If a group has `heldBack` files, a secret was found: move it into `.env.local` before going on.
+- Write `.aura/tasks/pr-notes.json` with `{ "<id>": { "title", "summary", "check": [] } }` for the groups whose work you know: a short title, a plain-language summary of what changed and why, and what to try before merging.
+- Show the user the plan, point out any `large` pull request (suggest splitting it by feature), and ask before opening anything. Only after their yes, run `aura pr --yes --notes .aura/tasks/pr-notes.json`.
+- Tell them the order to merge in and to run `git pull` afterwards. Never merge a pull request yourself.
+
 ## Task files
 
 When `.aura/tasks/<id>.md` exists, it is your brief. Follow it exactly. If it starts with a breakdown of a large change, show the user that breakdown and get their yes before changing anything, and do only the chunk it names: