← All skills
AI skills · Job 3

Is it ready to go?

The same 6 checks, every time — you decide

In short

Pilots check a list before every flight.

This AI checks 6 things every time.

It says yes, no, or "I can't tell".

Then you decide what happens next.

Before every take-off, pilots read the same checklist — even after a thousand flights. Not because they forget, but because a list never gets tired or rushed. And the checklist never flies the plane: the pilot still decides.

These skills are that checklist — for a new feature, a blog post, a social media post or a change to a program. Each one runs its own 6 checks, marks each one, and shows why. If it can't tell, it says so instead of guessing. Whether to launch, publish or go ahead stays your decision.

How it works

Each check gets one mark: Pass, Fail, Could not determine (it can't tell, because it doesn't know enough) or N/A (doesn't apply).

How it works Something about to go out goes through the same 6 checks every time. Each check gets pass, fail or can't tell. Then you decide whether it goes out; the AI never makes that call. Something about to go out The same 6 checks every time — each team has its own 6 Pass · Fail · Can't tell — each You decide: does it go out? The AI never makes that call

Pick a team

Every team has its own checklist. Pick one to see its 6 checks, its request and what the real AI said.

The 6 checks before a feature launches

The Product team's skill is the Feature Launch Readiness Checklist.

  1. If something goes wrong, can we switch it off fast?
  2. Can we give it to a few people first, instead of everyone at once?
  3. How will we know it worked — is there a number to watch?
  4. Are the help pages ready?
  5. Does the support team know it's coming?
  6. Are any known problems still open?

A good check vs a weak one

For the feature below, this is what we built the skill to do — and the kind of answer it must avoid.

  • ✅ "A few people first: Fail. There is an on/off switch, but it's already on for everyone."

    Good: it checked what the switch is actually used for.

  • ✅ "5 of the 6 checks failed. This will help whoever decides on the launch."

    Good: clear facts, and the decision stays with you.

  • ❌ "A few people first: Pass — there's an on/off switch."

    Weak: having a switch isn't the same as using it to go slowly.

  • ❌ "Don't launch this week."

    Weak: only you can decide that, not the checklist.

The lesson: a checklist is only useful if it's honest — a "Pass" needs a real reason, and "I can't tell" is a fine answer.

What we gave the AI

The request:

Use the Feature Launch Readiness Checklist on the CSV export feature we're shipping this week.

What the team knew, the week of launch:

Feature: CSV export of the currently filtered Reports view, for
Analyst-role users and above.

Known so far:
- Behind a feature flag, currently enabled for 100% of eligible users
  (no staged rollout planned).
- No rollback plan beyond "turn the feature flag off."
- Success metric: PRD states the goal is reducing export-related support
  tickets (~15/month baseline) but no target number or dashboard exists yet.
- No documentation or help-center article has been written.
- Support team has not been given any advance notice.
- One open bug: export fails silently for reports with >10,000 rows;
  not yet fixed, not yet explicitly accepted as a known limitation.

A "feature flag" is an on/off switch for a feature, so it can be turned off without a new release.

What the real AI said

    Loading the recorded run…

    See this skill's recipe card on GitHub

    The 6 checks before a blog post goes live

    The Content team's skill is the Content Publish Readiness Checklist.

    1. No spelling mistakes, and no leftover placeholders like "[insert stat here]"?
    2. Does every link go somewhere real?
    3. Can search engines find it — is there a title and a short summary?
    4. Does every picture have a short description for people who can't see it ("alt text")?
    5. Does every number or claim come from a real source?
    6. Does it sound like the company's style guide says it should?

    A good check vs a weak one

    For the draft below, this is what we built the skill to do — and the kind of answer it must avoid.

    • ✅ "Links: Fail. 'Read more at #' doesn't go anywhere."

      Good: it points at the exact problem.

    • ✅ "Numbers have a source: Could not determine. The number isn't written yet — check its source once it is."

      Good: "I can't tell yet" is honest, and it says what to do next.

    • ❌ "Looks good, ready to publish!"

      Weak: it missed a leftover placeholder, a dead link and a missing title.

    • ❌ It quietly fills in the placeholder and adds the picture description itself.

      Weak: a checklist reports problems. Fixing them is up to you.

    The lesson: a good check finds the "[insert stat here]" before your readers do.

    What we gave the AI

    The request:

    Use the Content Publish Readiness Checklist on draft-blog-post.md before we publish it.

    The part of the draft it had to check:

    Title: (none set)
Body: "...check out our new export feature [insert stat here] and
see the difference for yourself! Read more at #."
Image: <img src="export-screenshot.png"> (no alt attribute)
Brand guide: not supplied.

    The "Image" line is how a web page adds a picture. The "alt attribute" is where its description would go — here it's missing.

    What the real AI said

      Loading the recorded run…

      See this skill's recipe card on GitHub

      The 6 checks before a post goes out

      The Social media team's skill is the Social Publish Readiness Checklist.

      1. Is it short enough for the site's character limit?
      2. Are the hashtags written correctly, and about the post?
      3. Does the picture or video fit the site's size rules?
      4. Do pictures have a description, and videos have subtitles?
      5. Do links go somewhere real, and can the team count the clicks?
      6. Does it clash with another planned post, or a bad moment to post?

      A good check vs a weak one

      For the post below, this is what we built the skill to do — and the kind of answer it must avoid.

      • ✅ "Hashtags: Fail. '# export' has a space in it, and #followus, #like and #share have nothing to do with the post."

        Good: it says exactly what's wrong and why.

      • ✅ "Character limit: Could not determine. You didn't say which limit your account has."

        Good: some accounts allow longer posts, so it doesn't assume.

      • ❌ "Character limit: Pass — it's under 280."

        Weak: it assumed a limit nobody confirmed.

      • ❌ "Don't post this."

        Weak: only you can decide that, not the checklist.

      The lesson: a quick post still deserves a proper check — and an honest "I can't tell".

      What we gave the AI

      The request:

      Use the Social Publish Readiness Checklist on draft-caption.md before we post it to Twitter/X.

      The draft post it had to check:

      Platform: Twitter/X (280-character limit not confirmed by user).
Caption: "Check out our new export feature! # export #newfeature
#trending #followus #like #share See more at bit.ly/xyz"
Image: <img src="export-screenshot.png"> (no alt attribute)
Posting calendar: not supplied.

      "bit.ly/xyz" is a shortened link. The "alt attribute" is where a picture's description would go — here it's missing.

      What the real AI said

        Loading the recorded run…

        See this skill's recipe card on GitHub

        The 6 checks before new code joins the main version

        The Software team's skill is the Pre-Merge Readiness Checklist.

        In plain words:

        • A branch is a side copy of the program where programmers make changes.
        • A merge is when those changes join the main version. Someone checks them first.
        • A diff is the list of changes.
        • Tests are small automatic checks that the program still works.
        1. Were tests added or updated for the changed parts?
        2. If users will notice the change, were the help pages updated?
        3. Is any leftover debugging code (extra lines a programmer adds while hunting a bug) still in there?
        4. Do the change notes (commit messages) follow the team's usual style?
        5. Are there any passwords or secret keys in the change?
        6. Were any private files (like password files) added by mistake?

        A good check vs a weak one

        For the change below, this is what we built the skill to do — and the kind of answer it must avoid.

        • ✅ "Tests: Fail. This project keeps its tests in __tests__ folders, and none of them changed."

          Good: it judged by the project's own habits, not a guess.

        • ✅ "Change notes: Fail. The team writes 'feat:' or 'fix:', but these say 'wip' and 'fix stuff'."

          Good: it compared with what the team really does.

        • ❌ "Tests: Pass — there are tests somewhere."

          Weak: tests existing isn't the same as tests for this change.

        • ❌ It writes the missing tests itself.

          Weak: a checklist reports the gap; filling it is a separate job.

        The lesson: the same honest checklist works for code — it reports, and a person decides.

        What we gave the AI

        The request:

        Use the Pre-Merge Readiness Checklist on my current branch diff against main.

        A summary of the change — which files changed, and what the team noticed:

        Changed files:
  src/reports/export.js       (+42, -3)
  src/reports/formatters.js   (+11, -0)

Repo conventions observed:
  - Existing tests live under src/**/__tests__/*.test.js
  - No __tests__ changes in this diff
  - README.md documents the "Export" menu; not touched in this diff
  - Commit history uses Conventional Commits (feat:, fix:, chore:)
  - This diff's commits: "wip", "more changes", "fix stuff"
  - No console.log/debugger/pdb found in the diff
  - No secret-like patterns found in the diff
  - No new .env/.pem/credentials.json files added

        "+42, -3" means 42 lines added and 3 removed. "console.log", "debugger" and "pdb" are common kinds of leftover debugging code; ".env", ".pem" and "credentials.json" are common names for files holding passwords.

        What the real AI said

          Loading the recorded run…

          See this skill's recipe card on GitHub

          This page never talks to an AI. It shows runs that were recorded earlier, exactly as the AI wrote them.

          Next: Agents — skills that work together → Use these skills in your own AI tool