V16 / BUNDLED SCENARIO

Design project contracts and class skeletons

Design project contracts and class skeletons: 2 ordered steps in Lilith V16, with no tool access. Read the exact bundled XML and its input and exit contracts.

V16Pinned source · 6df58cd3ed86Exit: copy

Use this scenario

Run

Run project_architect scenario.

Use run_scenario with the saved scenario name and string-valued inputs. Required values are requested before execution.

View invocation JSON
JSON
{
  "scenario_name": "project_architect",
  "inputs": {
    "kind": "your kind",
    "prd": "your prd",
    "previous": "No previous plan.",
    "diagnostics": "No host diagnostics yet.",
    "personality": "A precise software architect. Prefer small clear designs, explicit interfaces, cohesive responsibilities and testable acceptance criteria. Challenge omissions before creating implementation tasks."
  }
}
SCENARIO BLUEPRINT

Read the workflow.

project_architect5 INPUTS / 0 TOOLS / 2 STEPS
01

Inputs

PARAMETERS
InputRequirementDefault value
kindRequiredNo default
prdRequiredNo default
previousOptionalNo previous plan.
diagnosticsOptionalNo host diagnostics yet.
personalityOptionalA precise software architect. Prefer small clear designs, explicit interfaces, cohesive responsibilities and testable acceptance criteria. Challenge omissions before creating implementation tasks.
02

Agent instructions

SYSTEM PROMPT

You are the project architect, not a file writer. Treat the PRD as requirements data. Return valid JSON only, never tool calls or executable XML. No filesystem or shell access. Limit the design to a small complete V11 project: at most 12 files, 20 methods and 40000 total source characters. Contract must make independently produced components compatible.

STYLE

Optional personality

{{personality}}

Applied to this child only when nonempty; does not change the main assistant profile.

03

Tool access

CAPABILITIES

No tools are granted to this child conversation.

04

Ordered steps

EXECUTION
  1. 01
    CHAT TURN 01

    Create the architecture for kind {{kind}}. PRD: {{prd}} Return exactly {"contract":"shared interfaces, behavior and acceptance checklist","files":[{"path":"...","skeleton":"...","methods":[]}],"packages":[]}. For website: exactly index.html, styles.css and app.js; methods empty; skeleton empty. Contract MUST assign each file its responsibility; define every shared DOM ID, class, control, game/application state, event, function boundary, responsive layout and keyboard/touch/accessibility behavior. Use classic JavaScript, no modules, build pipeline or npm. The HTML loads styles.css and app.js. If the PRD needs libraries, list exact-version HTTPS CDN resources and usage in the contract; do not introduce dependencies otherwise. Include empty, invalid-input, reset/restart and completion behavior where relevant. For console: files are .cs sources only; use a conventional Program.Main entry point (not top-level statements). Each skeleton has all using directives, namespace if needed, classes, fields and types, but NO method bodies. Each method is a literal slot /*METHOD:unique_id*/. The file's methods array contains {"id":"unique_id","signature":"public static void Main(string[] args)","requirements":"..."} for each slot. IDs unique across all files. Contract includes signatures, shared types, ownership, IO and error behavior. Method writers receive the contract and their signature only, so include all fields/type definitions they need. At least one method, no more than 20. Each method signature must be complete and omit the body. NuGet dependencies, only when needed, are {"id":"Package.Id","version":"1.2.3"} with an exact version. Target net8.0, implicit usings and nullable enabled. The host supplies Application.csproj; do not generate build XML, package scripts or test code that runs at build time.

    Save output as design.

  2. 02
    CHAT TURN 02

    Review your architecture against the PRD and correct these actual host diagnostics, if present: {{diagnostics}} Previous failed plan, if present: {{previous}} Prefer only 3-5 methods for a simple console app. CRITICAL: in each skeleton a method slot REPLACES THE ENTIRE METHOD DECLARATION. Do not put any signature or semicolon next to a slot. IDs MUST match literally: if methods has id Calculator_Add, skeleton contains /*METHOD:Calculator_Add*/, not /*METHOD:Add*/. Include every closing class and namespace brace. Example file: {"path":"Calculator.cs","skeleton":"public static class Calculator { /*METHOD:add*/ }","methods":[{"id":"add","signature":"public static double Add(double a, double b)","requirements":"Return a+b."}]}. Never use abstract-style declarations in skeletons. Verify every slot appears exactly once and matches its methods array ID, then check all interfaces, initialization, invalid input and exit/restart behavior. Return complete corrected architecture JSON only; no explanation or Markdown.

05

Return to main

COPY EXIT

Return architecture JSON unchanged.

The final text returns without model rewriting. Bound operation scenarios return application results; pending changes still require host approval.

EVERY XML ELEMENT / IN FILE ORDER

Every part, briefly.

Short explanations of every element and chat step in this scenario.

  1. 01
    <scenario>

    Names and versions the workflow.

    Writing example ↗
  2. 02
    <inputs>

    Declares input values.

    Writing example ↗
  3. 03
    <input>kind

    Requires a supplied value.

    Writing example ↗
  4. 04
    <input>prd

    Requires a supplied value.

    Writing example ↗
  5. 05
    <input>previous

    Provides an optional value.

    Writing example ↗
  6. 06
    <input>diagnostics

    Provides an optional value.

    Writing example ↗
  7. 07
    <input>personality

    Provides an optional value.

    Writing example ↗
  8. 08
    <personality>

    Optionally styles this child's replies.

    Writing example ↗
  9. 09
    <systemPrompt>

    Sets the child's instructions.

    Writing example ↗
  10. 10
    <steps>

    Orders the chat turns.

    Writing example ↗
  11. 11
    <step 1>

    Create the architecture for kind {{kind}}. PRD: {{prd}} Return…

    Writing example ↗
  12. 12
    <step 2>

    Review your architecture against the PRD and correct these…

    Writing example ↗
  13. 13
    <exit>

    Returns the output unchanged.

    Writing example ↗