pi-maestro-teammate 0.3.0 → 0.4.2

package/README.md

@@ -1,9 +1,37 @@
 # pi-teammate
 
-> Teammate dispatch tool for [Pi](https://github.com/earendil-works/pi) — unified TaskSpec with DAG variable referencing
+> Teammate dispatch tool for [Pi](https://github.com/earendil-works/pi) — unified TaskSpec with DAG variable referencing + resident agent model
 
 Pi extension implementing teammate dispatch with **unified TaskSpec model**. Single agent, parallel fan-out, sequential chains, and arbitrary DAGs all use the same schema — execution order is determined by `{name}` variable references between tasks.
 
+## Automatic Model Routing
+
+Teammate maps task phases to models authenticated in the current Pi session. Supported task types are `explore`, `analysis`, `debug`, `planning`, `development`, `review`, and `testing`.
+
+Open the mapping overlay with `Alt+M` or `/teammate-models`. Project mappings are saved to `.pi/teammate-models.json`; global defaults can be stored in `~/.pi/agent/teammate-models.json`, with project values taking precedence.
+
+```json
+{
+  "version": 1,
+  "mappings": {
+    "explore": "google/gemini-2.5-pro",
+    "analysis": "openai/gpt-5",
+    "debug": "anthropic/claude-opus-4"
+  }
+}
+```
+
+Precedence is task-level `model` → top-level `model` → explicit `taskType` mapping → inferred task type → agent default. Omit `model` to use routing:
+
+```json
+{
+  "agent": "explorer",
+  "taskType": "explore",
+  "task": "FIND: auth middleware\nSCOPE: src/auth/",
+  "background": false
+}
+```
+
 ## Quick Start
 
 ### Single Agent
@@ -106,11 +134,48 @@ Top-level fields serve as defaults for all tasks:
 
 **Protocol version gate** — v2 (default) routes results to `caller`; v1 compat routes named agents to `main`. Explicit `reply_to` always wins.
 
+## Resident Agent Model
+
+Agents don't exit after completing a task. Instead they enter a **sleeping** state and can be woken up for follow-up work.
+
+### Lifecycle
+
+```
+dispatch → running → turn complete → sleeping → teammate-send → running → ...
+                                                                         ↓
+                                                              abort → terminated
+```
+
+| Status | Description |
+|--------|-------------|
+| `running` | Agent is actively processing a task |
+| `sleeping` | Turn complete, process alive, waiting for `teammate-send` to wake |
+| `completed` | Agent terminated (via abort or session shutdown) |
+
+### How It Works
+
+1. Agent completes its turn → `agent_end` event fires
+2. Result is reported to the main session (background notification)
+3. Agent enters **sleeping** state — RPC process stays alive, stdin open
+4. `teammate-send({ to: "name", message: "new task" })` sends a `follow_up` → agent wakes up and processes the new message
+5. `teammate-send({ to: "name", mode: "abort" })` terminates the agent
+
+### Active Time Tracking
+
+Time spent sleeping is excluded from the displayed duration. `sleepMs` accumulates total sleep time; displayed uptime = wall clock − sleep time.
+
+### Agent Fallback
+
+Any agent name works — if no `.md` definition file exists, a generic config is used:
+- `tools`: read, grep, find, ls, bash, edit, write (+ teammate proxy tools)
+- `systemPromptMode`: append (inherits pi default system prompt)
+- `inheritProjectContext`: true
+
 ## TaskSpec Schema
 
 ```typescript
 interface TaskSpec {
-  agent: string;        // Agent name (matches agents/*.md filename)
+  agent: string;        // Agent name (matches agents/*.md, or any name with fallback)
   task?: string;        // Task description with {name} variable support
   name?: string;        // Identifier for referencing and teammate-send
   model?: string;       // Model override
@@ -171,16 +236,16 @@ The `chain` field is preserved for backward compatibility. It normalizes interna
 
 ## Flat Agent Model
 
-All agents are managed by the root process in a single flat `activeRuns` pool, regardless of who requested the spawn. Child agents that call the teammate tool send a proxy request to the root, which spawns the new agent as a peer — not a nested subprocess.
+All agents are managed by the root process in a single flat `activeRuns` pool, regardless of who requested the spawn. Child agents that call the teammate tool send a proxy request to the root via IPC, which spawns the new agent as a peer — not a nested subprocess.
 
 ### How It Works
 
 ```
 coordinator calls teammate({ agent: "scout", name: "recon" })
-  │  stdout: teammate_proxy_request
+  │  IPC: teammate_proxy_request (process.send)
   ▼
 Root spawns scout → registers in root's activeRuns/namedAgents
-  │  IPC: teammate_proxy_result
+  │  IPC: teammate_proxy_result (child.send)
   ▼
 coordinator receives result
 ```
@@ -192,16 +257,18 @@ All agents are flat peers:
 
 ### Child Proxy Tools
 
-Child processes register proxy versions of all teammate tools. Each proxy:
-1. Writes a `teammate_proxy_request` JSON line to stdout
-2. Awaits the result via Node.js IPC (`process.on("message")`)
+Every child process automatically gets proxy versions of all 4 teammate tools (injected into `--tools` whitelist regardless of agent definition). Each proxy:
+1. Sends a `teammate_proxy_request` via Node.js IPC (`process.send()`)
+2. Awaits the result via IPC (`process.on("message")`)
 
-The root's event parser intercepts these requests and executes them locally. The IPC channel is established via `stdio: ["pipe","pipe","pipe","ipc"]` at spawn time.
+The root's IPC message listener (`child.on("message")`) intercepts these requests and executes them locally.
 
 ## Reliability
 
 - **Model fallback chain** — primary model → `fallbackModels[]` from agent config → automatic retry
 - **Flat agent pool** — all agents managed by root process; child proxy tools forward spawn requests to root; depth guard (`PI_TEAMMATE_DEPTH`) prevents runaway recursion
+- **Resident lifecycle** — agents sleep after turn completion; process stays alive for follow-up; only killed on explicit abort or session shutdown
+- **IPC disconnect guard** — child proxy resolves all pending requests with error on disconnect (root crash / agent abort)
 - **Windows-safe pi resolution** — `getPiSpawnCommand()` resolves the pi binary via env override, Windows script detection, or PATH
 - **Abort signal** — SIGTERM → 5s grace → SIGKILL
 
@@ -243,7 +310,7 @@ You are a specialized agent. Your system prompt goes here.
 ## Install
 
 ```bash
-pi install npm:@pi-maestro/teammate
+pi install npm:pi-maestro-teammate
 # or from local path
 pi install ./pi-teammate
 ```
@@ -262,3 +329,33 @@ pi install ./pi-teammate
 ## License
 
 MIT
+# Agent discovery
+
+Agent Markdown files are loaded with project-over-user-over-builtin precedence:
+
+1. nearest project `.pi/agents/*.md`
+2. `~/.pi/agent/extensions/teammate/agents/*.md`
+3. this npm package's bundled `agents/*.md`
+
+Pi has no native `pi.agents` package manifest field. Builtin teammate agents are
+resolved relative to the installed extension module, so npm, git, global and local
+Pi package installs all use the same package-local `agents/` directory.
+
+## Fixed prompt templates
+
+`teammate` can load Pi-compatible Markdown prompt templates with `prompt` and
+`promptArgs`. Discovery priority is project `.pi/prompts/*.md`, user
+`~/.pi/agent/prompts/*.md`, then this package's `prompts/*.md`. Template syntax uses
+Pi's `$1`, `$2`, `$@`, `$ARGUMENTS`, `${1:-default}`, and `${@:N:L}` forms. The task
+value is `$1`; `promptArgs` start at `$2`.
+
+```json
+{
+  "agent": "delegate",
+  "prompt": "analysis",
+  "task": "Analyze the authentication flow",
+  "promptArgs": ["@src/auth/**/*.ts", "file:line evidence"],
+  "model": "provider/model",
+  "background": true
+}
+```

package/agents/coordinator.md

@@ -21,4 +21,6 @@ Your approach:
 3. Let the execution engine resolve the dependency graph — no need to manually order
 4. Verify results and synthesize a coherent output
 
+After an agent completes its turn, it enters sleeping state. Use teammate-send to wake it for follow-up work. Use teammate-list to check agent status (● running / ◉ sleeping). Use teammate-send with mode "abort" to terminate an agent.
+
 Be methodical and thorough. Document your reasoning for key decisions. If a step fails, attempt recovery before reporting failure.

package/package.json

@@ -1,18 +1,22 @@
 {
   "name": "pi-maestro-teammate",
-  "version": "0.3.0",
-  "description": "Pi extension for teammate dispatch with P0 three-axis decoupling (name, reply_to)",
+  "version": "0.4.2",
+  "description": "Pi extension — teammate agent dispatch with DAG task graphs, RPC messaging, and compact TUI",
   "type": "module",
   "keywords": [
     "pi-package",
+    "pi-extension",
     "pi",
-    "pi-coding-agent",
     "teammate",
     "agents"
   ],
+  "scripts": {
+    "test": "node --experimental-transform-types --test \"test/*.test.ts\""
+  },
   "files": [
     "src/**/*.ts",
     "agents/",
+    "prompts/",
     "README.md"
   ],
   "pi": {
@@ -23,7 +27,8 @@
   "peerDependencies": {
     "@earendil-works/pi-agent-core": "*",
     "@earendil-works/pi-ai": "*",
-    "@earendil-works/pi-coding-agent": "*"
+    "@earendil-works/pi-coding-agent": "*",
+    "@earendil-works/pi-tui": "*"
   },
   "peerDependenciesMeta": {
     "@earendil-works/pi-agent-core": {
@@ -34,15 +39,18 @@
     },
     "@earendil-works/pi-coding-agent": {
       "optional": true
+    },
+    "@earendil-works/pi-tui": {
+      "optional": true
     }
   },
   "dependencies": {
-    "@earendil-works/pi-tui": "0.74.0",
-    "typebox": "1.1.24"
+    "typebox": "^1.1.24"
   },
   "devDependencies": {
-    "@earendil-works/pi-agent-core": "0.74.0",
-    "@earendil-works/pi-ai": "0.74.0",
-    "@earendil-works/pi-coding-agent": "0.74.0"
+    "@earendil-works/pi-agent-core": "0.80.3",
+    "@earendil-works/pi-ai": "0.80.3",
+    "@earendil-works/pi-coding-agent": "0.80.3",
+    "@earendil-works/pi-tui": "0.80.3"
   }
 }

package/prompts/analysis-analyze-code-patterns.md

@@ -0,0 +1,53 @@
+---
+description: Analyze implementation patterns, conventions, and anti-patterns
+argument-hint: "<task> [context ...]"
+---
+## Invocation Context
+
+Primary task:
+
+$1
+
+Additional context and arguments:
+
+${@:2}
+
+Apply the following fixed protocol to the invocation context above.
+
+Analyze implementation patterns and code structure.
+
+## Planning Required
+Before providing analysis, you MUST:
+1. Review all files in context (not just samples)
+2. Identify patterns with file:line references
+3. Distinguish good patterns from anti-patterns
+4. Apply template requirements
+
+## Core Checklist
+- [ ] Analyze ALL files in CONTEXT
+- [ ] Provide file:line references for each pattern
+- [ ] Distinguish good patterns from anti-patterns
+- [ ] Apply RULES template requirements
+
+## REQUIRED ANALYSIS
+1. Identify common code patterns and architectural decisions
+2. Extract reusable utilities and shared components
+3. Document existing conventions and coding standards
+4. Assess pattern consistency and identify anti-patterns
+5. Suggest improvements and optimization opportunities
+
+## OUTPUT REQUIREMENTS
+- Specific file:line references for all findings
+- Code snippets demonstrating identified patterns
+- Clear recommendations for pattern improvements
+- Standards compliance assessment with priority levels
+
+## Verification Checklist
+Before finalizing output, verify:
+- [ ] All CONTEXT files analyzed
+- [ ] Every pattern has code reference (file:line)
+- [ ] Anti-patterns clearly distinguished
+- [ ] Recommendations prioritized by impact
+
+## Output Requirements
+Provide actionable insights with concrete implementation guidance.

package/prompts/analysis-analyze-performance.md

@@ -0,0 +1,45 @@
+---
+description: Analyze performance bottlenecks and optimization opportunities
+argument-hint: "<task> [context ...]"
+---
+## Invocation Context
+
+Primary task:
+
+$1
+
+Additional context and arguments:
+
+${@:2}
+
+Apply the following fixed protocol to the invocation context above.
+
+Analyze performance characteristics and optimization opportunities.
+
+## CORE CHECKLIST ⚡
+□ Focus on measurable metrics (e.g., latency, memory, CPU usage)
+□ Provide file:line references for all identified bottlenecks
+□ Distinguish between algorithmic and resource-based issues
+□ Apply RULES template requirements exactly as specified
+
+## REQUIRED ANALYSIS
+1. Identify performance bottlenecks and resource usage patterns
+2. Assess algorithm efficiency and data structure choices
+3. Evaluate caching strategies and optimization techniques
+4. Review memory management and resource cleanup
+5. Document performance metrics and improvement opportunities
+
+## OUTPUT REQUIREMENTS
+- Performance bottleneck identification with specific file:line locations
+- Algorithm complexity analysis and optimization suggestions
+- Caching pattern documentation and recommendations
+- Memory usage patterns and optimization opportunities
+- Prioritized list of performance improvements
+
+## VERIFICATION CHECKLIST ✓
+□ All CONTEXT files analyzed for performance characteristics
+□ Every bottleneck is backed by a code reference (file:line)
+□ Both algorithmic and resource-related issues are covered
+□ Recommendations are prioritized by potential impact
+
+Focus: Measurable performance improvements and concrete optimization strategies.

package/prompts/analysis-analyze-technical-document.md

@@ -0,0 +1,49 @@
+---
+description: Analyze technical documents with evidence-backed references
+argument-hint: "<task> [context ...]"
+---
+## Invocation Context
+
+Primary task:
+
+$1
+
+Additional context and arguments:
+
+${@:2}
+
+Apply the following fixed protocol to the invocation context above.
+
+Analyze technical documents, research papers, and specifications systematically.
+
+## CORE CHECKLIST ⚡
+□ Plan analysis approach before reading (document type, key questions, success criteria)
+□ Provide section/page references for all claims and findings
+□ Distinguish facts from interpretations explicitly
+□ Use precise, direct language - avoid persuasive wording
+□ Apply RULES template requirements exactly as specified
+
+## REQUIRED ANALYSIS
+1. Document assessment: type, structure, audience, quality indicators
+2. Content extraction: concepts, specifications, implementation details, constraints
+3. Critical evaluation: strengths, gaps, ambiguities, clarity issues
+4. Self-critique: verify citations, completeness, actionable recommendations
+5. Synthesis: key takeaways, integration points, follow-up questions
+
+## OUTPUT REQUIREMENTS
+- Structured analysis with mandatory section/page references
+- Evidence-based findings with specific location citations
+- Clear separation of facts vs. interpretations
+- Actionable recommendations tied to document content
+- Integration points with existing project patterns
+- Identified gaps and ambiguities with impact assessment
+
+## VERIFICATION CHECKLIST ✓
+□ Pre-analysis plan documented (3-5 bullet points)
+□ All claims backed by section/page references
+□ Self-critique completed before final output
+□ Language is precise and direct (no persuasive adjectives)
+□ Recommendations are specific and actionable
+□ Output length proportional to document size
+
+Focus: Evidence-based insights extraction with pre-planning and self-critique for technical documents.

package/prompts/analysis-assess-security-risks.md

@@ -0,0 +1,45 @@
+---
+description: Assess security risks, attack surfaces, and prioritized mitigations
+argument-hint: "<task> [context ...]"
+---
+## Invocation Context
+
+Primary task:
+
+$1
+
+Additional context and arguments:
+
+${@:2}
+
+Apply the following fixed protocol to the invocation context above.
+
+Analyze security implementation and potential vulnerabilities.
+
+## CORE CHECKLIST ⚡
+□ Identify all data entry points and external system interfaces
+□ Provide file:line references for all potential vulnerabilities
+□ Classify risks by severity and type (e.g., OWASP Top 10)
+□ Apply RULES template requirements exactly as specified
+
+## REQUIRED ANALYSIS
+1. Identify authentication and authorization mechanisms
+2. Assess input validation and sanitization practices
+3. Review data encryption and secure storage methods
+4. Evaluate API security and access control patterns
+5. Document security risks and compliance considerations
+
+## OUTPUT REQUIREMENTS
+- Security vulnerability findings with file:line references
+- Authentication/authorization pattern documentation
+- Input validation examples and identified gaps
+- Encryption usage patterns and recommendations
+- Prioritized remediation plan based on risk level
+
+## VERIFICATION CHECKLIST ✓
+□ All CONTEXT files analyzed for security vulnerabilities
+□ Every finding is backed by a code reference (file:line)
+□ Both authentication and data handling are covered
+□ Recommendations include clear, actionable remediation steps
+
+Focus: Identifying security gaps and providing actionable remediation steps.

package/prompts/analysis-diagnose-bug-root-cause.md

@@ -0,0 +1,136 @@
+---
+description: Diagnose bug root causes and propose targeted read-only corrections
+argument-hint: "<task> [context ...]"
+---
+## Invocation Context
+
+Primary task:
+
+$1
+
+Additional context and arguments:
+
+${@:2}
+
+Apply the following fixed protocol to the invocation context above.
+
+# Role & Output Requirements
+
+**Role**: Software engineer specializing in bug diagnosis
+**Output Format**: Diagnostic report in Chinese following the specified structure
+**Constraints**: Do NOT write complete code files. Provide diagnostic analysis and targeted correction suggestions only.
+
+## Core Capabilities
+- Interpret symptoms from bug reports, stack traces, and logs
+- Trace execution flow to identify root causes
+- Formulate and validate hypotheses about bug origins
+- Design targeted, low-risk corrections
+- Analyze impact on other system components
+
+## Analysis Process (Required)
+**Before providing your final diagnosis, you MUST:**
+1. Analyze symptoms and form initial hypothesis
+2. Trace code execution to identify root cause
+3. Design correction strategy
+4. Assess potential impacts and risks
+5. Present structured diagnostic report
+
+## Objectives
+1. Identify root cause (not just symptoms)
+2. Propose targeted correction with justification
+3. Assess risks and side effects
+4. Provide verification steps
+
+## Input
+- Bug description (observed vs. expected behavior)
+- Code snippets or file locations
+- Logs, stack traces, error messages
+- Reproduction steps (if available)
+
+## Output Structure (Required)
+
+Output in Chinese using this Markdown structure:
+
+---
+
+### 0. 诊断思维链 (Diagnostic Chain-of-Thought)
+Present your analysis process in these steps:
+1. **症状分析**: Summarize error symptoms and technical clues
+2. **初步假设**: Identify suspicious code areas and form initial hypothesis
+3. **根本原因定位**: Trace execution path to pinpoint exact cause
+4. **修复方案设计**: Design targeted, low-risk correction
+5. **影响评估**: Assess side effects and plan verification
+
+### **故障诊断与修复建议报告 (Bug Diagnosis & Correction Proposal)**
+
+### **第一部分:故障分析报告 (Part 1: Fault Analysis Report)**
+*   **1.1 故障现象描述 (Bug Symptom Description):**
+    *   **观察到的行为 (Observed Behavior):** [清晰、客观地转述用户报告的异常现象或日志中的错误信息。]
+    *   **预期的行为 (Expected Behavior):** [描述在正常情况下,系统或功能应有的表现。]
+*   **1.2 诊断分析过程 (Diagnostic Analysis Process):**
+    *   **初步假设 (Initial Hypothesis):** [陈述您根据初步信息得出的第一个猜测。例如:初步判断,问题可能出在数据解析环节,因为错误日志显示了格式不匹配。]
+    *   **根本原因分析 (Root Cause Analysis - RCA):** [**这是报告的核心。** 详细阐述您的逻辑推理过程,说明您是如何从表象追踪到根源的。例如:通过检查 `data_parser.py` 的 `parse_record` 函数,发现当输入记录的某个可选字段缺失时,代码并未处理该 `None` 值,而是直接对其调用了 `strip()` 方法,从而导致了 `AttributeError`。因此,**根本原因**是:**对可能为 None 的变量在未进行空值检查的情况下直接调用了方法**。]
+*   **1.3 根本原因摘要 (Root Cause Summary):** [用一句话高度概括 bug 的根本原因。]
+
+### **第二部分:涉及文件概览 (Part 2: Involved Files Overview)**
+*   **文件列表 (File List):** [列出定位到问题或需要修改的所有相关文件名及路径。示例: `- src/parsers/data_parser.py (根本原因所在,直接修改)`]
+
+### **第三部分:详细修复建议 (Part 3: Detailed Correction Plan)**
+---
+*针对每个需要修改的文件进行描述:*
+
+**文件: [文件路径或文件名] (File: [File path or filename])**
+
+*   **1. 定位 (Location):**
+    *   [清晰说明函数、类、方法或具体的代码区域,并指出大致行号。示例: 函数 `parse_record` 内部,约第 125 行]
+
+*   **2. 相关问题代码片段 (Relevant Problematic Code Snippet):**
+    *   [引用导致问题的关键原始代码行,为开发者提供直接上下文。]
+    *   ```[language]
+        // value = record.get(optional_field)
+        // processed_value = value.strip() // 此处引发错误
+        ```
+
+*   **3. 修复描述与预期逻辑 (Correction Description & Intended Logic):**
+    *   **建议修复措施 (Proposed Correction):**
+        *   [用清晰的中文自然语言,描述需要进行的具体修改。例如:在调用 `.strip()` 方法之前,增加一个条件判断,检查 `value` 变量是否不为 `None`。]
+    *   **修复后逻辑示意 (Corrected Logic Sketch):**
+        *   [使用简洁的 `diff` 风格或伪代码来直观展示修改。]
+        *   **示例:**
+            ```diff
+            - processed_value = value.strip()
+            + processed_value = value.strip() if value is not None else None
+            ```
+            *或使用流程图:*
+            ```
+            获取 optional_field ───► [value]
+            ◊─── IF (value is not None) THEN
+            │    └───► value.strip() ───► [processed_value]
+            ELSE
+            │    └─── (赋值为 None) ───► [processed_value]
+            END IF
+            ... (后续逻辑使用 processed_value) ...
+            ```
+    *   **修复理由 (Reason for Correction):** [解释为什么这个修改能解决之前分析出的**根本原因**。例如:此修改确保了只在变量 `value` 存在时才对其进行操作,从而避免了 `AttributeError`,解决了对 None 值的非法调用问题。]
+
+*   **4. 验证建议与风险提示 (Verification Suggestions & Risk Advisory):**
+    *   **验证步骤 (Verification Steps):** [提供具体的测试建议来验证修复是否成功,以及是否引入新问题。例如:1. 构造一个optional_field字段存在的测试用例,确认其能被正常处理。2. **构造一个optional_field字段缺失的测试用例,确认程序不再崩溃,且 `processed_value` 为 `None` 或默认值。**]
+    *   **潜在风险与注意事项 (Potential Risks & Considerations):** [指出此修改可能带来的任何潜在副作用或需要开发者注意的地方。例如:请注意,下游消费 `processed_value` 的代码现在必须能够正确处理 `None` 值。请检查相关调用方是否已做相应处理。]
+
+---
+*(对每个需要修改的文件重复上述格式)*
+
+## Key Requirements
+1. **Language**: All output in Chinese
+2. **No Code Generation**: Use diff format or pseudo-code only. Do not write complete functions or files
+3. **Focus on Root Cause**: Analysis must be logical and evidence-based
+4. **State Assumptions**: Clearly note any assumptions when information is incomplete
+
+## Self-Review Checklist
+Before providing final output, verify:
+- [ ] Diagnostic chain reflects logical debugging process
+- [ ] Root cause analysis is clear and evidence-based
+- [ ] Correction directly addresses root cause (not just symptoms)
+- [ ] Correction is minimal and targeted (not broad refactoring)
+- [ ] Verification steps are actionable
+- [ ] No complete code blocks generated

package/prompts/analysis-review-architecture.md

@@ -0,0 +1,45 @@
+---
+description: Review architecture, dependencies, integration points, and trade-offs
+argument-hint: "<task> [context ...]"
+---
+## Invocation Context
+
+Primary task:
+
+$1
+
+Additional context and arguments:
+
+${@:2}
+
+Apply the following fixed protocol to the invocation context above.
+
+Analyze system architecture and design decisions.
+
+## CORE CHECKLIST ⚡
+□ Analyze system-wide structure, not just isolated components
+□ Provide file:line references for key architectural elements
+□ Distinguish between intended design and actual implementation
+□ Apply RULES template requirements exactly as specified
+
+## REQUIRED ANALYSIS
+1. Identify main architectural patterns and design principles
+2. Map module dependencies and component relationships
+3. Assess integration points and data flow patterns
+4. Evaluate scalability and maintainability aspects
+5. Document architectural trade-offs and design decisions
+
+## OUTPUT REQUIREMENTS
+- Architectural diagrams or textual descriptions
+- Dependency mapping with specific file references
+- Integration point documentation with examples
+- Scalability assessment and bottleneck identification
+- Prioritized recommendations for architectural improvement
+
+## VERIFICATION CHECKLIST ✓
+□ All major components and their relationships analyzed
+□ Key architectural decisions and trade-offs are documented
+□ Data flow and integration points are clearly mapped
+□ Scalability and maintainability findings are supported by evidence
+
+Focus: High-level design patterns and system-wide architectural concerns.

package/prompts/analysis-review-code-quality.md

@@ -0,0 +1,44 @@
+---
+description: Review code quality across correctness, maintainability, and testing
+argument-hint: "<task> [context ...]"
+---
+## Invocation Context
+
+Primary task:
+
+$1
+
+Additional context and arguments:
+
+${@:2}
+
+Apply the following fixed protocol to the invocation context above.
+
+Conduct comprehensive code review and quality assessment.
+
+## CORE CHECKLIST ⚡
+□ Review against established coding standards and conventions
+□ Assess logic correctness, including potential edge cases
+□ Evaluate security implications and vulnerability risks
+□ Check for performance bottlenecks and optimization opportunities
+
+## REQUIRED ANALYSIS
+1. Review code against established coding standards and conventions
+2. Assess logic correctness and potential edge cases
+3. Evaluate security implications and vulnerability risks
+4. Check performance characteristics and optimization opportunities
+5. Validate test coverage and documentation completeness
+
+## OUTPUT REQUIREMENTS
+- Standards compliance assessment with specific violations
+- Logic review findings with potential issue identification
+- Security assessment with vulnerability documentation
+- Performance review with optimization recommendations
+
+## VERIFICATION CHECKLIST ✓
+□ Code is assessed against established standards
+□ Logic, including edge cases, is thoroughly reviewed
+□ Security and performance have been evaluated
+□ Test coverage and documentation are validated
+
+Focus: Actionable feedback with clear improvement priorities and implementation guidance.