deuriib/frame-ship
Frame-Ship methodology — from strategic intent to shipped release.
Turns a rough idea into one written goal plus two to four things that count as success, and waits for you to approve it. No code, no requirements. Use when something new is starting, or when a goal needs writing down. Triggered by "start something new", "what are we building", "set the goal", or "quarterly planning".
Use when planning a campaign, reviewing content, or settling who owns a metric between brand and revenue.
Writes the code, and only the files the proposal approved, with a test for every requirement it covers. Use when the proposal has been approved and the code needs writing. Triggered by "build it", "start implementing", "the proposal is approved", or "go ahead".
Checks a proposal against the design, and writes a decision note when it changes a contract, a data model, or something many parts share. Use when a change is about to alter a public API, a data model, or anything many parts depend on. Triggered by "check the design", "does this change the API", "we are changing the data model", or "what would this break".
Looks at what a change could do to login, personal data, or a service outside us, and returns pass, pass-with-conditions, or fail. Use when a change touches auth, personal data, or an outside API, or when the security lead has to sign off. Triggered by "is this safe", "security check", "we are adding a login", or "we are storing personal data".
Use when closing the books, handling tax or payroll, moving treasury funds, or reviewing spend controls.
Use when something is broken, a test fails, behavior is not what was expected, or a fix is not taking effect and the root cause is still unknown.
Use when committing changes, splitting a dirty worktree into atomic units, writing Conventional Commits messages, or shaping history into a linear logical sequence before push or PR.
Use when creating, triaging, searching, taking, commenting on, or closing GitHub issues, or when turning an issue into a branch and pull request.
Use when signing a contract, clearing IP, handling personal data, or facing a labor or litigation question.
Use when a branch is finished and needs review, or when a pull request must be scoped, titled, described, linked to an issue, or made ready for review.
Use when setting access rules, reviewing performance, mediating team friction, or rolling out a change.
Use when shaping discovery, writing a PRD, validating with users, or planning pricing and launch.
Writes PROPOSAL.md — what would change, which files, what could break, and how it gets tested — then stops and waits for your yes. Changes no code. Use when someone is ready to work and needs a yes first. Triggered by "propose this", "can we change", "I want to add", or "how should we do this".
Writes the release notes, updates the changelog, tags the release, and moves the finished work into the archive. Use when the work is verified and ready to go out. Triggered by "ship it", "release this", "publish", or "cut a release".
Use when setting pricing, reviewing the funnel, working a deal, or questioning revenue recognition.
Hands the work to reviewers who cannot see each other's work, then merges what they say into REVIEW.md. A single failure closes the review. Use when the code is written. Triggered by "review this", "is this good", "run the review", or "check my work".
Explains the nine steps and the rules that hold in all of them. Use when a session starts, after the conversation gets shortened, or when someone asks what this does. Triggered by "what can you do", "how does this work", or session start.
Checks the work against the done checklist and writes HANDOFF.md — what was delivered and the proof. Use when someone says the work is finished and it needs a second look before it ships. Triggered by "is it done", "verify this", "hand this off", or "ready to ship".
Turns an agreed goal into requirements you can put a test against, plus the design that holds them. Use when the goal is approved and the work needs spelling out, or when something new needs a spec. Triggered by "the goal is approved", "write the requirements", or "what exactly are we building".