Skip to content

deuriib/frame-ship

v0.17.1MIT

Frame-Ship methodology — from strategic intent to shipped release.

agree-the-goal

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".

brand

Use when planning a campaign, reviewing content, or settling who owns a metric between brand and revenue.

build

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".

check-design

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".

check-security

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".

finance

Use when closing the books, handling tax or payroll, moving treasury funds, or reviewing spend controls.

fix-a-bug

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.

git-commit

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.

github-issues

Use when creating, triaging, searching, taking, commenting on, or closing GitHub issues, or when turning an issue into a branch and pull request.

legal

Use when signing a contract, clearing IP, handling personal data, or facing a labor or litigation question.

open-a-pull-request

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.

people

Use when setting access rules, reviewing performance, mediating team friction, or rolling out a change.

product

Use when shaping discovery, writing a PRD, validating with users, or planning pricing and launch.

propose

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".

release

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".

revenue

Use when setting pricing, reviewing the funnel, working a deal, or questioning revenue recognition.

review

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".

start-here

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.

verify

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".

write-the-requirements

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".