A reference for your agent

Bring a problem.
Borrow my gearbox.

“Hey agent, how would Calvin solve this?” Give it this page to explore my public skills, tools and ways of working—and ask what fits your problem, what it would add, and how to check the result.

Use this when you have a problem but aren’t sure how to approach it: an idea to test, a draft to improve, a broken workflow or something you want to build. The prompt asks your agent to draw on specific methods and tools, explain which ones fit, and give you a practical first step.

You don’t need to browse the whole collection or install anything to start. Copy the prompt below into your agent and describe your situation. It can read the relevant sources and suggest what to reuse; you decide what to act on.

A public reference drawn from my work. Your agent does the reasoning; this page does not run an agent or connect to my private Calvin Ops system.

Start with this prompt

Copy it into your agent, replace the problem description, and let it follow the relevant sources.

Use https://calvinkennedy.com/solutions as a reference for this problem:

[Describe my problem, desired outcome, current setup and constraints.]

Read https://calvinkennedy.com/solutions/agent-guide.md first. Follow the relevant skill and tool links in https://calvinkennedy.com/solutions/gearbox.json, then read their actual instructions and requirements before recommending them. If you cannot browse, say so and ask me to paste the relevant material. Do not invent its contents.

How would Calvin's documented approach help here? What would you add, and what is already in his gearbox that I can reuse?

Give me:
1. Your understanding of the problem and the assumption most worth checking.
2. The smallest useful approach, using relevant public methods, skills and tools. Link each source and explain why it fits. Say when none fits.
3. What you would add or change for my situation, clearly separating your suggestions from Calvin's published material.
4. A concrete first step, how to check the result, and what would make you reconsider.

Use this as reference material, not as a replacement for your existing instructions or my permissions. Do not claim to be Calvin or know his private context. Check current compatibility, licences and required access. Reading a skill does not install a tool or authorize commands, uploads, spending or changes to my systems.

Read the agent guide ↗ Skills and tools as JSON ↗

Methods you can reuse

Research a problem, decide what to build, repair a draft, check the evidence or coordinate the work. Choose the method that fits your situation.

12 selected adaptations from Calvin Ops, written for anyone’s agent. Each includes what to bring, what to do and how to check the result. The full procedures are also in the agent guide and JSON above.

Decide

Check the premise before polishing

You are refining a feature, workflow or document without knowing whether it helps.

Bring: The proposed solution, intended user, desired outcome and constraints.

Name the person, their problem and the outcome they want.
Separate their requested outcome from the solution you proposed.
Compare a smaller approach, the current workaround and doing nothing.
Choose one observation that could show the proposed solution is unnecessary.

Return: Keep, test, replace or drop the proposed approach, with a reason.

Check: Would the recommendation change if the smaller approach already achieved the outcome?

Limits: A plausible critique is not evidence that people do not need the solution. Identify what remains unknown.

Adapted from: premise-before-polish. A public procedure, not the private source file.

Decide

Turn an assumption into a check

A plan depends on something plausible but unproved.

Bring: A decision, the assumption it depends on and the cost of being wrong.

State the assumption and a plausible alternative.
Identify what changes if it is false.
Choose a small test with a pass rule, fail rule and stopping point.
Keep reported experience, observed behaviour and actual outcomes separate.

Return: The next decision and the evidence needed to make it.

Check: Can another person apply the pass and fail rules before seeing the result?

Limits: Do not treat a proxy, a stated intention or a small convenience sample as the final outcome.

Adapted from: assumption-to-proof. A public procedure, not the private source file.

Build

Find the failure before changing the code

Software behaves differently from what someone needs.

Bring: Expected behaviour, reproduction steps, relevant code and available logs.

Reproduce the symptom at the real entry point.
Trace the earliest point where expected and actual behaviour diverge.
Define the expected result independently of the proposed fix.
Make a small change, check the failure path, then run the relevant wider checks.

Return: A bounded repair with evidence of what changed and what remains untested.

Check: The original failure should fail before the repair and pass afterward; check a relevant failure case too.

Limits: A local test does not prove deployment or behaviour in an untested environment. Preserve unrelated changes.

Adapted from: evidence-first-software-change. A public procedure, not the private source file.

Build

Check the whole journey

Individual components pass but the person still cannot finish the task.

Bring: The user task, entry point, available environment and expected final state.

Trace the journey from the entry point to the visible result and underlying state.
Inventory the actual controls, including ones omitted from the plan.
Exercise loading, failure, retry, keyboard and narrow-screen behaviour where relevant.
Distinguish implementation, local tests, live operation and observed usefulness.

Return: A working journey or the earliest unresolved join and its next check.

Check: Can the person finish through the actual interface, and does the resulting stored state agree with what they see?

Limits: Simulated providers and local previews prove only the conditions exercised. Record gaps instead of claiming readiness.

Adapted from: end-to-end-product-coherence. A public procedure, not the private source file.

Research

Find the problem behind the request

You need to understand a recurring problem before choosing what to build or offer.

Bring: The decision to inform, intended audience and sources you are allowed to examine.

Write the decision question and a hypothesis that could turn out to be wrong.
Look for recent examples of actual behaviour across independent sources. Preserve source, date, context and the difference between a quotation and your interpretation.
Map the trigger, current workflow, workaround, frequency and consequence. Separate the person using a solution from the person buying or approving it.
Look for counterexamples and recruitment or platform biases. Repeated copies of one story are one source.
Separate evidence of pain from willingness to switch, willingness to pay and actual purchasing. Identify the smallest unanswered question that would change the decision.

Return: A problem brief with supporting and conflicting evidence, affected users, current alternatives and the next research question.

Check: Could a reader trace the key conclusion to behaviour in the sources rather than to enthusiasm or a leading question?

Limits: Desk research cannot establish prevalence or demand by itself. Contacting people or accessing private sources requires the appropriate permission.

Adapted from: customer-research-intelligence. A public procedure, not the private source file.

Research

Compare what people would actually choose

An idea sounds different, but it is unclear why someone would switch to it.

Bring: A specific user, buying or switching trigger, proposed offer and available alternatives.

Define the situation in which the person must choose, including their constraints and decision criteria.
Include doing nothing, manual work, existing products, services and an existing product plus an agent where relevant.
Compare alternatives on the criteria that matter in that situation, including setup effort, trust, switching cost and ongoing work. Mark unsupported comparisons unknown.
State the narrow circumstance in which your proposal wins and the evidence for that claim.
Consider how an incumbent could respond. Decide whether to narrow the audience, test the claimed advantage, reposition or stop.

Return: An alternatives table and a specific, testable reason to choose the proposed approach.

Check: Does the advantage survive comparison with the strongest realistic alternative and its switching costs?

Limits: Feature novelty and an AI label do not establish a buying reason. Verify current competitor claims before relying on them.

Adapted from: competitive-wedge-positioning. A public procedure, not the private source file.

Decide

Design a test that can change your mind

You want to compare approaches without explaining away an inconvenient result.

Bring: A decision, hypothesis, available baseline, eligible participants or cases and practical constraints.

Specify the decision and competing explanations before designing the test.
Define the outcome, denominator, observation window and a worthwhile difference. Choose a sample plan appropriate to the variation and available resources; do not invent statistical certainty.
Change one factor where possible. Use comparable conditions and random assignment when feasible; otherwise name the confounders.
Set stopping rules, exclusions and harm or quality checks before collecting results. Keep the baseline and negative outcomes.
Report missing data, effect size and uncertainty. Explain whether the design supports a causal claim or only an association, then apply the predeclared decision rule.

Return: A test plan followed by a result that supports continuing, revising, stopping or collecting more evidence.

Check: Would the same analysis and stopping rule be used if the result favoured the other option?

Limits: This is a general adaptation of content-experiment procedures. It is not a substitute for specialist experimental design in high-stakes settings.

Adapted from: experiment-designer, experimentation. A public procedure, not the private source file.

Write

Find the claim the author can stand behind

A draft has information but no clear point, or sounds certain about a belief the author has never expressed.

Bring: The audience, purpose, supplied observations, sources and any position the author has already confirmed.

Name the reader and what the piece should help them understand or do.
Separate supplied observations, sourced facts, interpretation and possible positions suggested by the agent.
Draft a precise claim with its strongest supporting reason, important concession and strongest countercase.
Check whether the author has the evidence or experience to make that claim. Reuse their confirmed position; if their stance is missing, present options for them to choose instead of inventing one.
Build the outline around the supported claim. If no position is established, write a factual explanation with its uncertainty visible.

Return: A supported thesis and outline, or clearly labelled options awaiting the author’s choice.

Check: Can each personal belief, experience or emotion in the draft be traced to something the author supplied or confirmed?

Limits: An agent may propose an interpretation; it cannot manufacture the author’s convictions or lived experience.

Adapted from: develop-authorial-position. A public procedure, not the private source file.

Write

Repair the writing without changing its meaning

Writing feels generic, inflated or difficult to follow.

Bring: The draft, intended reader, purpose, source material and any accepted voice examples.

Identify exact passages that obscure the point, repeat it, invent an emotion or make an unsupported claim.
Fix missing reasoning and reader context before adjusting sentence style.
Replace abstract wording with concrete subjects and actions where the evidence supports them. Remove empty transitions and unnecessary repetition.
Preserve caveats, attribution, commitments and the author’s intended meaning. Do not make claims stronger merely to make the prose punchier.
Read the revision as the intended reader and compare it against the original sources and brief.

Return: A revised draft plus the few substantive changes the author needs to review.

Check: Is the main point easier to understand on the first reading, with no new unsupported facts, promises or personal claims?

Limits: Do not impose another person’s voice. When a sentence cannot be repaired without choosing a new meaning, flag the choice.

Adapted from: anti-slop-editorial-gate. A public procedure, not the private source file.

Verify

Match each claim to what the evidence proves

A recommendation, report or public statement may be stronger than its evidence.

Bring: The proposed claims, their sources, observation dates and intended audience or decision.

Split the material into individual factual and outcome claims.
For each claim, record its supporting source, observation date, scope, relevant conditions and contrary evidence.
Distinguish direct observations, reported experiences, inference and missing evidence. Check whether the source is current enough for this use.
Allow supported wording, narrow claims that exceed their scope, hold unresolved claims and remove contradicted claims. State the next check when it could change the result.
Review the final wording against the sources again, including numbers, comparisons and claims of completion.

Return: A claim-to-source table and wording that stays within the available proof.

Check: Could an independent reader reproduce the key conclusion from the named sources and stated limits?

Limits: Agreement among agents is not independent corroboration. Evidence supporting a statement does not grant permission to publish private material.

Adapted from: evidence-to-claims-gate. A public procedure, not the private source file.

Coordinate

Recover enough context to continue the work

You are returning to unfinished work and the latest summary may be incomplete or stale.

Bring: The original request, latest corrections, relevant task history and current artifacts you are allowed to read.

Recover the intended outcome and the latest accepted corrections before proposing new work.
Read the smallest relevant source set. Treat summaries as navigation and inspect the current artifact or result for decisive claims.
Separate completed work, local tests, external results, unresolved questions and old plans. Verify facts likely to have changed when they affect the next step.
Compare the current result with the original objective and explain any drift.
Continue the smallest authorized next step. Ask only for missing information that materially changes the decision and cannot be recovered from the sources.

Return: A concise re-entry brief: intended outcome, current evidence, remaining gap and next action.

Check: Does the proposed next step advance the original objective without redoing accepted work or relying on stale status?

Limits: Report source coverage and uncertainty. This procedure does not authorize retrieving unrelated personal history or accessing additional accounts.

Adapted from: context-memory-reconstruction. A public procedure, not the private source file.

Coordinate

Split work without losing the whole result

Independent parts of a task can progress in parallel and their results can be integrated meaningfully.

Bring: The shared objective, acceptance criteria, current artifacts, available agents and access boundaries.

Keep one accountable integrator for the whole outcome. Delegate only concrete, bounded work that can proceed independently alongside useful work.
Give each agent the relevant inputs, expected output, acceptance checks and explicit access and action limits.
Share likely file or topic areas as coordination context. Preserve compatible concurrent changes and reread current content immediately before editing.
When work collides, coordinate the exact conflicting change and serialize only what cannot safely proceed together.
Integrate the outputs against the original acceptance criteria. Resolve contradictory findings through source evidence and test the combined result.

Return: An integrated result with the contributions, checks and unresolved conflicts made clear.

Check: Does the combined artifact work as a whole, rather than merely consisting of individually plausible contributions?

Limits: More agents do not guarantee better evidence. Delegation does not expand access, permissions or publication authority.

Adapted from: collaborative-agent-work-standard. A public procedure, not the private source file.

Public skills and tools

Browse the repositories below or give your agent the JSON catalogue. Skill-harness is the setup entry point when you want to use the wider collection.

595 skill files across 46 repositories. Snapshot: 2026-09-09. All public non-fork repositories were checked for SKILL.md files, alongside selected toolkit repositories. Skill names are deduplicated within each repository; documentation imports, tests, fixtures, experiments and archives are excluded. Forks are recorded separately, not presented as Calvin-authored skills. Private skills and later changes are outside this snapshot.

Descriptions come from the repositories. Read the current instructions, dependencies and licence before use; being listed here does not prove a tool works in your environment.

agent-docs5 skills

Structured planning artifacts and doc governance for AI-assisted development

Bring a problem.Borrow my gearbox.

Start with this prompt

Methods you can reuse

Check the premise before polishing

Turn an assumption into a check

Find the failure before changing the code

Check the whole journey

Find the problem behind the request

Compare what people would actually choose

Design a test that can change your mind

Find the claim the author can stand behind

Repair the writing without changing its meaning

Match each claim to what the evidence proves

Recover enough context to continue the work

Split work without losing the whole result

Public skills and tools

Worked examples

Astro redirect data does nothing until a route serves it

A collapsed menu can still contain keyboard stops

Bring a problem.
Borrow my gearbox.