← Forward DeployedCONTENT HISTORY

Update to Forward Deployed

Snapshot Nov 1, 2026 · 07:08 UTC · version 0.6.9

Collection source: downloaded plugin package.

WHAT CHANGED

Instructions updated for capability-exploration

Full description — Now says: proofs of concept,

Observed in instructions or declared skills. Runtime behavior has not been tested.

Save Forward Deployed and check future changes in Following.

Up to 10 plugins free · no card required.

All fields and original values.

Full description

Before

Oct 28, 2026 · 13:10 UTC

After

Nov 1, 2026 · 07:08 UTC

proofs of concept,

Skill instructions

Before

Oct 28, 2026 · 13:10 UTC

After

Nov 1, 2026 · 07:08 UTC

proofs of concept,

Compare saved observations

Download comparison JSON

SKILL.md text changes

− removed · + added

--- before
+++ after
@@ -1,6 +1,6 @@
 ---
 name: capability-exploration
-description: Discover and test what current AI products, models, runtimes, and enterprise tools can accomplish on a meaningful task. Use for capability exploration, platform choices, buy/adapt/build decisions, and finding a better way to deliver an AI workflow.
+description: Discover and test what current AI products, models, runtimes, and enterprise tools can accomplish on a meaningful task. Use for capability exploration, platform choices, buy/adapt/build decisions, proofs of concept, and finding a better way to deliver an AI workflow.
 ---
 
 # Capability exploration
Full technical diff · 2 changed fields

changed /description

BEFORE
"Discover and test what current AI products, models, runtimes, and enterprise tools can accomplish on a meaningful task. Use for capability exploration, platform choices, buy/adapt/build decisions, and finding a better way to deliver an AI workflow."
AFTER
"Discover and test what current AI products, models, runtimes, and enterprise tools can accomplish on a meaningful task. Use for capability exploration, platform choices, buy/adapt/build decisions, proofs of concept, and finding a better way to deliver an AI workflow."

changed /skill_md_contents

BEFORE
"---\nname: capability-exploration\ndescription: Discover and test what current AI products, models, runtimes, and enterprise tools can accomplish on a meaningful task. Use for capability exploration, platform choices, buy/adapt/build decisions, and finding a better way to deliver an AI workflow.\n---\n\n# Capability exploration\n\nFind the strongest practical way to complete the work. Explore the combination of model, business context, tools, and execution environment before freezing the solution. A useful discovery can change the task people delegate, the product they use, or how much custom software they need.\n\n## Give the system meaningful work\n\nStart with a representative assignment and a recognizable finished result: investigate an incident and restore the affected service, migrate a repository and pass its acceptance checks, or produce a research brief that resolves a decision. Identify what makes the work difficult and what an experienced person would inspect to accept it.\n\nKeep room for a better outcome than the initial feature request. \"Summarize our tickets\" could become investigating recurring failures, reproducing one, and preparing a tested fix. Establish whether that broader assignment serves the user's objective; then explore the capability that would make it possible.\n\n## Discover the available building blocks\n\nInspect the host's tools, skills, files, applications, and authorized account surfaces. Follow promising capabilities through operator, administrator, and developer interfaces. An incumbent product may already provide the work surface, permissions, source relationships, or task lifecycle that a proposed new application would otherwise recreate.\n\nResearch current primary documentation where capability or fit remains uncertain. Check the model and the product or runtime exposing it: available tools, supported inputs, execution duration, background work, recovery, deployment locations, and data handling can differ. Verify the commercial or operational constraint that affects this choice, including licensing, quotas, and cost.\n\nInvestigate unfamiliar approaches when they could change the outcome. A workforce product, an extension to an enterprise application, a managed agent service, and an application with its own runtime solve different parts of the problem. Compare the plausible arrangements for this task. Widen the search while a consequential gap remains; stop when further candidates are unlikely to change the decision.\n\n## Test the whole configuration\n\nBegin with a capable configuration suited to the difficult work and references that convey the intended result: business definitions, working examples, source code, executable acceptance checks, or a detailed design. Keep useful detail accessible as the task develops. This establishes a credible capability ceiling; then improve economics and operating fit while preserving the result that matters.\n\nLet the system investigate, create, inspect its results, and revise its approach. When it stalls, identify the missing capability: can it run the application, inspect logs, query the relevant state, or exercise the receiving workflow? Improve that access or interface and retry the assignment. More instructions to verify work cannot replace a usable verification path.\n\nRecord the configuration and inspect both the delivered artifact and the resulting environment. Measure completion, quality, elapsed time, human repair, and cost at the level of accepted work. Use comparable tasks when comparing candidates. Repeat variable results and distinguish shortcomings in reasoning from missing context, weak tool descriptions, access failures, or runtime behavior.\n\nWhen upgrading a model or runtime, also test a simpler arrangement. Fixed task splits, forced context resets, or repeated review loops may compensate for a limitation that has changed. Remove them when representative results support it, while retaining business requirements and enforced permissions. Test whether the new configuration can own a larger useful assignment as well as perform the old one faster.\n\nChoose additional probes from the claim the design depends on. Test resumption if tasks cross sessions; exercise the receiving system if the value depends on an action; inspect editability if the deliverable is a working document. Keep simulated behavior and executed product behavior distinguishable.\n\nRead [the engineering migration probe](references/engineering-migration.md) when the question is whether a model and harness can own substantial work through a tested artifact and an interruption.\n\n## Turn observations into a choice\n\nDescribe the recommended arrangement as something a team can operate: where people work, what the agent completes, which systems supply context and receive actions, where progress persists, and who maintains the custom parts.\n\nChoose managed or owned execution based on the responsibilities the workload requires. A managed runtime can supply lifecycle and execution facilities; an owned runtime can support unusual network, tool, or control requirements. Inspect the chosen service's current interfaces before assigning it either advantage. A capable employee product may already be sufficient.\n\nExplain the discovery that changed the design, the material alternative, and the unresolved fact that could reverse the recommendation. Carry successful probes into the requested solution or implementation. Preserve useful artifacts and primary sources so the next team can reproduce the reasoning. Revisit the choice when the workload or available capabilities change; keep the selection method durable.\n"
AFTER
"---\nname: capability-exploration\ndescription: Discover and test what current AI products, models, runtimes, and enterprise tools can accomplish on a meaningful task. Use for capability exploration, platform choices, buy/adapt/build decisions, proofs of concept, and finding a better way to deliver an AI workflow.\n---\n\n# Capability exploration\n\nFind the strongest practical way to complete the work. Explore the combination of model, business context, tools, and execution environment before freezing the solution. A useful discovery can change the task people delegate, the product they use, or how much custom software they need.\n\n## Give the system meaningful work\n\nStart with a representative assignment and a recognizable finished result: investigate an incident and restore the affected service, migrate a repository and pass its acceptance checks, or produce a research brief that resolves a decision. Identify what makes the work difficult and what an experienced person would inspect to accept it.\n\nKeep room for a better outcome than the initial feature request. \"Summarize our tickets\" could become investigating recurring failures, reproducing one, and preparing a tested fix. Establish whether that broader assignment serves the user's objective; then explore the capability that would make it possible.\n\n## Discover the available building blocks\n\nInspect the host's tools, skills, files, applications, and authorized account surfaces. Follow promising capabilities through operator, administrator, and developer interfaces. An incumbent product may already provide the work surface, permissions, source relationships, or task lifecycle that a proposed new application would otherwise recreate.\n\nResearch current primary documentation where capability or fit remains uncertain. Check the model and the product or runtime exposing it: available tools, supported inputs, execution duration, background work, recovery, deployment locations, and data handling can differ. Verify the commercial or operational constraint that affects this choice, including licensing, quotas, and cost.\n\nInvestigate unfamiliar approaches when they could change the outcome. A workforce product, an extension to an enterprise application, a managed agent service, and an application with its own runtime solve different parts of the problem. Compare the plausible arrangements for this task. Widen the search while a consequential gap remains; stop when further candidates are unlikely to change the decision.\n\n## Test the whole configuration\n\nBegin with a capable configuration suited to the difficult work and references that convey the intended result: business definitions, working examples, source code, executable acceptance checks, or a detailed design. Keep useful detail accessible as the task develops. This establishes a credible capability ceiling; then improve economics and operating fit while preserving the result that matters.\n\nLet the system investigate, create, inspect its results, and revise its approach. When it stalls, identify the missing capability: can it run the application, inspect logs, query the relevant state, or exercise the receiving workflow? Improve that access or interface and retry the assignment. More instructions to verify work cannot replace a usable verification path.\n\nRecord the configuration and inspect both the delivered artifact and the resulting environment. Measure completion, quality, elapsed time, human repair, and cost at the level of accepted work. Use comparable tasks when comparing candidates. Repeat variable results and distinguish shortcomings in reasoning from missing context, weak tool descriptions, access failures, or runtime behavior.\n\nWhen upgrading a model or runtime, also test a simpler arrangement. Fixed task splits, forced context resets, or repeated review loops may compensate for a limitation that has changed. Remove them when representative results support it, while retaining business requirements and enforced permissions. Test whether the new configuration can own a larger useful assignment as well as perform the old one faster.\n\nChoose additional probes from the claim the design depends on. Test resumption if tasks cross sessions; exercise the receiving system if the value depends on an action; inspect editability if the deliverable is a working document. Keep simulated behavior and executed product behavior distinguishable.\n\nRead [the engineering migration probe](references/engineering-migration.md) when the question is whether a model and harness can own substantial work through a tested artifact and an interruption.\n\n## Turn observations into a choice\n\nDescribe the recommended arrangement as something a team can operate: where people work, what the agent completes, which systems supply context and receive actions, where progress persists, and who maintains the custom parts.\n\nChoose managed or owned execution based on the responsibilities the workload requires. A managed runtime can supply lifecycle and execution facilities; an owned runtime can support unusual network, tool, or control requirements. Inspect the chosen service's current interfaces before assigning it either advantage. A capable employee product may already be sufficient.\n\nExplain the discovery that changed the design, the material alternative, and the unresolved fact that could reverse the recommendation. Carry successful probes into the requested solution or implementation. Preserve useful artifacts and primary sources so the next team can reproduce the reasoning. Revisit the choice when the workload or available capabilities change; keep the selection method durable.\n"
Full snapshot data
{
  "description": "Discover and test what current AI products, models, runtimes, and enterprise tools can accomplish on a meaningful task. Use for capability exploration, platform choices, buy/adapt/build decisions, proofs of concept, and finding a better way to deliver an AI workflow.",
  "included_files": [
    {
      "relative_path": "references/engineering-migration.md",
      "size_in_bytes": 5157
    }
  ],
  "name": "capability-exploration",
  "skill_md_contents": "---\nname: capability-exploration\ndescription: Discover and test what current AI products, models, runtimes, and enterprise tools can accomplish on a meaningful task. Use for capability exploration, platform choices, buy/adapt/build decisions, proofs of concept, and finding a better way to deliver an AI workflow.\n---\n\n# Capability exploration\n\nFind the strongest practical way to complete the work. Explore the combination of model, business context, tools, and execution environment before freezing the solution. A useful discovery can change the task people delegate, the product they use, or how much custom software they need.\n\n## Give the system meaningful work\n\nStart with a representative assignment and a recognizable finished result: investigate an incident and restore the affected service, migrate a repository and pass its acceptance checks, or produce a research brief that resolves a decision. Identify what makes the work difficult and what an experienced person would inspect to accept it.\n\nKeep room for a better outcome than the initial feature request. \"Summarize our tickets\" could become investigating recurring failures, reproducing one, and preparing a tested fix. Establish whether that broader assignment serves the user's objective; then explore the capability that would make it possible.\n\n## Discover the available building blocks\n\nInspect the host's tools, skills, files, applications, and authorized account surfaces. Follow promising capabilities through operator, administrator, and developer interfaces. An incumbent product may already provide the work surface, permissions, source relationships, or task lifecycle that a proposed new application would otherwise recreate.\n\nResearch current primary documentation where capability or fit remains uncertain. Check the model and the product or runtime exposing it: available tools, supported inputs, execution duration, background work, recovery, deployment locations, and data handling can differ. Verify the commercial or operational constraint that affects this choice, including licensing, quotas, and cost.\n\nInvestigate unfamiliar approaches when they could change the outcome. A workforce product, an extension to an enterprise application, a managed agent service, and an application with its own runtime solve different parts of the problem. Compare the plausible arrangements for this task. Widen the search while a consequential gap remains; stop when further candidates are unlikely to change the decision.\n\n## Test the whole configuration\n\nBegin with a capable configuration suited to the difficult work and references that convey the intended result: business definitions, working examples, source code, executable acceptance checks, or a detailed design. Keep useful detail accessible as the task develops. This establishes a credible capability ceiling; then improve economics and operating fit while preserving the result that matters.\n\nLet the system investigate, create, inspect its results, and revise its approach. When it stalls, identify the missing capability: can it run the application, inspect logs, query the relevant state, or exercise the receiving workflow? Improve that access or interface and retry the assignment. More instructions to verify work cannot replace a usable verification path.\n\nRecord the configuration and inspect both the delivered artifact and the resulting environment. Measure completion, quality, elapsed time, human repair, and cost at the level of accepted work. Use comparable tasks when comparing candidates. Repeat variable results and distinguish shortcomings in reasoning from missing context, weak tool descriptions, access failures, or runtime behavior.\n\nWhen upgrading a model or runtime, also test a simpler arrangement. Fixed task splits, forced context resets, or repeated review loops may compensate for a limitation that has changed. Remove them when representative results support it, while retaining business requirements and enforced permissions. Test whether the new configuration can own a larger useful assignment as well as perform the old one faster.\n\nChoose additional probes from the claim the design depends on. Test resumption if tasks cross sessions; exercise the receiving system if the value depends on an action; inspect editability if the deliverable is a working document. Keep simulated behavior and executed product behavior distinguishable.\n\nRead [the engineering migration probe](references/engineering-migration.md) when the question is whether a model and harness can own substantial work through a tested artifact and an interruption.\n\n## Turn observations into a choice\n\nDescribe the recommended arrangement as something a team can operate: where people work, what the agent completes, which systems supply context and receive actions, where progress persists, and who maintains the custom parts.\n\nChoose managed or owned execution based on the responsibilities the workload requires. A managed runtime can supply lifecycle and execution facilities; an owned runtime can support unusual network, tool, or control requirements. Inspect the chosen service's current interfaces before assigning it either advantage. A capable employee product may already be sufficient.\n\nExplain the discovery that changed the design, the material alternative, and the unresolved fact that could reverse the recommendation. Carry successful probes into the requested solution or implementation. Preserve useful artifacts and primary sources so the next team can reproduce the reasoning. Revisit the choice when the workload or available capabilities change; keep the selection method durable.\n"
}

SHA-256 of public snapshot: b7a9e0c5b17b85d5a5809af12c08b7e88e1746b4489ba7dffc27613779dabc4d