Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →hashgraph-online/using-praxis
Use at session start to learn how Praxis skills are invoked and why triage runs before every task.
Passed 18 of 21 test cases with the skill, and 6 of 21 without it.
and 19 more in the full report
14 fixed5 passed either way2 still failing1 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 13 test cases the skill fixed. Same model, same prompt, with and without the skill.
We are continuing work on a multi-repo authentication change where a coordinator plan declaring multi-module topology already exists on disk. State your header line for this turn.
| Checked | Without skill | With skill |
|---|---|---|
| Carries forward the topology multi-module declaration in the header line. | Missed | Passed |
The instructions your model reads when the skill loads.
You have Praxis.
<EXTREMELY_IMPORTANT> Before any response or action on every user message, classify scope using the triage table below, announce it, then load required skills in parallel. </EXTREMELY_IMPORTANT>
One line before every response:
praxis: scope=<x>, loading=<skills> # single-module (default)
praxis: scope=<x>, topology=multi-module, loading=<skills> # multi-module
| scope | signal | load |
|---|---|---|
| vague | problem space undefined — can't yet say what to build, for whom, or whether it's worth building | design |
| trivial | typo, rename, docs-only, <=1-line, pure Q | none |
| small | one function, single file, <=50 LOC, or test-only change | tdd (intent unclear? clarify first) |
| standard | feature or source-code change | design, plan, tdd, review |
| complex | new system, >=5 tasks, or parallel edits | design, plan, worktree, subagents, review, ship |
| debug | broken, regression, failing test | debug |
| onboard | existing project, no docs/tech-spec.md | onboard |
Topology is declared alongside scope, not chosen from the table. Default single (omit it). Announce topology=multi-module when one change spans multiple modules or repositories - every loaded workflow skill then follows skills/references/multi-module.md. Multiple repositories require a user-designated existing coordinator repository. Once a multi-module change is underway, a coordinator spec/plan declaring topology: multi-module exists on disk; read it and carry topology=multi-module forward every turn - do not re-decide from scratch. If unsure, check for that declaration before announcing.
topology doesn't change scope: classify exactly as for single-repo work; multi-module only adds execution mechanics (multi-module.md). Unsure? Start single-module; upgrade the declaration once confirmed.
If multiple scopes fit, choose the smaller one. vague is a last resort — if you can name a rough deliverable, use a lower scope instead. feature change = user-visible/public-contract change. source code = code/schema/config that changes shipped behavior; docs, tests, examples, CI, and tooling excluded.
docs/tech-spec.md first.praxis: scope=<x>, loading=<skills> (add topology=multi-module when the change spans multiple modules - see Topology above)praxis:<name> / native skill tool), otherwise read skills/<name>/SKILL.md with the native file-read tool.<gate> markers.test cases passed, vs 6 / 21 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.