abrahamferga/define

Turn an accepted SPEC.md into PLAN.md — capabilities grouped into epics in build order, the module split (default: exactly one domain module), a per-module tool inventory carrying permission strings and approval flags, the tab list, the connector surface, background jobs, the refined role model, and the open questions the design loop must settle. Epic 1 is the thinnest real slice of the domain that proves module loads + tool runs + approval gate fires + tab renders; there is no Foundations epic, because the platform already is the foundation. USE FOR: sequencing capabilities into epics, deciding how many modules, naming every tool and its permission before any code exists, turning spec roles into concrete grants, listing what the design loop still has to decide. DO NOT USE FOR: writing the spec itself (../synthesize-spec/SKILL.md), publishing epics as GitHub issues on a board (../sync-backlog/SKILL.md), or pinning versions, schemas, solution layout and ADRs (/shape:design-product).

Competitive research on one chosen industry, written to research/<industry>.md: who the leading commercial vendors are, a capability comparison matrix built only from sources actually opened, the recurring UX patterns buyers already expect, the regulatory obligations that shape the build, a one-to-one map of the industry's table stakes onto what Plenipo already delivers, an explicit list of what it does not, and a must-have / differentiator / out-of-scope split. This is the artifact the spec is written from. USE FOR: mapping a vendor landscape from cold, separating table stakes from differentiators, sourcing the compliance obligations that constrain v1, refreshing stale research. DO NOT USE FOR: turning the findings into a specification (../synthesize-spec) or deciding which vertical to enter in the first place (/scout:find-industry).

Project PLAN.md into GitHub as the system of record: epic and feature issues upserted by a hidden marker so a re-run never fans out duplicates, features linked under their epic as sub-issues, and every card on the Projects v2 board in Backlog with its build order. Also reaps the gap the predecessor left open — an issue whose capability was deleted from the plan is detected and closed or escalated, instead of sitting Ready waiting for someone to build it. USE FOR: publishing a finished plan to issues plus a board, re-syncing after the plan changed, finding orphaned issues. DO NOT USE FOR: authoring the plan (../plan-product), creating the repo or the board (/deliver:scaffold-product), moving cards out of Backlog (/shape:design-product), implementing an issue (/deliver:work-next-issue).

Turn research/<industry>.md into SPEC.md — the one-sentence framing, jobs to be done, personas and their authority tiers, the must-have / differentiator / out-of-scope capability split, an RBAC model of dotted action-noun permissions, regulatory constraints, and observable success metrics. Its defining move is binding every capability to a named Plenipo seam — module tool (approval-gated if it writes), tab, connector, background job, module endpoint, host seam — and deleting outright anything the platform already supplies. USE FOR: writing or re-scoping a product spec, cutting v1 down to what ships, sketching the shipped role baselines. DO NOT USE FOR: the competitive landscape (../research-industry), epics and build order (../plan-product), or technology, layout and data-model decisions (/shape:design-product).