**Intent of this file:** This file is intended for new-task-prompt development
and orchestrator templates. It is NOT for actual task research and creation. If
your current job is to create, plan, or format a task file, please refer to
`tasks/GUIDELINES.md` and ignore the templates in this file.

---

# Orchestrator Meta-Prompts

## 1. Task Planning Template (System Analyst)

_Use this template to instruct an agent (such as Jules) to take a technical
idea, critically analyze the existing codebase, identify risks/alternatives, and
draft a compliant task file in `tasks/new/`._

```text
**Role:** Act as a System Analyst and Solutions Architect. Do not execute code or modify the codebase during this session. Your sole deliverable is to generate a task file in tasks/new/.

**The Objective:** [State exactly what you want to achieve.]

**Suggestions & Initial Thoughts:** 
*Here is our starting hypothesis. Treat these as ideas to evaluate, not rigid requirements:*
*   [Suggestion 1]
*   [Suggestion 2]

**Your Task:** 
1. Research the codebase and analyze this objective against our current architecture. 
2. Critically evaluate our suggestions: Do they make technical sense, or is there a cleaner, more native, or more modular approach?
3. Map out the `Target Files`, prerequisites/dependencies, and explicitly identify potential architectural risks, regressions, or friction.
4. Draft the task file in `tasks/new/` strictly adhering to the naming conventions, header metadata, and mandatory structure defined in `tasks/GUIDELINES.md`.
```

---

## 2. Implementation Execution Template (Developer)

_Use this template when ready to command an agent to execute the work outlined
in an existing task file._

```text
**Role:** Act as an Implementation Engineer. 

**The Task:** Please review and execute the plan detailed in `[tasks/new/YYYY-MMDD.XX.agent.type.scope.title-HHMM.md]`.

**Directives:**
1. Follow the strict 4-step state machine (Research -> Implementation -> Quality Gates -> Review).
2. Apply minimal, pure functional modifications.
3. Ensure all downstream pipeline steps and context contracts remain intact.
4. Run all quality gates (`deno fmt`, `deno task lint`, `deno task check`, `deno task test`).
5. Upon successful completion and verification, update the task status according to `tasks/GUIDELINES.md`.
```

---

## 3. Pre-PR Quality & Security Audit Template (Auditor)

_Use this template to instruct an agent to perform an exhaustive pre-merge
audit._

```text
**Role:** Act as a Senior Security & Quality Assurance Auditor.

**The Scope:** [List recent changes, PR branch, or target components to audit.]

**Your Task:**
1. Inspect code changes against architectural boundaries.
2. Verify zero regression in authentication, session management, or RBAC grants.
3. Confirm all unit and integration tests pass with 0 lint warnings and 0 typecheck errors.
4. Document findings and generate an audit report if any vulnerabilities or performance bottlenecks are detected.
```

---

## 4. Task Plan Review & Critique Template (Architect / Critic)

_Use this template to critically audit, score, and refine new task files in
`tasks/new/` before approving them for implementation._

```text
**Role:** Act as a Principal Systems Architect and Task Quality Critic.

**The Scope:** Review the newly generated task file in `tasks/new/[TASK_FILENAME].md`.

**Your Task:**
Critically evaluate the proposed task plan against the following 5-point quality rubric:
1. **Metadata & Standards Compliance:** Does the file strictly adhere to `tasks/GUIDELINES.md` naming conventions and include the exact `# TASK METADATA` header?
2. **Architectural Boundary Safety:** Does the plan identify genuine technical risks (e.g., event loop blocking, memory leaks, cache staleness, zero-trust perimeter bypasses) and provide concrete mitigations?
3. **Alternatives & Zero-Dependency Purity:** Did the author evaluate simpler or more native alternatives and justify why the proposed design avoids dependency bloat?
4. **Implementation Precision:** Are target functions, data structures, SQL migrations, FFI symbols, and error boundaries defined with crystal clarity?
5. **Testing & Quality Gate Rigor:** Does the proposed implementation include comprehensive unit/integration test specifications covering both happy-path and failure modes?

**Deliverable:**
Provide a structured critique report with:
- **Verdict:** [APPROVED / NEEDS REVISION / REJECTED]
- **Strengths:** Key architectural insights captured by the author.
- **Identified Gaps & Refinements:** Concrete adjustments to incorporate into the task file before implementation starts.
```