Agent Ops Pack: first 30 minutes
This page shows a buyer what to do immediately after purchase so the bundle becomes a working delivery system, not just a downloaded file. It covers the first-session checklist, how to move the files into Docs or Notion, what to adapt first, and where the public reference points live.
$49 one-time template pack
What this page is for
It is a public orientation layer. The paid pack still unlocks the full editable files and verified download path.
This page is a public onboarding reference for buyers before or right after purchase.
The paid bundle is still the actual deliverable. This page explains how to use it first.
Use the product page and preview page as public references instead of sharing private delivery files too early.
Keep one master copy
Download the bundle, store an untouched copy, then duplicate the individual files into your own working system. The pack is easiest to adapt when the original stays clean and editable.
First-session checklist
A buyer should be able to do these steps in the first half hour without guessing what comes first.
1. Download the full bundle first
Grab agentbuildkits-agent-ops-pack-bundle.md before you start editing so you keep one clean source copy.
2. Duplicate the files into your own workspace
Keep the originals untouched. Copy the pack into your current client or internal ops folder before editing owners, launch notes, or support paths.
3. Fill the owner table and scope before touching prompts
Start with the delivery discovery SOP so the workflow owner, approver, fallback owner, systems, and non-goals are explicit before build work drifts.
4. Mark human-review points now
Use the QA, launch, and handoff files to mark where humans still approve edge cases, sensitive data, outbound messages, or change requests.
5. Decide what stays public and what stays private
Keep your adapted delivery docs private. Use the public product and preview pages when a collaborator needs context without the paid bundle.
Move the bundle into your docs stack
Keep the pack editable first. If you later need PDFs or polished client-facing docs, export from your adapted copy rather than from the untouched source files.
Simple rule
One untouched master copy. One live working copy for the current project. That split keeps the product reusable while still letting you customize aggressively.
Do not flatten the workflow too early
Keep kickoff, QA, launch, and handoff as separate working docs. Combining everything into one giant page usually hides owners, blockers, and sign-off points.
Markdown-first
Best if you want the least friction. Keep one folder per client or project, duplicate the files, and treat the untouched source copy as the master backup.
Google Docs
Paste each file into its own doc, preserve the headings and checklists, and link the kickoff, QA, launch, and handoff docs from one overview page.
Notion
Import or paste each Markdown file into a separate page. Keep the original file names as page titles so the pack still scans like a clean ops system.
Adapt these first
These changes affect delivery safety and clarity. They should happen before the next kickoff or launch review.
- Business outcome, phase-one scope, and explicit non-goals.
- Workflow owner, approver, fallback owner, and blocked access.
- Human-review points, launch blockers, and rollback notes.
- Support owner, urgent issue path, and change-request boundary for this client.
Adapt these later
These matter, but they should not block the first live use of the pack.
- Branding polish, formatting cleanup, and client-facing tone changes.
- Longer internal SOP notes after the first live version is already working.
- Reusable snippets pulled from repeated launches across multiple projects.
- PDF export or presentation polish after the editable working docs are stable.
Public reference points
The product and preview pages should do the public-facing explanation work. Your private adapted docs should handle the client-specific details.
Use the product page as the public scope page
Send this when someone needs the current promise, price, included files, and support/update boundary in one clean public URL.
Open reference pageUse the preview page as the public proof layer
Send this when a collaborator or buyer wants to inspect the delivery style and structure without receiving the whole paid bundle.
Open reference pageWhat is included and what is not
Keep the purchase boundary explicit. The pack is a reusable operator system, not a done-for-you service layer.
Included with the purchase
- README.md: Explains what the pack covers, who it is for, how it sits after the intake pack, and the order to use the files.
- discovery-sop.md: Gives the operator a repeatable kickoff and implementation-discovery sequence once the project is approved.
- prompt-qa-checklist.md: Provides a pass-fail QA sheet for agent prompts, operational workflows, and human-review controls before launch.
- launch-checklist.md: Covers pre-launch gates, launch-day checks, rollback planning, and the first 48 hours of monitoring.
- handoff-support-template.md: Documents what shipped, what still needs human review, how support works, and how change requests should be routed.
Not included
- Custom implementation or client-specific consulting.
- Unlimited prompt review, debugging, or support on your live workflows.
- A done-for-you launch inside your own stack.
- Permission to skip your own approvals, QA, or human review.
Keep the follow-up path simple
Once the buyer understands the first half hour, the next public references should be the updates page, the product page, and the preview page — in that order depending on whether they need revisions, scope, or proof.