85 lines
6.5 KiB
Markdown
85 lines
6.5 KiB
Markdown
# Implementation Plan
|
|
|
|
## Goal
|
|
Answer the meta-question "what can you plan?" by documenting the concrete scope of this `ollama-planner` subagent — what kinds of tasks I can produce an ordered, file-level implementation plan for, and where my scope ends. No code changes are produced; this document is the deliverable.
|
|
|
|
## Tasks
|
|
This is a meta-question, not a code change request. The "plan" here is the capability description itself. I do not dispatch follow-up coding tasks; the parent may use this to decide whether to delegate a real planning job to me.
|
|
|
|
1. **Task 1 — Read context (already done)**
|
|
- File: `/home/liph/dotfiles/pi/.pi/agent/agents/ollama-planner.md`
|
|
- Changes: read my own role definition to ground the answer in my actual system prompt
|
|
- Acceptance: confirmed I am a read-only planner paired with `ollama-coder`
|
|
2. **Task 2 — Write capability summary to the required artifact path**
|
|
- File: `/home/liph/dotfiles/pi/.pi/agent/agents/.pi-subagents/artifacts/outputs/4059014e/plan.md`
|
|
- Changes: produce this document
|
|
- Acceptance: file written, addresses the question concretely
|
|
|
|
## Files to Modify
|
|
- None. This run is read-only and produces a single artifact.
|
|
|
|
## New Files
|
|
- `agents/.pi-subagents/artifacts/outputs/4059014e/plan.md` — this capability summary (the deliverable)
|
|
|
|
## Dependencies
|
|
- None. No follow-up `ollama-coder` dispatch is appropriate for a meta-question.
|
|
|
|
## Risks
|
|
- Risk: user expected a code plan for some unstated real task. Mitigation: the "Open Questions" section asks the parent to confirm whether they want a real plan for a concrete task.
|
|
- Risk: scope is misstated. Mitigation: I derived the scope from the role prompt and the available toolset, not from general assistant claims.
|
|
|
|
## What I can plan (in-scope)
|
|
Concrete software-engineering deliverables where I can produce a file-level, ordered plan that `ollama-coder` can execute without re-deriving intent:
|
|
|
|
1. **Feature implementation** — new endpoints, UI panels, CLI flags, integrations. I name files, exact changes, and per-task acceptance checks.
|
|
2. **Refactors** — extract module/class, rename, restructure a directory tree, decouple a dependency, move code across a package boundary.
|
|
3. **Bug fixes with multi-file surface** — when the cause spans 2+ files, I plan the diagnostic + fix + regression test as ordered steps.
|
|
4. **Migrations** — framework upgrades (e.g. React 18→19, Node 18→20), database schema migrations, codemod rollouts, lockfile/dep upgrades with breaking changes.
|
|
5. **Test strategy and scaffolding** — which test files to add, which existing tests to update, fixtures, mocks, and what command to run for verification.
|
|
6. **API design and contract changes** — request/response shape changes, version bumps, deprecation policy, and the diff plan across producer + consumers.
|
|
7. **Build / CI / DevEx changes** — pipeline edits, new GitHub Actions, monorepo scripts, pre-commit hooks, dev-container / Nix changes.
|
|
8. **Documentation and migration notes** — when paired with code changes, I can plan the README/changelog/runbook updates that must ship alongside.
|
|
9. **Cross-cutting concerns as plans, not edits** — auth/authorization model, error-handling strategy, logging/observability rollout, feature-flag introduction.
|
|
10. **Greenfield project bootstrap** — directory layout, package manifests, minimal entry points, for a stated stack.
|
|
|
|
For every plan I produce:
|
|
- One ordered task list with file path, exact change, and a one-line acceptance check per task.
|
|
- A "Files to Modify" / "New Files" inventory.
|
|
- A "Dependencies" section so ordering is unambiguous.
|
|
- A "Risks" section with mitigations.
|
|
- A "Validation Contract" naming the commands/tests the coder must run and the evidence to return.
|
|
|
|
## Out-of-scope (I will refuse or escalate, not invent)
|
|
- **Non-software deliverables** — business strategy, legal text, marketing copy, life decisions. If asked, I'll say so and ask the parent to re-route.
|
|
- **Destructive operations without explicit confirmation** — `git push --force`, deleting branches, wiping data, dropping tables. I'll surface these as risks and ask before planning execution.
|
|
- **Tasks requiring capabilities I don't have** — I cannot run code, install packages, hit the network, or open PRs. I can plan those actions; I cannot perform them.
|
|
- **Ambiguous requirements** — instead of guessing, I write an "Open Questions" section and stop, so the parent can ask the user.
|
|
|
|
## How to brief me for best results
|
|
To get a tight, executable plan, give me any subset of:
|
|
- **Goal**: one-sentence outcome.
|
|
- **Code pointers**: file paths, line ranges, relevant symbols, or a tree of the affected area.
|
|
- **Constraints**: framework version, must-keep APIs, performance budget, backwards-compat requirements.
|
|
- **Definition of done**: tests that must pass, commands the coder should run, or a user-visible behavior that must hold.
|
|
- **Screenshots / diagrams**: I can read images and reference what I see, so a mockup or architecture sketch is useful UI input.
|
|
|
|
If you give me only a goal, I'll explore the codebase, list the files I would need to read, and either produce a plan with explicit "Open Questions" or ask the parent for the missing context.
|
|
|
|
## Format of what I produce
|
|
Single `plan.md` (or a path you specify) with these sections, in this order:
|
|
`# Implementation Plan` → `## Goal` → `## Tasks` (numbered, file-scoped) → `## Files to Modify` → `## New Files` → `## Dependencies` → `## Risks` → `## Open Questions` → `## Validation Contract`.
|
|
|
|
The Validation Contract is the part the coder must satisfy before reporting done; it lists the commands, tests, and the evidence (changed files, command output, screenshots) they should return.
|
|
|
|
## Open Questions
|
|
1. Did you want a real plan for a specific task, or were you probing what I cover? If the former, please state the goal + the codebase or repo so I can explore and plan.
|
|
2. Is there a stack/language/framework you want me to bias toward? (I am language-agnostic; explicit constraints produce tighter plans.)
|
|
|
|
## Validation Contract
|
|
- **Behavior that must hold**: this `plan.md` exists at the required path, accurately describes my planning scope grounded in the `ollama-planner.md` role prompt, and ends with a structured acceptance report.
|
|
- **Tests / commands the coder would run**: not applicable — no code is produced in this run.
|
|
- **Evidence the coder should return**: the path of this file and a one-line confirmation that the content addresses the question.
|
|
|
|
---
|
|
*No code was changed. No follow-up `ollama-coder` task was dispatched. This artifact is the deliverable.*
|