--- name: completeness-plan description: "Plan a complete resource or operational workflow for a data-heavy web app before implementation. Use when a new or materially expanded admin, CRUD, directory, queue, or management feature still needs product-scope decisions and the requested deliverable is a plan, not implementation in this turn. Do not invoke when the user explicitly asks to build or implement the workflow, or when the request is for marketing, e-commerce, editorial, styling-only work, a narrow bug fix, an audit of existing behavior, or a small change whose behavior is already fully specified." license: MIT --- # Completeness Plan Produce a decision-complete, implementation-ready contract without changing the project. ## Boundaries - Stay read-only. Inspect source, tests, schemas, and documentation, but do not edit project files or run mutating commands. - Limit v0.1 to operational apps such as admin systems, CRMs, internal tools, and SaaS operations; do not apply it to marketing, e-commerce, or editorial product design. - Return the contract in chat. Write an artifact only when the user explicitly asks for one. - Treat completeness as a set of contextual decisions, not a demand to add every possible feature. - Reuse established project conventions when they are sound. Surface a conflict instead of silently replacing the architecture. ## Load the right guidance Read [the capability catalog](references/capability-catalog.md) before assessing scope. Read [the evidence model](references/evidence-model.md) when describing existing behavior. If the project uses React, Next.js, shadcn/ui, TanStack Table, tRPC, or Prisma, also read [the React/Next reference](references/react-next.md). Use [the output contract](references/output-contract.md) for the deliverable. ## Workflow 1. **Pin the boundary.** Identify the resource or workflow, actors, primary jobs, data source, expected scale, permissions, and consequential actions. Resolve repository facts by inspection; ask the user only for product decisions that cannot be discovered. 2. **Establish the baseline.** Find analogous modules and existing paths for list, detail, create, update, archive/delete, recovery, and permissions. A capability is `present` only with evidence. Record evidence-backed existing defects as findings instead of burying them in rationale. 3. **Assess applicability.** Walk every relevant catalog area. Apply each rule's `applies_when`, `skip_when`, authority, and strength. Require positive evidence from the request, domain, or repository before a rule enters the contract. An unmet trigger is omitted, not recorded as `defer` or `not-applicable`. Record an explicit exclusion only when the user raised the option or when the exclusion prevents a likely scope mistake. Do not turn a `should` or `may` into a universal requirement. 4. **Classify the product decisions.** Use only `present`, `include`, `defer`, `not-applicable`, or `needs-decision`. Group related rules under the smallest useful product-level decision, with a short rationale and rule IDs; never emit one row per catalog rule. Never silently omit an applicable `must` or `must-decide` rule. 5. **Close the decisions.** Present the unresolved frontier together with recommended answers. Incorporate the user's answers and reissue the complete contract. Do not finish with `needs-decision` entries. 6. **Make behavior testable.** Specify observable acceptance criteria, state transitions, authorization boundaries, failure behavior, and data-reachability semantics. Preserve this invariant for collection views: `displayed rows = paginate(sort(filter(complete reachable dataset)))` 7. **Deliver the plan.** Follow the output contract. Separate approved scope, explicit deferrals, and manual verification so an implementer does not have to invent product policy. ## Exit conditions Stop only when all applicable areas have an explicit status, no `needs-decision` remains, acceptance criteria are observable, and deferred work is clearly outside the implementation scope. Do not begin implementation from this skill.