The method · roles
Five roles. One team.
Each role is a human responsibility — the AI assists every one, holds none. Here's what each does, day to day, and how to operate it on the reference platform.
The founder sets direction and is the root of trust. They decide what gets built and in what order, found the project, and keep the system healthy. The first user, with full visibility.
Once — found the project
- 1
Design the project on the canvas
Any interfaceFill the H1VE Canvas with the architect, then expand into the four foundation documents.
- 2
Set up the team
PanelInvite members and assign each a role.
- 3
Connect the source
PanelLink the GitHub repo and webhook so the board reflects reality.
Every day — 5 minutes
- 1
Check the inbox and notifications
PanelThe panel shows what's waiting on you and what's stuck.
- 2
Approve pending specs
PanelNo feature enters development without your (or the architect's) approval.
- 3
Watch blockers and the architect's queue
PanelSpot bottlenecks before they grow.
Every week
- 1
Record technical-health metrics
PanelInput the week's health signals — CI pass rate, cycle time.
- 2
Decide the next features
PanelPrioritize from the roadmap and set each feature's appetite.
May
Create and prioritize features · approve specs · assign roles · see everything.
May not
Skip the gates. The founder's authority is direction, not a bypass.
The architect translates vision into technical reality. They lead the technical spec, approve specs from a technical angle, review pull requests, and hold the exclusive authority to merge into main — the final human gate.
Once — found the technical side
- 1
Lead the technical spec (SDD)
Any interfaceDefine stack, data model, APIs, and key decisions with the AI as drafting partner.
- 2
Adapt the project's memory file
Any interfaceSet the non-negotiable rules, critical files, and current state in CLAUDE.md.
When a spec arrives
- 1
Review with technical focus
PanelCheck schema, ownership, and acceptance criteria.
- 2
Approve the spec
PanelOnly then does the dev begin to code.
When a PR arrives
- 1
Verify the pre-conditions
PanelCI green, QA and Data both signed off, the DONE present.
- 2
Review the critical files
PanelFocus where the AI declaration flags generated code.
- 3
Perform the merge
PanelThe squash merge into main — your exclusive authority. Resolve conflicts manually, never via AI.
May
Approve specs · review and merge PRs · resolve conflicts · define architecture.
May not
Merge work lacking CI, QA sign-off, or Data sign-off. Merge authority is a responsibility, not a shortcut.
The dev writes the code, paired with an AI agent, working only within an approved spec and only on assigned files. They declare what the AI generated and how much was reviewed.
Before coding
- 1
Confirm the approved spec
Any interfaceRead the project context and the spec for your feature.
- 2
Generate a personal token
PanelCreate your token to use the CLI and the AI integration under your own identity.
- 3
Start the feature
CLI
nf startshows your assigned features and creates the branch automatically — no naming by hand.
During the work
- 1
Build with the AI, inside the spec
MCPThe agent generates; you stay within the spec's file scope.
- 2
Check status without leaving the terminal
CLI
nf statusshows the current feature, stage, and blockers. - 3
Log a blocker if stuck
CLI
nf blocker "..."— or ask your AI to log it via MCP.
When done
- 1
Submit the AI declaration
CLI
nf donerecords what the AI generated and moves the feature to PR. The agent can do this via MCP. - 2
Open the pull request
Any interfaceOpening the PR moves the feature automatically; CI runs.
May
Implement an approved spec · open PRs · log blockers · submit the AI declaration.
May not
Write code without an approved spec · touch files outside scope · merge to main.
QA verifies functionality against the spec's acceptance criteria. An independent gate — QA did not write the code. Focus is behavior, not code style or schema.
When a feature arrives
- 1
See it in your inbox
PanelThe panel notifies you: a feature awaits your sign-off.
- 2
Read the spec and the DONE
PanelThe spec gives the acceptance criteria; the DONE says how to test.
- 3
Run the functional tests
Any interfaceVerify the behavior the spec promised.
The decision
- 1
Check each criterion
PanelDoes it meet the spec, or not?
- 2
Sign off — or reject with reason
PanelSpecific, reproducible feedback if it fails.
- 3
The double gate completes
PanelWhen Data also signs off, the feature advances automatically.
May
Sign off or reject on functional grounds, with specific feedback.
May not
Be the person who wrote the code · substitute for the Data gate.
Data verifies schema, migrations, constraints, and types. It catches the specific way AI fails with data — inventing fields, renaming columns without migrations, breaking constraints silently — errors that pass a functional test but corrupt the database.
When a feature arrives
- 1
See it in your inbox
PanelThe panel notifies you: a feature awaits your sign-off.
- 2
Read the spec's data changes
PanelFocus on the schema and migration sections.
- 3
Inspect the migration line by line
Any interfaceCheck it against the existing schema.
The decision
- 1
Verify integrity
PanelBackward compatibility, constraints, types, indexes.
- 2
Sign off — or reject with the line
PanelPoint to the exact problematic line if it fails.
- 3
The double gate completes
PanelWhen QA also signs off, the feature advances automatically.
May
Sign off or reject on data-integrity grounds, with the exact line.
May not
Substitute for the QA gate. Two risks, two independent gates.