MCPInstall

plate

Turn finished local work into a commit, an ordinary pull request, or a pull request stack. Use this skill to commit changes or to publish a branch. Use it to open or update a pull request. Use it to create, sync, restack, or submit a pull request stack. You can also run /plate. This skill owns all staging, commits, pushes, pull request creation, and stack changes. GitHub inspection, reviews, comments, CI, issues, releases, and repository administration are outside this skill. Use the gh CLI directly for that work.

Installs
502
Last 24h
—
Trending rank
—
Security
Not audited

Install

Works with every agent the skills CLI supports.

npx skills add https://github.com/paulnsorensen/easy-cheese --skill plate
  1. 01

    Install

    Run the command in your project. The CLI asks which agents to install for.

  2. 02

    Describe the task

    Ask your agent for something this skill covers. It loads plate automatically when relevant.

  3. 03

    Review the result

    The agent follows the SKILL.md steps, scripts and references bundled with the skill.

SKILL.md

The instructions your agent reads when the skill is triggered.

/plate

Plate completes local work before review. It finishes required artifacts, validates, commits safely, and selects the correct publication path.

Phase entry

Run python3 skills/plate/scripts/plate.pyz wheypoint-resolve --ref <slug>. authoritative uses the record; its working_context is the first batched tilth_read. not-found proceeds cold; legacy shows its source and slug, then proceeds. gated, ambiguous, and error stop and show the payload. Show advisory stale-commit and grounded-path-missing findings.

Plate resolves the slug and reads the result, but it does not commit a wheypoint revision or publish a wheypoint revision.

Routing guard

Check ownership before you select a mode. /plate owns staging, commits, pushes, ordinary pull request changes, and pull request stack changes.

  • /plate never performs code-quality review. It never computes a review surface for its own sake. Review is /age.
  • GitHub inspection, reviews, comments, CI, merges, issues, workflows, releases, search, and administration are outside /plate. Use the gh CLI directly when no local publication transaction is necessary. Use /affinage to act on pull request feedback or CI failures.
  • A request that only reads or assesses GitHub or diff state leaves /plate before any mode is selected. Thus, routing it here is a plate-owned failure.
  • Destructive deletion, history rewrites, unsafe force-pushes, and protected-branch changes require explicit user authorization.

Classify, then load one reference

Classify every invocation into exactly one mode. Load one reference at a time. Do not read the others.

ModeTriggerLoad
Commit-onlySave local work without publishing itreferences/durable-writes.md
Topology preflightPersist the new-PR layout before another workflow creates commits or branchesreferences/topology.md
New PRNo PR exists for the branch and publication is requestedreferences/topology.md
Existing PRUpdate a PR while preserving its current topologyreferences/ordinary-pr.md
Stack maintenanceCreate, sync, restack, submit, recover, or explicitly ship a stackreferences/stacks.md

Inspect a stack only as a step of a requested stack change. Route a stack inspection request without a requested change out of /plate to the gh CLI.

New-PR work loads its references in this sequence. Load each reference alone. Close it before you load the next one.

  1. Load references/topology.md. Resolve the topology. Plate decides it and does not ask the user.
  2. Load references/ordinary-pr.md for the single or orthogonal_flat shape. Load references/stacks.md for a stacked shape.
  3. Load exactly one provider reference from references/stacks.md for a stacked shape. The provider references are gt.md, git-town.md, and gh-stack.md. When no provider is usable, references/stacks.md routes to setup.md.

When an existing pull request uses a stack, load references/stacks.md. Do not use a bare single-branch push.

Hard gate

Accept --hard to run /hard-cheese immediately before you first share the work for review. Give that gate one JSON context. Include the final artifact inventory, the completion rows, the tracked artifact diff digest, and the quality gate result. Do not give it an earlier implementation snapshot.

Read the gate status. Then apply this matrix:

Gate statusResponse
PASSContinue to publication
LOGGEDContinue to publication. Record the logged findings in the pull request body
ERRORAsk the user before you publish. Report the gate error
FAILEDHalt at quality gate. Do not publish. Fix the work

Ask the ERROR question through the shared question transport. See ../cheese/references/ask-user-question.md.

Tool routing

  • Run python3 skills/plate/scripts/plate.pyz stack-tools before you select a stack provider. The command detects Graphite, Git Town, and gh stack. It does not change repository state.
  • Use Git and GitHub for repository, remote, and PR state. Use the selected provider CLI for stack state.
  • Use the repository code-intelligence backend to edit tracked artifacts. Use the same backend to read them. Select the backend with code-intelligence-routing.md. Follow this sequence from references/durable-writes.md: fresh tagged read, one stale-safe write, diff read-back. Use named paths. Do not use shell redirects.
  • Send durable wiki knowledge through /wiki-ingest. Do not edit the Hallouminate tree directly.
  • Keep temporary completion and PR-body files under .cheese/. Do not stage them.
  • Slash commands are host renderings, not the control model. Name the capability before you show a host example. See ../cheese/references/harness-portability.md.

Generic transaction

Commit-only work and ordinary PR work use this transaction. Stacked work uses the per-layer transaction in references/stacks.md.

  1. Final writing gate — List every promised or required artifact. Write each artifact. Read each artifact back. Follow references/durable-writes.md. Stop if a required write is missing or unverified.
  2. Validate — Run the repository's quality gate. Use just check in easy-cheese or any repository that defines it. Do not commit or publish when the quality gate fails.
  3. Inspect — Read the status, complete diff, and recent log. Verify the intended file set.
  4. Stage — Add only named files. Do not stage the full tree. Keep temporary .cheese/ reports unstaged. Include tracked wiki and documentation changes. If the repository has a Hallouminate wiki, inspect git status for uncommitted .hallouminate/wiki/ paths. Include writes from earlier in the session. Stage these writes unless Git ignores them. Publish wiki updates with this transaction. Do not publish them later.
  5. Commit — Use a Conventional Commit message that explains the reason. Do not amend unless the user requests it. Do not bypass hooks.
  6. Verify — Inspect the status and the committed file set.
  7. Publish when requested — Follow references/ordinary-pr.md. Read the PR after publication. Verify it.

Commit-only mode stops after verification. It does not push or open a PR.

Commit contract

Before staging, inspect git status, the complete diff, and recent commits. Reject credentials, .env files, and unexplained large binaries. Stage every intended path explicitly. Use this format:

type(scope): short description

Optional body when the rationale needs it.

Write the subject first. Use a neutral tone. State the change first in the subject. Put only required reviewer facts in the optional body. Keep the body short. Omit narrative prose, tone, and slang.

Use these types: feat, fix, refactor, chore, docs, test, and style. If a hook fails, fix the failure. Re-run the writing and quality gates when artifacts change. Re-stage each named file. Create a new commit.

Use a single-quoted heredoc delimiter for multi-line commit messages. This delimiter protects backticks and dollar signs from shell interpolation. Use an optional Co-Authored-By: <name> <email> trailer when the project accepts the harness identity. Otherwise, omit the trailer. After staging, inspect the cached diff. An empty working diff can mean that all changes are staged. Read the cached diff to tell this state from no changes.

Create one commit for each review unit. Use one commit for a single PR and one commit for each stack layer. Do not shape a PR for commit-by-commit review. The system does not track approval for each commit. Quality gates usually run only on the branch tip. Feedback on one commit delays the other commits. Use multiple commits in one PR only for a short series of simple steps. Keep the combined change small.

Halting

Every halt names the mode, the failed step, and who owns the failure. Name the step with exactly one of: classify, topology, durable write, quality gate, stage/commit, publish, or terminal validation. Apply the shared voice rules from ../age/references/voice.md in halt and completion reports.

  • Plate-owned — This skill selected an incorrect call shape or route. Examples include a malformed write, stale write, skipped read, or unnamed staging path. A full-tree staging path is also Plate-owned. A mismatch between the mode and reference is also Plate-owned. Review work for /age or GitHub work outside publication is a Plate-owned routing error. Use this recovery rule: Fix the call shape or the routing, then retry that step.
  • Environment-owner — Authentication, permission, hooks, network, provider enablement, or a shared backend caused the failure. Name the owning system in the report. Never retry it as if the call shape were wrong. Also, never weaken a gate, stage unnamed paths, or skip read-back to bypass the failure.

A failed quality gate proves that the work is not shippable. Therefore, halt at quality gate. Then fix the work.

Completion

Write the terminal evidence to a temporary JSON file. Run python3 skills/plate/scripts/plate.pyz validate-publication <state.json>. Report completion only when the command returns normalized evidence with valid: true.

{
  "mode": "new-pr",
  "topology": "single",
  "provider": "ordinary",
  "artifacts": [
    {"target": "docs/adr/example.md", "backend": "tilth", "verified": true}
  ],
  "gate": {"command": "just check", "result": "pass"},
  "commits": ["0123456789abcdef0123456789abcdef01234567"],
  "pr_plan": {
    "contract_version": {
      "schema_uri": "https://schemas.easy-cheese.dev/pr-plan",
      "major": "1",
      "minor": "0"
    },
    "shape": "single",
    "target_branch": "main",
    "groups": [
      {
        "branch": "feature",
        "title": "docs: example ADR",
        "base": "main",
        "commits": ["0123456789abcdef0123456789abcdef01234567"],
        "depends_on": []
      }
    ]
  },
  "prs": [
    {
      "url": "https://github.com/example/repo/pull/42",
      "base": "main",
      "head": "feature",
      "verified": true
    }
  ],
  "risk": "none"
}

Use empty commits or prs lists when the selected mode does not create them. Topology preflight stops before the publication transaction and quality gate. Therefore, use gate: {"command": "n/a", "result": "n/a"} for topology preflight.

See the generated bundle command inventory in references/commands.md.

FAQ

What does the plate skill do?

Turn finished local work into a commit, an ordinary pull request, or a pull request stack. Use this skill to commit changes or to publish a branch. Use it to open or update a pull request. Use it to create, sync, restack, or submit a pull request stack. You can also run /plate. This skill owns all staging, commits, pushes, pull request creation, and stack changes. GitHub inspection, reviews, comments, CI, issues, releases, and repository administration are outside this skill. Use the gh CLI directly for that work.

How do I install plate?

Run npx skills add https://github.com/paulnsorensen/easy-cheese --skill plate in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/plate/ (personal) or .claude/skills/plate/ (project).

Which AI agents can use plate?

Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.

Is plate safe to install?

No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.

Who maintains plate?

It is published by paulnsorensen in paulnsorensen/easy-cheese. It has 502 recorded installs.

More from paulnsorensen/easy-cheese

View all →

cook

paulnsorensen/easy-cheese

Implement an approved spec or focused task through stale-safe source edits. Use this skill when the user says "implement this", "cook this spec", or "fix this bug". Use it for /cook .cheese/specs/ .md. Also use it when the user says "go" with clear acceptance criteria. Run it alone for an unambiguous task. Use --prototype when the user says "prototype this", "go prototype it", or "spike this out" and wants to refine the result round by round. A spec helps but is not required. Do not use it for fuzzy planning (/mold). Do not use it for no-write discussion (/culture) or review-only work (/age).

mold

paulnsorensen/easy-cheese

Turn a high-leverage design decision into a validated spec through grounded dialogue. Use it when a leverage trigger fires (auth, irreversible effects, concurrency, contracts, destructive ops, a new slice, a cross-slice dependency, an invariant gap) or when the user asks for a spec or design. Typical phrases include "let's design X", "shape this into a spec", "what should the API for Z look like", and "/mold". A feature ask with zero fired triggers is a /cook mini-spec, not a mold; route it through /cheese. Do NOT use it for free-form discussion without artifact intent (/culture), direct implementation (/cook), or research-only questions (/briesearch). Ceremony scales to the ask through references/tiers.md, so a small clear change gets a validated mini-spec without a write-approval turn.

cure

paulnsorensen/easy-cheese

Apply selected fixes from an /age report, findings list, or CI failure. Run the project gates and hand a clean result to /plate. Use when the user wants selected findings resolved. Do not use for review, test authoring, or direct publication.

DevOps & Cloud649 installs

age

paulnsorensen/easy-cheese

Review a diff, PR, branch, or path across thirteen dimensions. Emit a severity-grouped findings report. Use when the user wants a code review. Trigger on "review this", "/age", "is this safe to merge", or "find bugs". Also trigger on "spot security issues", "check for slop", "review my PR", or "what's wrong with this code". Review every requested dimension. Review all thirteen dimensions by default. Do not apply fixes. Route them to /cure. Do not harden tests; route that work to /press.

cheese

paulnsorensen/easy-cheese

Route an idea, path, pull request, issue, failure, question, or bare /cheese to the correct workflow skill. Use this skill for /cheese, routing requests, help requests, or opening messages without a named workflow skill.

culture

paulnsorensen/easy-cheese

Models problems and trade-offs without writing code or specifications. Use when a workflow needs silent reasoning, or the user asks for "/culture", "no writes", "rubber-duck this", or "these bugs feel connected". Not for specs (/mold), code (/cook), or bug diagnosis and fixes (/pasteurize).

Popular code quality & workflow skills

View category →

grill-me

mattpocock/skills

A relentless interview to sharpen a plan or design.

Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.

handoff

mattpocock/skills

Compact the current conversation into a handoff document for another agent to pick up.

domain-modeling

mattpocock/skills

Build and sharpen a project's domain model. Use when discussing codebase terminology, writing or editing a GLOSSARY.md, or recording or editing an ADR.

codebase-design

mattpocock/skills

Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.

diagnosing-bugs

mattpocock/skills

Diagnosis loop for hard bugs and performance regressions. Use when the user says "diagnose"/"debug this", or reports something broken/throwing/failing/slow.