skillZs
★ LIVE SKILL TAGS ★
>>> LIVE SKILLS INDEX <<<
* OPEN SOURCE *
NO LOGIN, NO TRACKING
※ REAL INSTALL DATA ※
← back to all skills
shkarupa-alex/meta-o131 installs

mo-setup

Use only when the user explicitly requests mo-setup; inspect or bring a project and its environment to the Meta-O contract.

How do I install this agent skill?

npx skills add https://github.com/shkarupa-alex/meta-o --skill mo-setup
view source ↗

Is this agent skill safe to install?

  • Gen Agent Trust Hubpass

    The skill is a project setup and verification tool for the Meta-O methodology. It performs environment posture checks, validates project structure (glossary, architecture, README), and verifies quality gates. It uses security best practices such as performing behavioral probes in disposable clones without network access, using structural AST parsers for project files, and requiring human confirmation for trust or posture changes.

  • Socketpass

    No alerts

  • Snykpass

    Risk: LOW · No issues

What does this agent skill do?

Set up a project for Meta-O

Start only when the user names mo-setup; a generic environment or tooling question does not activate setup mutation.

Read Project setup contract, Backend contract, Обратная связь о методологии, Маршрутизация подтверждённой внешней работы, and Purpose and architecture contract completely. For Python read Python QC profile; for JavaScript/TypeScript read TypeScript QC profile. Read both for a mixed project.

Inspect substance: business/architecture ids, glossary, README, byte-identical agent contracts, temporary feature backlog, acceptance/E2E, purpose, mature language gates and one deterministic non-mutating aggregate QC. Require the smallest regression test for a confirmed behavioral defect and an invariant comment for substantial ownership/concurrency/trust/security/compatibility/ transaction/resource-lifetime repair. Do not create a backend fixture document in an ordinary target project without a named consumer.

Read the knowledge layer first with bundled scripts/mo-knowledge-layer.mjs --candidate <HEAD sha> and report its line verbatim, the one a reviewer brief carries: a project that never had the layer answers Knowledge-Layer: state=not_enabled reason=never_enabled, and one that had it and lost a signal answers Knowledge-Layer: state=needs_attention with the helper's reason. Whether a project has the layer is the human's decision: on their answer write Knowledge-Layer: enabled or Knowledge-Layer: disabled as its own line in AGENTS.md, and never choose for them. disabled is only valid once the closure command, the papercut document and the history record are gone.

Find the project's documented backlog path and closure command, and make the line that declares it carry the literal MO-BACKLOG/1: that literal is how the layer helper finds the command. Verify MO-BACKLOG/1 in a disposable fixture: committed-blob identity, empty, not-empty, typed unknown, dirty declared path, unrelated dirt, malformed UTF-8/ schema/mode and non-mutation. Require G0/GC/G1/G2 in the project contract. Ordinary QC must test the reader/schema but not assert the current branch empty.

Read Knowledge id history contract and check current-tree agreement separately from history. The current tree is checked by bundled scripts/mo-knowledge.mjs check with the project's own declaration — business document, architecture directory, every declared document and first-party root, exact excludes — and its MO-KNOWLEDGE/1 status=… gives current_tree; a project does not need its own checker for that portable core. Never guess: take the declared stage from a level-two section whose heading contains Knowledge id history, holding exactly one fenced one-line command, exactly one line naming the authoritative QC command, and exactly one history_cutoff_sha record. Parse it with a Markdown AST. Any other count is history=unknown with cutoff=none. The same contract must name where identifiers live: the business document and the architecture directory the stage reads. Unnamed, ambiguous or contradictory locations are history=unknown cutoff=none and no fixture is written at all — a fixture built on a guessed location certifies documents nobody checks, or edits a clone at random.

Prove the stage by its own behavior, never by the project's full QC, and only in a disposable clone: git clone --no-hardlinks --no-local <path> <tmp> under a disposable TMPDIR, no network. The candidate worktree is never opened for writing. Budget 600 s for the whole probe and 120 s for one stage run; exceeding either is unknown naming the exhausted budget, never gate_missing. The stage must be part of the declared QC command — appearing in it verbatim, or named as its stage by the same line and present in the tracked runner definition that line points at — or it is gate_missing: a stage outside the authoritative check is a stage nobody runs. A red baseline run in the clean clone is gate_failing and stops the probe.

Then two fixtures, in the clone only, touching only the declared locations and only definitions the AST actually found there. Delete one identifier definition and commit without a trailer: the stage must exit non-zero and print a typed marker, either MO-KNOWLEDGE-HISTORY/1 status=violations or the project's documented equivalent; a zero exit or no marker is gate_missing. Reset the clone with git reset --hard and git clean -xdff, then change a literal with a correct trailer and a matching knowledge_id_change record: the stage must pass, and a failure is gate_failing. Strictness without tolerance and tolerance without strictness each prove only half. Delete the clone in a finally; its path is machine-local and never reported.

Report one record, with qc as JSON or none and no local paths:

Knowledge-IDs/1 current_tree=<ok|violations|unknown> history=<gate_present|gate_missing|gate_failing|unknown> stale=<yes|no|unknown> qc=<json|none> cutoff=<sha|none>

Compute stale by hashing, not by trusting the version string: hash the bundle you ship by the documented rule and compare with the hash in the copy's last-line MO-KNOWLEDGE-HISTORY-SOURCE comment. Equal is stale=no; different is stale=yes and both <semver> values go in the report; a missing, duplicated or unparsable line is stale=unknown, except in the supplier project itself — whose package.json names the package this bundle came from — where the stage runs the source the bundle is built from and the record is stale=no. The version explains a difference to a human and never decides it.

Find the commands-and-papercuts document by content, not only at docs/papercut.md, and report Papercut/1 path=<json|none> linked=<yes|no> where linked means AGENTS.md actually links it. The layer helper recognizes that document by the path docs/papercut.md or by papercut in the linked file name; a document named anything else is declared, on the same human answer that writes the marker, by the line Knowledge-Layer-Papercut: <path> in AGENTS.md, or the helper reports a partial set. Accepted repair starts from Commands and papercuts template.

Accepted repair copies three shipped bundles into the project, each with its tools/licenses/, and all three then belong to the project. scripts/mo-knowledge.mjs goes to tools/mo-knowledge.mjs, and a QC stage calls its check with that project's own declaration. scripts/mo-backlog.mjs goes to tools/mo-backlog.mjs, and the closure command that calls it must name that project's own --path, --title, --open-heading, one --intro for each paragraph between the title and the open section, in order, and every --entry-field, with the title and each paragraph as rendered text, without Markdown markup and with whitespace collapsed: without the whole schema the checker would hold a foreign notebook to this project's Russian wording, and a partial schema is a call error. scripts/mo-knowledge-history.mjs goes to tools/mo-knowledge-history.mjs with its version line; a stage calling it joins the project's own QC with the project's own cutoff, and AGENTS.md gains the declaration section plus the trailer grammar with verbs remove|reuse|editorial. Never copy this project's boundaries or commit ids: a foreign cutoff exempts exactly the history the target needs checked. Propose no CI job naming a path this repair does not create.

Check .orca/ and spec/ independently through git check-ignore -v --no-index; accept only a match from a tracked repository ignore file proven by git ls-files --error-unmatch. Separately require git ls-files -- .orca/ spec/ to be empty: an ignore match never proves that already-indexed private workspace bytes are absent.

Resolve one absolute Orca binary. Require non-empty version-matched bundled orchestration and orca-cli guides via orca skills list/get --json; never install guide copies. Separately prove native status/project identity, provider auth, account freshness, selected-harness launch, normal prompt versus trust UI/shell, stable title capability, one owner of unsandboxed posture, and supported blocking-wait duration.

Check orca/orca-cli separately from the upstream orchestration companion. Also check mature jq and flock dependencies.

Read ProjectRegistrationSet/1 and OwnedResourceSet/1. A folder/no-project workspace without an existing same-project isolated route is a setup gap. Never register a temporary path as a review workaround. Any project/repository registration or personal trust/posture change requires separate human confirmation; the project root the user named at this call, and this run's own resources, are that confirmation already.

Probe the named project root live and report one line:

Harness-Trust/1 harness=claude path=<json> state=<trusted|accepted|needs_human|unknown> screen_version=<id>

accepted is reported only when all three ownership conditions held: the terminal was created by this run and recorded in OwnedResourceSet/1, the realpath of the path in the dialog equals the realpath of that terminal's worktree, and that worktree is a run resource or the root the user named. Confirming the dialog means answering for whatever is in that folder, so a missing condition is needs_human with the recipe — open the tab <title> and choose Yes, I trust this folder — and never a retry.

Inspect active hosting/CI settings read-only. Parse GitHub Actions or GitLab CI only with js-yaml, following literal tracked local includes/reusable workflows. Return one CI-Coverage/1 record with provider, repository, entrypoint, resolved graph, job/step, events, required policy, outcome, unresolved, plus history=<full|shallow|unknown> and backlog_job=<yes|no|unknown>: a shallow clone turns the history stage into a silent skip, and closure needs a job separate from ordinary QC. Outcomes are covered|config_present|no_ci_surface|unknown; dynamic/remote constructs and unreadable settings cannot yield covered. Compare against the shipped examples in assets/ci/ and show an exact proposed YAML patch, but never change tracked CI or server protection without a separate request.

If tracked repair is accepted, use a separate feature/meta-o-setup branch based on current develop; never mix setup repair into the current feature branch. Preserve unrelated work. Report each missing control, companion, capability, credential and policy independently, each with one actionable next step the human runs: the exact install, login, trust or configuration command, with no secret value in it. Never ask for or collect the credential itself.

Meta-O calls

  • none

Add the canonical catalog link to the repository README so users can inspect current installs and available audits. The publishing guide covers the complete discovery path.

<a href="https://skillzs.dev/skills/shkarupa-alex/meta-o/mo-setup">View mo-setup on skillZs</a>