agentleFS
paulnsorensenpaulnsorensen/easy-cheese/skills/plate/SKILL.md

plate

Skill19 starsChanged 27 days agoMITView on GitHub

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.

  • Reads credentials

The file

Show its rules and text

We split this skill into the rules it gives an agent

37 rules. About 0 are common, 15 are distinctive, and 22 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈15

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 22

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Check ownership before you select a mode.

    line 29
  2. Very specific:

    Use the gh CLI directly when no local publication transaction is necessary.

    line 34
  3. Very specific:

    Use /affinage to act on pull request feedback or CI failures.

    line 35
  4. Very specific:

    When no provider is usable, references/stacks.md routes to setup.md.

    line 60
  5. Very specific:

    When an existing pull request uses a stack, load references/stacks.md.

    line 62
  6. Distinctive:

    Do not give it an earlier implementation snapshot.

    line 68
  7. Distinctive:

    Read the gate status. Then apply this matrix:

    line 70
  8. Very specific:

    Ask the ERROR question through the shared question transport.

    line 79
  9. Very specific:

    Run python3 skills/plate/scripts/plate.pyz stack-tools before you select a stack provider.

    line 84
  10. Distinctive:

    Use Git and GitHub for repository, remote, and PR state.

    line 86
  11. Very specific:

    Use the repository code-intelligence backend to edit tracked artifacts.

    line 87
  12. Very specific:

    Follow this sequence from references/durable-writes.md: fresh tagged read, one stale-safe write, diff read-back.

    line 89
  13. Distinctive:

    Use named paths. Do not use shell redirects.

    line 90
  14. Very specific:

    Keep temporary completion and PR-body files under .cheese/.

    line 92
  15. Very specific:

    Commit-only work and ordinary PR work use this transaction.

    line 98
  16. Very specific:

    Follow references/durable-writes.md.

    line 101
  17. Distinctive:

    Do not commit or publish when the quality gate fails.

    line 103
  18. Very specific:

    Keep temporary .cheese/ reports unstaged.

    line 106
  19. Very specific:

    If the repository has a Hallouminate wiki, inspect git status for uncommitted .hallouminate/wiki/ paths.

    line 107
  20. Distinctive:

    Do not bypass hooks.

    line 111
  21. Distinctive:

    Commit-only mode stops after verification.

    line 116
  22. Very specific:

    Before staging, inspect git status, the complete diff, and recent commits.

    line 120
  23. Distinctive:

    Write the subject first. Use a neutral tone.

    line 130
  24. Distinctive:

    Put only required reviewer facts in the optional body.

    line 131
  25. Very specific:

    Use these types: feat, fix, refactor, chore, docs, test, and style.

    line 133
  26. Distinctive:

    If a hook fails, fix the failure.

    line 134
  27. Very specific:

    Use a single-quoted heredoc delimiter for multi-line commit messages.

    line 137
  28. Very specific:

    Use an optional Co-Authored-By: <name> <email> trailer when the project accepts the harness identity.

    line 138
  29. Distinctive:

    After staging, inspect the cached diff.

    line 139
  30. Distinctive:

    Read the cached diff to tell this state from no changes.

    line 140
  31. Distinctive:

    Create one commit for each review unit.

    line 142
  32. Distinctive:

    Do not shape a PR for commit-by-commit review.

    line 143
  33. Distinctive:

    Use multiple commits in one PR only for a short series of simple steps.

    line 145
  34. Very specific:

    Every halt names the mode, the failed step, and who owns the failure.

    line 149
  35. Very specific:

    Use this recovery rule: Fix the call shape or the routing, then retry that step.

    line 157
  36. Very specific:

    Write the terminal evidence to a temporary JSON file.

    line 166
  37. Very specific:

    Use empty commits or prs lists when the selected mode does not create them.

    line 210

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

/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. Draw any PR diagram by diagrams.md from diagram-templates.md.

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.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.