Skill Builder
Turns docs, repos, browser research, outputs, and workflows into strict Markdown skills with proof artifacts.
Skill operating system
Build, scale, govern, and optimize agent skills.
OWOJI stores source lineage, feedback, quality scores, improvement jobs, and the visible output each skill produced so agents can reuse instructions without guessing.
Skill Garden
Versioned skill storage with tags, feedback, risk notes, source provenance, and previewable results.
Skill Finder
Search by domain, task, tool, or use case and return the best skill plus what it can produce.
Governance loop
Periodic improvement searches keep skills current while audit logs protect trust.
Validation-first browser skill bundle
Start the garden with one reusable browser skill that follows the strongest current public pattern: a user-triggered prompt surface, a model-triggered MCP tool surface, a reusable context bundle, an explicit invocation-policy block, and a deterministic validation layer. Keep the core skill lean, move long docs or selectors into references/, add validator scripts only when they reduce guesswork, and require a fixed evidence manifest for proof artifacts.
Starter structure
name: validation-first browser skill bundle
when_to_use: Repeated authenticated browser tasks with stable acceptance checks
invocation_policy:
mode: auto-or-manual
argument_hint: "[goal] [start_url]"
allowed_tools:
- browser
- screenshot
disallowed_tools:
- external_publish
context: inline-or-fork
inputs:
- goal
- start_url
- account_profile
- output_schema
bundle:
entry_skill: SKILL.md
references:
- docs.md
- selectors.md
- policy.md
- examples.md
scripts:
- validate-output.ts
assets:
- evidence-manifest.json
prompt_surface:
- slash-style launcher for human-triggered runs
tool_surface:
name: owoji_browser_workflow
input_schema: { type: object, required: [goal, start_url] }
context_bundle:
- docs, examples, selectors, or policy URIs
- compile today from provenance.sources plus output_artifact.evidence
workflow:
- verify the source and required account
- load the smallest context bundle needed for this run
- bootstrap stable locators with codegen or recorder output when useful
- reuse saved browser state when allowed
- act through resilient locators, not brittle selectors
- return structured output plus evidence manifest entries
safety:
- require approval for writes or sensitive actions
- never commit auth artifacts or secrets
evals:
- exact required fields returned
- validator script passes on output schema and evidence manifest
- failure mode logged
- session closed and state persisted safelyWhat the sources agree on
MCP distinguishes prompts for users, tools for models, and resource templates for reusable context, while current skill docs keep emphasizing progressive disclosure: keep SKILL.md lean, move long guidance into bundled references, and use scripts when deterministic validation is cheaper than making the model improvise. Current skill docs also keep pushing invocation metadata: declare whether a skill is manual-only or auto-invocable, what arguments it expects, which tools it may use, and whether it belongs inline or in a forked context. Browser automation docs then add the operational layer: reuse auth state carefully and prefer resilient role, text, or test-id locators.
Split reusable data from presentation
If a skill needs both machine-usable data and a human-facing preview, do not overload one tool. Return complete structured data through a typed data surface with an explicit outputSchema, then attach the preview, widget, or proof artifact in a separate render step. That keeps the skill easier to validate, safer to reuse, and clearer for follow-up model calls.
Starter structure
data_ui_split:
data_tool:
returns: complete structured output
output_schema: required when returning structured data
render_step:
returns: proof artifact or widget
rule: presentation only; consumes prepared dataLow-risk rollout
1. Publish this as a visible starter template. 2. Tighten the daily skill-builder prompt so generated skills include a bundle plan for references/, optional validator scripts, an evidence manifest, typed outputs, and a data-vs-render split when previews are needed. 3. Keep the render step inside today’s proof-artifact fields until OWOJI later adds first-class data-tool and render-tool registry types.