@fro.bot/systematic 2.2.1 → 2.3.0

package/skills/ce-review-beta/references/diff-scope.md

@@ -1,31 +0,0 @@
-# Diff Scope Rules
-
-These rules apply to every reviewer. They define what is "your code to review" versus pre-existing context.
-
-## Scope Discovery
-
-Determine the diff to review using this priority order:
-
-1. **User-specified scope.** If the caller passed `BASE:`, `FILES:`, or `DIFF:` markers, use that scope exactly.
-2. **Working copy changes.** If there are unstaged or staged changes (`git diff HEAD` is non-empty), review those.
-3. **Unpushed commits vs base branch.** If the working copy is clean, review `git diff $(git merge-base HEAD <base>)..HEAD` where `<base>` is the default branch (main or master).
-
-The scope step in the SKILL.md handles discovery and passes you the resolved diff. You do not need to run git commands yourself.
-
-## Finding Classification Tiers
-
-Every finding you report falls into one of three tiers based on its relationship to the diff:
-
-### Primary (directly changed code)
-
-Lines added or modified in the diff. This is your main focus. Report findings against these lines at full confidence.
-
-### Secondary (immediately surrounding code)
-
-Unchanged code within the same function, method, or block as a changed line. If a change introduces a bug that's only visible by reading the surrounding context, report it -- but note that the issue exists in the interaction between new and existing code.
-
-### Pre-existing (unrelated to this diff)
-
-Issues in unchanged code that the diff didn't touch and doesn't interact with. Mark these as `"pre_existing": true` in your output. They're reported separately and don't count toward the review verdict.
-
-**The rule:** If you'd flag the same issue on an identical diff that didn't include the surrounding file, it's pre-existing. If the diff makes the issue *newly relevant* (e.g., a new caller hits an existing buggy function), it's secondary.

package/skills/ce-review-beta/references/findings-schema.json

@@ -1,128 +0,0 @@
-{
-  "$schema": "http://json-schema.org/draft-07/schema#",
-  "title": "Code Review Findings",
-  "description": "Structured output schema for code review sub-agents",
-  "type": "object",
-  "required": ["reviewer", "findings", "residual_risks", "testing_gaps"],
-  "properties": {
-    "reviewer": {
-      "type": "string",
-      "description": "Persona name that produced this output (e.g., 'correctness', 'security')"
-    },
-    "findings": {
-      "type": "array",
-      "description": "List of code review findings. Empty array if no issues found.",
-      "items": {
-        "type": "object",
-        "required": [
-          "title",
-          "severity",
-          "file",
-          "line",
-          "why_it_matters",
-          "autofix_class",
-          "owner",
-          "requires_verification",
-          "confidence",
-          "evidence",
-          "pre_existing"
-        ],
-        "properties": {
-          "title": {
-            "type": "string",
-            "description": "Short, specific issue title. 10 words or fewer.",
-            "maxLength": 100
-          },
-          "severity": {
-            "type": "string",
-            "enum": ["P0", "P1", "P2", "P3"],
-            "description": "Issue severity level"
-          },
-          "file": {
-            "type": "string",
-            "description": "Relative file path from repository root"
-          },
-          "line": {
-            "type": "integer",
-            "description": "Primary line number of the issue",
-            "minimum": 1
-          },
-          "why_it_matters": {
-            "type": "string",
-            "description": "Impact and failure mode -- not 'what is wrong' but 'what breaks'"
-          },
-          "autofix_class": {
-            "type": "string",
-            "enum": ["safe_auto", "gated_auto", "manual", "advisory"],
-            "description": "Reviewer's conservative recommendation for how this issue should be handled after synthesis"
-          },
-          "owner": {
-            "type": "string",
-            "enum": ["review-fixer", "downstream-resolver", "human", "release"],
-            "description": "Who should own the next action for this finding after synthesis"
-          },
-          "requires_verification": {
-            "type": "boolean",
-            "description": "Whether any fix for this finding must be re-verified with targeted tests or a follow-up review pass"
-          },
-          "suggested_fix": {
-            "type": ["string", "null"],
-            "description": "Concrete minimal fix. Omit or null if no good fix is obvious -- a bad suggestion is worse than none."
-          },
-          "confidence": {
-            "type": "number",
-            "description": "Reviewer confidence in this finding, calibrated per persona",
-            "minimum": 0.0,
-            "maximum": 1.0
-          },
-          "evidence": {
-            "type": "array",
-            "description": "Code-grounded evidence: snippets, line references, or pattern descriptions. At least 1 item.",
-            "items": { "type": "string" },
-            "minItems": 1
-          },
-          "pre_existing": {
-            "type": "boolean",
-            "description": "True if this issue exists in unchanged code unrelated to the current diff"
-          }
-        }
-      }
-    },
-    "residual_risks": {
-      "type": "array",
-      "description": "Risks the reviewer noticed but could not confirm as findings",
-      "items": { "type": "string" }
-    },
-    "testing_gaps": {
-      "type": "array",
-      "description": "Missing test coverage the reviewer identified",
-      "items": { "type": "string" }
-    }
-  },
-
-  "_meta": {
-    "confidence_thresholds": {
-      "suppress": "Below 0.60 -- do not report. Finding is speculative noise.",
-      "flag": "0.60-0.69 -- include only when the persona's calibration says the issue is actionable at that confidence.",
-      "report": "0.70+ -- report with full confidence."
-    },
-    "severity_definitions": {
-      "P0": "Critical breakage, exploitable vulnerability, data loss/corruption. Must fix before merge.",
-      "P1": "High-impact defect likely hit in normal usage, breaking contract. Should fix.",
-      "P2": "Moderate issue with meaningful downside (edge case, perf regression, maintainability trap). Fix if straightforward.",
-      "P3": "Low-impact, narrow scope, minor improvement. User's discretion."
-    },
-    "autofix_classes": {
-      "safe_auto": "Local, deterministic code or test fix suitable for the in-skill fixer in autonomous mode.",
-      "gated_auto": "Concrete fix exists, but it changes behavior, permissions, contracts, or other sensitive areas that deserve explicit approval.",
-      "manual": "Actionable issue that should become residual work rather than an in-skill autofix.",
-      "advisory": "Informational or operational item that should be surfaced in the report only."
-    },
-    "owners": {
-      "review-fixer": "The in-skill fixer can own this when policy allows.",
-      "downstream-resolver": "Turn this into residual work for later resolution.",
-      "human": "A person must make a judgment call before code changes should continue.",
-      "release": "Operational or rollout follow-up; do not convert into code-fix work automatically."
-    }
-  }
-}

package/skills/ce-review-beta/references/persona-catalog.md

@@ -1,50 +0,0 @@
-# Persona Catalog
-
-8 reviewer personas organized in two tiers, plus CE-specific agents. The orchestrator uses this catalog to select which reviewers to spawn for each review.
-
-## Always-on (3 personas + 2 CE agents)
-
-Spawned on every review regardless of diff content.
-
-**Persona agents (structured JSON output):**
-
-| Persona | Agent | Focus |
-|---------|-------|-------|
-| `correctness` | `systematic:review:correctness-reviewer` | Logic errors, edge cases, state bugs, error propagation, intent compliance |
-| `testing` | `systematic:review:testing-reviewer` | Coverage gaps, weak assertions, brittle tests, missing edge case tests |
-| `maintainability` | `systematic:review:maintainability-reviewer` | Coupling, complexity, naming, dead code, premature abstraction |
-
-**CE agents (unstructured output, synthesized separately):**
-
-| Agent | Focus |
-|-------|-------|
-| `systematic:review:agent-native-reviewer` | Verify new features are agent-accessible |
-| `systematic:research:learnings-researcher` | Search docs/solutions/ for past issues related to this PR's modules and patterns |
-
-## Conditional (5 personas)
-
-Spawned when the orchestrator identifies relevant patterns in the diff. The orchestrator reads the full diff and reasons about selection -- this is agent judgment, not keyword matching.
-
-| Persona | Agent | Select when diff touches... |
-|---------|-------|---------------------------|
-| `security` | `systematic:review:security-reviewer` | Auth middleware, public endpoints, user input handling, permission checks, secrets management |
-| `performance` | `systematic:review:performance-reviewer` | Database queries, ORM calls, loop-heavy data transforms, caching layers, async/concurrent code |
-| `api-contract` | `systematic:review:api-contract-reviewer` | Route definitions, serializer/interface changes, event schemas, exported type signatures, API versioning |
-| `data-migrations` | `systematic:review:data-migrations-reviewer` | Migration files, schema changes, backfill scripts, data transformations |
-| `reliability` | `systematic:review:reliability-reviewer` | Error handling, retry logic, circuit breakers, timeouts, background jobs, async handlers, health checks |
-
-## CE Conditional Agents (migration-specific)
-
-These CE-native agents provide specialized analysis beyond what the persona agents cover. Spawn them when the diff includes database migrations, schema.rb, or data backfills.
-
-| Agent | Focus |
-|-------|-------|
-| `systematic:review:schema-drift-detector` | Cross-references schema.rb changes against included migrations to catch unrelated drift |
-| `systematic:review:deployment-verification-agent` | Produces Go/No-Go deployment checklist with SQL verification queries and rollback procedures |
-
-## Selection rules
-
-1. **Always spawn all 3 always-on personas** plus the 2 CE always-on agents.
-2. **For each conditional persona**, the orchestrator reads the diff and decides whether the persona's domain is relevant. This is a judgment call, not a keyword match.
-3. **For CE conditional agents**, spawn when the diff includes migration files (`db/migrate/*.rb`, `db/schema.rb`) or data backfill scripts.
-4. **Announce the team** before spawning with a one-line justification per conditional reviewer selected.

package/skills/ce-review-beta/references/review-output-template.md

@@ -1,115 +0,0 @@
-# Code Review Output Template
-
-Use this **exact format** when presenting synthesized review findings. Findings are grouped by severity, not by reviewer.
-
-**IMPORTANT:** Use pipe-delimited markdown tables (`| col | col |`). Do NOT use ASCII box-drawing characters.
-
-## Example
-
-```markdown
-## Code Review Results
-
-**Scope:** merge-base with the review base branch -> working tree (14 files, 342 lines)
-**Intent:** Add order export endpoint with CSV and JSON format support
-**Mode:** autonomous
-
-**Reviewers:** correctness, testing, maintainability, security, api-contract
-- security -- new public endpoint accepts user-provided format parameter
-- api-contract -- new /api/orders/export route with response schema
-
-### P0 -- Critical
-
-| # | File | Issue | Reviewer | Confidence | Route |
-|---|------|-------|----------|------------|-------|
-| 1 | `orders_controller.rb:42` | User-supplied ID in account lookup without ownership check | security | 0.92 | `gated_auto -> downstream-resolver` |
-
-### P1 -- High
-
-| # | File | Issue | Reviewer | Confidence | Route |
-|---|------|-------|----------|------------|-------|
-| 2 | `export_service.rb:87` | Loads all orders into memory -- unbounded for large accounts | performance | 0.85 | `safe_auto -> review-fixer` |
-| 3 | `export_service.rb:91` | No pagination -- response size grows linearly with order count | api-contract, performance | 0.80 | `manual -> downstream-resolver` |
-
-### P2 -- Moderate
-
-| # | File | Issue | Reviewer | Confidence | Route |
-|---|------|-------|----------|------------|-------|
-| 4 | `export_service.rb:45` | Missing error handling for CSV serialization failure | correctness | 0.75 | `safe_auto -> review-fixer` |
-
-### P3 -- Low
-
-| # | File | Issue | Reviewer | Confidence | Route |
-|---|------|-------|----------|------------|-------|
-| 5 | `export_helper.rb:12` | Format detection could use early return instead of nested conditional | maintainability | 0.70 | `advisory -> human` |
-
-### Applied Fixes
-
-- `safe_auto`: Added bounded export pagination guard and CSV serialization failure test coverage in this run
-
-### Residual Actionable Work
-
-| # | File | Issue | Route | Next Step |
-|---|------|-------|-------|-----------|
-| 1 | `orders_controller.rb:42` | Ownership check missing on export lookup | `gated_auto -> downstream-resolver` | Create residual todo and require explicit approval before behavior change |
-| 2 | `export_service.rb:91` | Pagination contract needs a broader API decision | `manual -> downstream-resolver` | Create residual todo with contract and client impact details |
-
-### Pre-existing Issues
-
-| # | File | Issue | Reviewer |
-|---|------|-------|----------|
-| 1 | `orders_controller.rb:12` | Broad rescue masking failed permission check | correctness |
-
-### Learnings & Past Solutions
-
-- [Known Pattern] `docs/solutions/export-pagination.md` -- previous export pagination fix applies to this endpoint
-
-### Agent-Native Gaps
-
-- New export endpoint has no CLI/agent equivalent -- agent users cannot trigger exports
-
-### Schema Drift Check
-
-- Clean: schema.rb changes match the migrations in scope
-
-### Deployment Notes
-
-- Pre-deploy: capture baseline row counts before enabling the export backfill
-- Verify: `SELECT COUNT(*) FROM exports WHERE status IS NULL;` should stay at `0`
-- Rollback: keep the old export path available until the backfill has been validated
-
-### Coverage
-
-- Suppressed: 2 findings below 0.60 confidence
-- Residual risks: No rate limiting on export endpoint
-- Testing gaps: No test for concurrent export requests
-
----
-
-> **Verdict:** Ready with fixes
->
-> **Reasoning:** 1 critical auth bypass must be fixed. The memory/pagination issues (P1) should be addressed for production safety.
->
-> **Fix order:** P0 auth bypass -> P1 memory/pagination -> P2 error handling if straightforward
-```
-
-## Formatting Rules
-
-- **Pipe-delimited markdown tables** -- never ASCII box-drawing characters
-- **Severity-grouped sections** -- `### P0 -- Critical`, `### P1 -- High`, `### P2 -- Moderate`, `### P3 -- Low`. Omit empty severity levels.
-- **Always include file:line location** for code review issues
-- **Reviewer column** shows which persona(s) flagged the issue. Multiple reviewers = cross-reviewer agreement.
-- **Confidence column** shows the finding's confidence score
-- **Route column** shows the synthesized handling decision as ``<autofix_class> -> <owner>``.
-- **Header includes** scope, intent, and reviewer team with per-conditional justifications
-- **Mode line** -- include `interactive`, `autonomous`, or `report-only`
-- **Applied Fixes section** -- include only when a fix phase ran in this review invocation
-- **Residual Actionable Work section** -- include only when unresolved actionable findings were handed off for later work
-- **Pre-existing section** -- separate table, no confidence column (these are informational)
-- **Learnings & Past Solutions section** -- results from learnings-researcher, with links to docs/solutions/ files
-- **Agent-Native Gaps section** -- results from agent-native-reviewer. Omit if no gaps found.
-- **Schema Drift Check section** -- results from schema-drift-detector. Omit if the agent did not run.
-- **Deployment Notes section** -- key checklist items from deployment-verification-agent. Omit if the agent did not run.
-- **Coverage section** -- suppressed count, residual risks, testing gaps, failed reviewers
-- **Summary uses blockquotes** for verdict, reasoning, and fix order
-- **Horizontal rule** (`---`) separates findings from verdict
-- **`###` headers** for each section -- never plain text headers

package/skills/ce-review-beta/references/subagent-template.md

@@ -1,56 +0,0 @@
-# Sub-agent Prompt Template
-
-This template is used by the orchestrator to spawn each reviewer sub-agent. Variable substitution slots are filled at spawn time.
-
----
-
-## Template
-
-```
-You are a specialist code reviewer.
-
-<persona>
-{persona_file}
-</persona>
-
-<scope-rules>
-{diff_scope_rules}
-</scope-rules>
-
-<output-contract>
-Return ONLY valid JSON matching the findings schema below. No prose, no markdown, no explanation outside the JSON object.
-
-{schema}
-
-Rules:
-- Suppress any finding below your stated confidence floor (see your Confidence calibration section).
-- Every finding MUST include at least one evidence item grounded in the actual code.
-- Set pre_existing to true ONLY for issues in unchanged code that are unrelated to this diff. If the diff makes the issue newly relevant, it is NOT pre-existing.
-- You are operationally read-only. You may use non-mutating inspection commands, including read-oriented `git` / `gh` commands, to gather evidence. Do not edit files, change branches, commit, push, create PRs, or otherwise mutate the checkout or repository state.
-- Set `autofix_class` conservatively. Use `safe_auto` only when the fix is local, deterministic, and low-risk. Use `gated_auto` when a concrete fix exists but changes behavior/contracts/permissions. Use `manual` for actionable residual work. Use `advisory` for report-only items that should not become code-fix work.
-- Set `owner` to the default next actor for this finding: `review-fixer`, `downstream-resolver`, `human`, or `release`.
-- Set `requires_verification` to true whenever the likely fix needs targeted tests, a focused re-review, or operational validation before it should be trusted.
-- suggested_fix is optional. Only include it when the fix is obvious and correct. A bad suggestion is worse than none.
-- If you find no issues, return an empty findings array. Still populate residual_risks and testing_gaps if applicable.
-</output-contract>
-
-<review-context>
-Intent: {intent_summary}
-
-Changed files: {file_list}
-
-Diff:
-{diff}
-</review-context>
-```
-
-## Variable Reference
-
-| Variable | Source | Description |
-|----------|--------|-------------|
-| `{persona_file}` | Agent markdown file content | The full persona definition (identity, failure modes, calibration, suppress conditions) |
-| `{diff_scope_rules}` | `references/diff-scope.md` content | Primary/secondary/pre-existing tier rules |
-| `{schema}` | `references/findings-schema.json` content | The JSON schema reviewers must conform to |
-| `{intent_summary}` | Stage 2 output | 2-3 line description of what the change is trying to accomplish |
-| `{file_list}` | Stage 1 output | List of changed files from the scope step |
-| `{diff}` | Stage 1 output | The actual diff content to review |

package/skills/file-todos/SKILL.md

@@ -1,231 +0,0 @@
----
-name: file-todos
-description: This skill should be used when managing the file-based todo tracking system in the .context/systematic/todos/ directory. It provides workflows for creating todos, managing status and dependencies, conducting triage, and integrating with code review processes.
-disable-model-invocation: true
----
-
-# File-Based Todo Tracking Skill
-
-## Overview
-
-The `.context/systematic/todos/` directory contains a file-based tracking system for managing code review feedback, technical debt, feature requests, and work items. Each todo is a markdown file with YAML frontmatter and structured sections.
-
-> **Legacy support:** During the transition period, always check both `.context/systematic/todos/` (canonical) and `todos/` (legacy) when reading or searching for todos. Write new todos only to the canonical path. Unlike per-run scratch directories, `.context/systematic/todos/` has a multi-session lifecycle -- do not clean it up as part of post-run scratch cleanup.
-
-This skill should be used when:
-- Creating new todos from findings or feedback
-- Managing todo lifecycle (pending -> ready -> complete)
-- Triaging pending items for approval
-- Checking or managing dependencies
-- Converting PR comments or code findings into tracked work
-- Updating work logs during todo execution
-
-## Directory Paths
-
-| Purpose | Path |
-|---------|------|
-| **Canonical (write here)** | `.context/systematic/todos/` |
-| **Legacy (read-only)** | `todos/` |
-
-When searching or listing todos, always search both paths. When creating new todos, always write to the canonical path.
-
-## File Naming Convention
-
-```
-{issue_id}-{status}-{priority}-{description}.md
-```
-
-**Components:**
-- **issue_id**: Sequential number (001, 002, 003...) -- never reused
-- **status**: `pending` (needs triage), `ready` (approved), `complete` (done)
-- **priority**: `p1` (critical), `p2` (important), `p3` (nice-to-have)
-- **description**: kebab-case, brief description
-
-**Examples:**
-```
-001-pending-p1-mailer-test.md
-002-ready-p1-fix-n-plus-1.md
-005-complete-p2-refactor-csv.md
-```
-
-## File Structure
-
-Each todo is a markdown file with YAML frontmatter and structured sections. Use the template at [todo-template.md](./assets/todo-template.md) as a starting point when creating new todos.
-
-**Required sections:**
-- **Problem Statement** -- What is broken, missing, or needs improvement?
-- **Findings** -- Investigation results, root cause, key discoveries
-- **Proposed Solutions** -- Multiple options with pros/cons, effort, risk
-- **Recommended Action** -- Clear plan (filled during triage)
-- **Acceptance Criteria** -- Testable checklist items
-- **Work Log** -- Chronological record with date, actions, learnings
-
-**Optional sections:**
-- **Technical Details** -- Affected files, related components, DB changes
-- **Resources** -- Links to errors, tests, PRs, documentation
-- **Notes** -- Additional context or decisions
-
-**YAML frontmatter fields:**
-```yaml
----
-status: ready              # pending | ready | complete
-priority: p1              # p1 | p2 | p3
-issue_id: "002"
-tags: [rails, performance, database]
-dependencies: ["001"]     # Issue IDs this is blocked by
----
-```
-
-## Common Workflows
-
-> **Tool preference:** Use native file-search (e.g., Glob in OpenCode) and content-search (e.g., Grep in OpenCode) tools instead of shell commands for finding and reading todo files. This avoids unnecessary permission prompts in sub-agent workflows. Use shell only for operations that have no native equivalent (e.g., `mv` for renames, `mkdir -p` for directory creation).
-
-### Creating a New Todo
-
-1. Ensure directory exists: `mkdir -p .context/systematic/todos/`
-2. Determine next issue ID by searching both canonical and legacy paths for files matching `[0-9]*-*.md` using the native file-search/glob tool. Extract the numeric prefix from each filename, find the highest, and increment by one. Zero-pad to 3 digits (e.g., `007`).
-3. Read the template at [todo-template.md](./assets/todo-template.md), then write it to `.context/systematic/todos/{NEXT_ID}-pending-{priority}-{description}.md` using the native file-write tool.
-4. Edit and fill required sections:
-   - Problem Statement
-   - Findings (if from investigation)
-   - Proposed Solutions (multiple options)
-   - Acceptance Criteria
-   - Add initial Work Log entry
-5. Determine status: `pending` (needs triage) or `ready` (pre-approved)
-6. Add relevant tags for filtering
-
-**When to create a todo:**
-- Requires more than 15-20 minutes of work
-- Needs research, planning, or multiple approaches considered
-- Has dependencies on other work
-- Requires manager approval or prioritization
-- Part of larger feature or refactor
-- Technical debt needing documentation
-
-**When to act immediately instead:**
-- Issue is trivial (< 15 minutes)
-- Complete context available now
-- No planning needed
-- User explicitly requests immediate action
-- Simple bug fix with obvious solution
-
-### Triaging Pending Items
-
-1. Find pending items using the native file-search/glob tool with pattern `*-pending-*.md` in both directory paths.
-2. For each todo:
-   - Read Problem Statement and Findings
-   - Review Proposed Solutions
-   - Make decision: approve, defer, or modify priority
-3. Update approved todos:
-   - Rename file: `mv {file}-pending-{pri}-{desc}.md {file}-ready-{pri}-{desc}.md`
-   - Update frontmatter: `status: pending` -> `status: ready`
-   - Fill "Recommended Action" section with clear plan
-   - Adjust priority if different from initial assessment
-4. Deferred todos stay in `pending` status
-
-Load the `triage` skill for an interactive approval workflow.
-
-### Managing Dependencies
-
-**To track dependencies:**
-
-```yaml
-dependencies: ["002", "005"]  # This todo blocked by issues 002 and 005
-dependencies: []               # No blockers - can work immediately
-```
-
-**To check what blocks a todo:** Use the native content-search tool (e.g., Grep in OpenCode) to search for `^dependencies:` in the todo file.
-
-**To find what a todo blocks:** Search both directory paths for files containing `dependencies:.*"002"` using the native content-search tool.
-
-**To verify blockers are complete before starting:** For each dependency ID, use the native file-search/glob tool to look for `{dep_id}-complete-*.md` in both directory paths. Any missing matches indicate incomplete blockers.
-
-### Updating Work Logs
-
-When working on a todo, always add a work log entry:
-
-```markdown
-### YYYY-MM-DD - Session Title
-
-**By:** Agent name / Developer Name
-
-**Actions:**
-- Specific changes made (include file:line references)
-- Commands executed
-- Tests run
-- Results of investigation
-
-**Learnings:**
-- What worked / what didn't
-- Patterns discovered
-- Key insights for future work
-```
-
-Work logs serve as:
-- Historical record of investigation
-- Documentation of approaches attempted
-- Knowledge sharing for team
-- Context for future similar work
-
-### Completing a Todo
-
-1. Verify all acceptance criteria checked off
-2. Update Work Log with final session and results
-3. Rename file: `mv {file}-ready-{pri}-{desc}.md {file}-complete-{pri}-{desc}.md`
-4. Update frontmatter: `status: ready` -> `status: complete`
-5. Check for unblocked work: search both directory paths for `*-ready-*.md` files containing `dependencies:.*"{issue_id}"` using the native content-search tool
-6. Commit with issue reference: `feat: resolve issue 002`
-
-## Integration with Development Workflows
-
-| Trigger | Flow | Tool |
-|---------|------|------|
-| Code review | `/ce:review` -> Findings -> `/triage` -> Todos | Review agent + skill |
-| Beta autonomous review | `/ce:review-beta mode:autonomous` -> Downstream-resolver residual todos -> `/resolve-todo-parallel` | Review skill + todos |
-| PR comments | `/resolve_pr_parallel` -> Individual fixes -> Todos | gh CLI + skill |
-| Code TODOs | `/resolve-todo-parallel` -> Fixes + Complex todos | Agent + skill |
-| Planning | Brainstorm -> Create todo -> Work -> Complete | Skill |
-| Feedback | Discussion -> Create todo -> Triage -> Work | Skill |
-
-## Quick Reference Patterns
-
-Use the native file-search/glob tool (e.g., Glob in OpenCode) and content-search tool (e.g., Grep in OpenCode) for these operations. Search both canonical and legacy directory paths.
-
-**Finding work:**
-
-| Goal | Tool | Pattern |
-|------|------|---------|
-| List highest priority unblocked work | Content-search | `dependencies: \[\]` in `*-ready-p1-*.md` |
-| List all pending items needing triage | File-search | `*-pending-*.md` |
-| Find next issue ID | File-search | `[0-9]*-*.md`, extract highest numeric prefix |
-| Count by status | File-search | `*-pending-*.md`, `*-ready-*.md`, `*-complete-*.md` |
-
-**Dependency management:**
-
-| Goal | Tool | Pattern |
-|------|------|---------|
-| What blocks this todo? | Content-search | `^dependencies:` in the specific todo file |
-| What does this todo block? | Content-search | `dependencies:.*"{id}"` across all todo files |
-
-**Searching:**
-
-| Goal | Tool | Pattern |
-|------|------|---------|
-| Search by tag | Content-search | `tags:.*{tag}` across all todo files |
-| Search by priority | File-search | `*-p1-*.md` (or p2, p3) |
-| Full-text search | Content-search | `{keyword}` across both directory paths |
-
-## Key Distinctions
-
-**File-todos system (this skill):**
-- Markdown files in `.context/systematic/todos/` (legacy: `todos/`)
-- Development/project tracking across sessions and agents
-- Standalone markdown files with YAML frontmatter
-- Persisted to disk, cross-agent accessible
-
-**In-session task tracking (e.g., todowrite/TaskUpdate in OpenCode, update_plan in Codex):**
-- In-memory task tracking during agent sessions
-- Temporary tracking for single conversation
-- Not persisted to disk after session ends
-- Different purpose: use for tracking steps within a session, not for durable cross-session work items
-