Flows

Preparing your submission

Use this page together with the Developer dashboard and Submission studio labels. It describes what must exist in your GitHub repository so SIGMA’s static checks, sandbox, and manifest steps succeed — not internal implementation details.

For policy on pins, registries, and resubmissions, see Submitting code and Dependency requirements. For the audit sequence, see How it works and Submission and audit.

Principles (all categories)

Public GitHub only — The repository URL you paste must resolve to a public repo. SIGMA locks a branch, tag, or commit and reviews that exact tree. The submission studio does not offer a direct Markdown upload for this path: your SKILL.md and any code must be visible on GitHub for the public certificate flow.
Artifacts live in the tree — Dependency manifests (requirements.txt, package.json), SKILL.md, and your code entry point must be real files in that commit. Optional notes in the studio (for example CONTEXT_SCREENING / developer context) are screened for abuse and fed to reviewers as hypothesis only; they do not replace manifests or change what the pre-processor reads from the repo.
Entry point is always a repo-relative path — Use forward slashes, no leading slash, no .. segments. Examples: src/main.py, skills/my-skill/scripts/run.ts. For Skill + Code style categories, the entry point is the executable code file, never SKILL.md (the studio explains this in the entry-point guide).
Size and shape — Stay within the limits shown in the studio and in Submitting code (file count and total size caps). Prefer a minimal folder when you only need one skill or one tool.
Monorepos — A repository root URL is fine. SIGMA infers the skill / package folder from your entry point path and looks for SKILL.md alongside that code when the category includes a skill manifest. Keep SKILL.md in the same skill directory as the code you are certifying.

Dev portal studio (what you fill in)

These blocks align with New Submission in the dashboard:

Studio area	What you provide	Why it matters
Category	SKILL, CODE, packages variant, API variant, etc.	Chooses which pipelines run (manifest only, code review, package registry, live API checks).
Repository URL	`https://github.com/org/repo` (and optional `/tree/branch/path`)	Single source of truth for fetch. Same checkout is used for SKILL.md, code, and manifests.
Branch / tag / commit	As prompted after fetch	Pins the audit to an immutable revision when you submit.
Entry point (code categories)	Relative path to the main `.py`, `.js`, `.mjs`, `.cjs`, `.ts`, or shell script	Drives sandbox entry, monorepo scoping, and (with skill categories) which `SKILL.md` is paired.
Manifest (skill / plugin flows)	Server-generated and validated in the studio	You complete steps in the UI; do not hand-edit JSON in a way that contradicts `SKILL.md` or the studio will reject.
CONTEXT_SCREENING (optional)	Short implementation note	Auditors may read it; it is not a dependency file and not a substitute for `requirements.txt` / `package.json`.
API declaration (SKILL + API, API-only)	Endpoints, auth, probes as the studio shows	Required for live verification categories; see API surface for HTTP areas agents use.

Layout by runtime (code entry)

Expand one block at a time. The same entry point field in the studio applies to every runtime below (see The submission process).

Python

Entry file

Use .py (or .pyw if applicable) as the studio entry point for Python.
The file should be import-safe or side-effect–bounded enough to load under a read-only, no-network sandbox (see Security). Prefer a main guard or CLI pattern if heavy work should only run when invoked as a script.

Manifest

If you import anything outside the standard library, add a requirements.txt in the repository (typically next to your package or at the repo root, consistently with how you structure the project). Use exact pins (package==1.2.3); ranges are rejected. Rules: Dependency requirements.
If the project is stdlib-only, you may omit third-party deps; the sandbox still expects your entry path to exist in the tree that was fetched.

Monorepo example

text

skills/my-skill/
  SKILL.md
  requirements.txt
  scripts/
    run.py          ← entry point: skills/my-skill/scripts/run.py

Node / TypeScript

Entry file

JavaScript: .js, .mjs, or .cjs as the entry point.
TypeScript: .ts entry is supported; the isolated review environment loads TypeScript entrypoints the same way as a tsx-style runner (see Code review).

Manifest

Declare dependencies in package.json at the root of the Node project (or the folder SIGMA scopes to). Exact versions are accepted directly, and public-registry ranges such as ^ or ~ can also be accepted when SIGMA resolves them to one exact audited version. See Dependency requirements.
For CODE + PACKAGES / skill variants that include packages, the studio runs a package preview against the registry policy before quote — fix blocking rows shown there before paying.

Monorepo example

text

packages/my-tool/
  package.json
  SKILL.md                 ← if category includes skill
  src/
    index.ts               ← entry point: packages/my-tool/src/index.ts

Shell

Entry file

Use .sh, .bash, or .zsh as declared in the repo. Shell submissions are treated as high risk in review; keep scripts small, deterministic, and free of secrets.

Manifest

Shell does not use requirements.txt / package.json for the script itself. Anything the script invokes (interpreters, CLIs) must still be available in the image the audit uses — prefer documenting required tools in SKILL.md or your advisory text and keep external calls explainable.

Practical guidance

Avoid undeclared outbound HTTP from the script when the category does not include API verification; sandbox runtime is network-disabled for code review (Security).

Skill and manifest (studio-handled)

For categories that include a SKILL:

Keep SKILL.md in the same repository (and, in monorepos, under the same skill directory as your code entry point when code is in scope).
The SIGMA manifest you attach in the studio is generated and validated in the product from that source. Treat the manifest UI as the source of locked fields for submission — do not bypass it with ad-hoc files that contradict SKILL.md.
If your skill declares external HTTP usage, align the manifest and optional API flows with what you actually host; see Validator plugins — Concepts and API surface.

API-only and SKILL + API

API-only — You declare endpoints in the studio flow; there is no SKILL.md requirement.
SKILL + API — SKILL.md plus live endpoint checks. Ensure declared base URLs, auth, and routes match what SIGMA will probe.

Use Reference — APIs for route families (/sigma/v1/... validation, submit, certificates) and Package endpoints when package preview applies.

Checklist before you click Submit

Repo is public; ref is the one you intend to certify.
Entry point path matches a real file in that ref (code categories).
requirements.txt / package.json present and pinned whenever third-party code is imported.
SKILL.md present and consistent with the manifest when the category includes a skill.
CONTEXT_SCREENING used only for human-oriented notes — not as a manifest.
CODE + PACKAGES (or equivalent): package preview in the studio shows no blocking dependency rows.

Sigma documentation v1.2GitHub / Skill ↗