@assuredloop/orca-bot-kit 0.1.0 → 0.2.0

package/skills/obk-decision-memo/SKILL.md

@@ -0,0 +1,241 @@
+---
+name: obk-decision-memo
+description: >-
+  Writing up a decision so someone else can take it: the conclusion first, the
+  evidence it rests on with how fresh each piece is, the alternatives that were
+  really considered and why each was dropped, the risks, the strongest argument
+  against your own recommendation, and what you are not sure about. Use when a
+  choice matters enough to be written down, is expensive to reverse, or will be
+  asked about later: picking between options, committing to a direction, or
+  recommending something to whoever decides.
+---
+
+# Writing up a decision
+
+A memo exists so that the person who has to decide can decide, and so that
+whoever asks in a year gets the reasoning rather than the outcome. Both of
+those are served by the same thing: the conclusion up front, and an honest
+account of what it rests on.
+
+These are defaults for work where nothing says otherwise. A user who asks for
+something else gets what they asked for; say which of these you left and why.
+
+## Say what is being decided
+
+Before anything else, get the decision into two or three lines for yourself:
+the choice, and what turns on it. If you cannot get it that small, you do not yet have a
+decision: you have a subject, and the memo will wander.
+
+Then say who decides. A memo written for someone with no authority over the
+thing is a briefing, and it should be honest about being one.
+
+Say who else is in it and what they stand to gain. Where someone taking part in
+the decision has an interest in one of the options, that is a fact about the
+decision and belongs in the memo, because it changes how the decision has to be
+taken and not only which option wins. It outranks the comparison.
+
+Say how reversible it is, and how long it will be lived with. That governs how
+much work the memo is worth: a choice you can undo next week does not earn a
+week of research, and one that will outlive everyone reading it does. Calibrate
+to consequence and say what calibration you used.
+
+Where a date forces the matter before the evidence is in, say what can honestly
+be settled by then and let that be the ask. Something has to be decided on the
+day, but it does not have to be the thing you cannot yet support: who decides,
+what they are authorised to spend or commit, and the rule that will pick the
+answer once the missing fact arrives are all real decisions. Guessing the
+answer to look decisive on the day is the failure this trades away.
+
+## Frame it before you shop
+
+Write down the job to be done, the hard constraints, and what is deliberately
+out of scope, all in language that does not belong to any of the options. Once
+a candidate's vocabulary gets into the requirements, the comparison is over and
+that candidate has won it: a requirement phrased as "we need its workflow
+engine" has already chosen.
+
+Keep doing nothing in the comparison, as a real option rather than a straw one,
+and say what it costs. Sometimes the current state does the job and the change
+is all ownership and no value. A memo that cannot say what happens if nobody
+acts has not established that anything needs deciding.
+
+And ask whether the question is the right one before answering it, and whether
+it is the real goal or a stand-in for it. A different framing sometimes makes
+the whole comparison unnecessary, and that is the most valuable thing a memo
+can find. Put the premises the reader has to accept where
+they can disagree with them, rather than burying them in the reasoning.
+
+## Alternatives worth the name
+
+Two or three real candidates and the do-nothing baseline beat a long list.
+Breadth is not the number of options; it is whether the options differ in a way
+that matters. A list of near-identical variants is a single option wearing
+several hats.
+
+Where the obvious options all share a shape, go looking on purpose: what would
+the opposite look like, what would the version ten times simpler be, what would
+this look like if the tightest constraint were lifted, and what would someone
+who works in this field every day think obvious. You are trying to find the
+option nobody has thought of, not to fill a table.
+
+Every option that was dropped carries the reason it was dropped, in one line
+that names the thing about it that failed. "Rejected" with no reason reads as
+"not considered", and the reader will re-propose it.
+
+Where an option fails a hard constraint, it is out, or it stays in with a named
+mitigation, not with a lower score. A hard constraint nobody checked is not a
+pass. Do not turn judgement into arithmetic: a
+weighted table gives the answer you chose the weights for, and it hides the
+reasoning in a number. Compare the survivors in plain language, on the things
+that actually differ.
+
+Compare what it costs to live with, not what it costs to start. The glue, the
+upgrades, the thing that has to be maintained around it, what happens when you
+want to leave; and how long until it pays off, and what else that time and
+money would have bought. Compare exact versions and tiers, not reputations.
+Where two survivors come out even, prefer the one easier to undo.
+
+## Evidence, and how fresh it is
+
+A claim that decides something needs a source that owns it: the documentation,
+the specification, the contract, the measurement, the record. Popularity and
+reputation are how you find candidates, and they are never how you choose one.
+
+Record the finding, not just the link. "See their docs" is not evidence; what
+the docs say, in the words that settle the question, is. Note when you looked,
+because the volatile things (versions, prices, support, security, who
+maintains it) are exactly the things a decision turns on, and they are stale
+by the time anyone reads the memo.
+
+A number you worked out yourself needs more care than a sentence you worked
+out yourself, because a figure travels further than the caveat attached to it
+and arrives at the next meeting as a fact. Give a range rather than a point,
+put the assumptions beside it, and say plainly that it is an estimate and what
+would move it.
+
+Mark how you know each thing, because the reader is entitled to discount:
+
+- **You ran it or measured it**, on something representative.
+- **You read it** in something authoritative, and can point at where.
+- **You worked it out** from what you read. This is where most mistakes live,
+  and the label is what lets a reader find them.
+- **Someone told you**, and you could not check it. Most of what a memo rests
+  on arrives this way, so it needs saying rather than quietly reading as
+  established. Who told you matters: the person doing the work describing their
+  own week is worth more than a figure that has been passed along twice, and
+  the difference often decides the memo.
+
+That list runs from the strongest support to the weakest. Where a fact matters
+enough, move it towards the top as far as is cheap: go and measure the thing
+rather than reasoning about it, read the contract rather than recalling it.
+Then say where it stopped, and keep the honest label when a better check was
+not available. Where you could not check something at all, say so in
+the memo rather than in a footnote.
+
+Not being able to check something does not stop you comparing it. Where
+somebody hands you the terms of two named options, compare those terms, say
+they are as supplied and unchecked, and name which of them the answer turns on.
+A recommendation that holds if the stated terms are right is a real answer, and
+saying so is different from pretending the terms were verified; it stays
+provisional until they are checked.
+
+What you cannot do is compare what you do not have. Where the options are not
+even named, or the facts that would separate them are missing entirely, the
+memo changes job and says so in its first paragraph: it becomes a
+recommendation about how to find out, naming what to get, from whom, and what
+it would settle. Filling that gap from memory is the most damaging thing you
+could hand over, because it reads exactly like a comparison built on evidence.
+
+## Argue against yourself
+
+Write the strongest argument against your own recommendation, in its best form,
+and put it in the memo. Not a weak version you can knock down: the one that
+would persuade you if you heard it from someone you respected. A memo with no
+counterargument reads as advocacy, and a reader who finds the obvious objection
+missing stops trusting the rest of it.
+
+Where you wrote it yourself, say so, because an argument you found and were not
+persuaded by is a weaker thing than one from somebody who believes it. Getting
+it from a person who actually holds the view is better whenever you can.
+
+Then look for what would have to be true. Imagine it is a year on and this went
+badly: what happened? List the ways it fails, say which of them you could
+prevent and which you are choosing to accept, and say which would be fatal
+rather than merely painful. Rank them by what they would cost, not by how easy
+they are to fix.
+
+Separate what you are betting on into what must be true for this to work at
+all, what would hurt if wrong but is survivable, and what does not matter yet.
+The first group is the one to check before committing, not after.
+
+When you have someone else look at it, give them the memo and the constraints
+and not your reasoning, and ask them to find what is wrong with it rather than
+what they think of it. Handing over your conclusion gets you agreement with
+your conclusion. What comes back is information rather than a verdict: read the
+thing again against each objection before you decide which ones hold. If you
+push back, push back with evidence, and never by making clear which answer you
+want. An objection that is dropped only because you argued confidently has not
+been answered.
+
+Be honest rather than supportive. Where the answer is that none of the options
+is good, or that the thing is not worth doing, that is the memo.
+
+## What you are not sure about
+
+Say how confident you are and why, in a line, rather than leaving the reader to
+infer it from your tone. Confident prose about thin evidence is the failure
+this whole thing exists to prevent.
+
+Say what would change your mind. Name the specific finding, measurement or
+event that would move the recommendation to a different option. That is what
+tells the reader whether to act now or wait, and it is the sentence that makes
+the memo useful a year later.
+
+Where a real unknown is blocking, propose the smallest thing that would settle
+it: the question, what would count as a pass and a fail, how long it gets. A
+trial that could not change the decision is not worth running, and a trial does
+not take away the duties of owning the choice while it runs. Stop looking when
+more looking would not change the answer.
+
+Deferring is a real outcome, and so is doing nothing. Where you defer, say what
+you are waiting for and what would trigger picking it up again, so that
+deferring does not quietly become forgetting.
+
+## The memo
+
+Lead with the conclusion. A reader who stops after the first paragraph should
+have the recommendation and the main reason for it.
+
+After that, in whatever order serves the reader: what was considered and
+dropped, the evidence with where and when it came from, the risks and which are
+accepted, the strongest argument against, what you are unsure about and what
+would change it, and when to look at it again. Those are questions it answers,
+not headings it has to print; where an answer is one line, it is one line.
+
+Where the project already keeps decisions somewhere, match what is there: the
+place, the naming, the sections it already uses. Continue the sequence rather
+than starting a second one, and where two conventions are already in use, say
+so rather than quietly picking. Where there is no convention, put it where the
+person asked for it or hand it back in your reply; do not invent a new place to
+keep documents.
+
+Write in the words the reader uses. Where a sentence says the choice is fast,
+clean, modern or robust, replace it with the number or the behaviour you mean,
+because those words survive review by meaning nothing.
+
+The detail lives in the evidence or in what it points at, not in the argument.
+
+## It is a proposal until someone accepts it
+
+A memo you wrote is a recommendation, however sure you are. Someone with the
+authority decides, and the memo records who that was and when. Do not write up
+your own recommendation as a decision, and do not let a discussion that nobody
+objected to become one. Silence is not agreement, and the person who was going
+to object may not have read it yet.
+
+Once it is decided, the memo stops being an argument and becomes a record.
+Leave it where it is when things change: write the next one, and say which one
+it replaces. A decision that was right at the time and wrong later is the
+normal case, and the reasoning is the part worth keeping.
+
+Sources and licences: [NOTICE.md](NOTICE.md).

package/skills/obk-finops/LICENSES.md

@@ -0,0 +1,19 @@
+<!-- The licences of the sources this skill was consolidated from. They travel
+     with the skill directory because the licences require it of anyone who
+     distributes the material. NOTICE.md says what was taken from each source;
+     this file carries the permission notices themselves. -->
+
+# Licences of the sources
+
+`obk-finops` names its sources in [NOTICE.md](NOTICE.md).
+
+## Sources that need no third-party notice
+
+This skill reproduces no third-party text. It was written from this kit's own
+PRD and ADRs, from facts measured on the harnesses for this slice and recorded
+in the tech notes, and from the owner's own conclusions about his own spending,
+restated in our own words.
+
+Where the ideas behind it trace to material with no licence attached, nothing
+of that material is copied here and credit is given in NOTICE.md instead, which
+is where it belongs.

package/skills/obk-finops/NOTICE.md

@@ -0,0 +1,77 @@
+<!-- Attribution for the sources this skill was built from. Kept out of
+     SKILL.md so it is not read into context on every use; it travels with
+     the skill directory, which is what the licences require. -->
+
+# Sources and licences
+
+`obk-finops` reproduces no third-party text. It is written from this kit's own
+design, from what was measured for it, and from the owner's own conclusions
+about his own spending, restated in our own words.
+
+## The owner's own conclusions, restated
+
+He reviewed his real sessions and wrote down what he found. That is his own
+writing rather than a third party's, so there is no licence question, but the
+research pack holds it only at one remove, as another agent's digest, so
+nothing here quotes it:
+
+- that the figure worth knowing is what a result cost rather than what a token
+  cost, and that the sum includes the runs that failed, the work handed to
+  another tool, anything charged outside the token bill, and the person's own
+  time correcting and re-explaining, which is usually the largest part and the
+  part nobody writes down;
+- that effort should follow the work: high for the orchestrating session,
+  medium for the workers, and the top of the range kept for deep read-only
+  analysis, as the owner's usage review puts it;
+- that a long thread pays to re-read itself, that a high median input per call
+  is the measurable form of it, and that compaction is where it becomes
+  visible;
+- that a sentence in a prompt is not a budget control, and that where a limit
+  cannot be enforced by the platform, that has to be written down beside it
+  rather than left for a reader to assume;
+- the two directions to read the evidence in: short simple turns on a top
+  model, or a high effort setting that is never used, mean the model is more
+  than the job needs; repeated corrections, the same error returning after a
+  fix was claimed, and tests failing again mean it is not up to the work.
+
+## This kit's own design
+
+PRD 6.8 decides that prices come from a live lookup and that a price which
+cannot be found is said to be unknown, and ADR 0006 is why none of the
+arithmetic here is done by the kit's own code: what a token costs is judgement
+about a changing world, not plumbing.
+
+The four kinds of token and the warning about comparing them across harnesses
+come from what was measured for this slice and written into the tech notes: the
+two harnesses do not mean the same thing by input tokens, one counting the
+cache reads inside it and the other outside, so a figure read straight from a
+transcript is not comparable with the same figure from the other. The kit's own
+usage report already puts both into the same unit, which is why this skill says
+to take that rather than the files.
+
+## What was deliberately not taken
+
+The source material carries an autonomy ladder that raises and lowers what a
+bot may do on its own according to how clean its recent runs were. It is not
+here. The pack itself records that the ladder's rungs are missing from the
+source, so there is nothing to take but the idea, and an untested scheme for
+automatically widening a bot's permissions is not something to invent inside a
+skill about cost.
+
+Sources and licences in full: [LICENSES.md](LICENSES.md).
+
+## What the re-validation changed (#156)
+
+- Pricing per model from `obk usage --json`'s per-model rows (the review
+  finding on #141), and reasoning tokens priced once, since on Codex they sit
+  inside output (docs/tech-notes.md).
+- The effort defaults as the owner's usage review gives them.
+- The median input per call as the measure of a thread re-reading itself, a
+  hand-over after more than one compaction for a worker session while a
+  persona session is judged on its cost and lost state (grok-bot-lessons'
+  session policy), and a check-in every so many
+  tokens on a loop with no budget (the usage review, via grok-bot-lessons).
+- On the signs of a model not up to the work, the charter or the job is the
+  first suspect, as in `obk-fleet-review`.
+- The allowance share is given only where the plan shows it; the kit does not
+  report it.

package/skills/obk-finops/SKILL.md

@@ -0,0 +1,146 @@
+---
+name: obk-finops
+description: >-
+  What a bot's work costs and what to do about it: starting from what was
+  actually used rather than an impression, looking the price up now and saying
+  plainly what you could not price, costing a result rather than a token, the
+  signs that a model is more than the job needs and the signs that it is not
+  up to the work, and saying which limits are really enforced and which are
+  only a sentence. Use when someone asks what their bots cost, whether a model
+  or an effort level is the right one, or why a bill is what it is.
+---
+
+# What the work costs
+
+Two questions hide inside "what does this cost". One is arithmetic: how many
+tokens, at what price. The other is the one worth answering: is this the
+cheapest way to get the result, and would a different model, effort or shape
+of work get the same result for less.
+
+Answer the first honestly and the second carefully. A cost report that is
+precise about tokens and silent about whether the work was worth doing is the
+kind that gets read once.
+
+These are defaults for work where nothing says otherwise. A user who asks for
+something else gets what they asked for; say which of these you left and why.
+
+## Start from what was used, not from an impression
+
+The kit counts it for you. `obk usage` reports, per session, the conversations
+it had, the calls they made, the tokens by kind, the models and efforts they
+ran at, and how often they were compacted. Run `obk --help` for the flags the
+installed version takes.
+
+The figures are already the same unit on both harnesses, which matters more
+than it sounds: the two write their transcripts down differently, and a number
+read straight out of a transcript is not comparable with the same number from
+the other one. Take the kit's.
+
+The kinds of token do not cost the same. Uncached input, output, cache reads
+and cache writes are separate figures because they are separately priced, and
+a conversation that looks expensive on raw input is often a conversation doing
+its caching properly. Do not add them into one number and then reason about
+it. Reasoning is counted too, and on Codex it is already inside output: price
+it once. Price per model from the per-model rows `obk usage --json` gives, so a
+conversation that ran two models is not priced as one.
+
+## Look the price up now, and say what you could not price
+
+Prices change and a price you remember is a guess. Go to the page that belongs
+to whoever charges for the model, read today's number, and say where you got
+it and when.
+
+Where you cannot find a price, say so and leave the money out of that line.
+A report with a gap in it that is marked as a gap is useful. One that fills the
+gap with a plausible number is worse than no report, because nobody can tell
+afterwards which figures were real.
+
+The same goes for a subscription. Where the work runs against a plan rather
+than metered billing, tokens are not money at all, and the honest answer is what it
+would have cost metered, and what share of the allowance it used where the
+plan shows that.
+
+## Cost a result, not a token
+
+Tokens per day tells you nothing about whether the money bought anything. Put
+the spend against the thing it produced: what did this bot actually deliver
+that somebody accepted.
+
+Count everything the result took, not only the bot's own tokens. The runs that
+failed and were done again. Work it handed to another tool or another session.
+Anything charged outside the token bill. And the person's own time reading,
+correcting and re-explaining, which is usually the most expensive line and the
+one nobody writes down.
+
+A bot that is cheap per token and needs three corrections per result is not
+cheap. Say the ratio and say what goes into it, so a reader can argue with the
+parts.
+
+## When a model is more than the job needs
+
+Look for work that did not need the thinking it was given. Short, simple turns
+on the most capable model. A high effort setting on a session whose answers
+never reason at length. A conversation that mostly runs commands and reports
+what they said.
+
+That is the common case and the cheapest fix in the kit: drop the effort, or
+move the session to a smaller model, and watch whether anything gets worse.
+A usual shape: high effort for the session that orchestrates, medium for the
+ones doing the work, and the top of the range only for deep read-only
+analysis.
+
+## When a model is not up to the work
+
+The signs are in the work, not in the answers. The same instruction given
+again. The same error coming back after a fix was claimed. Tests that pass in
+the report and fail on the machine. A loop that retries the same failing
+action. A person interrupting often because the bot is going the wrong way.
+
+Two of those together are worth acting on, and the first suspect is the
+charter or the job rather than the model. Where it is the model, the fix is
+upwards: more capable model, or more effort, or a narrower job so the context
+is not doing the work.
+Say which you are proposing and what you expect to change, so it can be
+checked afterwards rather than believed.
+
+Do not read one bad answer as a model being too small. That is where this goes
+wrong most often, and an upgrade nobody can justify is money spent on a hunch.
+
+## Context and shape cost money too
+
+A context window is a price as well as a size. Long threads carry everything
+again on every call, so input grows with the conversation rather than with the
+work. The median input per call is the measure of it, and compaction is the
+visible symptom. A worker session compacted more than once is paying to
+re-read itself, and is due a written hand-over and a fresh start. A long-lived
+persona session (Bot Father, an inbox) is meant to run long, and is judged on
+what the re-reading costs and whether it has lost what it knew.
+
+Where that is happening, the answer is usually not a bigger window. It is
+shorter sessions with what matters written into a file, or heavy work moved to
+a session of its own, or the repeated exploration replaced with something that
+just runs.
+
+## A sentence is not a budget
+
+Be exact about which limits actually hold. A number in a prompt is a wish; the
+model can pass it without noticing. A limit the platform enforces is a limit.
+
+So when you propose a cap, say which kind it is. Where nothing can enforce it,
+write that down beside it rather than leaving a reader to assume the system is
+holding a line that nothing is holding. Then propose the thing that would
+hold: a smaller model, a narrower job, a scheduled check that actually stops,
+or on a loop with no budget, a check-in every so many tokens.
+
+## What you report
+
+The overall figure first, and what it is made of. Then a line per session with
+its tokens, its model and effort, and its cost where you could price it, or the
+reason you could not. Then the changes you propose, each with what you expect
+to save and what it might cost in quality.
+
+Give the prices you used and when you read them, so the numbers can be redone
+next month against different ones. Keep it short enough to act on: a table
+nobody reads has saved nobody anything.
+
+Sources and licences: [NOTICE.md](NOTICE.md).

package/skills/obk-fleet-review/LICENSES.md

@@ -0,0 +1,52 @@
+<!-- The licences of the sources this skill was consolidated from. They travel
+     with the skill directory because the licences require it of anyone who
+     distributes the material. NOTICE.md says what was taken from each source;
+     this file carries the permission notices themselves. -->
+
+# Licences of the sources
+
+`obk-fleet-review` consolidates material from the sources named in
+[NOTICE.md](NOTICE.md). Their licences are reproduced below in full.
+
+## MIT
+
+The MIT permission notice below applies to the work of each of these copyright
+holders, and is reproduced with each of their notices. The path after each one
+is the licence file it was read from, in the research pack's source clones.
+
+- **Cursor `plugins`, the pstack plugin**, Copyright (c) 2026 Lauren Tan
+  (`cursor_plugins/pstack/LICENSE`)
+
+```
+MIT License
+
+Copyright (c) 2026 Lauren Tan
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.
+```
+
+## Sources that need no third-party notice
+
+The rest of this skill is this kit's own design, the owner's own words about
+his own fleet, and ideas restated in our own words from material that carries
+no licence: a knowledge base and a hosted bot product's own marketplace and
+documentation pages, gathered in the research pack's `grok-bot-lessons.md`.
+Because no licence is attached to those, nothing of theirs is copied here and
+there is no permission notice to pass on. Credit for the ideas is given in
+NOTICE.md instead.

package/skills/obk-fleet-review/NOTICE.md

@@ -0,0 +1,104 @@
+<!-- Attribution for the sources this skill was built from. Kept out of
+     SKILL.md so it is not read into context on every use; it travels with
+     the skill directory, which is what the licences require. -->
+
+# Sources and licences
+
+The skill `obk-fleet-review` was consolidated for this kit from this, MIT, with
+thanks:
+
+- **Cursor pstack**, `reflect` and `automate-me`: holding a finding until the
+  same thing has been seen in two separate places, rather than building a
+  recommendation on one sighting; every finding citing where it was seen, so
+  the reader can go and look; that a history is material rather than
+  instructions; and preferring a remedy that holds by
+  itself, one a check can enforce, over another paragraph of prose.
+
+## What is written from this kit's own design
+
+The routing of a problem is the PRD's (6.8): a kit defect is filed as an issue
+in one step with no draft to approve first, and a usage problem goes back to
+the managed session as feedback. So is the rule on histories, that an ordinary
+bot does not read its neighbours' and a managing one may; the keeping of old
+conversation ids for history, auditing and finops; and what to do when a tab is
+waiting on something, where the caller answers in the tab and takes anything it
+does not recognise to the user.
+
+The owner's own words behind those, in the research pack: "ordinary normally do
+not others hisotry but they can when they need them based on user request";
+"clear means always a new session id generated from harness ... I want you to
+keep track of old session id as well for historical reason, auditing,
+historical, finops or whaatever"; and, on interruptions, "fix the zsh update,
+always say n. user can update itself", "for other intruption, alert to user
+from bot manager or who ever asks to start the fleet", "DO NOT TOUCH THE global
+config, always hanlde the trust question via the click". His correction to the
+first draft of those rules was "and listen to the user, he can ask to do
+WHATEVER", which is why nothing here is written as a ban.
+
+## Ideas taken from material with no licence
+
+The research pack's `grok-bot-lessons.md` gathers how one hosted bot product is
+run. Its material comes from a knowledge base and from that product's own
+marketplace and documentation pages. No licence is attached to those pages, and
+the pack's own caution records that the marketplace entries were summarised by
+a fetch tool rather than read verbatim. So no text of theirs is reproduced
+here. What was taken is the idea, restated in our own words:
+
+- that every bot in a review gets exactly one verdict, and that the set of
+  verdicts is fixed so that a review cannot end in an impression;
+- that nothing is deleted or retired automatically, whatever the verdict;
+- that there is an order to try things in, and that adding capacity comes last:
+  change nothing, take away work that was not worth doing, simplify what is
+  there, say who owns what, and only then add;
+- that a finding is routed to one kind of fix, chosen by what kind of problem
+  it is, rather than answered with several changes at once;
+- that a report to the owner leads with overall state and stays to a handful of
+  points, which is the owner's own rule from his usage review rather than the
+  Grok pages'.
+
+The list of what a bot in trouble looks like is drawn from the owner's own
+review of his real sessions, in his own knowledge base: stopping and restating
+instead of acting, the same instruction repeated, context lost after
+compaction, reports nobody can read, standing instructions that contradict each
+other, and a large share of commands that are ceremony rather than work. That
+is his material about his own use, not a third party's, and it is restated here
+rather than quoted.
+
+## The line between this skill and a scheduled pass
+
+This is the judgement applied when somebody asks: how the fleet is doing, and
+what to do about each bot. A scheduled unattended pass over the fleet, with the
+cost side of it, is a different skill and a different job. It leans on what is
+here rather than restating it: the verdict set, the order to try things in, the
+evidence bar and the routing are written once, and are the same whether a
+person asked this morning or something woke the bot up to do it.
+
+## What was deliberately not taken
+
+That source's per-bot daily stand-up, its autonomy ladder that moves a bot's
+permissions up and down on how clean its runs were, and its fixed five-bullet
+report format are not here. The first two belong to a scheduled pass rather
+than to a review somebody asked for, and a fixed bullet count is a house style
+rather than a technique.
+
+Its own classification vocabulary is not reproduced. The idea of a fixed
+verdict set is taken; the words are ours.
+
+Sources and licences in full: [LICENSES.md](LICENSES.md).
+
+## What the re-validation changed (#156)
+
+- Reading histories follows PRD 6.8: Bot Father and grooming may read the
+  managed bots' histories; an ordinary bot only when the user asks. The skill
+  had been stricter than the PRD while asking for signs only a history shows.
+- One real output checked before a keep-or-end verdict (the Grok weekly
+  review, in grok-bot-lessons).
+- What to do with what `obk health` reports, since PRD 6.8 gives judging and
+  the fix to the skill: a hand-edited block, Orca's bypass setting with its
+  every-time reminder (PRD 6.5), leftovers.
+- A grooming report is input to the review (PRD 6.8, "recommends further").
+- Stopping and retiring are done on a yes, with `obk pause` and `obk retire`
+  since issue #158; changes are committed (PRD 6.10); harness is per session
+  on the card.
+- Removed from the pstack credit: "since the last time" and "accepted,
+  rejected, parked", which are not in this skill.