Guides

New here? See the operating model: four stages, the packs in each, and where you decide.

Start here: the install-to-ship walkthrough takes you from installing the catalogue to a merged change you approved, in about ten hours.

Find your job by stage

Work moves through four stages, and most work skips one or two. Find your stage, then open the job page.

Set up a repository

• Start a project gets a repository ready for your agent.
• Connect your tracker brings Jira, Linear, or GitHub work in.

Decide what to build

• Research a question gives you an evidence-graded answer.
• Understand the code shows what a codebase does and what a change would break.
• Analyse the market produces a written analysis.
• Set direction and goals turns market knowledge into goals engineers can pick up.

Shape it

• Shape an idea turns a rough idea into a plan ready to build.
• Design the architecture agrees a design on half a page.
• Design the experience goes from a customer’s goal to reviewed screens.
• Design an API contract gives you a checked contract.

Build it

• Run the build loop takes a change from a request to merged work.
• Fix a bug finds the cause and fixes it with the smallest change.
• Review a pull request gets an independent review.
• Build a page or component checks accessibility, states, and layout.
• Record a decision writes down why.
• Write the docs documents a shipped feature.

Ship it

• Release a change deploys, checks, and ships on your approval.
• Change infrastructure turns a request into reviewed Terraform or OpenTofu.
• Measure delivery reports cycle time and throughput from Jira.

The install-to-ship walkthrough

This route is an ordered set of guides from installation to a governed, reported release. Each stage names what you need first, roughly what it costs, and which stage comes next.

P1 · Adopt the catalogue — ~1 hour

Prerequisite: none. For: anyone, first session. Stage: before any of them.

1. Install packs for your agent
2. Install the whole lifecycle
3. Adapt an existing repo, or start a new project
4. Orient at session start

First value: workspace status answers what to work on next. Ends at: a repository whose queues you can read.

Next: P2 · Shape what to build.

P2 · Shape what to build — ~3 hours

Prerequisite: P1. For: product manager, product engineer, strategist. Stage: Shape it.

Start the shaping with the light path: frame an intent, test its riskiest assumption, and break it down. Take the wider path only when the problem is unclear or the bet is large. The intent tree explains the choice.

1. Gather evidence when the answer is not already known
2. Shape a feature intent with intent frame
3. De-risk it with intent de-risk
4. Shape the architecture concept when the work changes how the system is built
5. Break it down with intent decompose
6. Hand the intent to the build loop

On the wider path, frame the situation first. Then identify opportunities, generate options, and place a bet. Map the capabilities before you shape the architecture concept.

First value: one written intent naming an outcome and the bet behind it. Ends at: Core intake, which picks the route from the content: a spec, a delivery brief, or a minimum repository intent.

Next: P3 · Build it. For a wider alternative, see P2b · the four product disciplines.

P2b · Take the wider route through the four disciplines — ~4 hours

Prerequisite: P1. For: product manager, researcher, designer, product engineer. Stage: Decide what to build, then Shape it.

This is an alternative to P2, not something you do after it. Take P2 when you change something that exists and need a framed, evidenced bet. Take P2b when the work also needs a strategic choice and a designed surface, such as a new product area or a user-facing flow.

1. Find out what is true hands Product Strategy graded evidence.
2. Decide what to build hands Experience Design a committed strategy.
3. Design how it should feel hands Product Engineering a per-screen state matrix.
4. Shape the bet and build it ends with a shaped bet and a change you approved.

You can stop after any step and still hold the artifact it produced.

First value: graded evidence on your question, before anyone commits to an answer. Ends at: a shaped bet whose evidence, strategy, and design you can point to.

Next: P3 · Build it.

P3 · Build it — ~2 hours

Prerequisite: P2, or an existing spec. For: engineer, agent. Stage: Build it.

1. Orient at session start
2. Plan and execute non-trivial work
3. Review someone else’s PR
4. Close and disposition the work

First value: a spec and plan you approved before any code was written. Ends at: a merged change, and the decision to merge is yours.

Next: P4 · Decide together.

P4 · Decide together — ~1.5 hours

Prerequisite: P1. For: tech lead, architect. Stage: any. Decisions get written down wherever they are made.

1. The governance index shows whether you need an RFC, an ADR, or a spec.
2. Propose an RFC
3. Record an ADR

An RFC or ADR is written from the artifacts of P2: an intent, a decision brief, a research survey, or an architecture concept.

First value: a circulated proposal with its alternatives written down. Ends at: an accepted decision that outlives the people who made it.

Next: P5 · Ship and report.

P5 · Ship and report — ~2 hours

Prerequisite: P3. For: delivery lead, SRE. Stage: Ship it.

This release and reporting stage takes the build through its human ship gate.

1. The release loop
2. Run a release
3. Project slices out to a tracker, or intake from one
4. Measure flow and DORA metrics

First value: a deployed artifact validated in an environment like production. Ends at: a human ratifying the production ship.

Extend the catalogue

P6 · Extend the catalogue — ~3 hours

Prerequisite: P1 and P3. For: AI enablement, catalogue owner.

1. Why catalogue curation
2. Your first skill
3. Build an org stack pack
4. Create a catalogue

First value: one skill of your own that your agent can run. Ends at: a catalogue your organisation owns.

Choose by outcome

• Decide what to build: desk-research, then product-strategy, then product-engineering.
• Design the product and system: experience-design, architect, contracts, and frontend-engineering.
• Build and review software: core, with code-intelligence, governance-extras, and monorepo-extras.
• Provision and release safely: iac-terraform, then release-engineering.
• Work with team systems and evidence: atlassian, github, linear, figma, converters, and credential-brokers.
• Document what ships: product-documentation.
• Build and govern a catalogue: catalogue-curation, with the catalogue authoring standards.

Every pack

Each pack has its own guide home with a short list of its job pages.

• architect: design a system and draw it.
• atlassian: work with Jira and Confluence, and measure delivery.
• catalogue-curation: write, import, and govern catalogue skills.
• code-intelligence: query an indexed code graph.
• contracts: write API and event contracts.
• converters: convert documents and publish Markdown.
• core: take work from a request to a merged change.
• credential-brokers: keep secrets out of your agent’s context.
• desk-research: get an evidence-graded answer.
• experience-design: design reviewed screens.
• figma: read a Figma file.
• frontend-engineering: build and check a page or component.
• github: bring GitHub work into the repository.
• governance-extras: record decisions and proposals.
• iac-terraform: change infrastructure with review.
• linear: bring Linear work into the repository.
• monorepo-extras: scaffold a new package.
• product-documentation: write and check product docs.
• product-engineering: shape a bet and hand it to delivery.
• product-strategy: analyse the market and set direction.
• release-engineering: deploy, verify, and ship.

Guidance for every pack

_shared/ holds the guides that apply whichever packs you install.

• Install agentbundle, install packs, configure it, and upgrade packs.
• Check adapter support for your agent tool.
• Start, remember, inspect, or refresh repository work, with the routing and lifecycle reference.
• Understand packs, profiles, and catalogues, then apply the authoring standards.

To write a guide, use the author-product-docs workflow.