Inception Skills¶

Location: inception_skills/

Three spec-driven skills for working on Project Inception. Two turn a business use case directly into a production-shaped application; the third turns a target system's operations into a new tool-execution-layer MCP server. Instead of assembling core libraries, MCP servers, and governance patterns by hand, a developer describes what's needed, and the skill handles which existing building blocks to reuse, how to structure the result, and how to wire tool governance, identity, observability, and evaluation so it's deployable on day one — not a demo that needs a rewrite later. recipe-builder also handles the other half of a recipe's lifecycle — amending one that's already built, via a scoped change-request workflow (see Amend an Existing Recipe below) rather than the fresh-build workflow.

They are plain markdown files, usable with any AI coding assistant that can read files in this repository.

Skill	Use it to	Entry point
recipe-builder	Turn a business use case into a complete, working `inception_recipes/<name>/` application, spec first	`recipe-builder/SKILL.md`
mcp-server-builder	Turn a target system's operations (a reference repo, SDK, or API doc) into a complete, working `inception_mcp_servers/<name>/` FastMCP server, spec first	`mcp-server-builder/SKILL.md`
agentic-engineering	Review, assess, or govern an existing (or proposed) agent against the AE-01..AE-15 production-practices framework	`agentic-engineering/SKILL.md`

recipe-builder uses agentic-engineering's AE-01..AE-15 practices as its own elicitation checklist and spec structure. Use them together: recipe-builder to build a new recipe, agentic-engineering to review one in depth — especially on high-risk domains such as financial, legal, health, or security use cases.

Meridian Bank and EBS Invoice Reconciliation are both complete recipes built this way and are the reference examples throughout this page.

Build Your First Agent¶

This is the entire developer-facing interface to Project Inception: describe the use case, get a reviewed spec, then a working application. No need to decide which of the agent patterns to use or how identity propagation should work — the skill handles that.

Step 1 — Fill in the intake form¶

Copy recipe-builder/USE_CASE_PROMPT_TEMPLATE.md. It has twelve sections, each mapping to one of the AE-01..15 practices:

One-line summary
Business objective and success measure
Actors and their identity
End-to-end workflow
Systems and data involved — for each one, state whether it already exists on the platform or is a new integration
Allowed actions
Forbidden actions
Human-in-the-loop requirements
Decision/business logic
Non-goals for this iteration
Existing assets and constraints
Risk tier

A "not sure" or "TBD" answer is fine anywhere in the form — it tells the skill to ask before proceeding rather than guess. See What developers commonly leave out below for the sections worth spending the most time on.

Step 2 — One prompt¶

Use inception_skills/recipe-builder/SKILL.md to build this use case:
[paste filled-in USE_CASE_INTAKE.md]
Draft specs/SPEC.md and hold for my sign-off before scaffolding anything.

That's the whole prompt. The AE-01..15 rigor is built into the skill itself (see Hard guardrails), so it doesn't need to be spelled out here.

Step 3 — What the skill does¶

Reads the platform's own ground truth first — docs/architecture.md, docs/capabilities.md, docs/inception-core-libs.md, docs/inception-core-accelerators.md, docs/inception-mcp-servers.md — and the closest existing recipe to the new use case.
Checks every integration named in section 5 of the intake form against what actually exists in inception_core/inception_mcp_servers.
Drafts specs/SPEC.md, structured section-by-section on the AE-01..15 framework, then runs a self-audit against each practice's actual requirement (not just its section header).
Stops for review. No scaffolding happens before the spec is confirmed.
Once confirmed, designs the agent topology (the smallest of the 7 patterns, or a swarm, whichever fits), scaffolds the 3-tier layout, wires inception_core/inception_mcp_servers as reuse-first dependencies, and builds in order: domain models → DB layer → agents → workflow → API/CLI → tests → docs.

Step 4 — What you get¶

A new inception_recipes/<name>/ with the same shape as every recipe on this platform: specs/SPEC.md, docs/{architecture,adding-a-tool,adding-an-agent}.md, a db/ layer if needed, a uv-managed Python backend under src/{agents,agent_workflows,api,cli,config}/, and tests/{unit,interactive,evals}/ including a real AE-09 evaluation suite wired to metro.evals.

Build a New MCP Server¶

A narrower unit of work than a full recipe, so the prompt is three lines instead of twelve sections. Copy mcp-server-builder/USE_CASE_PROMPT_TEMPLATE.md:

Use mcp-server-builder to scaffold a new MCP server for <target system>.
Reference for the tool surface: <repo/SDK URL>.
Start with just: <tool_name>.

The skill places the target system into one of three architecture families (control-plane OCI SDK / data-plane direct driver / data-plane subprocess), verifies every tool signature against the reference you gave it — an installed SDK via inspect.signature, or the repo's own source, never a guessed signature — drafts specs/SPEC.md, and stops for review. Once confirmed, it scaffolds the same 3-file pattern (server.py/registry.py/tools.py) every server in inception_mcp_servers/ already follows, copying auth boilerplate from whichever existing server is the closest match rather than re-deriving it.

inception_mcp_servers/mcp_oci_control_plane_database/ is the worked example — built from exactly this prompt shape, live-verified end to end. Its specs/SPEC.md is a complete filled-in reference.

Amend an Existing Recipe¶

A different workflow from the one above, for when a recipe that's already built gets a new or changed requirement — an amended intake, a stakeholder ask, a discovered gap — rather than starting from a blank spec. The risk shape is different: a fresh build is free to design around whatever it's building, but an amendment lands on a system that already has live invariants other things depend on, and the amendment's own wording almost never announces which invariants it's about to disturb.

Copy recipe-builder/CHANGE_REQUEST_TEMPLATE.md to inception_recipes/<name>/specs/CHANGE_REQUESTS/<yyyy-mm-dd>-<slug>.md and fill it in — trigger, delta summary (new/modified/explicitly-out-of-scope), a blast-radius classification, a scoped AE-01..15 self-audit covering only the practices this change actually touches, an impact map of what the running code already couples to the surfaces this change touches, a build-order checklist, and a regression verification plan. No scaffolding or code edits happen before this document is reviewed and confirmed — the same gate SPEC.md gets for a fresh build, scoped to this change instead of the whole spec.

The impact map is the single highest-value section: grep the actual code for what already reads/writes the tables, global checks, or shared session/role model this change touches, not just what the change's prose implies. A change that looks purely additive can still break something else that made a global assumption — the template's own worked example is a global readiness check silently picking up new entities a change added for one period, and failing three other, previously-passing periods that had nothing to do with the change.

inception_recipes/finance_allocation_consolidation's 2026-08-24-finance-analyst-chatbot.md is a complete, filled-in worked example — a chatbot feature added to an already-running recipe via this exact workflow, dogfooding it against a real change.

Choosing a chat-agent shape¶

If the change (or a fresh build) adds a conversational entry point, the skill picks between two proven shapes rather than hand-rolling either:

Shape	Use when	Reference
Open-ended, tool-using Q&A	The user asks free-form questions; the agent decides which tool answers each one	Reference Chatbot
Bounded intent classification + slot-filling dispatch	A small fixed set of backend actions; the LLM only classifies intent and extracts slots, every actual decision is plain Python	`finance_analyst_chat_agent.py` in the worked example above (Pattern 3, Routing)

The bounded shape has a much smaller prompt-injection surface, since the model never freely decides which backend action to take — pick it whenever the chat's job is narrow dispatch rather than open-ended tool selection.

What developers commonly leave out¶

Section 5 (systems and data involved) and section 11 (existing assets and constraints) are the two sections worth the most care. A use case description can be detailed everywhere else and still leave real architectural questions unanswered if these two are thin. Watch for:

Assuming an integration is new when it already exists, or vice versa. Name the specific capability and check docs/capabilities.md and inception_core/libs/ before assuming — for example, OCI Document Understanding key/value extraction is already available as a direct-call tool (tools/dus2_tool.py), not something to build from scratch.
Platform-level access constraints that aren't obvious from the use case alone. Some backend systems are intentionally not reachable directly — EBS, for instance, is only reachable through Oracle Integration Cloud workflows on this platform, never a direct API call. State this explicitly in the spec rather than assuming a direct integration.
Push vs. poll for event detection. "Detect a new file" or "detect a new record" means different things depending on whether the underlying service supports a push event or only polling. mcp_os, for example, has no push mechanism — state the trade-off up front.
Related work already in the repository. Check inception_recipes/ for anything that overlaps with the new use case, even a prototype that predates current conventions — it may still be a useful reference for entity shapes or lessons learned, even where the code itself isn't reused.

The EBS Invoice Reconciliation recipe's own intake form — specs/USE_CASE_INTAKE.md — is a complete, filled-in example covering all twelve sections at this level of detail, alongside the specs/SPEC.md it produced.

Hard guardrails¶

Enforced steps in recipe-builder/SKILL.md itself, not conventions a developer has to remember:

No scaffolding before specs/SPEC.md is written and confirmed. Writing the spec is fine; generating code from it before sign-off is not.
The AE-01..15 self-audit is mandatory, and checks each practice's actual requirement, not just whether its section header is present: AE-01 needs a named business owner and safe-failure behavior per state-changing action; AE-03 needs explicit schemas, idempotency, timeouts/retries, and rejected-call logging; AE-04 needs credential lifetime and secret-storage location; AE-07 needs a stated dead-letter/degraded-mode behavior; AE-08 needs a tracing/cost layer and a PII-in-logs statement; AE-11 needs retention/encryption/data-minimization; AE-12 needs a compliance/exception path; AE-14 needs rollback criteria and staged-rollout detail; AE-15 needs a baseline and a segmentation plan.
Every audit_log(...) call must pass user_id=/session_id= explicitly — metro.logging.agentic_logging's audit_log() never populates these from ambient context; an omitted kwarg logs null with no error.
Every get_agentic_logger(...) call must pass application="<recipe_name>" explicitly — the .env discovery in metro/env.py always resolves to the shared library's own .env first, never the consuming recipe's, so the fallback cannot resolve correctly on its own.
Reuse-first, always — no new MCP server, and no reimplemented LLM invocation, logging, guardrails, evaluation, or token exchange, unless an existing building block's auth/connection model genuinely doesn't fit.
No destructive or live-system actions (running DDL, calling production OCI/IDCS endpoints) without explicit confirmation at that specific step, even on an already-approved build.

The agentic-engineering skill¶

The companion skill for reviewing an agent — new or existing — against the full AE-01..15 production-practices framework. Use it for:

Architecture or implementation plan reviews, mapping every component to its responsibility, trust boundary, and failure mode
Production-readiness assessments, rating each practice not addressed / partial / implemented / verified
Governance checklists on high-risk domains — financial, legal, health, security
Incident or remediation plans: contain first, preserve traces, then correct the control gap and add regression coverage

production-practices.md, bundled with the skill, is the canonical definition of all fifteen practices. recipe-builder's own self-audit is built directly from it, so the two skills stay consistent on what each practice requires.

Tool compatibility¶

All three skills are plain markdown with no tool-specific assumptions. To use recipe-builder or mcp-server-builder with any AI coding assistant: give it read access to this repository, provide the skill file plus a filled-in intake prompt, and let it work through the workflow section — it reads the other files it references (docs/architecture.md, the closest existing recipe or MCP server, and so on) as it goes.

Where to go next¶

If you want to...	Read
Build a new recipe right now	`recipe-builder/SKILL.md`, then copy `USE_CASE_PROMPT_TEMPLATE.md`
See a filled-in template and the spec it produced	EBS Invoice Reconciliation's intake form → its SPEC.md
Amend an already-built recipe	`recipe-builder/CHANGE_REQUEST_TEMPLATE.md`, see Amend an Existing Recipe above
Add a conversational entry point to a recipe	Reference Chatbot (open-ended tool use) or Amend an Existing Recipe's routing shape
Build a new MCP server right now	`mcp-server-builder/SKILL.md`, then copy `USE_CASE_PROMPT_TEMPLATE.md`
See an MCP server's filled-in spec	`mcp_oci_control_plane_database/specs/SPEC.md`
Review an existing agent's production-readiness	`agentic-engineering/SKILL.md`
Understand the 15 practices both skills are built on	`production-practices.md`
See two full recipes built this way	Meridian Bank · EBS Invoice Reconciliation
Add browser-facing IDCS SSO to a recipe's UI	IDCS Browser Login