LetA-Tech

mellions-bug-audit

Load this when asked to audit a subsystem, hunt for bugs, investigate a suspected defect, verify whether a reported problem is real, or establish root cause and blast radius before any issue or fix exists. Triggers — "audit this", "find bugs in", "is this actually broken", "root cause this", "what is the blast radius", "verify this finding", "review this subsystem for defects". Produces findings, never code and never issues. Not for planning or writing the fix (mellions-issue-remediation) or reviewing a diff that already exists.

Web & Frontend Listed

mellions-continuity

Load this at the start of any session that did not attend the one before it — a crash, a compaction, a restart, a switch between Claude and Codex, coming back tomorrow — whenever you find open work you have no memory of, and before acting on anything an earlier session wrote down. Triggers — "where were we", "what was I doing", "continue where you left off", "the session died", "pick this back up", "did that merge go through", "resume the assignment", "I lost the context". Not for choosing new work (survey), writing up what happened (report), or deciding what a run should teach the next one (mellions-self-learning).

mellions-deep-research

Load this before deciding anything the evidence at hand cannot settle — a work item's premise, a root cause, a remedy's mechanism, another session's or a subagent's claim, a provider's behaviour, what production actually does, which document has authority — and before publishing a claim about a file, run or record you have not opened. Triggers — "is this still true", "what does the code actually do", "the issue says", "the doc says", "the session says", "find out", "investigate", "establish", "where is the evidence". Not for deciding what to do with what you found (mellions-reasoning), proving a fix holds (mellions-falsification) or a full defect audit (mellions-bug-audit).

mellions-delegation

How to run a repository work session, and how to review the work of one you did not open — what a dispatch contains, how to judge what comes back, how to review a peer's pull request and whether merging it is yours, when to isolate work in the disposable sandbox, and when to close. Use when opening a session, writing a dispatch, deciding whether a session's report is trustworthy, unblocking one that is stuck, deciding a session is finished, or when a survey shows a peer's draft pull request waiting for a review nobody has given. Triggers — "delegate this", "open a session", "spin up a worker", "the session says", "is that report solid", "should this run in a sandbox", "review this PR", "should I merge this", "who reviews a draft", "nobody reviewed it". Assumes the session is a capable engineer who cannot see your record.

mellions-environment

What this host can actually do, and how to establish it rather than assume it — toolchains, git and GitHub access, container runtimes, the disposable sandbox, and where the repositories are. Use when deciding whether a task is possible here, choosing what to ask a session to run, telling one where a repository lives, or answering what tooling is available. Triggers — "can we run", "is X installed", "where is the repo", "what version of", "run the tests", "use the sandbox".

mellions-falsification

Load this before a test, a mutation, a revert arm or a green run is cited as proof that a fix holds — and again before writing "falsified" in a pull request. Triggers — "prove it holds", "falsify", "neutralise the fix", "watch it fail", "the test passes", "is the test real", "mutation", "revert arm", "the suite is green", "proof section". Not for deciding what to do with the result (mellions-reasoning) or for establishing what is true in the first place (mellions-deep-research).

mellions-harness-rule

Turn a lesson into a check the repository enforces itself. Use when a defect has just been fixed and the same mistake could be made again — especially when it exists or existed in sibling repositories, or when the reason it was wrong is invisible from the call site.

mellions-issue-closure

Load this when work on an issue is finished and the question is whether the issue may close — after a merge, after a deploy, when an issue's defect turns out to be already gone at HEAD, or when a survey shows resolved work still open. It decides which event the issue actually closes on, what proof must be on the record first, and whether closing is yours or the owner's. Triggers — "close issue NN", "can we close this", "is this done", "post the proof", "the PR merged, close it", "this was fixed elsewhere". Not for deciding whether a defect is real (mellions-bug-audit) or for the implementation (mellions-issue-remediation).

mellions-issue-remediation

Load this whenever the instruction is to remediate, fix, build, ship or land the work a defect or work item describes — before the worktree is cut. Triggers — "remediate this", "fix issue NN", "implement the fix", "ship the remediation", "open the PR for this", "land this work", "start the implementation". Not for deciding whether a defect is real (mellions-bug-audit) or for closing the issue afterwards (mellions-issue-closure).

mellions-issue-resolution-proposal

Load this after the issue exists and before the first commit — to write the resolution plan on the issue itself, in the repository's approval model, so the plan survives the session, a reviewer can approve one comment, and closure can later read the acceptance rule it was made under; and again when the premise moved and the plan must be re-made. Triggers — "post the proposal", "write the plan on the issue", "record the plan", "document the proposal on issue NN", "before I start on NN". Not for producing the analysis (mellions-bug-audit), implementing (mellions-issue-remediation) or closing (mellions-issue-closure).

mellions-sandbox

Load this when uncertainty can be settled by running something — reproducing behaviour, an integration test, a hypothesis, unfamiliar code, a clean build, a bounded test dependency — in a disposable isolated environment rather than on the host. Triggers — "use the sandbox", "leta-mac-sbx", "leta-linux-sbx", "run it isolated", "reproduce this safely".

mellions-self-learning

Load this at every handoff; whenever something other than you located a failure in how you worked — a reviewer, peer or owner correction, a retracted claim, a proof that tested nothing, unplanned rework; before changing a Skill, a guard, a tool or Mellions' own source; and when a Skill you load changed recently, to say whether the change changed what you did. Triggers — "what did we learn", "that approach was wrong", "next time", "improve the skill", "the reviewer caught", "mellions is broken", "fix the tool", "did that change help". Not for recording what happened.

mellions-territory

Load this before removing, moving or reverting anything you did not write; when a file or work appears that you do not recognise; when opening work in a repository somebody may already be in; when two lanes need the same file or contract; or when you find something that affects another engineer's work — which lane is yours, how to find the others, and how surfaces several lanes write are shared. Triggers — "whose file is this", "stray file", "untracked", "another session", "worktree", "we both edited", "clean the tree", "rm -rf", "tell the other session".