@fro.bot/systematic 2.33.3 → 3.0.0

package/skills/test-xcode/SKILL.md

@@ -1,214 +0,0 @@
----
-name: test-xcode
-description: "Build and test iOS apps on simulator using XcodeBuildMCP. Use after making iOS code changes, before creating a PR, or when verifying app behavior and checking for crashes on simulator."
-argument-hint: "[scheme name or 'current' to use default]"
-disable-model-invocation: true
----
-
-# Xcode Test Skill
-
-Build, install, and test iOS apps on the simulator using XcodeBuildMCP. Captures screenshots, logs, and verifies app behavior.
-
-## Prerequisites
-
-- Xcode installed with command-line tools
-- XcodeBuildMCP MCP server connected
-- Valid Xcode project or workspace
-- At least one iOS Simulator available
-
-## Workflow
-
-### 0. Verify XcodeBuildMCP is Available
-
-Check that the XcodeBuildMCP MCP server is connected by calling its `list_simulators` tool.
-
-MCP tool names vary by platform:
-- OpenCode: `mcp__xcodebuildmcp__list_simulators`
-- Other platforms: use the equivalent MCP tool call for the `XcodeBuildMCP` server's `list_simulators` method
-
-If the tool is not found or errors, inform the user they need to add the XcodeBuildMCP MCP server:
-
-```
-XcodeBuildMCP not installed
-
-Install via Homebrew:
-  brew tap getsentry/xcodebuildmcp && brew install xcodebuildmcp
-
-Or via npx (no global install needed):
-  npx -y xcodebuildmcp@latest mcp
-
-Then add "XcodeBuildMCP" as an MCP server in your agent configuration
-and restart your agent.
-```
-
-Do NOT proceed until XcodeBuildMCP is confirmed working.
-
-### 1. Discover Project and Scheme
-
-Call XcodeBuildMCP's `discover_projs` tool to find available projects, then `list_schemes` with the project path to get available schemes.
-
-If an argument was provided, use that scheme name. If "current", use the default/last-used scheme.
-
-### 2. Boot Simulator
-
-Call `list_simulators` to find available simulators. Boot the preferred simulator (iPhone 15 Pro recommended) using `boot_simulator` with the simulator's UUID.
-
-Wait for the simulator to be ready before proceeding.
-
-### 3. Build the App
-
-Call `build_ios_sim_app` with the project path and scheme name.
-
-**On failure:**
-- Capture build errors
-- Create a P1 todo for each build error
-- Report to user with specific error details
-
-**On success:**
-- Note the built app path for installation
-- Proceed to step 4
-
-### 4. Install and Launch
-
-1. Call `install_app_on_simulator` with the built app path and simulator UUID
-2. Call `launch_app_on_simulator` with the bundle ID and simulator UUID
-3. Call `capture_sim_logs` with the simulator UUID and bundle ID to start log capture
-
-### 5. Test Key Screens
-
-For each key screen in the app:
-
-**Take screenshot:**
-Call `take_screenshot` with the simulator UUID and a descriptive filename (e.g., `screen-home.png`).
-
-**Review screenshot for:**
-- UI elements rendered correctly
-- No error messages visible
-- Expected content displayed
-- Layout looks correct
-
-**Check logs for errors:**
-Call `get_sim_logs` with the simulator UUID. Look for:
-- Crashes
-- Exceptions
-- Error-level log messages
-- Failed network requests
-
-**Known automation limitation — SwiftUI Text links:**
-Simulated taps (via XcodeBuildMCP or any simulator automation tool) do not trigger gesture recognizers on SwiftUI `Text` views with inline `AttributedString` links. Taps report success but have no effect. This is a platform limitation — inline links are not exposed as separate elements in the accessibility tree. When a tap on a Text link has no visible effect, prompt the user to tap manually in the simulator. If the target URL is known, `xcrun simctl openurl <device> <URL>` can open it directly as a fallback.
-
-### 6. Human Verification (When Required)
-
-Pause for human input when testing touches flows that require device interaction.
-
-| Flow Type | What to Ask |
-|-----------|-------------|
-| Sign in with Apple | "Please complete Sign in with Apple on the simulator" |
-| Push notifications | "Send a test push and confirm it appears" |
-| In-app purchases | "Complete a sandbox purchase" |
-| Camera/Photos | "Grant permissions and verify camera works" |
-| Location | "Allow location access and verify map updates" |
-| SwiftUI Text links | "Please tap on [element description] manually — automated taps cannot trigger inline text links" |
-
-Ask the user (using the platform's question tool — e.g., `question` in OpenCode, `request_user_input` in Codex, `ask_user` in Gemini — or present numbered options and wait):
-
-```
-Human Verification Needed
-
-This test requires [flow type]. Please:
-1. [Action to take on simulator]
-2. [What to verify]
-
-Did it work correctly?
-1. Yes - continue testing
-2. No - describe the issue
-```
-
-### 7. Handle Failures
-
-When a test fails:
-
-1. **Document the failure:**
-   - Take screenshot of error state
-   - Capture console logs
-   - Note reproduction steps
-
-2. **Ask the user how to proceed:**
-
-   ```
-   Test Failed: [screen/feature]
-
-   Issue: [description]
-   Logs: [relevant error messages]
-
-   How to proceed?
-   1. Fix now - I'll help debug and fix
-   2. Create todo - Add a todo for later (using the todo-create skill)
-   3. Skip - Continue testing other screens
-   ```
-
-3. **If "Fix now":** investigate, propose a fix, rebuild and retest
-4. **If "Create todo":** load the `todo-create` skill and create a todo with priority p1 and description `xcode-{description}`, continue
-5. **If "Skip":** log as skipped, continue
-
-### 8. Test Summary
-
-After all tests complete, present a summary:
-
-```markdown
-## Xcode Test Results
-
-**Project:** [project name]
-**Scheme:** [scheme name]
-**Simulator:** [simulator name]
-
-### Build: Success / Failed
-
-### Screens Tested: [count]
-
-| Screen | Status | Notes |
-|--------|--------|-------|
-| Launch | Pass | |
-| Home | Pass | |
-| Settings | Fail | Crash on tap |
-| Profile | Skip | Requires login |
-
-### Console Errors: [count]
-- [List any errors found]
-
-### Human Verifications: [count]
-- Sign in with Apple: Confirmed
-- Push notifications: Confirmed
-
-### Failures: [count]
-- Settings screen - crash on navigation
-
-### Created Todos: [count]
-- `006-pending-p1-xcode-settings-crash.md`
-
-### Result: [PASS / FAIL / PARTIAL]
-```
-
-### 9. Cleanup
-
-After testing:
-
-1. Call `stop_log_capture` with the simulator UUID
-2. Optionally call `shutdown_simulator` with the simulator UUID
-
-## Quick Usage Examples
-
-```bash
-# Test with default scheme
-/test-xcode
-
-# Test specific scheme
-/test-xcode MyApp-Debug
-
-# Test after making changes
-/test-xcode current
-```
-
-## Integration with ce:review
-
-When reviewing PRs that touch iOS code, the `ce:review` workflow can spawn an agent to run this skill, build on the simulator, test key screens, and check for crashes.

package/skills/todo-create/SKILL.md

@@ -1,109 +0,0 @@
----
-name: todo-create
-description: Use when creating durable work items, managing todo lifecycle, or tracking findings across sessions in the file-based todo system
-disable-model-invocation: true
----
-
-# File-Based Todo Tracking
-
-## Overview
-
-The `.context/systematic/todos/` directory is a file-based tracking system for code review feedback, technical debt, feature requests, and work items. Each todo is a markdown file with YAML frontmatter.
-
-> **Legacy support:** Always check both `.context/systematic/todos/` (canonical) and `todos/` (legacy) when reading. Write new todos only to the canonical path. This directory has a multi-session lifecycle -- do not clean it up as scratch.
-
-## Directory Paths
-
-| Purpose | Path |
-|---------|------|
-| **Canonical (write here)** | `.context/systematic/todos/` |
-| **Legacy (read-only)** | `todos/` |
-
-## File Naming Convention
-
-```
-{issue_id}-{status}-{priority}-{description}.md
-```
-
-- **issue_id**: Sequential number (001, 002, ...) -- never reused
-- **status**: `pending` | `ready` | `complete`
-- **priority**: `p1` (critical) | `p2` (important) | `p3` (nice-to-have)
-- **description**: kebab-case, brief
-
-**Example:** `002-ready-p1-fix-n-plus-1.md`
-
-## File Structure
-
-Each todo has YAML frontmatter and structured sections. Use the todo template included below when creating new todos.
-
-```yaml
----
-status: ready
-priority: p1
-issue_id: "002"
-tags: [rails, performance]
-dependencies: ["001"]     # Issue IDs this is blocked by
----
-```
-
-**Required sections:** Problem Statement, Findings, Proposed Solutions, Recommended Action (filled during triage), Acceptance Criteria, Work Log.
-
-**Optional sections:** Technical Details, Resources, Notes.
-
-## Workflows
-
-> **Tool preference:** Use native file-search/glob and content-search tools instead of shell commands for finding and reading todo files. Shell only for operations with no native equivalent (`mv`, `mkdir -p`).
-
-### Creating a New Todo
-
-1. `mkdir -p .context/systematic/todos/`
-2. Search both paths for `[0-9]*-*.md`, find the highest numeric prefix, increment, zero-pad to 3 digits.
-3. Use the todo template included below, write to canonical path as `{NEXT_ID}-pending-{priority}-{description}.md`.
-4. Fill Problem Statement, Findings, Proposed Solutions, Acceptance Criteria, and initial Work Log entry.
-5. Set status: `pending` (needs triage) or `ready` (pre-approved).
-
-**Create a todo when** the work needs more than ~15 minutes, has dependencies, requires planning, or needs prioritization. **Act immediately instead** when the fix is trivial, obvious, and self-contained.
-
-### Triaging Pending Items
-
-1. Glob `*-pending-*.md` in both paths.
-2. Review each todo's Problem Statement, Findings, and Proposed Solutions.
-3. Approve: rename `pending` -> `ready` in filename and frontmatter, fill Recommended Action.
-4. Defer: leave as `pending`.
-
-Load the `todo-triage` skill for an interactive approval workflow.
-
-### Managing Dependencies
-
-```yaml
-dependencies: ["002", "005"]  # Blocked by these issues
-dependencies: []               # No blockers
-```
-
-To check blockers: search for `{dep_id}-complete-*.md` in both paths. Missing matches = incomplete blockers.
-
-### Completing a Todo
-
-1. Verify all acceptance criteria.
-2. Update Work Log with final session.
-3. Rename `ready` -> `complete` in filename and frontmatter.
-4. Check for unblocked work: search for files containing `dependencies:.*"{issue_id}"`.
-
-## Integration with Workflows
-
-| Trigger | Flow |
-|---------|------|
-| Code review | `/ce:review` -> Findings -> `/systematic:todo-triage` -> Todos |
-| Autonomous review | `/ce:review mode:autofix` -> Residual todos -> `/systematic:todo-resolve` |
-| Code TODOs | `/systematic:todo-resolve` -> Fixes + Complex todos |
-| Planning | Brainstorm -> Create todo -> Work -> Complete |
-
-## Key Distinction
-
-This skill manages **durable, cross-session work items** persisted as markdown files. For temporary in-session step tracking, use platform task tools (`todowrite`/`TaskUpdate` in OpenCode, `update_plan` in Codex) instead.
-
----
-
-## Todo Template
-
-@./assets/todo-template.md

package/skills/todo-resolve/SKILL.md

@@ -1,68 +0,0 @@
----
-name: todo-resolve
-description: Use when batch-resolving approved todos, especially after code review or triage sessions
-argument-hint: "[optional: specific todo ID or pattern]"
----
-
-Resolve approved todos using parallel processing, document lessons learned, then clean up.
-
-Only `ready` todos are resolved. `pending` todos are skipped — they haven't been triaged yet. If pending todos exist, list them at the end so the user knows what was left behind.
-
-## Workflow
-
-### 1. Analyze
-
-Scan `.context/systematic/todos/*.md` and legacy `todos/*.md`. Partition by status:
-
-- **`ready`** (status field or `-ready-` in filename): resolve these.
-- **`pending`**: skip. Report them at the end.
-- **`complete`**: ignore, already done.
-
-If a specific todo ID or pattern was passed as an argument, filter to matching todos only (still must be `ready`).
-
-Residual actionable work from `ce:review mode:autofix` after its `safe_auto` pass will already be `ready`.
-
-Skip any todo that recommends deleting, removing, or gitignoring files in `docs/brainstorms/`, `docs/plans/`, or `docs/solutions/` — these are intentional pipeline artifacts.
-
-### 2. Plan
-
-Create a task list grouped by type (e.g., `todowrite` in OpenCode, `update_plan` in Codex). Analyze dependencies -- items that others depend on run first. Output a mermaid diagram showing execution order and parallelism.
-
-### 3. Implement (PARALLEL)
-
-Spawn a `systematic:workflow:pr-comment-resolver` agent per item. Prefer parallel; fall back to sequential respecting dependency order.
-
-**Batching:** 1-4 items: direct parallel returns. 5+ items: batches of 4, each returning only a short status summary (todo handled, files changed, tests run/skipped, blockers).
-
-For large sets, use a scratch directory at `.context/systematic/todo-resolve/<run-id>/` for per-resolver artifacts. Return only completion summaries to parent.
-
-### 4. Commit & Resolve
-
-Commit changes, mark todos resolved, push to remote.
-
-GATE: STOP. Verify todos resolved and changes committed before proceeding.
-
-### 5. Compound on Lessons Learned
-
-Load the `ce:compound` skill to document what was learned. Todo resolutions often surface patterns and architectural insights worth capturing.
-
-GATE: STOP. Verify the compound skill produced a solution document in `docs/solutions/`. If none (user declined or no learnings), continue.
-
-### 6. Clean Up
-
-Delete completed/resolved todo files from both paths. If a scratch directory was created at `.context/systematic/todo-resolve/<run-id>/`, delete it (unless user asked to inspect).
-
-```
-Todos resolved: [count]
-Pending (skipped): [count, or "none"]
-Lessons documented: [path to solution doc, or "skipped"]
-Todos cleaned up: [count deleted]
-```
-
-If pending todos were skipped, list them:
-
-```
-Skipped pending todos (run `/systematic:todo-triage` to approve):
-  - 003-pending-p2-missing-index.md
-  - 005-pending-p3-rename-variable.md
-```

package/skills/todo-triage/SKILL.md

@@ -1,70 +0,0 @@
----
-name: todo-triage
-description: Use when reviewing pending todos for approval, prioritizing code review findings, or interactively categorizing work items
-argument-hint: "[findings list or source type]"
-disable-model-invocation: true
----
-
-# Todo Triage
-
-Interactive workflow for reviewing pending todos one by one and deciding whether to approve, skip, or modify each.
-
-**Do not write code during triage.** This is purely for review and prioritization -- implementation happens in `/systematic:todo-resolve`.
-
-- First set the /model to Haiku
-- Read all pending todos from `.context/systematic/todos/` and legacy `todos/` directories
-
-## Workflow
-
-### 1. Present Each Finding
-
-For each pending todo, present it clearly with severity, category, description, location, problem scenario, proposed solution, and effort estimate. Then ask:
-
-```
-Do you want to add this to the todo list?
-1. yes - approve and mark ready
-2. next - skip (deletes the todo file)
-3. custom - modify before approving
-```
-
-Use severity levels: 🔴 P1 (CRITICAL), 🟡 P2 (IMPORTANT), 🔵 P3 (NICE-TO-HAVE).
-
-Include progress tracking in each header: `Progress: 3/10 completed`
-
-### 2. Handle Decision
-
-**yes:** Rename file from `pending` -> `ready` in both filename and frontmatter. Fill the Recommended Action section. If creating a new todo (not updating existing), use the naming convention from the `todo-create` skill.
-
-Priority mapping: 🔴 P1 -> `p1`, 🟡 P2 -> `p2`, 🔵 P3 -> `p3`
-
-Confirm: "✅ Approved: `{filename}` (Issue #{issue_id}) - Status: **ready**"
-
-**next:** Delete the todo file. Log as skipped for the final summary.
-
-**custom:** Ask what to modify, update, re-present, ask again.
-
-### 3. Final Summary
-
-After all items processed:
-
-```markdown
-## Triage Complete
-
-**Total Items:** [X] | **Approved (ready):** [Y] | **Skipped:** [Z]
-
-### Approved Todos (Ready for Work):
-- `042-ready-p1-transaction-boundaries.md` - Transaction boundary issue
-
-### Skipped (Deleted):
-- Item #5: [reason]
-```
-
-### 4. Next Steps
-
-```markdown
-What would you like to do next?
-
-1. run `/systematic:todo-resolve` to resolve the todos
-2. commit the todos
-3. nothing, go chill
-```

package/skills/writing-systematic-skills/SKILL.md

@@ -1,119 +0,0 @@
----
-name: writing-systematic-skills
-description: Use when creating, editing, auditing, or fixing bundled Systematic skills, especially when authoring SKILL.md files, adding skill reference files, resolving content-integrity frontmatter failures, or deciding which Systematic conventions apply beyond the general writing-skills guidance.
----
-
-# Writing Systematic Skills
-
-Systematic skills are OpenCode-native workflow assets. Use this skill after loading the general `writing-skills` foundation; this file only covers the Systematic-specific delta.
-
-## When To Use
-
-Use this skill when you are:
-
-- Creating a new bundled skill under `skills/`
-- Editing an existing bundled skill's frontmatter or file layout
-- Fixing content-integrity frontmatter or sub-file failures
-- Deciding whether a skill needs references, scripts, assets, or templates
-- Auditing bundled skills for provider-portable defaults
-
-Load `writing-skills` first (bundled). This skill covers the Systematic delta.
-
-## Foundation
-
-`writing-skills` supplies the authoring discipline: pressure scenarios, clear trigger-oriented descriptions, concise bodies, and reference files only when depth earns its keep.
-
-Systematic adds repository-specific constraints:
-
-- Runtime-recognized frontmatter fields are fixed by the skill loader.
-- Skill sub-files live in a small set of conventional directories.
-- Bundled agents omit the `model` field; subagents inherit the invoking primary agent's model.
-- Content-integrity enforces the mechanical parts in CI.
-
-For worked examples and judgment calls, read `references/foundation-conventions.md`.
-
-## Frontmatter Rules
-
-Every bundled skill must have YAML frontmatter with:
-
-- `name` - unprefixed skill identifier. The loader adds the `systematic:` command prefix automatically unless the skill intentionally belongs to another namespace such as `ce:`.
-- `description` - third-person trigger conditions. Prefer `Use when...`; describe when to load the skill, not its internal workflow.
-
-Optional fields are allowed only when the runtime loader recognizes them:
-
-| Field | Use |
-|---|---|
-| `argument-hint` | Shows expected invocation arguments. |
-| `disable-model-invocation` | Prevents direct model invocation for dispatcher-style skills. |
-| `allowed-tools` | Declares tool constraints for skill execution. |
-| `license` | Carries skill licensing metadata. |
-| `compatibility` | Notes platform or version compatibility. |
-| `metadata` | String-only metadata map. |
-| `user-invocable` | Marks whether users should invoke the skill directly. |
-| `agent` | Selects a companion agent when the loader supports it. |
-| `model` | Selects a model for skill execution when justified. |
-| `context` | Use `fork` when the skill should run in forked subtask context. |
-| `subtask` | Explicit forked-subtask marker recognized by the runtime. |
-
-`preconditions` is banned. It has no runtime consumer. Put prerequisite guidance in the skill body instead.
-
-## File Layout
-
-The required entry point is:
-
-```text
-skills/<skill-name>/SKILL.md
-```
-
-Optional sub-files must live under one of these directories:
-
-- `references/` - deeper guidance, decision tables, long examples, or API notes
-- `scripts/` - executable helpers an agent can run
-- `assets/` - static files used by the skill
-- `templates/` - reusable stubs or document templates
-
-Keep the main `SKILL.md` small enough to decide whether and how to proceed. Move heavy detail to `references/`, and cite it with a repo-local path such as `references/foundation-conventions.md` so the sub-file integrity gate can verify it exists.
-
-## Identity Defaults
-
-Bundled agents must omit the `model` field entirely:
-
-```yaml
----
-name: example-agent
-description: ...
-# no `model:` line
----
-```
-
-Per [OpenCode's agent docs](https://opencode.ai/docs/agents/), subagents with no `model` inherit the model of the primary agent that invoked them — which is the desired portable behavior. Do **not** declare `model: inherit`: that literal value is undocumented and produces `ProviderModelNotFoundError` on OpenCode older than ~v1.13.x (pre [sst/opencode#17888](https://github.com/sst/opencode/pull/17888)). Hardcoded provider model IDs (`anthropic/...`, `openai/...`, etc.) are also banned from **bundled agent markdown/frontmatter** because they break users on other providers. Source-owned category model defaults in TypeScript code are a separate mechanism — they are audited, centrally maintained, and do not violate this markdown rule.
-
-For agent or API attribution, `ai:systematic` is the machine ID used by Systematic-owned operations, such as Proof's `by` field and `X-Agent-Id` header. It is not a skill cross-reference convention.
-
-## Validator
-
-Run the content-integrity gate before shipping skill changes:
-
-```bash
-bun 'scripts/content-integrity.ts'
-```
-
-The gate checks:
-
-- Skill frontmatter is present and uses only runtime-recognized fields.
-- Required `name` and `description` fields are non-empty.
-- Banned frontmatter such as `preconditions` is absent.
-- Bundled agents omit the `model` field.
-- Skill references to `references/`, `scripts/`, `assets/`, and `templates/` resolve on disk.
-
-If the gate fails, fix the content rather than broadening the validator unless the runtime loader contract has actually changed.
-
-## Common Mistakes
-
-| Mistake | Fix |
-|---|---|
-| Adding a new frontmatter field because it reads well | Add body prose instead, unless the runtime loader consumes the field. |
-| Summarizing the whole workflow in `description` | Describe trigger conditions only. |
-| Adding any `model` field to a bundled agent | Omit the field; subagents inherit from the invoking primary agent. |
-| Linking to a non-existent reference file | Create the file or remove the link. |
-| Duplicating the general writing-skills guidance | Link to the foundation and document only the Systematic delta. |