chore: sync sproutclaw to gitea

- Remove unused .pi extensions and prompts
- Update generated model files
- Add context.md
- Update pi-test.sh and package-lock.json

.pi/prompts/cl.md

@@ -1,54 +0,0 @@
----
-description: Audit changelog entries before release
----
-Audit changelog entries for all commits since the last release.
-
-## Process
-
-1. **Find the last release tag:**
-   ```bash
-   git tag --sort=-version:refname | head -1
-   ```
-
-2. **List all commits since that tag:**
-   ```bash
-   git log <tag>..HEAD --oneline
-   ```
-
-3. **Read each package's [Unreleased] section:**
-   - packages/ai/CHANGELOG.md
-   - packages/tui/CHANGELOG.md
-   - packages/coding-agent/CHANGELOG.md
-
-4. **For each commit, check:**
-   - Skip: changelog updates, doc-only changes, release housekeeping
-   - Skip: changes to generated model catalogs (for example `packages/ai/src/models.generated.ts`) unless accompanied by an intentional product-facing change in non-generated source/docs.
-   - Determine which package(s) the commit affects (use `git show <hash> --stat`)
-   - Verify a changelog entry exists in the affected package(s)
-   - For external contributions (PRs), verify format: `Description ([#N](url) by [@user](url))`
-
-5. **Cross-package duplication rule:**
-   Changes in `ai`, `agent` or `tui` that affect end users should be duplicated to `coding-agent` changelog, since coding-agent is the user-facing package that depends on them.
-
-6. **Add New Features section after changelog fixes:**
-   - Insert a `### New Features` section at the start of `## [Unreleased]` in `packages/coding-agent/CHANGELOG.md`.
-   - Propose the top new features to the user for confirmation before writing them.
-   - Link to relevant docs and sections whenever possible.
-
-7. **Report:**
-   - List commits with missing entries
-   - List entries that need cross-package duplication
-   - Add any missing entries directly
-
-## Changelog Format Reference
-
-Sections (in order):
-- `### Breaking Changes` - API changes requiring migration
-- `### Added` - New features
-- `### Changed` - Changes to existing functionality
-- `### Fixed` - Bug fixes
-- `### Removed` - Removed features
-
-Attribution:
-- Internal: `Fixed foo ([#123](https://github.com/earendil-works/pi-mono/issues/123))`
-- External: `Added bar ([#456](https://github.com/earendil-works/pi-mono/pull/456) by [@user](https://github.com/user))`

.pi/prompts/is.md

@@ -1,25 +0,0 @@
----
-description: Analyze GitHub issues (bugs or feature requests)
-argument-hint: "<issue>"
----
-Analyze GitHub issue(s): $ARGUMENTS
-
-For each issue:
-
-1. Add the `inprogress` label to the issue via GitHub CLI before analysis starts. If adding the label fails, report that explicitly and continue.
-2. Read the issue in full, including all comments and linked issues/PRs.
-3. Do not trust analysis written in the issue. Independently verify behavior and derive your own analysis from the code and execution path.
-
-4. **For bugs**:
-   - Ignore any root cause analysis in the issue (likely wrong)
-   - Read all related code files in full (no truncation)
-   - Trace the code path and identify the actual root cause
-   - Propose a fix
-
-5. **For feature requests**:
-   - Do not trust implementation proposals in the issue without verification
-   - Read all related code files in full (no truncation)
-   - Propose the most concise implementation approach
-   - List affected files and changes needed
-
-Do NOT implement unless explicitly asked. Analyze and propose only.

.pi/prompts/pr.md

@@ -1,41 +0,0 @@
----
-description: Review PRs from URLs with structured issue and code analysis
-argument-hint: "<PR-URL>"
----
-You are given one or more GitHub PR URLs: $@
-
-For each PR URL, do the following in order:
-1. Add the `inprogress` label to the PR via GitHub CLI before analysis starts. If adding the label fails, report that explicitly and continue.
-2. Read the PR page in full. Include description, all comments, all commits, and all changed files.
-3. Identify any linked issues referenced in the PR body, comments, commit messages, or cross links. Read each issue in full, including all comments.
-4. Analyze the PR diff. Read all relevant code files in full with no truncation from the current main branch and compare against the diff. Do not fetch PR file blobs unless a file is missing on main or the diff context is insufficient. Include related code paths that are not in the diff but are required to validate behavior.
-5. Check for a changelog entry in the relevant `packages/*/CHANGELOG.md` files. Report whether an entry exists. If missing, state that a changelog entry is required before merge and that you will add it if the user decides to merge. Follow the changelog format rules in AGENTS.md. Verify:
-   - Entry uses correct section (`### Breaking Changes`, `### Added`, `### Fixed`, etc.)
-   - External contributions include PR link and author: `Fixed foo ([#123](https://github.com/earendil-works/pi-mono/pull/123) by [@user](https://github.com/user))`
-   - Breaking changes are in `### Breaking Changes`, not just `### Fixed`
-6. Check if packages/coding-agent/README.md, packages/coding-agent/docs/*.md, packages/coding-agent/examples/**/*.md require modification. This is usually the case when existing features have been changed, or new features have been added.
-7. Provide a structured review with these sections:
-   - Good: solid choices or improvements
-   - Bad: concrete issues, regressions, missing tests, or risks
-   - Ugly: subtle or high impact problems
-8. Add Questions or Assumptions if anything is unclear.
-9. Add Change summary and Tests.
-
-Output format per PR:
-PR: <url>
-Changelog:
-- ...
-Good:
-- ...
-Bad:
-- ...
-Ugly:
-- ...
-Questions or Assumptions:
-- ...
-Change summary:
-- ...
-Tests:
-- ...
-
-If no issues are found, say so under Bad and Ugly.

.pi/prompts/wr.md

@@ -1,31 +0,0 @@
----
-description: Finish the current task end-to-end with changelog, commit, and push
-argument-hint: "[instructions]"
----
-Wrap it.
-
-Additional instructions: $ARGUMENTS
-
-Determine context from the conversation history first.
-
-Rules for context detection:
-- If the conversation already mentions a GitHub issue or PR, use that existing context.
-- If the work came from `/is` or `/pr`, assume the issue or PR context is already known from the conversation and from the analysis work already done.
-- If there is no GitHub issue or PR in the conversation history, treat this as non-GitHub work.
-
-Unless I explicitly override something in this request, do the following in order:
-
-1. Add or update the relevant package changelog entry under `## [Unreleased]` using the repo changelog rules.
-2. If this task is tied to a GitHub issue or PR and a final issue or PR comment has not already been posted in this session, draft it in my tone, preview it, and post exactly one final comment.
-3. Commit only files you changed in this session.
-4. If this task is tied to exactly one GitHub issue, include `closes #<issue>` in the commit message. If it is tied to multiple issues, stop and ask which one to use. If it is not tied to any issue, do not include `closes #` or `fixes #` in the commit message.
-5. Check the current git branch. If it is not `main`, stop and ask what to do. Do not push from another branch unless I explicitly say so.
-6. Push the current branch.
-
-Constraints:
-- Never stage unrelated files.
-- Never use `git add .` or `git add -A`.
-- Run required checks before committing if code changed.
-- Do not open a PR unless I explicitly ask.
-- If this is not GitHub issue or PR work, do not post a GitHub comment.
-- If a final issue or PR comment was already posted in this session, do not post another one unless I explicitly ask.