[ PACK LIBRARY / SOFTWARE DEVELOPMENT ]

FOUNDATIONFREE SAMPLETESTED

Tech-stack manifest: languages, frameworks, infra, and who owns what

STAFF THEO / KIRA / IDRIS / JASON / ROOT / TORQUE / JERRY / KAYLE / PAUL / ORBIT / SATCHMO / ZACK · V0.2.0
bopen-tools:runtime-context

REQUIRES

  • claude plugin install bopen-tools@b-open-io

WHEN TO REACH FOR THIS

Every other playbook in this pack works better when it starts from facts about your stack. This is the fill-in-the-blank onboarding doc — an AGENTS.md-style manifest that every one of the twelve staff reads first, so they know your package manager, database, and deploy owner before they act. Fill it once, commit it at the repo root, and point every later playbook at it.

REQUIRES

  • claude plugin install bopen-tools@b-open-io (provides bopen-tools:runtime-context and the full software-development roster)
  • A checkout of the repo you want the manifest to describe
  • No other accounts or keys; this is a documentation foundation, so no build or deploy is involved

CONTEXT INPUTS

Fill these in. Leave a field blank only if it genuinely does not apply, and say so — a blank you meant to fill is worse than "n/a".

{{PROJECT_NAME}}          # what the product is called
{{ONE_LINE_PURPOSE}}      # what it does, in one sentence

# --- Languages & runtimes ---
{{PRIMARY_LANGUAGE}}      # e.g. TypeScript
{{RUNTIME}}               # e.g. Bun, Node 22, Deno
{{PACKAGE_MANAGER}}       # e.g. bun, pnpm, npm ; the ONE the repo actually uses

# --- Frameworks ---
{{WEB_FRAMEWORK}}         # e.g. Next.js 16 App Router
{{MOBILE_FRAMEWORK}}      # e.g. React Native / Expo, or n/a
{{UI_LAYER}}              # e.g. shadcn/ui + Tailwind v4, or n/a
{{BACKEND_FRAMEWORK}}     # e.g. Hono, tRPC, Convex functions, or n/a

# --- Data ---
{{DATABASE}}              # e.g. Postgres (Neon), Convex, Turso, MongoDB
{{ORM_OR_CLIENT}}         # e.g. Drizzle, Prisma, Convex client, raw SQL
{{CACHE_OR_QUEUE}}        # e.g. Redis, Convex scheduler, or n/a

# --- Infra & deploy ---
{{HOSTING}}               # e.g. Vercel, Railway, Fly, self-hosted
{{CI_PROVIDER}}           # e.g. GitHub Actions, GitLab CI
{{ENV_SECRET_STORE}}      # e.g. Vercel env, Doppler, .env.local
{{OBSERVABILITY}}         # e.g. Sentry, Axiom, none yet

# --- Conventions ---
{{LINTER_FORMATTER}}      # e.g. Biome, ESLint + Prettier
{{TEST_STACK}}            # e.g. Vitest + Playwright, or none yet
{{BRANCH_MODEL}}          # e.g. trunk-based, PRs to main, feature branches

# --- Ownership (who to route to) ---
{{FRONTEND_OWNER}}        # human or agent (e.g. Theo)
{{DATA_OWNER}}            # e.g. Idris
{{DEPLOY_OWNER}}          # e.g. Root
{{SECURITY_OWNER}}        # e.g. Paul
{{ESCALATION_HUMAN}}      # the human who signs off on irreversible changes

THE PROMPT

PASTE INTO YOUR AGENT
You are producing a tech-stack manifest for {{PROJECT_NAME}}, committed as AGENTS.md at the repo root. Start from the filled-in context inputs above, then verify and complete them against the actual repo. Do not accept a claimed value that the repo contradicts.

1. Load the bopen-tools:runtime-context skill so you correctly describe the environment the code runs in (Claude Code, Vercel Sandbox, local dev) and do not assume tools that are not present.
2. Read package.json / lockfile, config files (next.config, biome.json, tsconfig, drizzle/convex config), CI workflow files, and any existing README. For every context input, confirm it against what you find. Where the repo disagrees with the input, use the repo's truth and flag the discrepancy.
3. Write AGENTS.md with these sections: Purpose, Languages & Runtimes, Frameworks, Data, Infra & Deploy, Conventions, and an Ownership/Routing table mapping each area to its owner from the inputs. If an AGENTS.md already exists (modern scaffolds commit one, and a CLAUDE.md may import it), read it first and keep any managed marker block (a "BEGIN:... / END:..." comment pair) intact; add your manifest sections around that block instead of replacing the file.
4. Add a short "How to run it" block (install, dev, build, test) using the ONE package manager the repo actually uses.

Negative prompts:
- Do NOT invent tools, versions, or owners. If a field cannot be verified from the repo and was left blank, write "unknown - confirm with the team", not a plausible guess.
- Do NOT recommend swapping any tool here. This documents what IS, not what should be.
- Do NOT list multiple package managers as if they are interchangeable; name the real one.
- Do NOT overwrite an existing AGENTS.md wholesale. Preserve any managed marker block and any CLAUDE.md import that points at it.

EXPECTED OUTPUT

An AGENTS.md at the repo root that any of the twelve staff can read cold and know your languages, frameworks, data layer, infra, conventions, and who owns what — with every field either verified against the repo or explicitly flagged as unconfirmed.

FOLLOW-UP CHAIN

  • sd-cicd-baseline — CI/CD baseline doc: provider, required checks, deploy targets, secrets policy
  • sd-coding-conventions — Coding conventions and review-bar doc
  • sd-security-profile — Security and compliance profile: sensitive-data map, controls, sign-off owner

← PACK CONTENTS