$npx -y skills add sweetcornna/mathodology --skill mathodology-gateway-apiUse when maintaining archived knowledge about Mathodology's former gateway, API routes, auth, state, LLM routing, exports, submission bundles, or contracts.
| 1 | # Mathodology Gateway API Archive |
| 2 | |
| 3 | ## Scope |
| 4 | |
| 5 | This skill preserves architectural knowledge about the former Mathodology gateway and public API surface. |
| 6 | |
| 7 | The current GitHub branch does not contain the gateway source, contracts, migrations, tests, or generated clients. Use this skill for archived guidance and reconstruction planning, not for editing or compiling a gateway in this checkout. |
| 8 | |
| 9 | ## Archived Concepts |
| 10 | |
| 11 | The former gateway acted as the service boundary for the product: |
| 12 | |
| 13 | - request intake for modeling runs |
| 14 | - run status, event streaming, and artifact access |
| 15 | - authentication for development and hosted usage |
| 16 | - persistence through application state and backing stores |
| 17 | - LLM provider routing, streaming, fallback, and cost accounting |
| 18 | - paper export and submission bundle generation |
| 19 | - API contracts shared with the worker and web UI |
| 20 | |
| 21 | ## Workflow Adapter Role |
| 22 | |
| 23 | In the award-level workflow, use this skill when the submission package needs service or product-style reasoning from the former gateway design: |
| 24 | |
| 25 | - define a clean boundary between user prompt, computation, artifacts, and final package |
| 26 | - preserve event-log thinking for phase logs and reproducibility trails |
| 27 | - treat exports and submission bundles as first-class deliverables |
| 28 | - keep API-contract thinking when specifying output schemas for code, data, tables, figures, and paper sections |
| 29 | |
| 30 | Codex agents should use this as architecture guidance, not as a command to rebuild the removed gateway. |
| 31 | |
| 32 | Claude Code subagents should reference this only when package boundaries, artifacts, exports, or reproducibility contracts are unclear. |
| 33 | |
| 34 | ## How To Maintain This Skill |
| 35 | |
| 36 | When updating archived gateway guidance: |
| 37 | |
| 38 | 1. Mark implementation details as historical unless verified from Git history. |
| 39 | 2. Prefer behavior and contract concepts over missing source paths. |
| 40 | 3. Do not add build, test, migration, or contract-generation commands as current validation. |
| 41 | 4. If exact route behavior is needed, recover it from an older commit in a separate worktree. |
| 42 | 5. Keep cross-boundary notes aligned with the pipeline and web UI archive skills. |
| 43 | |
| 44 | ## Useful Questions |
| 45 | |
| 46 | Use this skill for questions like: |
| 47 | |
| 48 | - What responsibilities did the former gateway own? |
| 49 | - How did gateway concepts connect worker runs, web streaming, exports, and LLM providers? |
| 50 | - What should be preserved before reconstructing API contracts? |
| 51 | - Which historical areas need Git-history inspection before implementation work? |
| 52 | |
| 53 | ## Current-Branch Rule |
| 54 | |
| 55 | Any current-branch edit should be limited to skills or documentation. Do not add gateway source, contracts, migrations, generated clients, service config, or tests back to this branch unless the user explicitly changes the repository strategy. |