Proposal Foundation Layout

<!-- Adapted from Maxine-1520/OpenAIR_proposal; see ../ATTRIBUTION.md. -->

Proposal Foundation and Layout

Use this skill only for the research proposal formatting stage.

Goal

Establish the durable research context that governs the complete proposal workflow, then express it as a readable, restrained, publication-quality Typst document. The model defines the context blocks needed for the actual project instead of fitting every proposal into a fixed field list. Later workflow stages will treat these blocks as authoritative and may refine them through explicit patches.

Read the method reference completely before acting: references/foundation-and-coordination.md. When changing the generated NSFC presentation layer, also read references/typst-template.md for its upstream source, license, and adaptation boundary.

You may read any project source file for context. You may modify only the selected entry document, styles/, and assets/. Project documents are optional context. Their names describe their role; decide whether and when to read each one from the current stage and request. The presence of a project document does not make it mandatory input.

Typst Syntax

The typst-author skill is enabled alongside this one and owns Typst language questions. It bundles a local copy of the official Typst 0.15 documentation under its docs/ directory.

Read that documentation before writing Typst code that names a function, parameter, or syntax form. Typst is newer than most training data, and a function name that merely sounds plausible produces a compile error rather than a near miss — #numbered-list(...), for example, does not exist (the function is enum), and Typst reads the hyphen as subtraction, so the whole call fails.

Do not rely on recall for the following, all of which are documented in the bundled mirror:

• list markup and its functions, including enum, list, and terms;
• set and show rules, selectors, and styling;
• page setup, margins, headers, footers, and numbering;
• figures, tables, equations, and cross-references;
• font fallback chains and set text options.

If the mirror does not settle a runtime question, probe it with typst eval rather than guessing.

Workflow

1. The runtime describes available context artifacts and their roles. formatting-target.json identifies the selected entry, user-context.txt contains the author's current request, and proposal-foundation.json contains previously established context. Select only the material needed for the current formatting work.
2. Inspect the selected Typst entry and any imports needed to understand its layout. If the entry does not exist, the source tree contains the material from which it may be created.
3. Treat any author-approved context you choose to use as a durable baseline, not as disposable model output.
4. Apply the intake, dependency, and foundation method from the reference. Create only the context blocks needed to preserve the project's confirmed meaning, requirements, evidence, decisions, uncertainties, and coordination constraints. Choose descriptive stable keys and clear titles; do not force a predefined block taxonomy.
5. Use AskUserQuestion for consequential missing or conflicting choices. Keep questions concrete and avoid asking about facts already fixed by the source or author.
6. Preserve an existing venue template and its required page geometry. The default workspace keeps presentation rules in styles/nsfc-proposal.typ; edit that file instead of duplicating layout rules in section files. Otherwise use conservative academic defaults and centralize them with Typst set and show rules.
7. Edit only the selected Typst entry file, styles/, and assets/. Create the selected entry when formatting-target.json names a Typst file that does not exist yet, using the uploaded source material as read-only context. Other proposal sections may be read for context but belong to later stages and must not be changed here.
8. After the source edit is complete, call publish_stage_result from the enabled LLM4AD stage MCP server. Pass the final artifact and a stable idempotency key for this completed revision. A successful tool response is the only completion signal; if validation fails, correct the source or artifact and call it again. Upsert every context block established or changed in this turn, leave unrelated persisted blocks untouched, and remove a key only when the author or trusted source explicitly invalidates it:

{
  "source_path": "proposal.typ",
  "summary": "Established the proposal foundation and updated its visual system.",
  "context_patch": {
    "upsert": [
      {
        "key": "model_defined_stable_key",
        "title": "A project-specific context heading",
        "content": "Complete Markdown content, including any useful hierarchy or equations.",
        "source_refs": ["author response or proposal.typ: section"]
      }
    ],
    "remove_keys": []
  }
}