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-setupIs 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
How can the creator link this skill?
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>