Personal Productivity
YouTube ... Quora ...Google search ...Google News ...Bing News
- Agents/Assistants ... Robotic Process Automation ... Personal Companions ... Productivity ... Email ... Negotiation ... LangChain
- Immersive Reality ... Metaverse ... Omniverse ... Transhumanism ... Religion
- Simulation ... Simulated Environment Learning ... World Models ... Minecraft: Voyager
- Case Studies
- Development ... Notebooks ... AI Pair Programming ... Codeless ... Hugging Face ... AIOps/MLOps ... AIaaS/MLaaS
- 16 AI Tools to Speed Up Your Work | Prathamesh Ingle, MarkTechPost, 2023 Historical tool overview; product details may have changed.
- The Best AI Productivity Tools | Zapier The earlier page cited the 2023 survey; this maintained URL may now describe a different selection.
Personal productivity with AI means handing parts of your own work to AI systems so you finish faster, make fewer mistakes, or take on work you could not do alone. The work itself is ordinary: research, writing, analysis, coding, scheduling, and the small administrative jobs that fill a week. What has changed is how you hand it over.
Between 2023 and 2026 the tools moved through three stages:
- Chat assistants. You type a request, read the answer, and start over next time. The quality of the result depends on how well you happen to phrase the request that day.
- Reusable prompt libraries. You capture your best instructions once and reuse them. This page's Personal Acton Library is an example: 7 agents-type structure and 66 actions stored in a Chrome extension called QFill.
- Agent environments. The same instructions run inside a runtime that gives the AI tools, files, memory, sandboxes, and the ability to delegate to other agents. Claude Code, Claude Managed Agents, the OpenAI Agents SDK and Agents API, Gemini CLI, and Google's Agent Development Kit (ADK) all fall into this stage.
The main builders of these environments are Anthropic, OpenAI, and Google. Since December 2025, several of the formats they use have become shared standards: Anthropic published Agent Skills (the SKILL.md folder format) as an open specification, and the Linux Foundation formed the Agentic AI Foundation to steward the Model Context Protocol (MCP), the AGENTS.md instruction-file format, and Block's goose agent. Meanwhile, researchers at METR, Stanford, MIT, Harvard Business School, the University of Chicago, Banking the Federal Reserve Bank of St. Louis, and Anthropic's own economic research team have started measuring how much time AI actually saves.
This page addresses a practical question: how do you organize AI instructions so they stay reusable, consistent, and easy to improve, and then move them into an agent environment without starting over? The answer it develops is to separate who does the work (an agent) from what work gets done (an action), keep shared rules in one place, pair every creative step with a verification step, and treat the library as software with names, versions, tests, and usage data.
That approach differs from earlier automation in two ways. Unlike Robotic Process Automation, which replays fixed clicks and keystrokes, an agent interprets a goal and decides its own steps, so it handles variation but needs guardrails and review. Unlike ad hoc prompting, a library makes instructions durable: you improve an action once and every future use benefits. Anthropic's engineers describe the broader shift as moving from prompt engineering to context engineering: deciding what instructions, information, and tools the model sees at each step.
Scope and source authority. The catalog below describes the supplied October 11, 2026 default data snapshot. It does not establish which defaults are installed today, whether a shortcut was successfully executed, or whether the extension automatically connects to an agent runtime. Exact identifiers and group assignments come from defaultData.js; runtime examples are proposed implementations requiring separate configuration and testing.
How AI Supports Personal Productivity
AI can significantly enhance personal productivity by automating tasks, providing intelligent insights, and streamlining decision-making processes. Here are the main ways it helps, updated for current tools:
- Task Automation: AI can automate repetitive and time-consuming tasks, freeing up valuable time for users to focus on more important and creative activities. For instance, AI-powered virtual assistants can schedule meetings, manage emails, set reminders, and perform other administrative tasks, reducing the burden on the user. Current agents go further: they can operate a browser or desktop apps, call connected services, and run scheduled tasks while you are away. Anything with consequences (sending, paying, deleting, publishing) still deserves an approval step.
- Smart Scheduling: AI can analyze your calendar, preferences, and other relevant data to suggest the most optimal times for meetings and appointments. This minimizes scheduling conflicts and ensures you can allocate your time effectively.
- Personalized Recommendations: AI algorithms can analyze your habits, preferences, and past behavior to offer personalized recommendations. For example, in email applications, AI can prioritize important emails or categorize messages based on their relevance, saving you time sorting through your inbox.
- Knowledge Management: AI-powered tools can help you organize and access information more effectively. From intelligent note-taking apps that categorize and search your notes to content curation tools that deliver relevant articles based on your interests, AI enhances knowledge management. Connectors, often built on MCP, now let an assistant search your own documents, tickets, and messages instead of relying on whatever you paste in.
- Workflow Optimization: AI can optimize workflows by identifying bottlenecks, suggesting process improvements, and automating repetitive steps. This streamlines operations and improves overall efficiency. A prompt library adds a second layer: chained actions, such as audit, then merge, then verify, then hand off, turn a recurring multi-step job into a repeatable recipe.
- Personalized Learning: AI-driven educational platforms can adapt to your learning pace, identify your strengths and weaknesses, and provide personalized learning paths, helping you acquire new skills efficiently.
- Document and Information Management: AI can assist in document management by categorizing files, extracting relevant information, and even summarizing lengthy texts, making it easier to access and process information. In the Personal Action Library, these jobs map to specific actions such as Extract Data (
/e.extract) and Summarize to Main Points (/a.summarize). - Coding and Technical Work: AI pair programming tools write, explain, test, and review code. This is where the evidence is most contested: controlled studies have found both large speedups and, for experienced developers in familiar codebases, slowdowns (see Productivity Research).
An agent is a durable professional identity. An action is something that professional can be asked to do.
The Mechanism
A request moves through the same six steps whether you run it by hand from a prompt library or let a runtime do it for you:
- Classify the request. Decide what kind of job it is: understand something, judge something, produce paste-ready text, plan, or write code. In the QFill library, the
in:andout:tags on each action provide useful routing hints. They do not grant capabilities or fully describe every requirement in the prompt body. - Select an agent and an action. You pick them yourself with a shortcut such as
/e.merge, or a router chooses them. In a runtime, routing happens when the model reads each agent's and skill's description and matches it to the request. - Assemble the context. The model receives the agent definition (identity, standards), the action instructions (procedure, output format), shared house rules (style, link rules), and the task-specific input (your notes, page, code, or files).
- Generate or act. In a prompt library the model writes a response. In an agent environment it can also call tools: search the web, read and write files, run tests, or call a wiki API through MCP.
- Verify. A second action checks the first: a Retention Audit after a merge, a Regression Audit after an implementation, a red-team pass after an analysis. In a runtime this can be a fresh-context subagent or an automated loop.
- Persist state. Decisions, open questions, and finished artifacts are written somewhere durable (a handoff report, a decisions file, a published artifact) so the next session starts where this one stopped.
The major components are the agent (who), the action or skill (what and how), the tools (what the agent can actually do), the state (files, session history, memory), and the router (the Workflow Processor, a root manager agent, or a deterministic pipeline). Each step depends on the one before it: routing is only as good as the descriptions, actions are only as good as the context they receive, and verification is only as good as the reviewer's independence from the author.
Uncertainty remains in three places. Routing by description can misfire, and no public benchmark measures it for personal libraries. Instructions tuned for one model do not always transfer cleanly to another or to a newer version of the same model. And the evidence that all of this saves time overall, rather than task by task, is still mixed.
Measuring Productivity
A useful evaluation can compare the time needed for an acceptable final result:
Net time saved = baseline completion time
- (AI interaction + verification + rework time)
Also record factual accuracy, defect rate, information retention, user satisfaction, and cost. Fast first drafts are not necessarily fast finished work. Measure performance on the actual task family rather than extrapolating from a demonstration.
Why This Matters
The evidence now supports a careful conclusion: AI can save a great deal of time on the right tasks, the savings shrink when you look at whole jobs, and experienced people working on familiar, complex material sometimes see no gain at all. A well-organized library helps on all three fronts. It concentrates AI use on tasks it does well, it bakes verification into the routine, and it makes your instructions an asset you can improve rather than something you retype.
| Study | Setting and method | Main result | What it does not establish |
|---|---|---|---|
| Brynjolfsson, Li, and Raymond, Generative AI at Work (2023 working-paper estimates; later published in Quarterly Journal of Economics) | 5,179 customer-support agents at one firm; staggered rollout of an AI assistant | 14 percent more issues resolved per hour on average, 34 percent for novice workers, little gain for the most experienced | Effects in other occupations or with more capable agents |
| Dell'Acqua and colleagues, Navigating the Jagged Technological Frontier (2023 working paper; Organization Science, 2026) | Randomized experiment with 758 consultants using GPT-4 | On tasks inside the AI's capability: 12.2 percent more tasks, 25.1 percent faster, over 40 percent higher quality. On a task outside it: 19 percentage points less likely to be correct | How the frontier moves with newer models |
| METR (July 2025) | Randomized trial: 16 experienced open-source developers, 246 tasks in their own mature repositories, early-2025 tools | 19 percent slower with AI allowed, even though developers expected a 24 percent speedup and afterward believed they had been 20 percent faster | Results for less experienced developers, unfamiliar codebases, or later tools |
| Bick, Blandin, and Deming (Federal Reserve Bank of St. Louis, February 2025) | Nationally representative U.S. survey | Users reported saving 5.4 percent of their work hours; about 1.4 percent across all workers | Self-reported time, not measured output |
| Humlum and Vestergaard, Large Language Models, Small Labor Market Effects (NBER 2025) | About 25,000 Danish workers in 7,000 workplaces; surveys linked to administrative records, 2023 to 2024 | Average time savings of 2.8 percent of work hours; no detectable effect on earnings or hours | Effects of later, more agentic tools |
| Anthropic, Estimating AI productivity gains from Claude conversations (November 2025) | 100,000 sampled conversations; Claude estimated each task's duration with and without AI | About 80 percent time reduction per task; implies roughly 1.8 percent added annual U.S. labor productivity growth over a decade if adoption is broad | Measured outcomes; time spent checking and fixing AI output outside the conversation |
The engineering implications follow directly:
- Your instructions are an asset. Once actions live in plain files with open formats, the same library can run in Claude, OpenAI, or Gemini tools. The vendor lock-in risk is real: OpenAI scheduled its no-code Agent Builder to shut down after November 30, 2026, about a year after launch.
- Personal productivity becomes a software problem. Names, versions, shared modules, regression tests, usage telemetry, and code review all apply to a prompt library.
- Verification is not optional. The METR perception gap (developers felt faster while measuring slower) and the BCG "outside the frontier" error increase both say the same thing: build checks into the workflow rather than trusting how fast the work feels.
What remains uncertain: whether task-level savings add up to measurable gains in output and pay, how to measure quality rather than speed, whether heavy reliance erodes the skills needed to catch AI mistakes, and how well a library tuned on one model survives the next model release.
Personal Action Library
A Personal Action Library is a collection of reusable AI prompts organized around a small team of agent specialists. Instead of writing a new prompt from scratch every time you need help, you call on a specialist you have already defined and tell it which job to do. This page explains how to structure the library, describes each specialist and the jobs it performs, and offers guidelines for growing the library over time.
The library now lives in QFill, a Manifest V3 Chrome extension. Its default data package defines 7 agents and 66 actions, each reachable through a short slash shortcut. Later sections show how to move the same catalog into the Claude, OpenAI, and Gemini agent environments.
Roles & Actions
This Agent- Action structure is a step towards the utilization of agents later.
The Core Idea
A useful way to organize reusable AI prompts is to separate two things that people often blend together:
- The Agent (specialist) role defines who does the work.
- The Action defines what work gets done.
The Agent defines a stable professional identity. It captures the specialist's expertise, reasoning style, quality standards, and general area of responsibility. These qualities rarely change.
The Action defines the specific task the agent performs right now. Actions are narrower, more concrete, and more numerous than agents.
This separation creates a cleaner and more reusable hierarchy than treating every individual prompt as its own separate agent. QFill names the result a two-tier library: agents form the first tier, and action templates form the second.
An Analogy: Hiring a Professional
Imagine you hire an accountant. You explain your expectations once: be accurate, cite the relevant rules, and flag anything that looks risky. After that, you can ask the same accountant to prepare your taxes, reconcile your accounts, or review the payment terms in a contract. You do not hire and onboard a brand-new accountant for each job.
Prompts work the same way. The agent is the professional you hired. The actions are the jobs you hand them.
The Problem This Solves
Without this separation, prompt libraries tend to sprawl. Each task gets its own standalone prompt, and each prompt restates the same identity, expertise, and rules. Over time, this causes three problems:
- Duplication: The same instructions appear in dozens of places.
- Drift: When you improve one prompt, the others fall out of sync.
- Confusion: Similar prompts overlap, and you can no longer tell which one to use.
Separating agents from actions reduces these problems when the application actually composes the shared instructions with each action. In the supplied QFill file, agent records provide organization and descriptions, while action bodies often supply their own personas. The data alone does not establish automatic instruction inheritance.
The fix only works for the material you actually move into the shared layer. The QFill library separates agents cleanly, but its house rules (style, citation, link, and output-format rules) still repeat inside many action bodies, because this data file does not define a shared-rule import or composition mechanism. Whether the full extension implements one requires inspection of its application code. Shared Rules Across Actions lists them, and the agent environment sections show where they belong once the library runs in a runtime.
Prompt Structure
A practical structure has four layers:
Agent (specialist) - Role (responsibility)
→ Actions
→ Task-specific input
→ Output requirements
Each layer answers a different question and changes at a different rate:
| Layer | Question it answers | How often it changes | Example | Where it lives in QFill |
|---|---|---|---|---|
| Agent (specialist) | Who does this work, and how do they think? | Rarely | Editor (internal ID technical-editor)
|
Agent record: id, name, description, color, and icon
|
| Role (responsibility) | What does this specialist own? | Rarely | Paste-ready text: drafts, rewrites, proofreading, tone, format conversion, merging, and pages | The agent's description field
|
| Action | Which specific task should the agent perform? | Occasionally, when you add new actions | Expand source content (/e.expand)
|
Action record: shortcut, action, description, tags, and the procedure in body
|
| Task-specific input | What material does the agent work on this time? | Every request | Rough notes about a new feature | Bracketed placeholders at the end of the body, such as [PASTE SOURCE TEXT HERE]
|
| Output requirements | What should the result look like? | Often | Use headings and bullet points; avoid em dashes | Inside the body (output sections and quality checks), or typed into your request |
Agent environments add a fifth layer that a prompt library cannot provide: tools, the executable capabilities (search, file access, a shell, a wiki API) that let an agent act instead of only advising. The OpenAI Agent Environment section develops that layer in detail.
Worked Example
Consider this request:
Act as a Technical Editor. Take the provided brief notes or outline and expand them into comprehensive, clear documentation. Add necessary context, examples, and analogies. Use professional, conversational English and prioritize active voice. Organize the text with clear headings and bullet points. Do not use em dashes.
Here is how that request breaks down into layers:
- Agent: Technical Editor (now displayed as Editor)
- Role: Updates and improves structured technical content
- Action: Expand Content (now Expand source content, shortcut
/e.expand) - Task-specific input: The brief notes or outline
- Output requirements: Professional, conversational English; active voice; clear headings and bullet points; no em dashes
The same Editor could handle a completely different job, such as Reorganize Content (/e.org), if you simply swap the action. The identity and standards stay the same.
The current /e.expand action shows how far a one-paragraph request can grow once it becomes a maintained action. It now carries 14 expansion rules (preserve meaning, expand without inflating, mark illustrative examples as illustrative, explain terms on first use, flag only meaningful gaps), a MediaWiki output rule, and a 14-point final quality check.
Deciding What Goes Where
Use this rule of thumb when you write a new instruction:
- Put it in the agent definition if it should apply to every task that agent performs.
- Put it in the action definition if it applies only to that type of task.
- Put it in the output requirements if it applies only to this one request.
- Put it in a shared house rule if it applies to every agent. In an agent environment that means the workspace instruction file (
CLAUDE.md,AGENTS.md, orGEMINI.md). In this QFill snapshot, keep repeated wording identical until a shared-rule composition mechanism is implemented and verified.
An example agent definition:
You are a Technical Editor. You improve structured technical content so that it is accurate, clear, and easy to navigate. You preserve the author's intent, keep terminology consistent, and flag any claim you cannot verify.
An example action definition:
Action: Expand Content. Turn the provided notes or outline into complete documentation. Add context, examples, and analogies wherever a point would otherwise be hard to follow. Do not invent facts the notes do not support.
Verified QFill Package Snapshot
| Source field | Supplied value or interpretation |
|---|---|
| Source | defaultData.js, QFill Default Two-Tier Agents and Action Templates, Baked Delivery Package, Manifest V3
|
| Generated | 2026-10-11 17:28:55.550 UTC (as stated in the file header) |
| DELIVERY_VERSION | 1791739735446
|
| DEFAULT_SORT_BY | shortcut
|
| Agent groups | 7 |
| Action templates | 66 |
| Action organization | Each DEFAULT_SNIPPETS record is assigned by agentId to a DEFAULT_AGENTS record
|
| Provided data | Agent IDs, names, descriptions, presentation fields, action IDs, shortcuts, descriptions, tags, bodies, and selected activity metadata |
| Not established by this file | Chrome UI behavior, clipboard insertion, external tool access, automatic routing, API credentials, remote execution, syncing, or deployment status |
The JavaScript exposes the arrays as DEFAULT_AGENTS and DEFAULT_SNIPPETS. A source change should preserve existing IDs and shortcuts unless there is a deliberate migration and compatibility plan.
Agent Catalog
The table below lists every agent in the current library, what it owns, how many actions it holds, and the situations that call for it. The internal IDs come from the original catalog and stayed fixed when the display names were shortened, so saved data and integrations keep working.
| Agent (specialist) | Internal ID | Shortcut prefix | Role (responsibility) | Actions | Call on it when... |
|---|---|---|---|---|---|
| Analyst | research-analyst
|
/a.
|
Understands and judges material: explanations, summaries, comparisons, fact checks, research briefs, and audits | 18 | You need to know what something means, or whether it is accurate, current, complete, relevant, or sound |
| Developer | software-engineer
|
/d.
|
Working code and technical checks: features, fixes, refactors, tests, code reviews, and specification audits | 14 | You need code written, fixed, explained, tested, reviewed, or deliberately broken |
| Editor | technical-editor
|
/e.
|
Paste-ready text: drafts, rewrites, proofreading, tone, format conversion, merging, and MediaWiki pages | 19 | You need finished text, or several sources turned into one document |
| Strategist | solution-architect
|
/s.
|
Plans and decisions: plans, ideas, alternatives, decisions, priorities, risks, and conversation continuity | 14 | You need to decide, plan, prioritize, or carry work into a new session |
| Team Manager | tm
|
/t.
|
Fantasy sports (ESPN): NFL and MLB player research with valuation reports and roster recommendations | 2 | You are making a roster decision |
| Queue | queue
|
/q.
|
Quick-add holding area for unassigned or pending actions; move them to the proper agent anytime | 2 | You want to save a prompt now and file it later |
| Workflow Processor | orchestrator
|
/w.
|
Routing: classifies a request and sequences the agents and shortcuts to run, without doing the work | 1 | A request is complex enough to need more than one agent or action |
Five agents do substantive work. The Queue and the Workflow Processor (shown in italics) are support roles: one holds actions that have no home yet, and the other plans the order of work without performing it.
Agent and Action Hierarchy
The seven groups below contain all 66 actions. The directory preserves exact stored labels and descriptions, including source spelling errors. The later profiles explain procedures and limitations in more detail.
Complete Action Shortcut Directory
Analyst shortcuts (18 actions)
| Shortcut | Action (exact stored label) | Stored description |
|---|---|---|
/a.brief
|
Brief Research | Researches a topic using current sources. Returns overview, current state, key players, evidence, open questions, and sources. |
/a.challenge
|
Challenge Identificaiton | Frames the problem behind a situation or material. Returns the core challenge, why it is hard, root cause, stakes, and done state. |
/a.compare
|
Compare Items | Compares named concepts, tools, or options. Returns a side-by-side table and when to choose each. |
/a.consolidate
|
Consolidate Source Materials | Consolidates fragmented rules, patches, and addendums into a single master technical specification. |
/a.decision
|
Decision Rationale | Documents hard decisions made, rationales, and future restrictions. |
/a.explain
|
Explain Simply | Explains a concept or term. Returns definition, how it works, why it matters, an example, and misconceptions. |
/a.factcheck
|
Fact Check | Checks the factual claims in material against current sources. Returns a verdict, evidence, and correction for each claim. |
/a.gamecasestudy
|
Game Case Study | Provide Mediawiki case study. ... put GAME_NAME = ______ |
/a.gap
|
Gap Analysis | Audits material for what is missing. Returns missing context, unsupported leaps, and two or three research next steps. |
/a.interpret
|
Interpret This | Reads a chart, table, screenshot, diagram, or excerpt. Returns what it shows, what it means, and what to watch for. |
/a.proscons
|
Pros and Cons | Weighs one idea or option. Returns ranked pros and cons, hidden factors, deal-breakers, and a bottom-line verdict. |
/a.questions
|
Questions to Ask | Surfaces what to ask about a topic or situation. Returns foundational, critical, and often-missed questions, and who to ask. |
/a.redteam
|
Red-Team Analysis | Answers a research question from pasted context and stress-tests the answer. Returns core analysis, challenges to it, and remaining gaps. |
/a.regress
|
Regression Audit | Compares original requirements against updated code or document for accidental omissions. |
/a.relevance
|
Relevance Evaluation | Audits material against your core objective. Returns high-signal points, noise to cut, and a relevance verdict. |
/a.summarize
|
Summarize to Main Points | Condenses material without adding anything. Returns bottom line, key points, exact details, and implications. |
/a.synthesize
|
Synthesize Collective View | Combines what two or more sources say into one account. Returns a bottom line, shared points, key divergences, and confidence. |
/a.update
|
Update with New Information | Evaluates submitted material for currentness, accuracy, completeness, and missing developments. |
Developer shortcuts (14 actions)
| Shortcut | Action (exact stored label) | Stored description |
|---|---|---|
/d.advtest
|
Adversarial Testing | Reviews logic, code, or specification strictly looking for ways to break it and exploits weaknesses. |
/d.assemble
|
Assemble Code | Collects the final code from this conversation, applying every agreed patch. Returns complete files and a list of what was applied. |
/d.bookmarklet
|
Bookmarklet Update | Adds a feature to a bookmarklet or vanilla JS script with zero regressions. Returns clean source and a minified bookmarklet. |
/d.bug
|
Bug Fix | Diagnoses a bug from code and an error description. Returns the root cause, a short explanation, and the complete corrected code. |
/d.doc
|
Document Code | Documents code without changing behavior. Returns fully commented code and a short README section. |
/d.error
|
Error Explanation | Interprets an error message, stack trace, or log. Returns plain meaning, ranked causes, quick checks, and a fix. |
/d.feature
|
Feature Implementation | Writes complete, working feature code adhering to best practices and performance. |
/d.gap
|
Specification Gap Analysis | Runs a phased adversarial audit on a specification. Returns failures, root causes, remedies, and an updated consolidated specification. |
/d.howdoi
|
How Do I | Answers a how-do-I coding question. Returns the standard approach, a short working example, and one gotcha. |
/d.plan
|
Plan Implementation | Plans a code change before any code is written. Returns scope, approach, changes by file, steps, risks, a test plan, and open questions. |
/d.refactor
|
Refactor | Refactors code to improve readability, performance, and maintainability without breaking behavior. |
/d.regress
|
Regression Audit | Compares original requirements against an updated version. Returns a pass or fail list and anything dropped or weakened. |
/d.review
|
Code Review | Reviews code without rewriting it. Returns findings grouped by severity and a ship verdict. |
/d.tests
|
Write Tests | Writes tests for code. Returns a complete test file covering behavior, edge cases, invalid input, and errors. |
Editor shortcuts (19 actions)
Queue shortcuts (2 actions)
| Shortcut | Action (exact stored label) | Stored description |
|---|---|---|
/q.imagenew
|
Image New Creation | TBD |
/q.scope
|
Scope updates to AI Studio and Chrome Ext | TBD |
Strategist shortcuts (14 actions)
| Shortcut | Action (exact stored label) | Stored description |
|---|---|---|
/s.brainstorm
|
Brainstorm | Generates ideas for a topic or problem. Returns twelve distinct ideas labeled Safe, Stretch, or Bold, and the top three picks. |
/s.clarify
|
Clarify Requirements | Eliminates ambiguity by identifying 3 to 5 critical vague areas and forcing decisions. |
/s.conversation
|
Conversation Review | Checks this conversation for errors, weak assumptions, and drift. Returns a goal check, issues found, missed angles, and a verdict. |
/s.decide
|
Decide Between Optiions | Weighs the options you list. Returns weighted criteria, a scored decision matrix, reversibility notes, and a pick. |
/s.explore
|
Explore Alternatives | Outlines 3 distinct alternative solutions with architecture, pros, and cons/risks. |
/s.handoff
|
Handoff Transfer | Captures the conversation for a fresh chat. Returns a paste-ready handoff covering goal, settled context, open questions, and next move. |
/s.next
|
Next Move Planning | Defines the single most impactful action or question required in this exact moment. |
/s.plan
|
Plan to Achieve Goal | Turns a goal into a plan. Returns ordered steps, dependencies, effort, risks, and the first action. |
/s.premortem
|
Pre-Mortem Planning | Assumes a plan failed. Returns likely failure stories, warning signs, ratings, prevention steps, and the top fix. |
/s.prioritize
|
Prioritize Tasks, Features, or Ideas | Triages a list of tasks or ideas by impact and effort. Returns sorted buckets and a ranked list. |
/s.recommend
|
Recommend Approach | Reviews the alternatives discussed so far. Returns one decisive pick, its rationale, and the first three steps. |
/s.solution
|
Solution Development | Builds a solution to the gaps identified so far, one question at a time. Returns A to D options with a flagged recommendation. |
/s.status
|
Status Check | Reviews the conversation so far. Returns a brief recap of what is done, in progress, not started, and next. |
/s.strategic
|
Strategic Analysis | Analyzes data for strategic position. Returns core dynamics, strategic opportunities, and blind spots. |
Team Manager shortcuts (2 actions)
| Shortcut | Action (exact stored label) | Stored description |
|---|---|---|
/t.mlb
|
MLB Player Research | Provide baseball player report |
/t.nfl
|
NFL Player Research | Provide football player report |
Workflow Processor shortcuts (1 action)
| Shortcut | Action (exact stored label) | Stored description |
|---|---|---|
/w.sequence
|
Sequence Workflow | Classifies a request without doing the work. Returns the agents to use, in order, and the actions each performs. |
Agent Profiles
This section describes each agent in more detail and explains what every action does.
Analyst
The Analyst investigates before anyone acts. It explains material, evaluates claims, compares options, verifies facts, and finds what is missing. Think of it as a fact-checker, a reference librarian, and a skeptical reviewer rolled into one. It is also the library's busiest agent: Update with New Information is the most-used action in the catalog.
- Brief Research (
/a.brief): Produces a current research brief: overview, current state with developments from the past 12 to 24 months, key players and where they disagree, evidence and data, open questions, and a short source list. It separates established facts from emerging findings and opinion. - Challenge Identification (
/a.challenge): Frames the real problem behind a situation: the challenge in one sentence, why it is hard, visible symptoms versus root cause, the stakes, and what "solved" looks like. The stored template is currently a completed worked example (on AI curiosity) rather than a fill-in form, so it works best as a model answer to imitate. - Compare Items (
/a.compare): Gives the single most important difference, a comparison table, a "Pick X if..." statement for each option, and the most common confusion. If one option is better for most people, it says so and explains the exceptions. - Consolidate Source Materials (
/a.consolidate): Folds rules, patches, and addendums into one master document, whether a technical specification, a policy, or a mix. It applies explicit priority instructions first, then dates or version numbers, and never assumes an item is newer just because it appears later. It uses strict hierarchical numbering and appends a Supersession Record and an Unresolved Items list when needed. - Decision Rationale (
/a.decision): Reviews the conversation and records every substantive decision as Decision, Rationale, and Implication. It separates confirmed decisions from proposals, marks missing rationales as undocumented, and identifies which version governs when a decision was revised. - Explain Simply (
/a.explain): Adapts to its input. For code, it returns purpose, a walkthrough in execution order, key details, inputs and outputs, and concerns. For a topic, it returns a plain-English definition, an everyday analogy and where it breaks down, how it works, why it matters, a concrete example, common misconceptions, and a key takeaway. - Fact Check (
/a.factcheck): Rates each substantive claim as Accurate, Mostly Accurate, Misleading, Inaccurate, Outdated, or Unverifiable, cites the best evidence, writes a correction where needed, and closes with an overall reliability assessment. - Game Case Study (
/a.gamecasestudy): Researches a named game and writes a MediaWiki case study covering player experiences, emergence, genre classification, mechanics, key dynamics by player type (Achievers, Explorers, Socializers, Killers), aesthetics, and narrative. Genre and mechanic labels must come verbatim from canonical lists; any genuinely new label carries aNEW_NEW_prefix so it is easy to review. - Gap Analysis (
/a.gap): Reports missing context, unanswered questions, and two or three prioritized research steps, each with a stable finding ID. For a system specification it adds a four-phase protocol: 10 parameterized adversarial scenarios per iteration, root-cause analysis, proposed remedies, and a consolidated specification with a Preserved Invariant Log. It never presents a predicted failure as an observed one. - Interpret This (
/a.interpret): Explains a chart, table, screenshot, diagram, dataset, or excerpt: what it is, what it shows, what it means, and what could mislead a reader. It separates what is shown from its own interpretation. - Pros and Cons (
/a.proscons): Ranks real advantages and drawbacks, adds hidden factors and deal-breakers, and gives a bottom-line verdict. It refuses to pad either side for false balance. - Questions to Ask (
/a.questions): Builds a numbered question register in four groups: Foundational, Critical, Questions People Forget, and Questions to Ask Others. Each entry carries why it matters, what is needed, who can answer, a status (Blocking, Non-blocking, or Blocking status unclear), and whether the gap was documented or recommended. - Red-Team Analysis (
/a.redteam): Answers a research question from the material you supply, then attacks its own answer: the weakest assumptions, the weakest-supported claims, the strongest counterargument, the missing context, and two or three low-cost research actions. Each conclusion carries a confidence level, and no outside facts are allowed. - Regression Audit (
/a.regress): Compares original requirements against an updated document or code and returns a pass or fail list, flagging anything dropped, weakened, or altered. - Relevance Evaluation (
/a.relevance): Judges material against a stated objective: high-signal points, low-signal noise, and a verdict of Highly Relevant, Partially Relevant, or Irrelevant with the source's best use. - Summarize to Main Points (
/a.summarize): Returns a bottom line, five to seven key points, exact details worth keeping, and implications, adding nothing that is not in the source and flagging contradictions instead of smoothing them over. - Synthesize Collective View (
/a.synthesize): Combines several sources into one briefing on what they say together: a bottom line, the shared picture with source labels, divergences that change the picture, points only one source adds, and a confidence rating. It is neither a side-by-side comparison nor a merged document.
Developer
The Developer implements, explains, tests, and deliberately breaks software. It writes working code, explains its changes, and respects the existing conventions of the codebase. Since the Systems Auditor was retired, the Developer also owns adversarial testing and specification audits, so the agent that writes code is also the place you go to attack it. In an agent environment those two roles should run in separate contexts so the reviewer never grades its own work.
- Adversarial Testing (
/d.advtest): Produces a break-test report: edge cases and failure conditions, unexpected user behavior, exact reproduction steps, the resulting failure, and a severity (Critical, High, Medium, or Low) with likelihood. It deliberately proposes no fixes. It works like a crash-test engineer who wrecks cars on purpose so that real drivers stay safe. - Assemble Code (
/d.assemble): Rebuilds the final version of every file discussed in a conversation by starting from the latest complete version and applying each agreed change in order. It outputs whole files only and lists what it applied, skipped, resolved as a conflict, and never verified. For bookmarklets it also returns the minified one-line version. - Bookmarklet Update (
/d.bookmarklet): Adds a feature to a bookmarklet or vanilla JavaScript script with zero regressions. It preserves every selector, storage key, output format, and edge case; wraps the code in an immediately invoked function; avoids global variables; ends withvoid 0so the page is not replaced; and marks changes withADDED,UPDATED, andPRESERVEDcomments. It returns exactly two code blocks: clean source and a one-linejavascript:production bookmarklet. This action shows that the library can hold narrow, personal jobs alongside general ones. - Bug Fix (
/d.bug): Separates the visible symptom, the immediate failure, and the underlying root cause, explains the fix in one paragraph, and returns the complete corrected code with the smallest safe change. - Document Code (
/d.doc): Adds docstrings and only the inline comments that non-obvious logic needs, changes no behavior, and writes a short README section. - Error Explanation (
/d.error): Translates an error, stack trace, or log into plain language, ranks likely causes, gives a quick check for each, and fixes the most likely one. - Feature Implementation (
/d.feature): Writes complete, working feature code with brief comments on complex logic and attention to performance and security. It is the second most-used action in the library. - Specification Gap Analysis (
/d.gap): Runs iteration X of 10 of an adversarial audit: 10 test vectors across boundary conditions, malformed payloads, concurrency, fault injection, and ambiguous contracts; root causes; remedies; and full rewritten sections with a Preserved Invariant Log. - How Do I (
/d.howdoi): Gives the standard way to do a task, a short working example, the key lines explained, one common gotcha, and a better production alternative if one exists. - Plan Implementation (
/d.plan): Plans a change before any code is written: goal and scope, current state, approach, changes by file, ordered steps, risks and regressions, a test plan, and open questions. - Refactor (
/d.refactor): Improves the internal structure and readability of code without changing what it does. Think of it as reorganizing a closet: everything is still there, but now you can find it. - Regression Audit (
/d.regress): The same pass or fail requirement check as/a.regress, tagged for code input. - Code Review (
/d.review): Reviews without rewriting. Findings are grouped as Critical, Important, or Minor, each with location, problem, and suggested fix, and the review ends with a verdict: Ship, Ship with Fixes, or Needs Rework. - Write Tests (
/d.tests): Uses the project's existing test framework, covers main behavior, edge cases, invalid input, and error handling, mocks external calls, and lists behavior that is hard to test or looks like a bug.
Editor
The Editor produces paste-ready text. It drafts, rewrites, proofreads, converts formats, merges sources, and writes and updates pages, improving accuracy, clarity, and structure while keeping the original meaning intact. Since the Knowledge Synthesizer was retired, the Editor also owns synthesis jobs. Picture three people taking notes in the same meeting: Merge Sources turns their three versions into one official record that captures everything each person caught, and Retention Audit confirms nothing fell out.
- Capture to Document (
/e.capture): Turns a conversation's findings into a standalone document for someone who never saw the conversation. It keeps only final agreed versions, preserves exact figures and code, adds nothing new, and lists unresolved items under Open Questions. - Draft Message (
/e.draft): Writes an email, message, post, memo, or announcement from notes, an audience, and a goal. It leads with the point, keeps it as short as the goal allows, and lists anything important the notes left out. - Expand source content (
/e.expand): Turns brief notes or outlines into complete documentation with context, examples, and analogies, without inventing facts. Use the stored body as the procedure; this profile is a summary of its intended behavior. - Extract Data (
/e.extract): Pulls entities, facts, and figures into a table, MediaWiki table, CSV, or JSON. Values are copied exactly, missing fields stay blank rather than guessed, and a source-location column is added when the material has clear divisions. - Feedback on Writing (
/e.feedback): Critiques without rewriting: overall notes, clarity, structure, line notes, and the top three priorities. - Convert Format (
/e.format): Converts content between MediaWiki, Markdown, HTML, plain text, tables, and outlines without changing a word of content, and lists anything that would not convert cleanly. - Merge Sources (
/e.merge): Treats Source 1 as the master and integrates every supplemental source with zero substantive data loss. It deduplicates by substance rather than wording, keeps detailed versions over vague ones, places new material where it belongs rather than appending it, and marks true contradictions with a visible[REVIEW: Source N states ... ; Source 1 states ...]note instead of choosing a winner. - Reorganize Content (
/e.org): Restructures text for flow and hierarchy without adding or removing facts. It puts the most important material first, keeps rules next to their exceptions, and preserves existing contradictions and uncertainty rather than resolving them. - Improve Prompt (
/e.prompt): Audits a prompt for contradictions, ambiguity, missing pieces, title and body mismatches, redundancy, and wording problems, then returns a fixed version and a change list. It keeps shared blocks word for word unless the problem is inside them, which makes it the right tool for maintaining this library. - Proofread (
/e.proof): Fixes spelling, grammar, punctuation, capitalization, and consistency errors only, keeps all markup intact, and lists every change as original and corrected text. - Reconcile Sources (
/e.recon): Maps two or more sources without picking a winner: common ground, differences classified into eleven types, unique contributions (Truly Novel or Novel Detail), a contradiction table with a root cause only when the sources support one, strengths and limitations, coverage gaps, a comparison matrix, and the decisions left for a human. - Retention Audit (
/e.retention): Compares a draft against its sources and lists every fact, name, date, constraint, or concept that went missing, or confirms that the draft retains the full factual baseline. Run it after every merge or consolidation. - Rewrite for Clarity (
/e.rewrite): Uses plain words, active voice, and shorter sentences while keeping every fact and the original markup. - Tighten (
/e.tight): Cuts 30 to 50 percent of the length without losing substance, reports before and after word counts, and lists anything cut that might matter. - Tone Adjustment (
/e.tone): Rewrites for a named audience and tone while keeping all facts and the core message.
Strategist
Once the problem is clear, the Strategist designs the response. Like a building architect, it produces the blueprint but does not lay the bricks. Implementation belongs to other agents, such as the Developer or the Editor. Since the Continuity Strategist was retired, the Strategist also carries work across sessions. Think of a hospital shift change: the outgoing nurse tells the incoming nurse what happened, what the team decided, what to watch for, and what to do next. Handoff Transfer writes that report for your projects.
- Brainstorm (
/s.brainstorm): Generates 12 genuinely different ideas labeled Safe, Stretch, or Bold, then picks the top three. - Clarify Requirements (
/s.clarify): Finds the 3 to 5 most critical vague, conflicting, or missing requirements, asks a pointed question about each, and shows the trade-off behind it. - Conversation Review (
/s.conversation): Reviews the conversation as a skeptical outsider: drift from the original goal, errors (including the AI's own earlier answers), weak assumptions, points accepted too quickly, missed angles, and a verdict to continue, adjust, or rethink. - Decide Between Options (
/s.decide): Weights the criteria, scores each option from 1 to 5 in a decision matrix, notes which choices are reversible, recommends one, and states what would have to be true for another to win. - Explore Alternatives (
/s.explore): Outlines three genuinely different solutions, each with its approach, advantages, and costs or risks. - Handoff Transfer (
/s.handoff): Writes an eight-section Context Transfer Handoff Report: objective and done state, working model, settled context with a decision register (Decision, Rationale, Implication, Status), intent and rationale, friction and constraints, open questions, the immediate next move, and continuity instructions. - Next Move Planning (
/s.next): Names the single most useful next action or question, not a roadmap. - Plan to Achieve Goal (
/s.plan): Turns a goal into ordered steps with dependencies, effort, the top risks, and one thing to do today, stating assumptions instead of stopping to ask. - Pre-Mortem Planning (
/s.premortem): Assumes the plan failed six months from now and writes the five most likely failure stories, their early warning signs, likelihood and impact ratings, prevention steps, and the single fix that most improves the odds. - Prioritize Tasks, Features, or Ideas (
/s.prioritize): Sorts items into Do Now, Plan, Quick Wins If Time, and Drop or Defer by impact and effort, and calls out dependencies that change the order. - Recommend Approach (
/s.recommend): Picks exactly one path and returns three sections: the Verdict, the Rationale (time, complexity, and outcome first), and a Blueprint of the first three concrete steps. - Solution Development (
/s.solution): Builds a solution interactively, one decision question at a time. Each question offers options A to D, and D is always the recommended option, marked[RECOMMENDATION]. The full solution comes only after the key decisions are made. - Status Check (
/s.status): Gives a recap of under 200 words: where things stand, what is done, in progress, and not started, and what comes next. - Strategic Analysis (
/s.strategic): Reads supplied data for core dynamics, evidence-backed opportunities with confidence ratings, blind spots and second-order effects with signals to monitor, and a positioning summary.
Tip: The planning actions run best in a natural sequence: clarify requirements, explore alternatives, decide or recommend, then develop the solution and plan the work.
Team Manager
The Team Manager is a domain specialist for fantasy sports on ESPN. It passes the library's own test for a separate agent: a general analyst would not plausibly carry its specialized rules about probable starts, bye weeks, and waiver priorities.
- MLB Player Research (
/t.mlb): Compares season-long statistics with 15-day and 30-day splits and checks underlying metrics (BABIP, hard-hit rate, and exit velocity for hitters; xERA, FIP, K/9, BB/9, and swinging-strike rate for pitchers). It verifies probable starts and two-start weeks, refuses to recommend pitchers whose season-long numbers (such as an ERA above 5.00) reflect genuine decline, and never drops a strong recent performer for a weaker waiver target. Verdicts: ADD, DROP, HOLD, SELL-HIGH, BUY-LOW, or STASH. - NFL Player Research (
/t.nfl): Assumes PPR scoring and weighs opportunity (snap share, route participation, target share, air yards share, red-zone and goal-line touches) above raw points. It checks practice participation and game status, efficiency metrics such as yards per route run and EPA per play, matchup and Vegas context, weather, and bye weeks through the fantasy playoffs (typically Weeks 15 to 17). It treats touchdown spikes on low volume as regression candidates, suggests FAAB bid ranges, weighs handcuff stashes, and adds START or SIT to the verdict list.
Queue
The Queue is an inbox. When you write a useful prompt in the middle of other work, you save it here and assign it to the right agent later, so the library grows without forcing a filing decision at the worst moment.
- Image New Creation (
/q.imagenew): A formula for image-generation prompts: Subject, Action or Pose, Setting, Art Style or Medium, Lighting or Atmosphere, and Technical Details, each with examples. It is waiting for a permanent home. - Scope updates to AI Studio and Chrome Ext (
/q.scope): A one-line prefix, "Apply across both AI Studio and the Chrome Extension:", that tells the model to apply a requested change to both versions of a project. It shows that an action does not have to be a full prompt; a short, reusable modifier counts too.
Workflow Processor
The Workflow Processor acts as a manager or supervisor. It does not perform the work itself. Instead, it decides who does what and in which order, much like a conductor who never plays an instrument but directs the whole orchestra. In the first version of this page it was a placeholder that you filled yourself; it is now a working action.
The Workflow Processor answers four questions:
- What kind of request is this?
- Which agent should handle it?
- Which actions are required?
- In what sequence should they run?
- Sequence Workflow (
/w.sequence): Returns three sections: a Request Classification, an Agent Sequence in execution order, and an Action Plan that gives each agent its inputs, actions, output, and handoff. It uses the fewest agents that can do the job reliably, orders them by real dependencies (research before analysis, diagnosis before correction, drafting before editing, review after the thing being reviewed exists), and refuses to do any of the substantive work itself.
Example workflow. Suppose the request is: "Our onboarding documentation is out of date and spread across three separate pages." The Workflow Processor might sequence the work like this:
- Analyst → Update with New Information (
/a.update): Identify outdated information on each of the three pages. - Editor → Merge Sources (
/e.merge): Combine the three pages into one document. - Editor → Retention Audit (
/e.retention): Confirm that the merge kept everything important. - Strategist → Handoff Transfer (
/s.handoff): Summarize what changed and list any open questions.
The output of each step becomes the task-specific input for the next step. In a manual QFill workflow, you carry it by hand, pasting each result into the next action's input slot. In an agent environment, files carry it (see Handoffs Become Files).
Worked Example: Software Repair
- Developer,
/d.error: Interpret the error and rank possible causes. - Developer,
/d.bug: Diagnose and correct the defect. - Developer,
/d.tests: Create test coverage for the corrected behavior. - Developer,
/d.regress: Compare the result with the original requirements.
For source-controlled code, retain tests and previous working versions so failures can be reproduced.
Worked Example: MLB or NFL Research
The Team Manager group contains exactly two actions: /t.mlb and /t.nfl. Their stored prompt bodies contain distinct sport-specific evaluation criteria, so the two cannot safely be treated as one interchangeable action.
The MLB action emphasizes current role, recent performance, probable starts, roster fit, and a recommended transaction. The NFL action assumes PPR scoring, emphasizes opportunity and usage, injuries, upcoming opponents, bye weeks, roster coverage, and start/sit or transaction guidance. Current player facts still need an external source and appropriate date.
Finding the Right Action: Shortcuts and Tags
A 66-action library is only useful if you can find the right action in seconds. QFill uses two mechanisms.
Shortcuts. Every action has a shortcut built from a slash, the agent's letter, a dot, and a short name: /a.brief, /d.bug. The prefixes are a (Analyst), d (Developer), e (Editor), q (Queue), s (Strategist), t (Team Manager), and w (Workflow Processor). Because the extension sorts by shortcut by default, actions group themselves by agent automatically. Each action also has a label in the form "Agent • Action", such as "Editor • Wiki Page Update".
Tags. Every action carries three kinds of tags:
in:says what you supply:topic(a subject or question),item(a piece of material),list(several items or requirements),code,chat(the conversation itself), orqueue.out:says what you get back:understand(an explanation),judge(an assessment),paste(finished text),plan, orcode.goal:names the job in plain words, such asgoal:find-the-problem,goal:check-our-work, orgoal:hand-off-to-a-new-chat. Actions that serve the same intent share a goal tag: Proofread, Rewrite for Clarity, and Tighten all carrygoal:fix-or-polish, and the three wiki update and section actions carrygoal:bring-up-to-date.
Two flags mark special requirements: wiki (17 actions that understand MediaWiki) and bookmarklet (1 action).
| Input tag | Actions | Output tag | Actions |
|---|---|---|---|
in:item
|
26 | out:paste
|
19 |
in:topic
|
14 | out:understand
|
16 |
in:code
|
12 | out:judge
|
15 |
in:chat
|
7 | out:plan
|
11 |
in:list
|
6 | out:code
|
9 |
in:queue
|
1 | ||
The tags turn selection into a two-question lookup: what do I have, and what do I want? Material in hand plus a judgment wanted (in:item and out:judge) narrows the 66 actions to seven: Fact Check, Gap Analysis, Red-Team Analysis, Relevance Evaluation, Feedback on Writing, Reconcile Sources, and Strategic Analysis.
The in:chat tag matters most when you move to an agent environment. Its seven actions (Assemble Code, Capture to Document, Conversation Review, Handoff Transfer, Recommend Approach, Solution Development, and Status Check) read the conversation itself, so a fresh-context subagent needs an explicit transcript, decision log, or other complete task packet. Keeping them in the main conversation is usually simpler.
The descriptions follow a consistent two-sentence pattern that also pays off later: what the action does, then what it returns. For example: "Compares named concepts, tools, or options. Returns a side-by-side table and when to choose each." Agent environments route work by reading exactly this kind of description.
Shortcut Namespace and Identity Rules
/a.identifies Analyst actions./d.identifies Developer actions./e.identifies Editor actions./q.identifies Queue items./s.identifies Strategist actions./t.identifies Team Manager actions./w.identifies the Workflow Processor action.
The exact shortcut, not the English label, is the stable lookup key in the documented catalog. The action id is another identifier and may differ from the shortcut. One should not infer a particular action from its group prefix without examining the actual default record.
Known catalog metadata issues: The supplied labels include Challenge Identificaiton for /a.challenge and Decide Between Optiions for /s.decide. These spelling errors are recorded as source data rather than silently treated as corrected extension labels. Both Queue actions have TBD descriptions, although their bodies contain usable draft text: an image-prompt formula and a scope modifier. Their routing descriptions and permanent ownership still need review. The /a.challenge body is a completed AI-curiosity example rather than a general instruction template; its description alone overstates its readiness for arbitrary inputs.
The supplied definitions include full natural-language prompt bodies for each action. This page summarizes their purpose, but developers should treat the current extension manifest as the source of truth for their actual instructions. A change to a wiki summary does not modify the installed extension.
How to Choose an Action
| Goal | Recommended shortcut(s) | Distinction |
|---|---|---|
| Understand a new subject | /a.explain or /a.brief
|
Simple explanation versus current research brief |
| Check accuracy or currency | /a.factcheck or /a.update
|
Claim-by-claim verification versus full currentness audit |
| Compare choices | /a.compare or /s.decide
|
Comparative evidence versus a weighted decision recommendation |
| Identify an underlying problem | /a.challenge or /a.gap
|
Root challenge versus missing content and evidence |
| Produce a plan | /s.plan or /s.solution
|
Ordered implementation plan versus broader solution development |
| Fix code | /d.bug, then /d.regress
|
Repair, then check for unintended changes |
| Review code without changing it | /d.review or /d.advtest
|
Standard review versus adversarial testing |
| Improve a prompt | /e.prompt
|
Prompt structure, contradictions, and output contract |
| Merge files or documents | /e.merge, then /e.retention
|
Combine information and verify no important data disappeared |
| Preserve a chat for transfer | /s.handoff
|
Standalone context handoff to a future session |
| Research fantasy players | /t.mlb or /t.nfl
|
Sport-specific research rules, assumptions, and recommendations |
| Route a complex request | /w.sequence
|
Produces only the agent/action plan; does not execute it |
Many rules apply to most of the library, and today they live inside individual action bodies:
| Rule | Action bodies that state it | Where it belongs in an agent environment |
|---|---|---|
| Do not use em dashes; use commas, colons, semicolons, or parentheses | 18 | Workspace instruction file |
| Deliver the copy-and-paste result in a single code block | 18 | Action body (only some actions need it) |
| Never invent facts, sources, links, or video IDs | 17 | Workspace instruction file |
| End with a silent final quality check | 14 | Action body, with the checklist in a reference file |
No inline <ref> tags; cite with external links
|
11 | Shared MediaWiki reference file |
| Keep existing internal links exactly; add new ones only to pages known to exist | 10 | Shared MediaWiki reference file |
| The full OUTPUT FORMAT block for choosing and writing MediaWiki | 7 | Shared MediaWiki reference file |
| Zero regression: never weaken existing contracts or behavior | 3 explicitly, many in spirit | Developer agent definition |
The OUTPUT FORMAT block deserves a note because it encodes a small decision procedure. It picks the output format in priority order (a format you name, then MediaWiki for wiki tasks, then MediaWiki if any source contains wiki markup, then the primary source's format). It lists the markers that identify MediaWiki (equals-sign headings, apostrophe bold and italics, double-bracket links, single-bracket external links with a space-separated label, double-brace templates, {| tables, magic words, and wiki tags). It warns against deciding from bullet or numbered lists alone, because Markdown uses similar syntax, and it notes that text copied from a rendered page does not count as a MediaWiki source.
Overlaps and Distinctions
When two actions look similar, the library documents the difference. These are the pairs and groups most likely to cause confusion:
| Actions | The difference | Use when... |
|---|---|---|
Red-Team Analysis (/a.redteam) vs. Adversarial Testing (/d.advtest)
|
Both involve deliberate opposition, but they target different things. The Analyst red-teams ideas, arguments, and strategies. The Developer adversarially tests concrete systems, code, and specifications. | You want to stress a conclusion (red team) or break a system (adversarial test) |
Regression Audit (/a.regress) vs. Regression Audit (/d.regress)
|
Nearly identical procedures. The Analyst copy is tagged for requirement lists, the Developer copy for code. | Either works; they are candidates to merge or to keep only for findability |
Gap Analysis (/a.gap) vs. Specification Gap Analysis (/d.gap)
|
The Analyst version reviews any documentation and adds the adversarial protocol only for specifications; it forbids calling unvalidated output deployment-ready. The Developer version always runs the full protocol and asks for a specification "immediately ready for deployment", which conflicts with the Analyst rule. | General documents (/a.gap) or a specification hardening pass (/d.gap); reconcile the deployment-readiness wording
|
| Summarize, Synthesize, Compare, Merge, Reconcile | Summarize condenses one source. Synthesize turns several sources into one briefing. Compare puts named options side by side and may pick one. Merge builds one document with zero data loss. Reconcile maps agreement and conflict without picking a winner. | You want less text, one view, a choice, one document, or a map of disagreement |
Consolidate Source Materials (/a.consolidate) vs. Merge Sources (/e.merge)
|
Consolidate applies precedence: newer or higher-priority rules supersede older ones. Merge treats Source 1 as master and flags conflicts for a human instead of resolving them. | Rules with versions (consolidate) or documents with equal standing (merge) |
| Decision Rationale, Handoff Transfer, Status Check, Capture to Document | Decisions only; a full operational briefing for a new session; a short recap; a standalone write-up of findings for readers. | You need a decision record, a session transfer, a quick orientation, or a document |
| Explore Alternatives, Decide Between Options, Recommend Approach, Solution Development | Generate three options; score options you list; choose one from what was discussed; build a solution through guided questions. | You need options, a scored comparison, a verdict, or a designed solution |
| Proofread, Rewrite for Clarity, Tighten, Tone Adjustment, Feedback on Writing | Errors only; clarity; length; audience; critique without rewriting. | You know exactly which kind of help the text needs |
| Wiki Page Update, Wiki Section Update, Wiki Page New, Wiki Section New, Update with New Information | Whole page; one section; a new page; a new section fitted into an existing page; any material in any format, with a full reconciliation log. | The scope of the change, and whether you want a visible change log |
The QFill Chrome Extension
QFill is the retrieval layer of the library: it stores the catalog and surfaces each action by shortcut, agent, and tags so you can fill it into whatever AI tool you are using. It ships its defaults in a single file, defaultData.js, labeled "QFill Default Two-Tier Agents and Action Templates" and "Baked Delivery Package, Manifest V3". The current package was generated on October 11, 2026, at 17:28 UTC; its version number, 1791739735446, is a millisecond timestamp from the same build.
The file wraps its data in an immediately invoked function and exposes four values (DELIVERY_VERSION, DEFAULT_SORT_BY, DEFAULT_AGENTS, and DEFAULT_SNIPPETS) to globalThis, self, and window. That pattern lets the same file load in a Manifest V3 service worker, which has no window, and in the extension's pages.
Agent records contain:
id: the stable internal identifier, such astechnical-editor.nameanddescription: the display name and the routing text.color,badgeBg,badgeText,badgeBorder, andactiveColor: utility-class styling such asbg-sky-500/10.iconName: an icon such as Search (Analyst), Terminal (Developer), Feather (Editor), Briefcase (Strategist), Layers (Queue), or Sparkles (Team Manager and Workflow Processor).isCustom: whether the user created or customized the record.
Action records (stored as "snippets") contain:
id,shortcut,action, andlabel.body: the full prompt, including any input placeholders.agentIdandagentName: the owning agent. The name is stored alongside the ID, so a rename must update both or derive the name from the agent record when displaying it.descriptionandtags.createdAt,updatedAt, andlastUsedAt: millisecond timestamps.useCount,isCustom, andisModified: usage and provenance. Fourteen inherited defaults are marked modified; the other 56 actions are custom.
Benefits of This Approach
This approach allows a relatively small library of well-defined agents to support many specialized tasks without duplicating role definitions, reasoning instructions, or operating principles across dozens of individual prompts. Consider the numbers. The current catalog defines 7 agents (5 working agents plus the Queue and the Workflow Processor) and 66 actions. Without the agent and action split, you would maintain 66 standalone prompts, and each one would restate its specialist's identity and standards.
Key benefits include:
- Less duplication: You define each specialist's expertise and standards once.
- Consistency: Shared standards can make related actions more consistent when the runtime loads and enforces them.
- Easier maintenance: A configured runtime can load one shared house style for every Editor action. Updating an agent-group description alone does not rewrite the existing action bodies or prove that the extension inserts that rule.
- Easier growth: You can add a new action in a few lines without creating a new agent.
- Clearer choices: Each agent has a distinct responsibility, so you can quickly tell which one fits a request.
- Composable workflows: You can chain actions from different agents to handle complex, multi-step work.
- Portability: Because agents and actions are plain text with clear boundaries, they map almost one to one onto subagents and skills in Claude, OpenAI, and Gemini tools.
Guidelines for Growing the Library
- Add an action before you add an agent. If a new task fits an existing agent's responsibility, make it a new action under that agent.
- Create a new agent only for distinct expertise. Ask yourself: "Would this professional plausibly be asked to do this job?" If the answer is yes, you need an action, not an agent. The Team Manager passed this test; the Knowledge Synthesizer, in practice, did not.
- Name actions clearly. Use short task names that describe the work, such as Bug Fix, Merge Sources, or Gap Analysis, and keep the shortcut pattern of agent letter, dot, and short name.
- Keep agent definitions stable. Put task-specific instructions in the action and one-time instructions in the output requirements.
- Keep IDs stable when you rename. Change display names freely, but leave internal IDs alone so saved data, integrations, and file names keep working.
- Retire agents by moving their actions, not deleting them. Map every action to its new owner first, as the How the Catalog Evolved table does.
- Use the Queue as an inbox. Save useful prompts immediately and file them during a weekly review.
- Document overlaps. When two actions look similar, write down the difference, as Overlaps and Distinctions does, and either merge true duplicates or keep them deliberately.
- Pair creation with verification. Follow actions that produce something with actions that check it. For example, pair Merge Sources with Retention Audit, Feature Implementation with Regression Audit or Adversarial Testing, and Wiki Page Update with Fact Check.
- Keep shared wording identical. Until shared rules live in one file, copy them word for word and use Improve Prompt (
/e.prompt) to catch drift between copies. - Write descriptions as routing text. Say what the action does and what it returns. Runtimes will choose actions from these sentences.
- Watch action size. Keep instruction bodies under about 5,000 tokens (roughly 20,000 characters) so they fit the Agent Skills recommendation, and move long checklists or templates into reference files when you migrate.
- Prune with usage data, but give new actions time. A zero use count a week after creation means nothing; a zero use count after three months means the action is unclear, unneeded, or hard to find.
Maintaining the QFill Catalog
- Preserve each action's
idandshortcutwhen updating text, unless deliberately changing the external contract. - Keep each
agentIdassociated with an existing agent record. - Check uniqueness of agent IDs, action IDs, and shortcut strings.
- Update the action
descriptionwhenever itsbodychanges substantially. - Ensure short labels accurately describe the full prompt.
- Review the Queue actions and replace
TBDonly after their scope is decided. - Test all paths that insert, select, and run a shortcut in the actual Chrome extension separately from the manifest audit.
- For substantive updates, compare the new file with the previous manifest and run a retention or regression audit.
- Treat stored
createdAt,updatedAt, anduseCountvalues as metadata, not proof of successful execution or deployment.
Agent Environment
The catalog above runs by hand: you choose an action, fill in the input, and carry results between steps. An agent environment runs the same catalog with tools, isolated contexts, durable state, and automatic routing. This section starts with what changed across the industry in the last two years, then covers the cross-vendor rules for moving the QFill catalog, then walks through the Claude, OpenAI, and Gemini environments in turn.
Recent Developments
Between mid-2024 and late 2026, agent environments stopped being vendor experiments and settled into a common shape: a workspace instruction file, a folder of skills, specialist subagents, tools reached through MCP, a sandbox for code and files, and published artifacts for finished work. The research on whether all this makes people more productive also matured, and it now pulls in more than one direction.
Convergence on Open Formats
- Agent Skills became an open standard (December 2025). Anthropic introduced Agent Skills in October 2025 for the Claude apps, Claude Code, and the API, then published the format as an open specification at agentskills.io in December 2025. A skill is a folder with a
SKILL.mdfile: YAML frontmatter plus Markdown instructions, with optionalscripts/,references/, andassets/folders. The requirednamefield allows up to 64 lowercase letters, numbers, and hyphens and must match the folder name; the requireddescriptionallows up to 1,024 characters and should say both what the skill does and when to use it. Optional fields includelicense,compatibility,metadata, and an experimentalallowed-tools. OpenAI (in Codex and the API) and Google (in Gemini CLI and ADK) now load the same format. - Shared protocols moved to neutral governance (December 2025). The Linux Foundation formed the Agentic AI Foundation (AAIF) with three founding projects: Anthropic's Model Context Protocol, OpenAI's
AGENTS.md, and Block's goose. MCP is how agents reach tools and data;AGENTS.mdis a plain Markdown file of project instructions that many coding agents read. - Instruction files converged, but not completely. Claude Code reads
CLAUDE.md(which can import other files, includingAGENTS.md), Codex readsAGENTS.md, and Gemini CLI readsGEMINI.mdby default and can be configured to read other file names. Skill folders converged further: Codex and Gemini CLI discover skills under.agents/skills/, while Claude Code discovers project skills under.claude/skills/or through plugins.
What this means for the library: one set of skill folders can serve all three vendors, and the house rules can live in one instruction file that the others import or mirror.
Vendor Runtimes
| Date | Development | Why it matters for this library |
|---|---|---|
| December 2024 | Anthropic publishes Building effective agents, distinguishing predefined workflows from autonomous agents and recommending simple, composable patterns | Foundational: the Workflow Processor and deterministic pipelines are "workflows"; open-ended routing is the "agent" pattern |
| March 2025 | OpenAI releases the Agents SDK and the Responses API | Code-first agents with handoffs, guardrails, and tracing |
| April 2025 | Google open-sources the Agent Development Kit (ADK) | Code-first multi-agent systems with deterministic workflow agents |
| June 2025 | Google releases Gemini CLI as an open-source terminal agent | A Gemini counterpart to Claude Code |
| July 2025 | Claude Code adds custom subagents defined as Markdown files | Catalog agents can become isolated specialists |
| August 2025 | AGENTS.md launches as a shared instruction-file format for coding agents
|
House rules can live in one vendor-neutral file |
| October 2025 | OpenAI announces AgentKit, including the visual Agent Builder; Anthropic launches Claude Code plugins and Agent Skills | Skills give actions a portable file format; plugins package a whole library |
| December 2025 | Agent Skills becomes an open standard; the Agentic AI Foundation forms | Cross-vendor portability becomes realistic |
| Early to mid 2026 | Claude Code folds custom slash commands into skills; Gemini CLI and ADK add Agent Skills support (ADK through SkillToolset)
|
A QFill shortcut can become a skill you invoke by name |
| April 2026 | Anthropic launches Claude Managed Agents; Google announces the Gemini Enterprise Agent Platform at Cloud Next | Hosted runtimes for long-running agents on both platforms |
| September 2026 | OpenAI launches the Agents API in public beta, running the Codex harness as a managed service with durable sessions, subagents, and hosted sandboxes | A managed OpenAI counterpart to Claude Code and Managed Agents |
| November 30, 2026 | OpenAI's Agent Builder is scheduled to become unavailable | A reminder to keep the library's source of truth in plain, portable files |
Productivity Research
METR's developer trial (July 2025). METR ran a randomized controlled trial with 16 experienced open-source developers working on 246 real issues in large, mature repositories they knew well. Each issue was randomly assigned to allow or forbid AI tools (mainly Cursor with Claude 3.5 and 3.7 Sonnet). With AI allowed, tasks took 19 percent longer. Before the study the developers predicted a 24 percent speedup, and afterward they still believed AI had made them about 20 percent faster. The result establishes that early-2025 tools did not speed up this group on this kind of work, and that self-reported speedups can be badly wrong. It does not establish that AI slows developers in general: the sample was small, the developers were unusually expert in their codebases, and the tools have changed since.
METR's redesign (February 2026). When METR tried to repeat the study with newer tools, it ran into a selection problem: many developers no longer wanted to work without AI, so those willing to be randomized were not representative, and some participants avoided submitting tasks they expected AI to help with. METR said its newer data pointed toward speedups rather than slowdowns but could not be interpreted cleanly, and it announced a redesigned experiment. The open question is now how to measure productivity once AI use is the default.
Anthropic's conversation-based estimate (November 2025). Anthropic sampled 100,000 Claude conversations, asked Claude to estimate how long each task would take with and without AI, and found a typical time reduction of about 80 percent per task. Extrapolating across the economy under broad adoption, it estimated about 1.8 percent of added annual U.S. labor productivity growth over the next decade. The method scales well, but it measures model estimates rather than observed outcomes, and it does not count time spent outside the conversation checking, fixing, or integrating the work. It is best read as an upper-bound signal of task-level potential.
Danish administrative data (NBER, 2025). Humlum and Vestergaard linked surveys of about 25,000 workers in 11 AI-exposed occupations to Danish administrative records. Workers using chatbots reported saving an average of 2.8 percent of their hours, and the authors found no detectable effect on earnings or recorded hours through 2024. Some of the saved time went into new tasks that the AI itself created, such as checking its output. The data predate most agentic tools, so the study speaks to chat-era adoption.
Anthropic Economic Index (2025 to 2026). Anthropic's recurring reports track how people use Claude by occupation and task. Its September 2025 data showed "directive" use, where people hand Claude a task to complete with little back-and-forth, rising from 27 percent to 39 percent of sampled conversations in about eight months, and much higher shares in business API traffic. The January 2026 report added "economic primitives", such as task complexity, autonomy, and success, so later reports can track not just what people ask for but how well it goes.
How to read the evidence together. Task-level studies (Anthropic's estimates, the BCG experiment, the call-center rollout) show large gains on tasks within the AI's capability. Worker-level and economy-level studies (St. Louis Fed, Danish data) show small gains so far. Amdahl's law (see Introduction/Overview) explains part of the gap, verification time explains more, and the METR results show that how fast work feels is not a reliable measure. For a personal library, the practical lesson is to time a sample of your own tasks with and without AI rather than trusting impressions.
Context and Multi-Agent Research
- Multi-agent systems trade tokens for breadth (Anthropic, June 2025). Anthropic's research feature uses a lead agent that plans and spawns parallel subagents. On its internal research evaluation, a Claude Opus 4 lead with Claude Sonnet 4 subagents outperformed a single Opus 4 agent by 90.2 percent. The cost was token use about 15 times that of a chat. Anthropic found the pattern works best for broad, parallelizable research and worse for tightly coupled work such as most coding.
- The case against multi-agent systems (Cognition, June 2025). Cognition, the company behind the Devin coding agent, argued that parallel subagents lose shared context: each one makes implicit decisions the others cannot see, and their outputs conflict. It recommended single-threaded agents that compress history for long tasks, and later published a follow-up on which multi-agent patterns hold up in practice. The two positions reconcile reasonably well: parallelize read-only exploration and review, and keep writing in one thread. That is the split this page recommends (reviewers and researchers fork; the agent that edits stays in one context).
- Context engineering (Anthropic, September 2025). Anthropic described context as a finite resource with diminishing returns and recommended just-in-time retrieval, compaction of long histories, structured notes kept outside the context window, and subagents that return condensed results. Each recommendation maps onto a design choice in the runtime sections below.
- Context rot (Chroma, July 2025). Across 18 models, accuracy fell as inputs grew longer, even on simple tasks and well within advertised context limits. Bigger windows do not remove the need to keep context lean.
Objections and Open Questions
- Do instructions transfer across models? Prompts tuned for one model can underperform on another, and vendors' prompting guides differ. Portable formats move the files, not necessarily the quality. Re-test key actions when you switch models.
- Is routing reliable? Description-based routing can pick the wrong skill or none at all, especially with 70 similar-sounding actions. There is no public benchmark for personal libraries; traces and small repeated tests are the practical check.
- Are skills safe? A skill can include scripts, which makes installing one closer to installing software than to copying text. MCP tools can carry prompt-injection payloads. Install skills and connectors only from sources you trust, and require approval for actions with side effects.
- Does the library make you better or just faster? The BCG experiment found people were more likely to be wrong when they relied on AI outside its capability. Verification actions guard against errors, but nothing yet measures whether heavy use erodes the judgment needed to run them.
- Will today's platforms last? Agent Builder's scheduled shutdown about a year after launch illustrates how quickly product surfaces can change. Plain files in version control are the most durable home for the library.
From QFill Catalog to Runtime
Whichever vendor you choose, the same translation rules apply. Most of them fall straight out of the QFill data.
| QFill element | Runtime equivalent (all vendors) | Notes |
|---|---|---|
| Agent record | A specialist definition file under agents/, loaded as a subagent, an Agent(...), or an LlmAgent
|
Use the internal ID as the file name (technical-editor.md) so it never changes
|
Action body
|
The body of a SKILL.md file
|
Move long checklists and templates into references/
|
Action name and description
|
Skill description
|
Keep the "does X, returns Y" pattern and add "Use when..." wording for routing |
in:chat tag
|
Prefer the main conversation, or supply explicit history | A fresh subagent needs the relevant transcript or state; supported fork modes may inherit it |
out:judge tag
|
Read-only tool set | Reviewers and auditors should not be able to edit what they review |
out:paste and out:code tags
|
Write results to an outputs folder or publish an artifact | Finished work becomes a file, not a chat message |
wiki tag
|
Requires MediaWiki output rules; a live connection is optional | Pasted source and local files are sufficient for editing. API or MCP access is needed only for direct retrieval or publishing |
| Bracketed input placeholders | Skill arguments or files in an inputs folder | Claude Code skills, for example, accept $ARGUMENTS
|
| Repeated house rules | The workspace instruction file, plus a shared reference file for MediaWiki rules | Ends the duplication described in Shared Rules Across Actions |
| Queue actions | A drafts/ folder that runtimes do not scan
|
Promote a draft to a skill folder when it has a home |
useCount and lastUsedAt
|
Traces and run logs | Richer data: which skill ran, with what result, at what cost |
Workflow Processor (/w.sequence)
|
A root manager agent, a workflow skill, or a deterministic pipeline | Use code for known routes and a model for open-ended triage |
Which actions should normally stay inline. A fresh-context subagent does not automatically receive the conversation, although some runtimes support inherited-context forks or explicit transcript transfer. Ten actions depend on conversation or interactive project state, so the main session is the safest default: the seven in:chat actions (/d.assemble, /e.capture, /s.conversation, /s.handoff, /s.recommend, /s.solution, /s.status) plus /a.decision, /a.questions, and /s.next, whose bodies read the preceding conversation or current project state.
Which actions benefit most from forking. Research-heavy actions that produce long intermediate output (/a.update, /a.brief, /a.factcheck, /a.gamecasestudy, /e.merge, /e.recon) and every reviewer (/d.advtest, /d.review, /d.regress, /a.regress, /e.retention, /a.redteam). A reviewer that never saw the author's reasoning makes a better adversary.
A runtime agent the catalog does not need. The retired Systems Auditor is worth recreating as a runtime-only reviewer subagent. In QFill, adversarial testing lives under the Developer because that is where you look for it. In a runtime, the agent that wrote the code should not be the one attacking it.
Cross-Vendor Source Layout
The source of truth should move out of the wiki and into version-controlled files. The wiki should document the catalog; the files should run it. This layout serves Claude, OpenAI, and Gemini from one copy of every skill:
agent-catalog/
CLAUDE.md ← house rules for Claude Code (can import AGENTS.md)
AGENTS.md ← house rules for Codex and other AGENTS.md-aware tools
GEMINI.md ← house rules for Gemini CLI (or point Gemini CLI at AGENTS.md)
shared/
mediawiki-output-format.md ← the one canonical OUTPUT FORMAT block
house-style.md
agents/ ← canonical agent definitions, named by internal ID
research-analyst.md ← Analyst
software-engineer.md ← Developer
technical-editor.md ← Editor
solution-architect.md ← Strategist
tm.md ← Team Manager
orchestrator.md ← Workflow Processor
reviewer.md ← runtime-only fresh-context auditor
.agents/
skills/ ← one folder per action, each with a SKILL.md
a-brief/ a-challenge/ a-compare/ a-consolidate/ a-decision/
a-explain/ a-factcheck/ a-gamecasestudy/ a-gap/ a-interpret/
a-proscons/ a-questions/ a-redteam/ a-regress/ a-relevance/
a-summarize/ a-synthesize/ a-update/
d-advtest/ d-assemble/ d-bookmarklet/ d-bug/ d-doc/ d-error/
d-feature/ d-gap/ d-howdoi/ d-plan/ d-refactor/ d-regress/
d-review/ d-tests/
e-capture/ e-draft/ e-expand/ e-extract/ e-feedback/ e-format/
e-merge/ e-org/ e-prompt/ e-proof/ e-recon/ e-retention/
e-rewrite/ e-tight/ e-tone/ e-wp/ e-wpnew/ e-ws/ e-wsnew/
s-brainstorm/ s-clarify/ s-conversation/ s-decide/ s-explore/
s-handoff/ s-next/ s-plan/ s-premortem/ s-prioritize/
s-recommend/ s-solution/ s-status/ s-strategic/
t-mlb/ t-nfl/
w-sequence/
.claude/
skills → ../.agents/skills ← symbolic link (or a build-script copy) so Claude Code sees the same skills
agents/ ← Claude subagent files (frontmatter + agent text)
drafts/ ← Queue items: q-imagenew/, q-scope/
scripts/
build_skills.py ← copies shared/ files into each skill's references/,
checks names, descriptions, and body sizes
workspace/
inputs/ work/ outputs/ state/
The build script solves a portability problem. For self-contained, portable skill packages, include required supporting resources inside each skill directory. Some runtimes can read shared external paths, but that depends on their access and packaging rules. Keep one canonical copy in shared/ and let the script copy it into each skill that needs it.
Claude Agent Environment
From Prompt Library to Agent Environment
The Agent and Action catalog above is a prompt library: you choose a specialist, paste its definition, and hand it a task. An agent environment such as Claude Code keeps the same design but adds the runtime that a prompt cannot provide:
- Tools that let each agent act instead of only advising.
- Separate context windows so each specialist works without cluttering the main conversation.
- Persistent state that survives between sessions.
- Automatic routing based on each agent's description.
Because the library already separates agents from actions, moving to an agent environment is mostly a translation job, not a redesign. Anthropic offers the environment in three forms: Claude Code (on your machine or in the cloud), skills uploaded to the Claude apps, and Claude Managed Agents (a hosted runtime for long-running agents, launched in April 2026).
How the Pieces Map
| Catalog element | Agent environment (Claude Code) | What you gain |
|---|---|---|
| Agent definition | Subagent file in .claude/agents/
|
Own context window, tool permissions, and model |
| "Call on it when..." column | The description field
|
Claude routes work automatically |
| Action | Skill folder with a SKILL.md file
|
Runs as /e-expand or triggers automatically
|
| Agent and Action pairing | Skill with context: fork and agent: technical-editor
|
The action runs inside the specialist |
| QFill shortcut | The skill name
|
/e.expand becomes /e-expand, so muscle memory survives
|
| Task-specific input placeholder | $ARGUMENTS in the skill body, or a file path
|
Input arrives without pasting |
| Recurring output requirements | CLAUDE.md
|
Applies to every agent |
| One-time output requirements | Your message | Unchanged |
| Workflow Processor | The main conversation, plus one workflow skill per pipeline | No longer a manual step |
| Strategist continuity output (Handoff Transfer, Decision Rationale) | Files in the project, plus subagent memory | Survives across sessions |
| The whole library | A plugin | Installs in any project |
A subagent is a Markdown file with YAML frontmatter. The frontmatter configures the agent (name, description, tools, model), and the body becomes its system prompt. That body is your existing agent definition. Skills are the actions. Adding context: fork to a skill's frontmatter runs the skill in an isolated subagent, and the agent field names which subagent handles it. The reverse also works: a subagent's skills field preloads the full content of named skills at startup, so an Editor could start with its most-used actions already loaded.
Claude Code loads every skill's name and description into context so it can route, but it caps how much description text it loads (a configurable character budget). With 70 skills, check the total: the QFill shortcuts, names, and descriptions come to about 9,200 characters, so concise descriptions matter.
What Actually Changes
Agents Get Tools
Today the Analyst describes what an update audit would check. In an agent environment, it fetches the links, checks the versions, and reports what it found. A reviewer subagent stops imagining malformed inputs and actually runs them. This also makes the distinction between Red-Team Analysis and Adversarial Testing concrete: one is read-only reasoning, and the other gets a shell.
The Test for a New Agent Changes
In the prompt library, a new agent means distinct expertise. In an agent environment, a subagent earns its place when the work needs isolated context, restricted tools, or a different model. Expertise alone can live in a skill.
This rule has two consequences that are easy to miss:
- Fresh context needs explicit input. Standard non-fork subagents receive a delegation message rather than the complete parent conversation. Current Claude Code also documents forks that inherit parent history. Keep Handoff Transfer and other conversation-dependent actions inline unless you intentionally provide the needed transcript or use an appropriate inherited-context mode.
- Subagents cannot ask you questions. Claude Code withholds the question tool from subagents. Solution Development, which asks one decision question at a time, must run in the main conversation. Clarify Requirements can fork only if you are happy to receive its questions as a list and answer them afterward.
Isolation helps elsewhere. A reviewer benefits from a fresh context, because a reviewer that never saw the author's reasoning makes a better adversary.
Handoffs Become Files
The Workflow Processor example states that the output of each step becomes the input for the next step. Subagents return only a summary to the main conversation, so each step should write its full result to disk, such as an audit report or a merged draft. Retention Audit can then compare actual files instead of relying on memory.
Descriptions Do the Routing
Claude reads each agent's and skill's description to decide when to use it. The "Call on it when..." column in the Agent Catalog and the QFill action descriptions therefore become the most important text in the migration. A vague description leads to misrouted work. Actions that are near-duplicates (the two Regression Audits, the two Gap Analyses) need descriptions that say clearly when to use each, or they should be merged before migration.
Which Agents Become Subagents
| Agent | Implementation | Reason |
|---|---|---|
| Analyst | Subagent for research and audit actions; inline for /a.decision and /a.questions
|
Needs web tools, produces verbose output, and works read-only; two of its actions need the conversation |
| Developer | Subagent for implementation (/d.feature, /d.bug, /d.refactor); inline for /d.assemble
|
Needs edit and shell access; can work in an isolated copy of the repository |
| Reviewer (runtime-only, the former Systems Auditor) | Subagent with read-only source access and a constrained test sandbox | Runs /d.advtest, /d.review, /d.regress, /a.regress, and /e.retention with fresh eyes
|
| Strategist | Mostly inline; fork /s.explore, /s.premortem, and /s.strategic
|
Most of its actions read the conversation or ask you questions |
| Team Manager | Subagent with web tools, or skills plus a sports-data connector | Domain-specific and self-contained |
| Queue | Not a runtime agent | Its items live in drafts/ until they are filed
|
| Workflow Processor | Main conversation | Selects and sequences the other agents |
Migration Path
Step 1: Turn the Wiki into Source Files
Split each agent and each action into its own file, using the Cross-Vendor Source Layout. Rewrite every "Call on it when..." entry and action description as a description that says when to use the agent or action, not only what it does. Move repeated house rules into CLAUDE.md and the shared MediaWiki file. Then make this wiki page document those files instead of duplicating them. Otherwise, the library recreates the drift problem described in The Problem This Solves.
Step 2: Test in Claude.ai (Optional)
Claude.ai accepts uploaded skills, so you can test the library without a terminal. Package each agent as one skill:
SKILL.mdholds the agent definition and an index of its actions.- Each action lives in a separate reference file that loads only when needed.
This step tests routing cheaply, but it does not provide isolation or per-agent tools.
Step 3: Move Two Agents into Claude Code
Start with the Editor and the reviewer, because together they exercise both patterns (inline and forked). The project layout looks like this:
CLAUDE.md ← house style: active voice, no em dashes
.claude/
agents/
technical-editor.md
reviewer.md
skills/
e-expand/SKILL.md
d-advtest/SKILL.md
s-handoff/SKILL.md ← inline, no fork
docs/
HANDOFF.md
DECISIONS.md
work/ ← artifacts passed between steps
The agent file contains your existing definition plus configuration:
--- name: technical-editor description: Updates, expands, merges, and reorganizes wiki pages, guides, and specs. Use when existing documentation needs improving or several sources need to become one document. tools: Read, Edit, Write, Grep, Glob, WebFetch model: sonnet --- You improve structured technical content so that it is accurate, clear, and easy to navigate. Preserve the author's intent, keep terminology consistent, and flag any claim you cannot verify.
Each action binds itself to its agent:
--- name: e-expand description: Turn brief notes or an outline into complete structured documentation. Use when the source is correct but incomplete. Returns the expanded document. context: fork agent: technical-editor --- Turn the provided notes into complete documentation. Add context, examples, and analogies where a point would be hard to follow. Do not invent facts. Source notes: $ARGUMENTS Write the result to docs/work/ and return a short summary of what you added.
House style goes in CLAUDE.md. Custom subagents normally load the relevant instruction hierarchy, but current Claude Code documents exceptions, including built-in Explore/Plan behavior and omitClaudeMd. Check the selected configuration before relying on inherited rules. This extends the benefit described in Benefits of This Approach: you update one file, and every agent and action inherits the change.
Step 4: Give Agents Tools and State
- Connect the wiki. Connect the wiki's API, directly or through an MCP server, so the Editor reads and writes pages instead of receiving pasted text. You can scope a connection to a single subagent so its tools stay out of the main conversation.
- Enable memory. For agents that should learn over time, the
memoryfield gives the subagent a persistent directory that survives across sessions. - Bundle scripts. A skill can include script files alongside its instructions, which suits narrow actions such as Bookmarklet Update (a minifier) or Game Case Study (a checker that confirms every genre and mechanic label appears in the canonical lists).
Step 5: Promote the Workflow Processor, Then Package
Write each recurring workflow as its own skill. For example, a /refresh-docs skill can sequence the five steps from the onboarding example and build in the guideline to pair creation with verification. Once several workflows are stable, bundle the agents and skills into a plugin so the whole library installs in any project.
Claude Managed Agents
Claude Managed Agents, launched in April 2026, runs agents on Anthropic's infrastructure with a managed sandbox instead of on your machine. It suits catalog workflows that should run unattended or on a schedule, such as a weekly currentness sweep of wiki pages with /a.update, followed by /e.retention and a handoff report. The same conceptual roles and action text can be reused, but managed-service configuration, tool wiring, scheduling, and supported skill-loading paths must be adapted and tested.
The catalog defines who does the work and what work gets done. The agent environment adds the tools, memory, and routing that let the work happen.
Claude See Also
- Create custom subagents (Claude Code documentation)
- Skills (Claude Code documentation)
- Plugins (Claude Code documentation)
- MCP servers (Claude Code documentation)
- CLAUDE.md and memory (Claude Code documentation)
- Features overview (Claude Code documentation)
- Equipping agents for the real world with Agent Skills (Anthropic Engineering)
- Tool, skill, or subagent? Decomposing an agent that outgrew its prompt (Code with Claude session)
OpenAI Agent Environment
From Prompt Library to OpenAI Agent Environment
The same Agent and Action catalog maps cleanly to OpenAI's current agent stack. The closest managed equivalent to Claude Code is the OpenAI Agents API, which entered public beta in September 2026. It runs the Codex harness for you and can provide durable sessions, multi-agent orchestration, skills, tools, sandboxed files, and published artifacts. The OpenAI Agents SDK is the code-first alternative when you want your own Python or TypeScript application to own the agent loop, tools, approvals, state, and specialist definitions.
For this library, the practical target is:
- Agents API for a managed, durable agent environment with an OpenAI-hosted or self-hosted sandbox.
- Agents SDK when you want explicit
Agent(...)definitions, manager and specialist ownership, typed function tools, guardrails, approvals, and application-controlled orchestration. - Responses API only when you need lower-level control and are prepared to assemble more of the agent runtime yourself.
The important point is that the catalog does not need a conceptual redesign. It needs one additional distinction:
Agent = WHO owns the work Skill = HOW a repeatable kind of work is performed Tool = WHAT executable capability the agent can use
An artifact is then the durable result of that work, while a session and sandbox preserve the working state around it.
Do not build this migration around Agent Builder. OpenAI introduced Agent Builder as part of AgentKit in October 2025 and has since announced that it is being wound down, with the product scheduled to become unavailable after November 30, 2026. For a durable implementation, use the Agents API or the Agents SDK.
Assistants API Migration
OpenAI's earlier Assistants API was sunset on August 26, 2026. The supported migration path uses Responses and Conversations APIs. This distinction matters for older instructions and code samples that reference Assistants, Threads, or Runs as active endpoints.
Assistants Migration Guide | OpenAI, August 2026 Official migration instructions.
How the Pieces Map
| Catalog element | OpenAI implementation | What you gain |
|---|---|---|
| Agent definition | Agent(...) with instructions in the Agents SDK, or the root agent configuration in an Agents API session
|
Stable specialist identity, model choice, tools, guardrails, and ownership |
| Role (responsibility) | Agent instructions
|
The specialist's durable contract |
| "Call on it when..." column | handoffDescription, an agent-as-tool description, or skill description
|
Better routing and delegation |
| Action | Skill directory containing SKILL.md
|
Reusable workflow instructions, references, examples, and scripts |
| Agent and Action pairing | Agent instructions plus the skills exposed in that agent's sandbox or capability directories | A specialist can reuse several actions without duplicating its identity |
| Task-specific input | User input plus files placed or mounted in the sandbox | Large inputs do not have to be pasted into the prompt |
| Recurring workspace requirements | AGENTS.md
|
Shared repository or workspace conventions |
| Specialist-specific requirements | Agent.instructions
|
Rules that apply only to that specialist |
| One-time output requirements | The current user message | Remains task-specific |
| Executable business action | Function tool, hosted tool, MCP tool, shell, or other runtime tool | The agent can act instead of merely describing what to do |
| Workflow Processor | Root manager agent | Selects, sequences, delegates, and synthesizes |
| Specialist delegation | agent.as_tool(...) or handoffs=[...] in the Agents SDK; managed subagents in the Agents API
|
Explicit control over who owns the final response |
| Strategist continuity output | Session state, workspace files, snapshots, and explicit handoff and decision artifacts | Work can continue across turns or later runs |
| Finished document, spreadsheet, report, code file, etc. | Artifact written to /workspace/outputs in an OpenAI-hosted Agents API sandbox
|
The finished file is published and remains retrievable after the sandbox itself expires |
| The reusable capability library | Plugin containing skills and MCP configuration | Portable installation of reusable workflows and integrations |
OpenAI's current skill format is intentionally close to the structure this catalog already needs. A skill is a directory with a SKILL.md manifest plus any supporting references, assets, examples, or scripts, following the open Agent Skills specification. In an Agents API sandbox, the harness discovers skills from registered capability directories. In the OpenAI and Codex convention, reusable project skills commonly live under .agents/skills/.
The Most Important Change: Add Tools as a Separate Layer
The existing catalog separates Agents from Actions. OpenAI makes it useful to add a third layer: Tools.
Consider the Analyst's Update with New Information (/a.update), the successor to the original Currentness Audit:
- Agent: Analyst
- Skill:
a-update - Tools: web search, file search, browser or MCP access, or a wiki API
- Artifact: currentness assessment, updated page, and reconciliation log
The skill should explain the procedure: inspect dates, versions, links, deprecations, and unsupported claims, then write the update and the change log. The tools perform the actual searches and retrieval.
The same pattern applies to the Developer:
- Agent: Developer
- Skill:
d-bug(Bug Fix) - Tools: shell, file read and write, patching, tests, repository access
- Artifact: modified code plus test results
This distinction prevents the Action catalog from turning into a collection of low-level tool definitions. Actions remain human-readable jobs. Tools remain machine-executable capabilities.
Skills Are Not Subagents
A skill and a specialist agent solve different problems.
- Create a skill when the important thing is a repeatable procedure, checklist, standard, template, or script.
- Create a separate agent when the specialist needs different instructions, tools, guardrails, model settings, approval rules, context ownership, or response ownership.
- Give one agent many skills when the same professional can perform several related jobs.
This reinforces the rule already established in Guidelines for Growing the Library: add an action before adding an agent. In OpenAI, that normally means adding a skill before adding another runtime agent.
How the Workflow Processor Changes
The Workflow Processor can inform the root manager design, but its planning-only instructions must be adapted before it can execute a workflow.
The OpenAI Agents SDK supports two canonical delegation patterns:
- Agent as a tool. The manager calls a specialist, receives its result, and remains responsible for the final answer. Use this when several specialists contribute to one combined result.
- Handoff. The manager transfers ownership to a specialist, which then owns the next response. Use this when the specialist should take over the conversation.
For a runtime implementation of this catalog, agent as a tool is a useful default pattern. The stored Workflow Processor prompt only produces a plan and explicitly forbids executing the underlying task. A runtime manager that calls specialists and combines their results therefore needs a new execution contract; loading /w.sequence unchanged is not sufficient. Handoffs are better reserved for cases where you deliberately want a specialist to own the conversation from that point forward, such as handing a long implementation to the Developer.
The managed Agents API offers another pattern: enable multi-agent orchestration and allow the root agent to create independent subagents. Each subagent gets its own context and can work in parallel. This is especially useful for independent research, document review, testing, or several audits that can run at the same time, which is exactly where the research in Context and Multi-Agent Research says parallelism pays.
Which Catalog Members Should Become Runtime Agents
Not every catalog agent needs to become a separate runtime agent on day one.
| Catalog member | Recommended OpenAI implementation | Reason |
|---|---|---|
| Workflow Processor | Root manager agent | Owns routing, sequencing, synthesis, and the final response |
| Analyst | Specialist agent, normally called as a tool | Benefits from read-only web and file tools and an isolated research context |
| Reviewer (runtime-only, the former Systems Auditor) | Specialist agent, normally called as a tool | Benefits from fresh context, sandbox execution, and adversarial testing |
| Developer | Specialist agent; tool call or handoff depending on ownership | Needs a distinct edit and test tool surface and may own a long implementation branch |
| Editor | Start as skills on the manager; promote to an agent for large merges and page updates | Most editing actions share tools and do not require separate ownership, but large source sets crowd the manager's context |
| Strategist | Mostly skills on the manager | Its actions are mostly reasoning procedures, and several need the conversation itself |
| Team Manager | Specialist agent with web search, or skills plus a sports-data MCP server | Self-contained domain work |
| Queue | Not a runtime member | Drafts wait outside the skills directory |
This is a runtime decision, not a change to the conceptual catalog. The wiki can still document all seven agents. The implementation simply avoids paying the complexity cost of seven independent agents before isolation is useful.
Artifacts, Working Files, and State
OpenAI separates three things that are easy to blur together:
- Working files live in the sandbox while the agent is doing the job.
- Artifacts are finished files you deliberately publish or retrieve.
- Session state preserves the conversation and agent progress.
With an OpenAI-hosted Agents API sandbox, each session has its own workspace. Files written under /workspace/outputs are published as immutable artifacts when the turn completes. Those published copies remain retrievable after the sandbox expires.
A clean convention for this catalog is:
/workspace/
inputs/ ← source material supplied to the task
work/ ← intermediate reports and drafts
outputs/ ← final published artifacts
state/
DECISIONS.md
HANDOFF.md
OPEN_QUESTIONS.md
The Strategist's continuity actions therefore still matter, but their role changes. Instead of compensating for a completely stateless chat, Handoff Transfer, Decision Rationale, and Questions to Ask maintain human-readable project state on top of the runtime's session state.
Guardrails, Approvals, and Tracing
An agent environment should define not only what an agent can do, but what it is allowed to do automatically.
OpenAI separates these concerns:
- Tool exposure: which tools the agent can see.
- Guardrails: checks on inputs, outputs, or tool use.
- Approvals: pauses before actions that have side effects or require human review.
- Tracing: records model calls, tool calls, handoffs, guardrails, and other steps for debugging and evaluation.
For example, the Developer can be allowed to read and test freely while requiring approval before publishing, deploying, deleting, or writing to a production system. The Analyst can remain read-only. Traces also replace QFill's simple useCount with real evidence about which skills run, how often they succeed, and what they cost, which supports the AIOps/MLOps practice of monitoring a system you depend on.
This is a useful addition to the catalog because two agents may have identical skills but very different permission boundaries.
Recommended Source Layout
Use the Cross-Vendor Source Layout for agents and skills. OpenAI adds the workspace instruction file and the application code that defines the runtime agents:
agent-catalog/
AGENTS.md ← shared workspace rules
agents/ ← canonical prose definitions (shared)
.agents/skills/ ← shared skills (shared)
app/
agents.py ← Agent(...) definitions
tools.py ← function tools and MCP wiring
guardrails.py
run.py
The Markdown files under agents/ remain the canonical prose definitions and are loaded by the application into each agent's instructions. That lets the wiki summarize the definitions without becoming a second executable copy.
Example OpenAI Skill
The existing Expand source content action becomes a skill almost directly:
--- name: e-expand description: Turn brief notes or an outline into complete structured documentation when the source is correct but incomplete. Returns the expanded document. --- # Expand Content Use the Editor standards. 1. Preserve the author's intent and terminology. 2. Turn the supplied notes or outline into complete documentation. 3. Add context, examples, and analogies where they improve understanding. 4. Do not invent factual claims that the source does not support. 5. Keep the structure easy to navigate. 6. Write intermediate drafts to /workspace/work/. 7. Write the finished deliverable to /workspace/outputs/ when the task requires a file artifact.
A skill can also contain:
e-expand/
SKILL.md
references/
house-style.md
mediawiki-output-format.md ← copied from shared/ by the build script
assets/
page-template.txt
scripts/
validate_headings.py
This is where the Action catalog becomes much more useful than a collection of pasted prompts. Each action can carry its own supporting knowledge and executable helpers.
Example Manager and Specialist Relationship
In the Agents SDK, the Workflow Processor can keep ownership while calling a specialist as a tool:
from pathlib import Path
from agents import Agent
def load_text(path: str) -> str:
return Path(path).read_text(encoding="utf-8")
editor = Agent(
name="Editor",
instructions=load_text("agents/technical-editor.md"),
)
workflow_processor = Agent(
name="Workflow Processor",
instructions=(
"Execute the authorized workflow, delegate bounded editing work, "
"verify returned results, and own the final response. "
"Treat /w.sequence as a planning procedure, not the execution contract."
),
tools=[
editor.as_tool(
tool_name="editor",
tool_description=(
"Produce paste-ready text: update, expand, merge, or reorganize "
"structured technical content while preserving meaning and terminology."
),
)
],
)
The manager decides when the Editor is needed, the specialist performs its bounded work, and the manager can then call another specialist or assemble the final result.
When a specialist should take over completely, define a handoff instead.
Packaging as an OpenAI Plugin
Once the skills and integrations are stable, package the reusable capability layer as a plugin.
An OpenAI plugin can package:
- Skills.
- MCP server configuration.
- The metadata needed to install those capabilities into compatible environments.
A minimal layout is:
primo-agent-library/
.codex-plugin/
plugin.json
.mcp.json
skills/
a-update/
SKILL.md
e-expand/
SKILL.md
d-advtest/
SKILL.md
A plugin manifest points to the skills directory and MCP configuration:
{
"name": "primo-agent-library",
"version": "1.0.0",
"description": "Reusable PRIMO.ai agent skills and integrations.",
"skills": "./skills/",
"mcpServers": "./.mcp.json"
}
There is one important difference from the Claude packaging model: the plugin is the capability package, not necessarily the entire application. Your explicit Agent(...) definitions and orchestration code can remain in the application while the plugin carries the portable skills and MCP integrations.
Migration Path
Step 1: Make the Catalog Executable Source
Create one source file for every agent definition and one SKILL.md directory for every action. Keep the existing internal IDs for agents and derive skill names from the QFill shortcuts. Rewrite descriptions so they say clearly when the skill should be used, not merely what it does.
At this point, the wiki becomes documentation generated from or synchronized with the executable source rather than the master copy.
Step 2: Add the Missing Tool Layer
For each action, identify the capabilities it requires.
Examples:
- Update with New Information (
a-update) → web search, file retrieval, link checking. - Wiki Page Update (
e-wp) → wiki read and write or MCP access, plus web search for research and video verification. - Bug Fix (
d-bug) → shell, repository files, tests, patching. - Adversarial Testing (
d-advtest) → sandbox, test runner, malformed-input corpus. - Handoff Transfer (
s-handoff) → session history plus state files. - MLB Player Research (
t-mlb) → web search or a sports-data connector.
Do not turn these capabilities into new Actions. They are tools used by Actions.
Step 3: Build a Small Agents SDK Prototype
Start with the same pair that makes a useful Claude test: the Editor and the reviewer. Add the Workflow Processor as the manager.
This three-agent prototype exercises:
- a manager,
- a mostly inline editorial workflow,
- an isolated test and audit workflow,
- skills,
- tool permissions,
- artifacts,
- and manager-to-specialist delegation.
Use agent.as_tool(...) first so the Workflow Processor remains responsible for the combined result.
Step 4: Add a Sandbox and Artifact Convention
Give the reviewer and the Developer sandbox access. Establish the inputs/, work/, outputs/, and state/ directories.
Require finished files to go to /workspace/outputs. This turns "produce a document" or "fix the code" into a concrete artifact contract rather than a prose response.
Step 5: Move Durable Work to the Agents API
Once the local Agents SDK prototype behaves correctly, decide which workloads should run under the managed Agents API.
Use the Agents API when you want OpenAI to manage:
- the Codex harness,
- durable sessions,
- context compaction,
- recovery,
- multi-agent subagents,
- and optionally the hosted sandbox.
Use the Agents SDK when you want your own application to retain tighter control over the runtime and infrastructure. Because the Agents API is still in beta, keep the SDK prototype working as a fallback.
The two approaches can share the same conceptual agent definitions, skill files, tool contracts, and workspace conventions.
Step 6: Connect Real Systems Through MCP and Plugins
Replace pasted inputs with controlled integrations:
- Wiki API or MCP access for the Editor.
- Repository access for the Developer.
- Search and retrieval for the Analyst.
- Shared document and file sources for merge and reconciliation jobs.
Then package stable skills and MCP configuration into the PRIMO.ai plugin.
Step 7: Add Evaluation Before Expanding the Team
Use traces to inspect routing, tool calls, handoffs, approvals, and failures. Test the same task repeatedly before promoting more catalog members to independent agents.
Only create another runtime agent when you can answer at least one of these questions with "yes":
- Does it need a different tool set?
- Does it need different permission or approval rules?
- Does it need isolated context?
- Does it need a different model or output contract?
- Should it sometimes own the final response?
If not, keep it as a skill under an existing agent.
The OpenAI implementation adds one crucial layer to the catalog: agents own work, skills describe reusable procedures, tools perform executable actions, and artifacts preserve the results.
OpenAI See Also
- Agents overview (OpenAI)
- Agents API (OpenAI)
- Agents SDK (OpenAI)
- Skills (OpenAI)
- Skills in the OpenAI API (OpenAI Cookbook)
- Shell + Skills + Compaction: Tips for long-running agents that do real work (OpenAI Developers blog)
- Plugins (OpenAI)
- Sandbox agents (OpenAI)
- Files and artifacts (OpenAI)
- Orchestration and handoffs (OpenAI)
- Migrate from the Claude Agent SDK to the OpenAI Agents SDK (OpenAI Cookbook)
- Introducing AgentKit (OpenAI, October 2025; background on Agent Builder)
Gemini Agent Environment
From Prompt Library to Gemini Agent Environment
The Agent and Action catalog translates directly into Google's Gemini agent stack without requiring a redesign. Google supports the open Agent Skills specification (agentskills.io), which allows the shared SKILL.md core to be reused. Vendor-specific frontmatter, tools, permission rules, and execution behavior still require adaptation and testing.
Depending on whether you want an interactive terminal assistant, a code-first multi-agent pipeline, or a managed cloud runtime, the catalog maps onto three complementary Gemini layers:
- Gemini CLI for interactive local terminal work, using
GEMINI.mdfor global workspace rules,.gemini/skills/(or the shared.agents/skills/alias) for on-demand action skills, and MCP-based Gemini CLI Extensions. - Google Agent Development Kit (ADK) for code-first multi-agent systems in Python, TypeScript, Go, or Java, offering
LlmAgentspecialists, deterministic workflow orchestrators (SequentialAgent,ParallelAgent,LoopAgent), progressive skill loading viaSkillToolset, sharedsession.state, and versioned file persistence viaArtifactService. ADK's documentation also covers a Google Cloud Skill Registry integration for sharing skills across agents. - Managed cloud runtimes such as Vertex AI Agent Engine or Cloud Run when you want to deploy an ADK multi-agent system with persistent sessions and enterprise memory. In April 2026 Google announced the Gemini Enterprise Agent Platform to unify its enterprise agent tooling, so check current product names when you deploy.
How the Pieces Map
| Catalog element | Gemini implementation (Gemini CLI and Google ADK) | What you gain |
|---|---|---|
| Agent definition | LlmAgent(...) in Google ADK, or a custom Gem or specialized CLI profile
|
Dedicated model choice (a current Gemini Pro or Flash model), system instructions, tools, and callbacks |
| Role (responsibility) | LlmAgent.instruction
|
The specialist's durable contract and reasoning standards |
| "Call on it when..." column | LlmAgent.description and SKILL.md frontmatter description
|
Automatic delegation to subagents and on-demand skill activation |
| Action | Skill directory containing SKILL.md in .gemini/skills/ or .agents/skills/
|
Portable, three-stage progressive disclosure across Gemini CLI and ADK |
| Agent and Action pairing | LlmAgent configured with tools=[SkillToolset(skills=[...])]
|
A specialist loads only the specific action instructions needed for the current task |
| Task-specific input | User message, multimodal types.Part inputs, or injected {state_key} placeholders
|
Native multimodal inputs (text, PDFs, audio, video, large codebases) and structured state passing |
| Recurring workspace requirements | GEMINI.md in Gemini CLI, or shared root instructions in ADK
|
House style rules apply automatically across every session and task |
| One-time output requirements | The current user message | Remains task-specific |
| Executable business action | FunctionTool, McpToolset, google_search, or BuiltInCodeExecutor
|
Live web grounding, sandboxed code execution, and external API integrations |
| Workflow Processor | ADK workflow agents (SequentialAgent, ParallelAgent, LoopAgent) or a root LlmAgent coordinator
|
Deterministic pipelines and verification loops without relying on model guesswork |
| Specialist delegation | sub_agents=[...] (model-driven transfer_to_agent) or AgentTool(agent=...)
|
Choose between full conversational handoff and bounded tool-style invocation |
| Strategist continuity output | session.state dictionary via output_key, plus persistent MemoryService
|
Structured step-to-step state transfer and cross-session memory |
| Finished document, spreadsheet, report, code file, etc. | Versioned types.Part saved via context.save_artifact(filename, artifact)
|
Automatic file versioning managed by InMemoryArtifactService or GcsArtifactService
|
| The reusable capability library | Gemini CLI Extension (gemini-extension.json) or shared .agents/skills/ package
|
One-command installation of skills, MCP servers, and custom slash commands |
What Makes the Gemini Architecture Distinct
Three-Level Progressive Disclosure with SkillToolset
In a traditional prompt library, giving an agent dozens of actions means pasting a massive prompt or maintaining dozens of separate chats. Both Gemini CLI and Google ADK's SkillToolset solve this with three-level progressive disclosure:
- Level 1 (Metadata): At startup, the agent only receives the
nameanddescriptionfrom eachSKILL.mdfrontmatter (via the auto-generatedlist_skillstool). The specification gives roughly 100 tokens per skill as a planning estimate. The supplied QFill shortcuts, labels, and descriptions contain 9,241 characters, about 2,300 tokens under a rough four-characters-per-token heuristic, compared with about 60,000 tokens for its bodies. These are different estimates: actual serialized metadata, tool schemas, and tokenizer overhead must be measured in the chosen runtime. - Level 2 (Instructions): When a task matches a skill's description, the agent calls
load_skill(oractivate_skillin Gemini CLI) to pull the fullSKILL.mdinstructions into context. - Level 3 (Resources): Supporting files in
references/,assets/, orscripts/remain offloaded on disk until the skill's instructions tell the agent to fetch a specific file viaload_skill_resource.
Both Gemini CLI and ADK also support a meta-skill pattern (skill-creator) where the agent can read the agentskills.io specification at Level 3 and author new SKILL.md folders for your library at runtime. That makes it a natural way to promote Queue items into finished skills.
Deterministic Workflow Orchestrators Alongside Model Routers
In QFill, the Workflow Processor is a planning action that you then carry out by hand. Other frameworks turn the orchestrator into another model prompt that decides which specialist to call next. Google ADK supports model-driven routing through a root LlmAgent, but it also provides deterministic workflow agents that control execution flow in code without spending extra tokens on routing:
SequentialAgent: Runs a list of subagents in strict order, passing the sameInvocationContextfrom step to step. The five-step onboarding documentation workflow in Workflow Processor becomes a singleSequentialAgent.ParallelAgent: Runs multiple subagents concurrently on the same input. For example, the Analyst can run Update with New Information, Relevance Evaluation, and Fact Check in parallel and write each result to its own key insession.state.LoopAgent: Repeatedly runs a sequence of subagents until a quality condition is met ormax_iterationsis reached. This turns the catalog guideline to pair creation with verification into an automated runtime pattern: one specialist creates the work (such as Merge Sources or Feature Implementation), a second specialist checks it (such as Retention Audit or Regression Audit), and the loop stops when the audit signals completion or its iteration limit is reached. Reaching the limit is not a passing result; the application must check audit status before accepting or publishing the draft.
Explicit State Passing with output_key
When several specialists collaborate in a pipeline, summarizing outputs in chat messages can drop important details. In Google ADK, every LlmAgent can declare an output_key (for example, output_key="audit_findings"). When that specialist finishes, ADK automatically writes its final response into session.state["audit_findings"].
Downstream specialists can then inject that exact output into their own instructions using curly-brace placeholders such as {audit_findings}. A trailing question mark, as in {retention_report?}, marks a value that may not exist yet. This gives the Editor direct access to the previous step's work without relying on conversational memory.
Versioned Deliverables with ArtifactService
Google ADK separates conversational state (session.state) from file deliverables (Artifacts). An ADK Artifact is a named, versioned google.genai.types.Part object containing raw binary or text bytes and a MIME type (such as text/markdown, application/pdf, or text/csv).
Instead of dumping a long MediaWiki page or a compiled report into the chat stream, a tool or callback calls await context.save_artifact(filename="Personal_Productivity.wiki", artifact=part):
- Every save with the same filename automatically creates a new version number (version 0, 1, 2, and so on).
- Downstream agents such as the reviewer or a merge editor can load specific versions via
await context.load_artifact(filename="Personal_Productivity.wiki")or the built-inLoadArtifactsTool. - Storage is backed by
InMemoryArtifactServiceduring local testing orGcsArtifactService(Google Cloud Storage) for persistent production archives, and can be scoped to either the currentsessionor theusernamespace across all sessions.
Which Catalog Members Should Become Runtime Agents
| Catalog member | Recommended Gemini implementation | Reason |
|---|---|---|
| Workflow Processor | SequentialAgent, ParallelAgent, LoopAgent, or root LlmAgent
|
Use deterministic workflow agents for known pipelines and a root LlmAgent for open-ended triage
|
| Analyst | LlmAgent with search (through a small search agent) and SkillToolset
|
Benefits from Google Search grounding, read-only permissions, and parallel audit execution |
| Reviewer (runtime-only) | LlmAgent paired in a LoopAgent with the creator agent
|
Fresh context and code execution let it act as an automated critic in generator and critic loops |
| Developer | LlmAgent with BuiltInCodeExecutor or local shell and MCP tools
|
Needs code execution, repository tools, and isolated iteration |
| Editor | One or more LlmAgent instances with SkillToolset and a MediaWiki McpToolset
|
Reads audit state via {output_key}, uses Gemini's long context for large merges, and saves finished wiki markup as a versioned artifact
|
| Strategist | Inline skills in Gemini CLI, or an LlmAgent in ADK
|
Clarify Requirements and Solution Development run interactively with the user; design actions can run as skills |
| Team Manager | LlmAgent with search
|
Self-contained domain research |
| Strategist continuity actions | Skills combined with session.state, MemoryService, and handoff artifacts
|
Summarize session.state keys and write durable HANDOFF.md and DECISIONS.md artifacts
|
Guardrails, Callbacks, and Consent
Gemini provides explicit permission boundaries in both the terminal and the SDK:
- Gemini CLI consent prompts: In Gemini CLI, skill activation and tool execution are subject to configured permission policies. The documented interactive skill flow shows the name, description, and folder path before activation consent. Actual tool confirmations depend on permission mode, policy, trust settings, and prior approvals; do not assume every write necessarily triggers a new prompt.
- ADK callbacks as guardrails: In Google ADK, every agent supports lifecycle callbacks including
before_agent_callback,before_model_callback,before_tool_callback, andafter_tool_callback. Abefore_tool_callbackinspects the tool name and arguments before execution and can block a call, validate inputs against a policy, or require human confirmation before allowing a write operation.
Recommended Source Layout
Gemini CLI discovers .agents/skills/. The ADK example explicitly loads that same directory from application code; it does not rely on automatic workspace discovery. This lets both use the Cross-Vendor Source Layout. Claude Code looks in .claude/skills/ instead, which is why that layout links or copies the same folders there. Gemini adds:
agent-catalog/
GEMINI.md ← shared workspace rules and house style for Gemini CLI
.gemini/
settings.json ← Gemini CLI settings and MCP server wiring
adk_app/
__init__.py
agent.py ← root_agent definition for `adk web` and `adk run`
workflows.py ← SequentialAgent, ParallelAgent, and LoopAgent pipelines
tools.py ← FunctionTools, artifact savers, and McpToolset wiring
callbacks.py ← before_tool_callback guardrails
Implementation boundary. ADK Skills are documented as experimental. The Python sample below illustrates composition, not a tested complete application. Configure a runner, session and artifact services, actual source inputs, dependencies, and permissions. A reviewer sharing session history is not automatically independent merely because it has another name.
Example Google ADK Skill and Workflow Wiring
In Google ADK, you load the existing SKILL.md directories from disk using load_skill_from_dir and bundle them into a SkillToolset for each specialist. You can then wire those specialists into deterministic pipelines, add a creation and verification loop, and save the final output as a versioned ADK Artifact.
Two details in this example reflect current practice. The model ID comes from an environment variable, because Gemini model names change several times a year and hard-coded IDs go stale. And Google Search runs in its own small agent exposed through AgentTool, because ADK has historically restricted how built-in tools such as google_search combine with other tools in a single agent.
import os
from pathlib import Path
from google.genai import types
from google.adk.agents import LlmAgent, SequentialAgent, LoopAgent
from google.adk.skills import load_skill_from_dir
from google.adk.tools import google_search
from google.adk.tools.agent_tool import AgentTool
from google.adk.tools.skill_toolset import SkillToolset
from google.adk.tools.tool_context import ToolContext
BASE_DIR = Path(__file__).resolve().parent.parent
SKILLS_DIR = BASE_DIR / ".agents" / "skills"
AGENTS_DIR = BASE_DIR / "agents"
# Set ADK_MODEL to a current Gemini model ID from the Gemini API models page.
MODEL = os.environ["ADK_MODEL"]
def load_prompt(filename: str) -> str:
return (AGENTS_DIR / filename).read_text(encoding="utf-8")
def load_skills(*skill_names: str) -> SkillToolset:
skills = [load_skill_from_dir(SKILLS_DIR / name) for name in skill_names]
return SkillToolset(skills=skills)
async def save_wiki_artifact(
content: str,
filename: str = "updated_page.wiki",
tool_context: ToolContext = None,
) -> dict:
"""Saves finished MediaWiki markup as a versioned ADK Artifact."""
if tool_context is None:
raise ValueError("Artifact saving requires a configured ToolContext")
if not tool_context.state.get("final_validation_passed", False):
return {"status": "blocked", "reason": "Final page validation is required"}
part = types.Part.from_bytes(
data=content.encode("utf-8"),
mime_type="text/plain",
)
version = await tool_context.save_artifact(filename=filename, artifact=part)
return {"status": "saved", "filename": filename, "version": version}
def exit_loop(tool_context: ToolContext) -> dict:
"""Call this when the retention audit finds nothing missing."""
tool_context.state["retention_passed"] = True
tool_context.actions.escalate = True
return {"status": "retention confirmed"}
search_agent = LlmAgent(
name="search_agent",
model=MODEL,
description="Runs Google Search and returns findings with source URLs.",
instruction="Search the web and report findings with their source URLs.",
tools=[google_search],
)
analyst = LlmAgent(
name="analyst",
model=MODEL,
description="Checks material for currentness, relevance, and gaps.",
instruction=load_prompt("research-analyst.md"),
tools=[
AgentTool(agent=search_agent),
load_skills("a-update", "a-relevance", "a-gap", "a-factcheck"),
],
output_key="audit_findings",
)
merge_editor = LlmAgent(
name="merge_editor",
model=MODEL,
description="Merges several sources into one document with zero data loss.",
instruction=(
load_prompt("technical-editor.md")
+ "\nIncorporate these audit findings:\n{audit_findings}"
+ "\nFix anything listed in the last retention report:\n{retention_report?}"
),
tools=[load_skills("e-merge", "e-recon")],
output_key="merged_draft",
)
retention_reviewer = LlmAgent(
name="retention_reviewer",
model=MODEL,
description="Confirms that the merged draft kept every fact from the sources.",
instruction=(
load_prompt("reviewer.md")
+ "\nAudit this draft against the sources:\n{merged_draft}"
+ "\nIf nothing is missing, call exit_loop."
),
tools=[load_skills("e-retention"), exit_loop],
output_key="retention_report",
)
# Creation paired with verification: merge, audit, and repeat up to three times.
merge_until_retained = LoopAgent(
name="merge_until_retained",
sub_agents=[merge_editor, retention_reviewer],
max_iterations=3,
)
page_editor = LlmAgent(
name="page_editor",
model=MODEL,
description="Updates, expands, and formats technical documentation and wiki pages.",
instruction=(
load_prompt("technical-editor.md")
+ "\nUpdate the page using this merged draft:\n{merged_draft}"
+ "\nReturn the final draft for validation; do not save it yet."
),
tools=[
load_skills("e-wp", "e-ws", "e-expand", "e-org"),
],
output_key="final_wiki_page",
)
# Deterministic pipeline for the onboarding documentation refresh workflow
refresh_docs_pipeline = SequentialAgent(
name="refresh_docs_pipeline",
description="Audits, merges with verification, and updates multi-page documentation.",
sub_agents=[analyst, merge_until_retained, page_editor],
)
Before each run, clear retention_passed and final_validation_passed. The host must stop the pipeline if the merge loop exhausts its limit without passing. The final editing step can introduce new omissions, so validate final_wiki_page against the original sources after that step. Only a separate validation component should set final_validation_passed and call the artifact saver with the exact validated bytes. The example leaves this host-level gate to the application; defining a flag alone does not enforce it.
Packaging as a Gemini CLI Extension
Just as Claude Code and OpenAI support plugins, Gemini CLI packages reusable skills, MCP servers, and slash commands into an Extension. An extension directory contains a gemini-extension.json manifest alongside your skills:
primo-gemini-extension/
gemini-extension.json
GEMINI.md
skills/
a-update/
SKILL.md
e-expand/
SKILL.md
d-advtest/
SKILL.md
The manifest wires your MCP servers and context rules so any project or workstation can install the entire PRIMO.ai catalog with gemini extensions install or link it locally during development with gemini skills link:
{
"name": "primo-agent-library",
"version": "1.0.0",
"description": "Reusable PRIMO.ai specialist skills and MediaWiki MCP tools.",
"contextFileName": "GEMINI.md",
"mcpServers": {
"mediawiki": {
"command": "python",
"args": ["-m", "mcp_mediawiki_server"]
}
}
}
Migration Path
Step 1: Unify Your Action Library in .agents/skills/
Place all 70 action folders (68 once the two Queue items stay in drafts/) inside .agents/skills/ with valid YAML frontmatter (name and description) in each SKILL.md file. Gemini CLI, Google ADK, and Codex read this directory directly, and Claude Code reads it through the link or copy in .claude/skills/, so you maintain one copy of your actions across every vendor. Put your recurring output rules (active voice, conversational tone, no em dashes, MediaWiki formatting) into GEMINI.md, or configure Gemini CLI to read the shared AGENTS.md.
Step 2: Test Specialist Personas in Google AI Studio or Gems
Before writing orchestration code, test your agent definitions in Google AI Studio or as custom Gems in the Gemini app. Enable Grounding with Google Search for the Analyst and the Team Manager, and Code Execution for the Developer and the reviewer. This validates your specialist instructions and tool behavior with almost no setup.
Step 3: Run Interactive Workflows in Gemini CLI
Open Gemini CLI in your project directory. Gemini CLI automatically loads GEMINI.md and discovers the skills inside .agents/skills/.
- Run
/skills listto verify that every action is discovered. - Test natural requests to verify that your description fields trigger the right skill via progressive disclosure. Pay special attention to near-duplicates such as the two Regression Audits.
- Use the built-in
skill-creatorskill whenever you want Gemini to draft a new action folder from a conversational description.
Step 4: Build Deterministic Pipelines in Google ADK
Install the Agent Development Kit (pip install google-adk) and wire your first multi-agent workflow in Python:
- Start with the Analyst, the Editor, and the reviewer as
LlmAgentinstances equipped withSkillToolset. - Connect sequential steps using
SequentialAgentand pass outputs explicitly viaoutput_keyand{state_key}placeholders. - Wrap creation and verification pairs (such as Merge Sources plus Retention Audit, or Feature Implementation plus Regression Audit) inside a
LoopAgentso the audit runs automatically after creation. - Run
adk weblocally to open the ADK visual debugger, where you can inspect every event, skill activation, state change, and tool call.
Step 5: Add ArtifactService, Guardrails, and MCP Integrations
- Configure
InMemoryArtifactService(for local runs) orGcsArtifactService(for durable cloud storage) on your ADKRunnerso finished wiki pages, code files, and reports are saved and versioned viacontext.save_artifact(). - Connect your MediaWiki API and local repositories using
McpToolset. - Add a
before_tool_callbackguardrail so read-only tools execute freely while write operations (such as updating a live page on PRIMO.ai) require explicit confirmation. - When a workflow needs to run as an always-on service, deploy the ADK application to a managed runtime such as Vertex AI Agent Engine or Google Cloud Run.
In the Gemini ecosystem, open-standard skills load expertise on demand, deterministic workflow agents sequence the team, shared session state connects the steps, and the Artifact Service versions every deliverable.
Gemini See Also
- Agent Development Kit (ADK) Documentation (Google)
- Skills for ADK agents (Google ADK)
- Google Cloud Skill Registry (Google ADK)
- Artifacts in Agent Development Kit (Google ADK)
- Developer's Guide to Building ADK Agents with Skills (Google Developers Blog)
- Google ADK Recipes and Sample Agents (GitHub)
- Agent Skills (Gemini CLI documentation)
- Using Agent Skills in Gemini CLI (Gemini CLI Documentation)
- Gemini CLI Extensions Directory (Gemini CLI)
- Agent Skills Open Specification (agentskills.io)
Research and Evaluation
A productivity library should be evaluated on actual tasks, not only by whether prompts appear well written. Each action family needs appropriate acceptance criteria and representative examples. Research briefs should be checked for accurate sources; wiki updates for syntax and retention; code changes for tests and regression; fantasy sports recommendations for current underlying data and valid league assumptions.
Peer-Reviewed Follow-Up to the Consultant Experiment
A 2026 peer-reviewed paper in Organization Science, based on a previously released field experiment with 758 consultants, examined the uneven usefulness of generative AI. For tasks within the tested AI capability frontier, access to GPT-4 was associated with completing about 12.2% more tasks and doing them 25.1% faster on average, with higher measured quality. The findings did not apply uniformly to all tasks; results worsened for some activities outside the model's useful capability range. This is the jagged technology frontier problem: adjacent tasks can differ substantially in AI suitability.
Navigating the Jagged Technological Frontier | Organization Science, published 2026 Peer-reviewed field experiment with 758 knowledge workers, identifying both productivity improvements and capability boundaries.
Back to the Beginnings of AI at Work | Harvard Business School AI Institute, April 9, 2026 Explanation of the research and its practical implications.
Practical Evaluation Method
- Define a task, reference materials, and a clear passing standard.
- Run the task without the candidate action and record total completion time and final quality.
- Run matched tasks from the same task family using the relevant shortcut with authorized resources and tools. Alternate the order or randomize assignment where practical so familiarity with a repeated task does not masquerade as an AI benefit.
- Include source checking, revisions, and human quality control in the measured time.
- Compare accuracy, completeness, retention, reproducibility, and total effort.
- Repeat across several varied examples instead of relying on one demonstration.
- Record failures, modify the specific action, and rerun regression tests.
Useful Metrics
| Measure | Question | Example acceptance test |
|---|---|---|
| Task success | Did the intended outcome occur? | The exported wiki page renders correctly with links retained |
| Source accuracy | Are cited claims supported by the actual sources? | Randomly inspect factual claims and their primary sources |
| Retention | Did any required material disappear? | Compare retained internal wiki links against the original page |
| Regression | Did changes break earlier behavior? | Run existing and edge-case tests after a bookmarklet modification |
| Time saved | Did end-to-end effort decrease? | Compare total time including validation and rework |
| Cost | Is the result worth model and tool expense? | Cost per accepted deliverable |
| Safety | Were permissions, privacy, and approval rules respected? | No unauthorized write or external disclosure |
Related Videos
These six video IDs are retained from earlier versions. Their current titles, durations, and availability were not established by the source files; they are historical links, not newly verified recommendations:
Additional Viewing
Andrej Karpathy's Software Is Changing (Again) talk at Y Combinator's AI Startup School (2025) argues that prompts in English are now programs ("Software 3.0") and that the best AI products are "partial autonomy" apps with an adjustable autonomy slider and fast generate-then-verify loops that keep the AI on a short leash. It is the clearest high-level case for treating a prompt library as software and for pairing every creation step with a verification step. Watch on YouTube
Barry Zhang and Mahesh Murag of Anthropic explain, in the AI Engineer talk linked below, why they recommend one general-purpose agent equipped with many skills over many bespoke agents, and how skill folders, progressive disclosure, and scripts work in practice. This recording directly addresses the agent and skill split used throughout this page; no duration threshold is asserted here. Watch on YouTube
Further recordings worth watching (event pages, not embeds):
- State of AI Agents | Andrew Ng at LangChain Interrupt Andrew Ng's conversation at LangChain's 2025 agent conference about agentic workflows, evaluation, and where builders get stuck.
- How we Claude Code | Code with Claude A session on how Anthropic's own teams use Claude Code day to day.
- Tool, skill, or subagent? | Code with Claude London A session on deciding when instructions should become a tool, a skill, or a subagent: the same decision the "Which agents become subagents" tables on this page make.
- Don't Build Agents, Build Skills Instead | AI Engineer The conference page for the Anthropic skills talk above.
References
Productivity Studies
- Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity | METR July 2025 randomized trial: 16 experienced developers, 246 tasks, 19 percent slower with AI despite believing they were faster.
- We are Changing our Developer Productivity Experiment Design | METR February 2026 update explaining the selection problems that made newer, more favorable data hard to interpret.
- Estimating AI productivity gains from Claude conversations | Anthropic November 2025 estimate of about 80 percent task-level time savings from 100,000 conversations, with its macroeconomic extrapolation and caveats.
- Large Language Models, Small Labor Market Effects | Anders Humlum and Emilie Vestergaard, NBER Danish survey and administrative data: average time savings of 2.8 percent of work hours and no detectable effect on earnings.
- The Impact of Generative AI on Work Productivity | Bick, Blandin, and Deming, Federal Reserve Bank of St. Louis February 2025 survey: users saved 5.4 percent of work hours, about 1.4 percent across all workers.
- Generative AI at Work | Erik Brynjolfsson, Danielle Li, and Lindsey Raymond, NBER Customer-support rollout: The 2023 working paper reported a 14 percent average gain and 34 percent for novice/low-skilled workers; later published in the Quarterly Journal of Economics.
- Navigating the Jagged Technological Frontier | Fabrizio Dell'Acqua and colleagues, Harvard Business School and BCG Field experiment with 758 consultants showing large gains inside the AI's capability frontier and more errors outside it.
- Anthropic Economic Index report: Economic primitives | Anthropic January 2026 report adding task complexity, autonomy, and success measures to usage tracking.
- Anthropic Economic Index dataset | Anthropic on Hugging Face Open data behind the Economic Index reports, including the September 2025 release on directive and collaborative use.
Context Engineering and Multi-Agent Design
- Building effective agents | Anthropic December 2024 foundation for the workflow-versus-agent distinction and simple composable patterns.
- How we built our multi-agent research system | Anthropic June 2025 account of orchestrator and subagent design, the 90.2 percent evaluation gain, and the roughly 15 times token cost.
- Don't Build Multi-Agents | Walden Yan, Cognition June 2025 argument that parallel subagents fragment context and conflict, with the case for single-threaded agents.
- Multi-Agents: What's Actually Working | Cognition Cognition's follow-up on which multi-agent patterns hold up in practice.
- How and when to build multi-agent systems | LangChain A practitioner's reconciliation of the Anthropic and Cognition positions.
- Effective context engineering for AI agents | Anthropic September 2025 guidance on treating context as a finite resource: just-in-time retrieval, compaction, notes, and subagents.
- Context Rot: How Increasing Input Tokens Impacts LLM Performance | Chroma July 2025 study of 18 models showing accuracy declines as inputs grow.
- Lost in the Middle: How Language Models Use Long Contexts | Nelson F. Liu and colleagues, TACL 2024 Evidence that models use information at the start and end of long inputs better than information in the middle.
Standards and Platforms
- Agent Skills Specification | agentskills.io The open
SKILL.mdformat: required fields, naming rules, optional folders, and progressive disclosure guidance. - Equipping agents for the real world with Agent Skills | Anthropic October 2025 introduction of skills and the design reasoning behind progressive disclosure.
- Linux Foundation Announces the Formation of the Agentic AI Foundation | Linux Foundation December 2025 announcement covering MCP, AGENTS.md, and goose.
- AGENTS.md | Agentic AI Foundation The shared instruction-file format read by Codex and many other coding agents.
- Model Context Protocol | Agentic AI Foundation The protocol agents use to reach tools and data sources.
- OpenAI Launches the Agents API in Public Beta | MarkTechPost September 2026 coverage of the managed Codex harness, subagents, and hosted sandboxes.
- OpenAI Agent Builder Shutdown: Migrate Before Nov 30, 2026 | Matthew Wong Migration notes on Agent Builder's scheduled shutdown.
- Anthropic rolls out Claude Managed Agents | Paul Krill, InfoWorld April 2026 coverage of Anthropic's hosted agent runtime.
- Google Announces New Gemini Enterprise Agent Platform | THE Journal Coverage of Google's April 2026 consolidation of its enterprise agent tools.
- What is Manifest V3? | Google Chrome Developers Background on the extension platform QFill uses, including service workers in place of background pages.
Additional Implementation and Research Sources
- Agent Skills | Anthropic, October 2025 Reusable instruction and resource packages.
- Agent Orchestration | OpenAI Delegation and ownership models.
- Google Agent Development Kit | Google Agent and workflow architecture.
- Gemini CLI Skills | Google Official skill packaging tutorial.
- Skills for ADK Agents | Google SkillToolset, filesystem loading, and experimental status.
- Agent Skills | Gemini CLI Discovery paths and activation consent.
- Agent Builder | OpenAI Official notice of the scheduled November 30, 2026 shutdown.
Conclusion
AI personal productivity improves when reusable instructions are tied to clear responsibilities, authoritative input, suitable tools, and measurable completion standards. The QFill default package now supplies a concrete directory of seven agent groups and 70 shortcuts. Its value is not the number of saved prompts alone, but the ability to choose and reuse focused procedures without repeatedly rewriting the same instructions.
The manifest also establishes a necessary architectural boundary: saved action definitions do not automatically become autonomous agents. Claude, OpenAI, and Gemini runtimes can implement versions of the specialist/action pattern, but each requires explicit tools, permissions, source mapping, state management, and regression testing.
The governing principle remains simple: choose a specialist, choose an action, supply the right material, perform the work with appropriate authority, and verify the finished result.