365Skill: Discover, Validate & Share Agent Skills

What you’re actually getting with 365Skill

Most “agent skills” directories are just prompt dumps. They tell an agent *what to think*, not *how to work*. That works for one-shot demos and fails the moment you need something repeatable.

365Skill takes a different line: every skill in the repo has been battle-tested inside our own cross-border operations before it’s published. We ship three things together — a skill definition, an eval that measures it, and a deny-by-default gate that keeps untested skills out.

• Operator-built, not aspirational — The first three skills were made for our own sales and growth workflows, then opened.
• Evidence-gated — Nothing gets merged without passing its eval. If you can’t measure it, you can’t ship it.
• Apache-2.0 — Drop it into your product, your agent, or your team’s knowledge base with zero licensing friction.

The repo lives at en/products/365skill (part of the 365 product family). Since it’s open, you can read every decision, every test case, and every rejected idea — no demo theatre.

---

The three skills shipped so far (and why we built them)

We didn’t start with a taxonomy. We started with three real-world problems that waste operator hours every week.

These sound simple. That’s the point. A skill doesn’t need to be clever; it needs to be *reliable*. In our ops, five-step-dev cut rework caused by unclear task briefs by roughly 40 % over four weeks, simply because the agent runs a clarification step before writing a single line.

---

SKILL.md anatomy — readable by agents, reviewable by humans

Every 365Skill ships as a directory containing a SKILL.md file plus supporting assets (eval scripts, test fixtures). The format is deliberately flat: no schemas, no DSL, just a markdown file with well-known sections.

A typical SKILL.md contains:

• Metadata block — skill name, version, evals reference.
• Trigger condition — what signal tells the agent to invoke this skill.
• Step list — numbered actions the agent must execute, each with an observable output.
• Verification checklist — how a human (or a CI check) confirms the skill ran correctly.
• Failure modes — known ways this skill breaks and what to do.

The whole thing is designed so that:

• An agent can parse it and run it;
• A team lead can scan it in 90 seconds and decide if it’s fit for their context;
• A CI pipeline can execute the eval and block a release if it fails.

No point in a “standard format” that only one side can read. That’s just a prompt with extra steps.

---

How to install (90 seconds to your first skill)

The install path mirrors what you already do with agent frameworks: copy the skill directory into whichever client you use, then point your agent at it. Exact paths vary by client, so check the official docs for Claude Code, Cursor, Windsurf, or your platform of choice.

1. Clone the repo (or download the zip):

git clone https://github.com/laojin1900/365Skill.git

2. Inside the repo, pick the skill you want — say, five-step-dev.
3. Copy that skill folder into your agent client’s skills directory (look for custom_skills or user_skills in the client docs).
4. Restart or reload your agent so it picks up the new skill.
5. Run a test task and check the agent’s log to confirm the skill fired.

That’s it. No API keys, no account setup. The skill is plain text — you can edit it with any editor and version it with the rest of your project.

---

A worked example: five-step-dev on a real SEO content task

Let’s walk through what happens when I, Laojin, assign an agent a task using five-step-dev. This is exactly how we handle content operations for the insights engine that powers laojinchuhai.com.

Task: “Write an article comparing multi-model API gateways for indie developers.”

With five-step-dev active, the agent doesn’t start typing. It follows the five-step workflow:

• Clarify — The agent asks: target audience (indie devs shipping SaaS), comparison depth (pricing, latency, supported models), word count (1 200), any product mentions to include (our own AllModelsAPI vs OpenRouter). I answer in 3 minutes.
• Plan — The agent outputs a bullet outline with sections, data sources, and an internal link map. I approve or adjust.
• Implement — The agent writes the full draft, including a comparison table and CTA. I skip straight to the next step because I can review fast.
• Verify — The agent re-reads the draft against the plan and a short checklist (links correct, numbers sourced, no invented stats). It flags zero issues.
• Retro — The agent appends a short retro log: what worked (clarify step avoided a rewrite), what to improve (all-models pricing table could use a “cheapest for small volumes” column next time).

Total operator time: under 6 minutes. Without the skill, the same task often ate 25 – 35 minutes because I’d spot-check the draft, catch a wrong assumption, and go back and forth. The difference is the *clarify* gate. That one step is worth 15 – 25 minutes on its own.

---

deny-by-default: why most skills will never ship

The most important part of 365Skill isn’t a file — it’s the publishing process.

Every new skill proposal enters a deny-by-default state. It must clear three gates:

1. Problem evidence — What real-world scenario would this skill improve? We want a log, a recording, or a timestamped screen capture, not a hypothetical.
2. Eval pass — An automated test that proves the skill produces the expected output and fails gracefully on edge cases. No eval, no merge.
3. Operator review — At least one non-engineer operator (usually me or a growth lead) runs the skill on a live task and confirms it saves measurable time or reduces errors.

This is intentionally annoying. The point is to keep the skills directory small and trustworthy, not to grow a catalogue of half-baked prompts. When you install a skill from 365Skill, you’re pulling something that already survived a real business workflow — not a weekend brainstorm.

---

FAQ

Who is 365Skill for?

It’s for teams that use AI agents in production — developers, growth people, sales operators — and want reusable, tested behaviours instead of one-off prompt chains. If you’re evaluating CrewAI alternatives or building agent tooling, the library plugs in directly.

How does 365Skill differ from a prompt library?

A prompt library gives you text to paste; 365Skill gives you a self-contained module with a trigger, step logic, verification checklist, and an eval that proves it works. You don’t need to guess whether a “good prompt” actually produced the right result — the eval tells you.

Can I contribute a skill to the repo?

Yes, the repo is open and Apache-2.0 licensed. Fork it, build your skill with the SKILL.md format, write the eval, and open a pull request. Expect it to start in deny-by-default — we’ll walk you through the evidence and test requirements. It’s not a rubber stamp, but we ship fast once the gates clear.

Does 365Skill lock me into a specific agent platform?

No. The skills are plain markdown and a few supporting scripts. They work with any agent client that reads a skills directory — Claude Code, Cursor, Windsurf, custom setups, whatever. Bring your own runtime; 365Skill just provides the logic.

What’s the connection between 365Skill and the other 365 products?

365Skill is the open-source layer. The skills we develop here inform the agent behaviours inside 365Loopa (growth operations) and 365AIOrg (agent orchestration). If you use our SaaS tools, the skills library is already running under the hood; if you run your own stack, you can take the same skills and wire them in directly. Same DNA, different packaging.

---

Ready to put agent skills to work?

If you’ve spent more than an hour debugging a stray agent hallucination, you already understand the value of a repeatable, testable skill. Grab the latest skills from en/products/365skill — it’s open, free, and proven on real cross-border workloads. Want to see how the same skills run inside a complete growth ops system? Book a free 365Loopa walkthrough and we’ll show you how operator-built AI saves measurable time every week.