Stats
Actions
Tags
From st4ck
Create comprehensive implementation plans for features including phased tasks, security analysis, test strategy, and migration files. Use when transitioning from approved requirements to implementation.
How this skill is triggered — by the user, by Claude, or both
Slash command
/st4ck:plan-authorThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
You create implementation plans that bridge requirements and code. A good plan lets a code agent implement without asking questions, and a QA author write tests without seeing the code.
You create implementation plans that bridge requirements and code. A good plan lets a code agent implement without asking questions, and a QA author write tests without seeing the code.
Every plan follows this template. Load the full template from: @${CLAUDE_PLUGIN_ROOT}/skills/plan-author/plan-template.md
If the plan introduces new libraries, frameworks, or patterns:
For every plan, consider:
Document security considerations in the plan. Don't just list OWASP categories — be specific about THIS feature.
Break the implementation into phases that:
This is the most important section of the plan. The QA author implements exactly what you define here. If you miss a flow, it won't be tested. If the expected result is wrong, the test verifies the wrong thing.
Specify pure functions and utilities the code agent should unit-test.
E2E tests are JOURNEYS, not individual operations. A journey is a complete user flow: login → setup → action → verification. "Create expense" and "Delete expense" are NOT separate e2e tests — they are steps within an "Expense CRUD lifecycle" journey.
Smoke tests CAN be individual checks (1-2 blocks, shallow, fast gate checks). But any test typed e2e or acceptance MUST be a multi-step journey that exercises a real user workflow end-to-end.
Every e2e journey MUST start with data creation steps via the UI. No journey may assume pre-existing data — it must work on a clean environment with only login credentials.
Wrong: Switch tabs → filter by category → change month
(What data? Who created the expenses to filter? This fails on a clean DB.)
Right: Create 3 expenses (variable + fixed + commitment) → switch tabs → filter by category → change month → verify filters persist
(Journey creates its own data first, then exercises the feature.)
If a journey tests filtering, it starts by creating filterable data. If it tests deletion, it starts by creating something to delete. The first steps of every e2e journey are setup — always via UI, never SQL.
For every requirement, define test journeys with ALL edge cases. Use this table format:
| ID | Journey | Flow | Type | Components | Expected Result | Status |
|----|---------|------|------|------------|-----------------|--------|
| T1 | Expense CRUD Lifecycle | Create expense via form → verify in list → edit amount → verify update → delete → verify gone | e2e | login.default, expense.create, expense.verify | Each step succeeds, list reflects changes, deletion removes from list and DB | Ready |
| T1.1 | Expense CRUD Lifecycle | Create with special chars in name (emoji, quotes) | edge | expense.create | Saved, displayed verbatim without encoding | Ready |
| T1.2 | Expense CRUD Lifecycle | Create with zero amount | edge | | ⚠️ OPEN — Should zero be rejected or allowed? | Open |
| T1.3 | Expense CRUD Lifecycle | Create duplicate name | edge | expense.create | Error "Expense name already exists", no duplicate created | Ready |
| T2 | Expense Filtering | Create 3 expenses (variable, fixed, commitment) → switch tabs → filter by category → change month → verify filters persist | e2e | login.default, expense.create, navigation.sidebar_click | Filters survive tab switch and month navigation, correct data shown per filter | Ready |
| T2.1 | Expense Filtering | Navigate to month with no expenses (no setup needed) | edge | navigation.sidebar_click | "No expenses this month" message, no broken UI | Ready |
| T3 | Access Control | Owner creates expense → switch to viewer role → viewer sees but can't edit → viewer attempts create → blocked | e2e | login.default, expense.create | Viewer sees data, mutation UI hidden/disabled, direct API returns 403 | Ready |
| S1 | Smoke | Navigate to expenses page | smoke | navigation.sidebar_click | Page loads, list renders, zero console errors | Ready |
Column rules:
T[journey].[flow] for e2e/edge, S[n] for smokee2e (happy-path journey), edge (belongs to a journey), smoke, integrationReady or ⚠️ OPEN — [question for user]For EVERY journey, systematically sweep these categories. Do not skip any:
| Category | What to check |
|---|---|
| Empty/zero states | First-time user, no data, zero amounts, empty lists |
| Boundary values | Max length inputs, special characters, Unicode/RTL, negative numbers |
| Permission boundaries | Wrong role attempts action, cross-tenant access, expired session |
| Error paths | Invalid input, duplicate submission, network failure, timeout |
| State transitions | Status changes, undo after save, back-button after submit |
| Concurrent/timing | Double-click submit, rapid navigation, stale data after tab switch |
| Data integrity | Persists after refresh, related records update, cascade delete |
Every edge case becomes a row in the test flow table. If you cannot determine the expected result, mark it ⚠️ OPEN.
When the expected result for an edge case is ambiguous — you don't know if the system should reject or accept, show an error or silently ignore — do NOT guess. Mark it OPEN:
| T1.4 | CRUD Lifecycle | Submit form with future date | edge | expense.create | ⚠️ OPEN — Allow future dates or reject? | Open |
Rules:
This prevents the QA author from silently guessing edge case behaviors.
When building features, identify which test components (reusable eval sequences) exist and which need creation. This enables the deterministic runner to execute tests with zero LLM cost.
get_components() to see existing components for the projectlogin.default, expense.create, navigation.sidebar_click)This section is essential for the QA author — they will create components before writing tests, and compose tests from component calls instead of raw evals.
Explicitly list what must NOT happen:
Known pitfalls for the project's stack:
.single() vs .maybeSingle() for optional rowstoISOString() is UTC — use local formatting for user-facing comparisonsIf the plan requires database changes:
After completing the draft, review your own work before presenting it. Every section, every cross-reference, every task row, and every decision you made will be reviewed by an independent agent and then by the human. If the reviewer finds a gap — a missing task, a stale cross-reference, an orphan layer — it means your self-review was insufficient. The goal is not to perform review passes; the goal is to produce a plan where an adversarial reviewer finds nothing.
Each pass is a full re-read of the entire plan — not spot-checking individual sections.
Pass checklist (apply every pass):
Internal consistency — Do sections reference each other correctly? If Phase 2 mentions a table created in Phase 1, does Phase 1 actually create it? If a test journey references a component, is it listed in the Components table? If a task targets a file, is that file in the Relevant Files table?
Integration paths complete — For each new data format or API, trace the path through all layers that touch it (schema → handler → validation → DB → consumer). Does every layer have a task? If Phase 3 adds a new field to a schema, does another phase add code that sets it?
Cross-references survive edits — Adding or moving a phase renumbers everything downstream. Check that task IDs, test journey IDs, and phase references still point to the right targets.
Specificity — Read each acceptance criterion. Could an agent implement it without asking a question? Read each expected result. Could a QA author write a test from it without guessing?
Displacement damage — Did this pass's fixes move or change things that break other sections? Check the areas adjacent to every edit.
Stopping condition: The last pass found nothing to change. If a pass produces fixes, you must do another pass — fixes displace other content. There is no cap on passes.
Do not declare convergence prematurely. The tendency to skim familiar text and say "looks fine" is the single biggest source of plan defects. If you find yourself reading faster than the first pass, you are skimming, not reviewing. Slow down.
A plan is ready when the self-review converges (last pass found nothing) AND:
npx claudepluginhub edo-ceder/st4ck-plugin --plugin st4ckProvides a checklist for code reviews covering functionality, security, performance, maintainability, tests, and quality. Use for pull requests, audits, team standards, and developer training.