minimal-vibe-coding-kit 0.4.0 → 0.4.2

package/.grok/skills/memento/SKILL.md

@@ -0,0 +1,36 @@
+---
+name: memento
+description: Leave yourself a note before closing a multi-day task, then read it back at the start of the next session — it's the only memory that survives the gap.
+argument-hint: "'resume' to read it back, or a hint for what's next when writing it"
+disable-model-invocation: true
+---
+
+Leonard, in *Memento*, can't hold a new memory for more than a few minutes, so he writes down only what his future self must act on, and never trusts a note loose enough to misread later. A session runs out the same way: once it ends, the goal, the plan, and every trap you hit are gone unless they were on paper first. `MEMENTO.md`, at the repo root, is that paper — read and rewritten every session for as long as the task spans days or weeks.
+
+Same file, two moments: ending a session, or watching context run low, means **Wrap up**. Starting one with nothing said yet, or told to resume, means **Resume**.
+
+## Wrap up
+
+Read `MEMENTO.md` first if it exists — you're merging into a running note, not drafting a fresh one. Write back exactly these headers:
+
+- **Goal** — the task this spans, not just what this session touched.
+- **Done** — milestones so far. Append; never drop one an earlier session recorded.
+- **Stuck** — the current blocker, stated plainly. None? Say so.
+- **Next** — the immediate next step, concrete enough to start cold, including which skill to reach for if one applies. Fold in any hint the user gave about what's next.
+- **Traps** — every dead end and why it failed. Append — a trap logged three sessions ago still belongs here. A generic summary always loses this section first, and it's the one that costs the most to relearn.
+
+Every section answers one test: could a reader with none of this conversation, and no way to ask you anything, act correctly from the page alone? That's the bar — not length, not polish.
+
+Reference other artifacts (PRDs, ADRs, issues, diffs) by path instead of restating them, and redact secrets or anything personally identifying before you write. If the repo has a `.gitignore` and `MEMENTO.md` isn't in it, add it — this is a scratchpad, not something to ship in a PR.
+
+If **Goal** is now fully done, delete the file instead of writing a fifth version of "nothing left to do" — a stale memento left behind just confuses whatever this repo works on next.
+
+## Resume
+
+Read `MEMENTO.md` at the repo root. Missing? Say so and ask what to work on instead of inventing a goal to fill the gap.
+
+Found it: treat it as ground truth, but not blind faith — the note that undoes Leonard is the one he stops questioning. If it claims a file exists or a step landed and the repo says otherwise, flag the mismatch before building on top of it. Hand the human two or three lines — the goal, the immediate next step — before spending any work, so they can redirect first. Then pick up **Next**, invoking whatever skill it names, and treat every **Traps** entry as a closed door — don't reopen it.
+
+## Not `handoff`
+
+`handoff` and `claude-handoff` pass work to a *different* agent, right now, in parallel. Memento is one worker leaving a note for their own next session, days later, alone. Reach for this one when you're closing the laptop, not when you're spinning up a second agent.

package/.grok/skills/parallel-analysis/SKILL.md

@@ -0,0 +1,160 @@
+---
+name: parallel-analysis
+description: Fan out 2-5 independent read-only analysis lanes across the repo using your configured executor (Cursor CLI Composer, Claude subagents, or Codex CLI), then merge the lane reports and verify them with a refutation pass. Use for repo-wide questions, large uncommitted-diff reviews, multi-doc reading, impact analysis, or consistency audits. On first use it asks which provider/model to use and saves the answer so it never asks again.
+argument-hint: "<analysis question, diff, or review target>"
+user-invocable: true
+effort: medium
+---
+
+# Parallel Analysis (Multi-Agent Fan-Out)
+
+Split a large analysis into independent read-only lanes, run them concurrently
+with the configured executor, merge the lane reports, and verify merged claims
+with a skeptical refutation pass. One round of parallel lanes replaces slow
+serial reading; the verification lane replaces manual double-checking.
+
+This skill is project-agnostic: it works in any repo where the kit is
+installed, using that repo's `backbone.yml` (if present) for boundaries.
+
+## Best Use
+
+- Repo-wide questions ("where is X handled, what depends on Y").
+- Reviewing a large uncommitted diff by concern (backend vs frontend vs i18n
+  vs scripts).
+- Reading several large docs, plans, or reference trees at once.
+- Pre-change impact analysis across packages/apps listed in `backbone.yml`
+  `paths.apps`.
+- Consistency audits (docs vs code, rules vs skills, config vs actual layout).
+
+Do NOT use for single-file questions or quick lookups; direct reads are faster.
+
+## Executor Setup (first use only)
+
+Lane execution is delegated to ONE configured executor. The choice is stored
+in `.vibekit/parallel-analysis.json`; while that file exists and its preflight
+passes, NEVER ask again.
+
+1. **If `.vibekit/parallel-analysis.json` exists**: read it, run the matching
+   preflight below, and proceed silently on success. If preflight fails
+   (binary missing, logged out), tell the user what broke, offer to re-run
+   setup, and update the file with their answer.
+2. **If it does not exist**: detect what is available, then ask the user ONE
+   question — "Which provider should run parallel analysis lanes?" — using the
+   harness-native prompt (AskUserQuestion in Claude Code; a plain chat
+   question in Cursor/Codex). Offer, in this order:
+   - **Cursor CLI + Composer 2.5 Fast (recommended)** — fastest lane executor;
+     requires `cursor-agent` installed and logged in.
+   - **Claude subagents** — no extra install; lanes run as read-only Claude
+     Code subagents (Explore/general-purpose). Choose this automatically if
+     the user declines external CLIs.
+   - **Codex CLI** — lanes run via `codex exec` in a read-only sandbox with
+     the best available Codex model.
+3. **Resolve the model** for the chosen provider (see per-executor notes),
+   confirm the resolved value in one line, and write the config file. Include
+   a fallback executor so lanes still run when the primary is unavailable.
+
+### Preflights and model resolution
+
+- `cursor-cli`: `cursor-agent status` must report logged in (otherwise the
+  user runs `cursor-agent login` once). Resolve the model with
+  `cursor-agent --list-models` and prefer the Composer 2.5 fast variant
+  (e.g. `composer-2.5-fast`); if absent, use the newest Composer model and
+  record what was picked.
+- `claude-subagents`: available whenever running inside Claude Code; no
+  binary needed. Use read-only subagent types only.
+- `codex-cli`: `codex --version` must succeed. Use the CLI's default/best
+  coding model unless the user names one; record the resolved model.
+
+### Config file — `.vibekit/parallel-analysis.json`
+
+```json
+{
+  "executor": "cursor-cli",
+  "model": "composer-2.5-fast",
+  "fallback": "claude-subagents",
+  "configuredAt": "2026-07-16T07:30:00Z"
+}
+```
+
+`executor` is one of `cursor-cli` | `claude-subagents` | `codex-cli`. The file
+is local state (gitignored by default); a team may commit it deliberately to
+share a default. To change the choice later, delete the file or ask for
+"parallel-analysis setup" again.
+
+## Running a lane (per executor)
+
+Every lane is READ-ONLY: search, read, summarize — never edit files, execute
+project binaries, run hooks, or trigger installs/deploys/migrations.
+
+- `cursor-cli`:
+
+  ```sh
+  cursor-agent -p --mode ask --output-format text \
+    --model "<configured-model>" \
+    --workspace "<repo-root>" \
+    "<lane brief>"
+  ```
+
+  Never pass `--force` or `--yolo`; `--mode ask` keeps Composer read-only.
+  One workspace per lane; a question spanning multiple repos becomes one lane
+  per repo.
+- `claude-subagents`: launch each lane as a read-only subagent with the lane
+  brief as its prompt, all lanes in ONE message so they run concurrently.
+- `codex-cli`:
+
+  ```sh
+  codex exec --sandbox read-only -C "<repo-root>" "<lane brief>"
+  ```
+
+If the harness cannot run lanes concurrently (plain CLI loop), run them
+back-to-back without changing the briefs — merge and verification stay the
+same.
+
+## Workflow
+
+1. **Scope.** State the question in one sentence. Split it into 2-5 lanes that
+   are independent of each other (by directory, package, concern, or doc set).
+   If lanes would depend on each other's output, merge them or run two rounds.
+2. **Brief.** Give each lane a numbered brief: exact paths, the questions to
+   answer, and the required return format ("facts only, numbered sections,
+   findings as `file:line — issue — why it matters`").
+3. **Launch all lanes at once** with the configured executor.
+4. **Prepare while waiting.** Build the merge skeleton; do not duplicate lane
+   work.
+5. **Merge.** Combine lane reports into one findings list. Mark conflicts
+   between lanes and unknowns explicitly — never average away a disagreement.
+6. **Verify.** Run one verification lane that receives the merged claims (not
+   the reasoning) with the instruction: "Default-skeptical: confirm or refute
+   each claim against the repo with file:line evidence." Drop or re-investigate
+   every refuted claim; never silently keep one.
+7. **Deliver.** Report merged findings, what was verified, and remaining
+   unknowns. For issue triage, classify surviving findings with the
+   `reviewing-4p-priorities` skill (P0-P4). Decisions and edits stay in the
+   main session under the repo's normal review rules.
+
+## Lane brief template
+
+```text
+Lane <n>: <one-line purpose>
+Workspace: <repo root>
+Paths: <exact dirs/files>
+Read-only. Do not modify anything or execute binaries/scripts.
+Questions:
+1. <specific question>
+2. <specific question>
+Return: numbered sections matching the questions, facts only,
+findings as file:line — issue — why it matters.
+```
+
+## Guardrails
+
+- 2-5 lanes per round; needing more means the question is under-scoped.
+- Lanes are read-only; only the main session edits files. Agent-surface edits
+  (`backbone.yml`, `AGENTS.md`, `CLAUDE.md`, `.claude/**`, `.cursor/**`,
+  `.agents/**`, `.codex/**`, kit skills/commands) additionally require the
+  `agentshield-security-review` skill afterwards.
+- Respect `backbone.yml` `policy.protected_paths` in every lane brief.
+- Never put secrets in lane briefs or executor prompts: no `.env*` contents,
+  credentials, tokens, private keys, or customer data.
+- This skill produces analysis, not decisions; a lane may not conclude
+  "therefore change X" without main-session review.

package/.grok/skills/path-sensitive-shell-safety/SKILL.md

@@ -0,0 +1,69 @@
+---
+name: path-sensitive-shell-safety
+description: Guardrail workflow for shell changes that use path variables, remote base directories, repo folders, checkout repair, or destructive filesystem commands such as rm, mv, cp, rsync, find -delete, git clean, or git reset.
+argument-hint: "<script path, command, or safety review target>"
+user-invocable: true
+effort: medium
+---
+
+# Path-Sensitive Shell Safety
+
+Use this skill before editing or reviewing shell, deploy, installer, cleanup, or repair logic that builds filesystem paths from variables or touches remote repositories.
+
+Common triggers:
+
+- Path variables such as `remote_base`, `repo_dir`, `repo_folder`, `target_dir`, `backup_dir`, `worktree`, `site`, `app`, or user-entered folder names.
+- Destructive or path-sensitive commands: `rm`, `mv`, `cp -a`, `rsync --delete`, `find -delete`, `docker volume rm`, `git clean`, `git reset`, checkout repair, clone replacement, or symlink-sensitive copy.
+- Git sync that decides which branch or remote checkout will be deployed.
+
+## Safety objective
+
+No empty, unset, broad, symlinked, or unintended path may reach a destructive command. Validate values before joining paths, validate the joined path before use, and validate containment immediately before the command.
+
+## Required workflow
+
+1. Identify the command with the highest blast radius.
+2. List every variable that contributes to its path or repository target.
+3. Classify each variable:
+   - trusted constant;
+   - config value;
+   - remote/server value;
+   - user/operator input;
+   - derived path.
+4. Validate raw inputs before joining:
+   - required and non-empty;
+   - expected shape: absolute base path or safe single folder segment;
+   - no traversal, newlines, glob metacharacters, leading option dash, or control characters;
+   - explicit allowlist for server roots when possible.
+5. Join paths with quoted expansions only. Do not use `eval`.
+6. Canonicalize existing paths with physical resolution (`pwd -P` or `realpath`) before destructive work.
+7. Assert containment:
+   - target is inside the approved base;
+   - target is not `/`, `.`, `..`, `$HOME`, the base root itself, or another broad system directory;
+   - target is not a symlink unless the operation explicitly supports symlinks.
+8. Put the final guard directly next to the dangerous command.
+9. Use command terminators and quoting: `-- "$path"` where supported.
+10. For Git sync, verify expected origin, selected branch policy, fetch success, clean worktree, fast-forward state, and final `HEAD == origin/<branch>` before build/deploy.
+11. Run the repo validation command and AgentShield probe when this changes agent surfaces or automation rules.
+
+## Required outcomes
+
+- Prefer a recoverable delete (`trash`) over permanent `rm` for user files; permanent deletion requires explicit confirmation of the exact paths. If `trash` is missing, recommend installing it (macOS 14+ built-in; older macOS `brew install trash`; Linux `sudo apt install trash-cli`; any OS with Node `npm i -g trash-cli`).
+- A blank branch may follow the documented default-branch fallback policy.
+- An explicit branch must fail if missing; never silently deploy another branch.
+- A blank folder/base value must fail before any `rm`, `mv`, `cp`, `rsync`, `find`, Docker, or Git cleanup command runs.
+- A repair flow may move an unusable checkout to a timestamped backup only after a verified replacement exists.
+- No automatic cleanup should delete backups, locks, runtime data, uploads, volumes, databases, or environment files without separate explicit confirmation.
+
+## Review priority
+
+Use `reviewing-4p-priorities` if triage is needed:
+
+- P0: unsafe path command already caused data loss or can expose/delete secrets in the active environment.
+- P1: unchecked empty/broad variable can reach destructive commands in deploy/repair/install paths.
+- P2: guard exists but misses edge cases such as symlinks, traversal, explicit branch fallback, or wrong origin.
+- P3/P4: documentation clarity or minor naming improvements after the safety invariant is already enforced.
+
+## Reference
+
+Use `references/workflow.md` for copy-ready guard patterns and review checklist.

package/.grok/skills/path-sensitive-shell-safety/references/workflow.md

@@ -0,0 +1,127 @@
+# Path-Sensitive Shell Safety Reference
+
+This reference gives reusable guard patterns for shell scripts. Adapt names and allowlists to the repo, but keep the invariant: validate raw input, validate the joined path, then guard immediately before the dangerous command.
+
+## Baseline guard functions
+
+```bash
+die() {
+  printf 'ERROR: %s\n' "$*" >&2
+  exit 1
+}
+
+require_nonempty() {
+  local name="${1:?missing name}"
+  local value="${2-}"
+  [[ -n "$value" ]] || die "$name is required"
+  [[ "$value" != *$'\n'* && "$value" != *$'\r'* ]] || die "$name contains a newline"
+}
+
+validate_abs_base_path() {
+  local name="${1:?missing name}"
+  local value="${2-}"
+  require_nonempty "$name" "$value"
+  [[ "$value" == /* ]] || die "$name must be an absolute path: $value"
+  [[ "$value" != "/" && "$value" != "." && "$value" != ".." ]] || die "$name is too broad: $value"
+  [[ "$value" != *"/../"* && "$value" != *"/./"* && "$value" != *"//"* ]] || die "$name contains unsafe traversal: $value"
+  case "$value" in
+    /bin|/boot|/dev|/etc|/home|/lib|/lib64|/opt|/private|/root|/sbin|/srv|/sys|/tmp|/usr|/var)
+      die "$name points at a broad system directory: $value"
+      ;;
+  esac
+}
+
+validate_folder_segment() {
+  local name="${1:?missing name}"
+  local value="${2-}"
+  require_nonempty "$name" "$value"
+  [[ "$value" != -* ]] || die "$name must not start with '-': $value"
+  [[ "$value" != "." && "$value" != ".." ]] || die "$name is unsafe: $value"
+  [[ "$value" != */* && "$value" != *\\* ]] || die "$name must be one folder segment: $value"
+  [[ "$value" =~ ^[A-Za-z0-9._#@+=:-]+$ ]] || die "$name contains unsupported characters: $value"
+}
+
+join_child_path() {
+  local base="${1:?missing base}"
+  local child="${2:?missing child}"
+  printf '%s/%s\n' "${base%/}" "$child"
+}
+```
+
+## Containment guard
+
+```bash
+canonical_existing_dir() {
+  local path_value="${1:?missing path}"
+  [[ -d "$path_value" ]] || die "not a directory: $path_value"
+  [[ ! -L "$path_value" ]] || die "refusing symlink directory: $path_value"
+  (cd -P -- "$path_value" && pwd) || die "cannot resolve directory: $path_value"
+}
+
+assert_child_under_parent() {
+  local parent="${1:?missing parent}"
+  local child="${2:?missing child}"
+  [[ "$child" != "$parent" ]] || die "refusing to operate on parent directory itself: $child"
+  case "$child" in
+    "$parent"/*) ;;
+    *) die "path escapes parent: child=$child parent=$parent" ;;
+  esac
+}
+```
+
+## Safer remove wrapper
+
+Use a wrapper instead of inline deletion when a path contains variables.
+
+```bash
+safe_rm_rf_dir() {
+  local label="${1:?missing label}"
+  local target="${2-}"
+  local allowed_parent="${3-}"
+
+  validate_abs_base_path "$label target" "$target"
+  validate_abs_base_path "$label allowed parent" "$allowed_parent"
+
+  [[ -d "$target" ]] || die "$label target is not an existing directory: $target"
+  [[ ! -L "$target" ]] || die "$label target is a symlink: $target"
+
+  local parent_real
+  parent_real="$(canonical_existing_dir "$allowed_parent")"
+
+  local target_real
+  target_real="$(canonical_existing_dir "$target")"
+
+  assert_child_under_parent "$parent_real" "$target_real"
+  rm -rf -- "$target_real"
+}
+```
+
+Never call the wrapper with a broad parent such as `/`, `/opt`, `/var`, `/tmp`, or `$HOME`. Use the narrowest app-owned parent.
+
+## Git sync guard checklist
+
+- Validate the checkout directory is inside the approved app base.
+- Validate the origin URL or host matches the expected repository.
+- Fetch with bounded timeout and non-interactive credentials.
+- Explicit branch:
+  - require the exact remote branch;
+  - fail with an actionable message if it is missing.
+- Blank branch:
+  - current valid upstream;
+  - remote default branch;
+  - `main`;
+  - `master`.
+- Refuse dirty, local-ahead, or diverged worktrees unless the operator chooses a guided repair command.
+- After sync, verify `git rev-parse HEAD` equals `git rev-parse "origin/<branch>"`.
+- Build or deploy only after the equality check passes.
+
+## Review checklist
+
+- Are all path variables checked with `[[ -n "$value" ]]` or a stronger helper before use?
+- Are folder names validated as segments before joining?
+- Is the final path canonicalized or otherwise proven inside the base?
+- Is the destructive command adjacent to its guard?
+- Does the command use quoted expansions and `--` where available?
+- Does the code fail closed for missing explicit branches?
+- Does repair preserve runtime data and keep backups instead of deleting them?
+- Does validation cover empty values, traversal, symlink, wrong origin, dirty checkout, branch with `#`, and missing branch?

package/.grok/skills/prompt-sharpener/SKILL.md

@@ -0,0 +1,54 @@
+---
+name: prompt-sharpener
+description: Sharpen a rough prompt into a precise one — same intent, sharper not longer — then execute the sharpened version immediately in the same turn.
+argument-hint: "the rough prompt to sharpen and execute"
+disable-model-invocation: true
+---
+
+# Prompt Sharpener
+
+The text the user types after the invocation is the **raw prompt**. Upgrade it into a prompt that is **sharper, not longer** — keep the original intent, constraints, and language — then execute the upgraded version immediately in the same turn. No text after the invocation → ask the user what they want and stop.
+
+## Step 1 — Diagnose the raw prompt
+
+Scan for every ailment below; each ailment found gets its cure applied directly in the upgraded prompt. Cure silently; call out a cure only when it could shift the user's intent.
+
+- Vague verbs or adjectives ("help me", "make it nicer") → concrete, measurable operations and parameters.
+- Two tasks in one prompt → split into an explicit execution order.
+- No success criteria → add a binary pass/fail `Done when`.
+- Emotional description ("everything is broken") → extract the specific technical symptom.
+- "The whole app" scope → pin exact files/functions/directories; coding tasks always get a **scope lock** (edit only inside X, leave the rest untouched).
+- Relies on memory of an old session → copy the decisions already settled in this conversation (stack, architecture, what was tried and failed) into the `Context` block.
+- Invitation to fabricate ("what do experts say about X?") → anchor grounding: state only what can be verified; when unsure, say so explicitly.
+- No output format → fix the structure and length; when the format is hard to describe in words, include 2-3 sample examples (including an edge case) in the `Output Contract`.
+
+Done when: the raw prompt has been checked against the full list and no ailment is left without its cure in the upgraded prompt.
+
+## Step 2 — Build the upgraded prompt
+
+Classify the task (coding / research / writing / analysis / planning / review), then assemble blocks in this order — add a block only when it raises precision; small tasks need just 2-3 blocks:
+
+`Objective` → `Context` → `Work Style` → `Tool Rules` → `Output Contract` → `Verification` → `Done Criteria`
+
+Focus per task type:
+
+- Coding: scope lock, smallest correct change, validation after the edit — default to the `validate` command in `backbone.yml` when the repo has one.
+- Research: source quality, citations, explicit uncertainty.
+- Writing: audience, voice, length.
+- Review: group findings by severity, name the failure mode.
+
+Construction rules:
+
+- Write constraints with the strongest signal words: MUST instead of "should", NEVER instead of "avoid".
+- Missing information → state the assumption in `Context` and keep going; stop to ask only when the task is destructive or irreversible.
+- Say _what_ to verify; let the model regulate its own depth of thought.
+- Repo work MUST respect `backbone.yml` conventions and protected paths; when the upgraded task is a large decomposition or a risky decision, its `Work Style` block may direct Step 3 to open with the `sequential-thinking` or `clearthought` skill.
+- Closing audit: reread every sentence; if cutting it would not change the output, cut it — every remaining word is **load-bearing**.
+
+Done when the upgraded prompt scores on all 6 points: intent preserved — ambiguity reduced — right depth — clear output — has verification — has a stopping point.
+
+## Step 3 — Present and execute
+
+Print the upgraded prompt in a single code block, with at most 2 sentences on the key changes. Then treat it as the user's official request: start executing immediately in the same turn, researching and editing according to its own `Tool Rules`.
+
+Done when the upgraded prompt's `Done Criteria` are satisfied.

package/.grok/skills/reviewing-4p-priorities/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: reviewing-4p-priorities
+description: P0-P4 issue and task triage for vibe coding. Use when reviewing bugs, risks, feature requests, agent-surface changes, or deciding which work must happen first.
+argument-hint: "<issue, review finding, or task list>"
+user-invocable: true
+effort: medium
+---
+
+# Reviewing 4P Priorities
+
+Use this skill to classify work from P0 to P4 and convert review findings into a practical fix order.
+
+## Priority Scale
+
+| Priority | Meaning | Response |
+| --- | --- | --- |
+| P0 | Critical outage, data loss, security exposure, or all users blocked | Stop and fix immediately |
+| P1 | Major user-facing or release-blocking failure for many users | Fix before other planned work |
+| P2 | Important bug, maintainability risk, or strategic enhancement | Schedule in the current cycle |
+| P3 | Local polish, minor edge case, or narrow productivity improvement | Routine backlog |
+| P4 | Nice-to-have, exploratory idea, or low-confidence request | Capture, defer, or discard |
+
+## Vibe Coding Review Flow
+
+1. Identify the affected user, workflow, or agent surface.
+2. Separate evidence from guesses.
+3. Classify the current impact, not hypothetical worst cases.
+4. Explain why the item is not one level higher or lower.
+5. Convert each P0-P2 item into a small fix task and validation check.
+6. Leave P3-P4 items as optional follow-up unless they reduce risk cheaply.
+
+## Output
+
+```markdown
+## 4P Review
+
+Classification: P<0-4>
+Issue: <short description>
+Evidence:
+- <observed fact>
+Impact:
+- Users/workflows affected: <scope>
+- Failure mode: <what breaks>
+Rationale:
+- Why this priority:
+- Why not higher:
+- Why not lower:
+Fix order:
+1. <small task>
+2. <small task>
+Validation:
+- <command or manual check>
+```
+
+## Priority Boundaries
+
+- P0 requires immediate action because harm is happening now or secrets/data are exposed.
+- P1 is urgent but does not require emergency response for every user.
+- P2 is important and should be planned, but users have a workaround or impact is bounded.
+- P3 improves quality but does not materially block the workflow.
+- P4 is a candidate for a note, not an implementation commitment.
+
+## Examples
+
+Use `examples.md` when a priority boundary is ambiguous, especially P0 vs P1, P1 vs P2, security edge cases, or agent-surface risk classification.
+
+## Guardrails
+
+- Do not classify without impact evidence.
+- Do not use P0 for personal urgency.
+- Do not expand scope while triaging. Classify the current issue first.
+- For agent-surface changes, include security and prompt-injection risk in the impact section.