98 lines
4.5 KiB
Markdown
98 lines
4.5 KiB
Markdown
**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.
|
|
```
|