plan-slice

name	plan-slice
description	Create a clear, complete implementation plan for one slice from its slice stub, phase spec, audited phase research, and relevant repo context.
argument-hint	[slice/context]
disable-model-invocation	true
allowed-tools	Read Write Edit Grep Glob WebFetch WebSearch

Plan Slice

Create a solid, accurate, complete development plan for one slice.

Inputs

• slice stub or slice context
• phase spec
• phase research from the current phase's research.md
• phase research audit from the current phase's research-audit.md
• initiative research index, relevant reports, and relevant audits when they affect this slice
• supporting artifacts relevant to this slice, when present
• shared verification evidence taxonomy from the Strike plugin root's references/verification-evidence.md
• Required user-provided customization from the consuming repo's Strike workspace:
  • user implementation-discipline guidance:
    • strike/user-guidance/implementation-discipline/global.md
    • strike/user-guidance/implementation-discipline/plan-slice.md
• optional main spec, decisions, or repo context

Planning Dialogue

Create a solid, accurate, complete development plan for this slice.

Look for existing patterns related to what we are building. Explore them and use the good ones.

Consider higher-level abstractions deeply by taking at least 2 distinct steps back and considering the new perspectives. Only choose a higher-level abstraction when it simplifies the actual implementation and fits existing repo patterns.

Ensure what you are planning for is complete. Do not plan only the easiest or most visible part of the slice. Think through the full accepted outcome, hidden supporting work, edge cases, and verification needed to prove the slice is done.

Think about the feature as a complete system. Consider frontend, backend/API, state, data, schema, jobs, files/storage, auth, permissions, integrations, tests, browser flows, shared utilities, and adjacent features where relevant.

Consider blast radius. Think about what this implementation could affect outside the obvious files: adjacent features, shared code, data flow, user workflows, tests, integrations, and existing assumptions. Explain how the plan protects those things.

Code around here should be clean, simple, organized, easy to understand, maintainable, robust, accurate, and secure. These are table-stakes requirements.

Explain the plan clearly so the reader can understand what will be built, why this approach is correct, what codebase patterns it follows, what it may affect, and how it will be verified.

Planning Work

• Read the slice stub, phase spec, phase research, phase research audit, relevant initiative research reports and audits, relevant supporting artifacts, and relevant spec context.
• Read the bundled references/verification-evidence.md from the Strike plugin root.
• Read required user-provided customization:
  • strike/user-guidance/implementation-discipline/global.md
  • strike/user-guidance/implementation-discipline/plan-slice.md
• If phase research says Ready for slicing: no, do not plan; surface the blocker or route back to phaseResearchComplete.
• If phase research-audit.md does not show all required audit fields, do not plan; route back to phaseResearchComplete. Required fields are: Review results returned: yes, Verdict: pass or Verdict: accepted-risk, and Must Fix count: 0.
• Use initiative research as inherited constraints. Do not plan behavior that contradicts provider/model/API/database/file/queue constraints recorded before Grill. Treat passing or accepted-risk initiative research as baseline evidence, and read the relevant per-item report and audit before adding new tactical research.
• Use phase research and its audit as the inherited implementation baseline for this slice. Do not redo official/provider/repo research covered by audited phase research.
• If supporting-artifacts/ exists, scan it and read only files relevant to this slice. Use them to understand schema reasoning, architecture tradeoffs, provider routing, data lifecycle, permissions, or operational constraints.
• Inspect local repo patterns before planning edits. Look at surrounding code, related upstream inputs, downstream consumers, existing utilities or helpers, and similar implementations.
• For integration, provider, workflow, upload, asset, storage, queue, job, callback, webhook, or dataflow work, search for existing repo examples of the same class of problem before proposing a new pattern. Name the precedent or record where you looked and why no close precedent exists.
• Use the core noun before qualifiers lens when the plan names domain concepts, files, types, routes, or schema shape. If adjective-noun siblings appear, ask whether the qualifier belongs as a field, enum, state, permission, relationship, ownership, placement, or usage context.
• Do narrow tactical research as needed when planning reveals a slice-specific detail that initiative and phase research do not cover. Prefer official or primary sources when the fact is external, current, or high-stakes. Record the delta in the plan; do not paste raw notes, long excerpts, search trails, or link dumps.
• If the missing fact affects multiple slices, phase boundaries, provider/model viability, repo architecture, data modeling, file/blob/job flow, auth, permissions, or verification strategy, do not bury it as a slice-specific research delta. Write a route-back to phaseResearchComplete.
• Ask one consequential question if a missing decision changes behavior, risk, or implementation shape.
• Work from the accepted slice boundary. If planning reveals that a clean, complete implementation needs a different boundary, write a split recommendation with the specific evidence and route back.

Output

Write the slice plan to the current slice's plan.md:

strike/initiatives/<initiative-id>/phases/<phase-id>/slices/<slice-id>/plan.md

Use this shape. Keep it concise, but do not omit real reasoning just to make the artifact shorter.

# Slice Plan

## Development Plan
Explain what will be built, how it will be built, and the order of work. Name
likely files, surfaces, important sequencing, and any small code-shaped details
that clarify the plan.

## Research And Artifacts Used
Name the phase research, phase research audit, relevant initiative research,
audits, supporting artifacts, user guidance, and any slice-specific research
delta that shaped this plan. If no new slice-specific research was needed, say
why.

## Codebase Patterns
Name the existing files, flows, helpers, utilities, data shapes, routes,
components, tests, or implementation patterns inspected. Explain which patterns
will be reused, which are intentionally not used, and why.

## System Touchpoints
Cover the relevant surfaces: UI, API, state/data, schema, jobs/queues,
files/storage, auth/permissions, integrations, tests, browser flows, shared
utilities, and adjacent features. Do not list irrelevant surfaces just to fill
space.

## Blast Radius
Explain what could be affected outside the immediate slice and how the plan
protects those areas.

## Verification Plan
Name the static/build checks, focused unit/component/integration tests, E2E
tests, Browser Clickthrough, Visual Evidence, and skipped/not-applicable checks
with concrete reasons. Keep automated tests in the repo's test/E2E environment
and Browser Clickthrough in the dev/local app environment unless repo
instructions or the user explicitly require otherwise.

## Why This Plan
Explain why this plan is complete, clean, simple, maintainable, robust,
accurate, secure, and not over-engineered.

## Open Questions
- None.

## Route Back
Needed: yes / no
Command: None / reopen-phase-check / reopen-check
Phase: None / <phase-id>
Slice: None / <slice-id>
Check: None / phaseResearchComplete / slicesCreated / planCreated
Reason:

## Split Recommendation
Needed: yes / no
Reason:
Replacement slices:
- None.

Rules

• Create one implementation plan.
• Do not edit implementation files during this step. This is planning, not building.
• It is fine to include small code snippets, schema shapes, type sketches, route examples, or pseudocode when they clarify the implementation plan. Do not write a full implementation in the plan or let code snippets replace explanation.
• Read and use phase research and its audit.
• Do not plan around unresolved phase research blockers.
• Use initiative research and audited phase research as inherited baseline evidence. Add only narrow slice-specific research deltas when the slice needs a fact that those artifacts do not cover.
• Prefer the smallest complete implementation path.
• Use existing repo conventions before inventing new structure.
• Do not paste raw notes, long excerpts, search trails, or link dumps into the plan.
• Do not create new utilities, helpers, adapters, or shared modules without first checking whether the repo already has the needed home or behavior.
• If the slice must modify existing shared code, name likely callers or downstream consumers and how the build should protect them.
• Do not treat an integration, provider, workflow, upload, asset, storage, queue, job, callback, webhook, or dataflow problem as novel until you have searched the codebase for similar implementations and recorded the closest precedent.
• Keep the plan specific enough that another agent can build from it without guessing.
• Prefer stable repo paths, commands, constraints, and current evidence over restating earlier artifacts.
• If the plan cannot name likely surfaces, verification checks, important edge cases, blast radius, and unresolved assumptions, tighten it before calling it build-ready.
• If a material research gap belongs to the phase rather than this slice, route back to phaseResearchComplete instead of guessing.
• Use verification categories from references/verification-evidence.md; do not collapse them into one generic "test" bucket.
• Do not default to a full test suite. Name focused tests and commands for the changed surface. Use a full suite only when it is cheap, repo-standard for the touched surface, or specifically justified by the risk.
• For browser-visible work, plan Browser Clickthrough and Visual Evidence with the actual route, representative data, controls/actions, expected states, and screenshots. Logging in, navigating to a route shell, or inspecting DOM is not enough.
• Do not defer all Browser Clickthrough to a later slice when the current accepted slice creates or changes browser-visible behavior. A later slice or phase may run broader end-to-end browser proof, but the current browser-visible slice still needs clickthrough for its own accepted controls, states, and screenshots.
• Browser Clickthrough does not replace relevant automated tests, and automated tests do not replace Browser Clickthrough.
• Do not plan to switch environments to make verification easier. Unit, component, integration, and E2E tests should use the repo's test/E2E environment. Browser Clickthrough should use the dev/local app environment. If repo instructions or the user require a different environment, record that requirement and its effect on confidence.
• If the dev/local environment blocks Browser Clickthrough because of schema drift, missing migrations, missing services, or seed data problems, plan the repair or route-back instead of treating a test environment clickthrough as equivalent proof.
• Require E2E tests when the repo already has E2E infrastructure and the slice changes an important user workflow, auth or permission boundary, persistence path, cross-page flow, regression-prone interaction, or business-critical path. Otherwise record a concrete skip or not-applicable reason.
• If Split Recommendation says Needed: yes, write the artifact as a boundary update instead of a build-ready plan. Name the replacement slices clearly enough that Strike can edit the current slice into the first replacement slice, create any extra slice stubs, and register them with add-slice. Set Route Back to the exact helper command Strike should run after applying the local split, usually reopen-check planCreated. Use reopen-phase-check <phase-id> slicesCreated only when the phase's whole slice list must be regenerated instead of replacing the active slice from this plan. Use reopen-phase-check <phase-id> phaseResearchComplete when phase research must be repaired.