Simplify PR template and add write-pr-description skill

[craigmarker]

Summary

The 7-section PR template had low compliance — fields got skipped or
filled with "n/a." Since we squash & merge, the PR body becomes the
commit message on main, so the template should be designed for that
reality.

This replaces the template with two high-value sections (Summary and
Test plan), updates CONTRIBUTING.md to reflect the new philosophy, and
adds a write-pull-request-description Claude skill that walks developers
through producing a complete PR description.

Before / After Examples

These were generated by running the skill against real commits from our history.

Bug fix (3 files) — original commit message:

fix(ingester): use scheme.ObjectKinds() to resolve GVK, fixing controllermgr CrashLoopBackOff (#922)

• Add unit test
• Add AllCRDObjects to proto-go module
• update todo
• revert

What the skill produces:

Use scheme-based GVK resolution in ingester controller

Summary

Replace GetObjectKind().GroupVersionKind() with Scheme.ObjectKinds() for GVK resolution in the ingester controller. GetObjectKind() returns an empty GVK when the object has not been through serialization, causing silent failures in metadata storage operations. Scheme.ObjectKinds() resolves the GVK from the scheme registry, which is always populated after AddToScheme.

Test plan

Added TestSchemeGVKResolution — iterates all CRD objects in the v2 scheme and asserts each resolves to a non-empty, unique Kind.

---

Large feature (48 files) — original commit message:

Cron Trigger Support with Dynamic Parameters (#371)

What the skill produces:

Add cron trigger support with dynamic parameters

Summary

Add scheduled workflow execution via cron triggers with support for dynamic parameters resolved at runtime. Previously, workflows could only be triggered manually or via external schedulers with static configurations. This introduces a cron trigger system with a new TriggerRun controller, dedicated Cadence/Temporal activities and workflows, and workflow client extensions so both backends can run cron-triggered workflows through a unified API.

Test plan

Added cron_trigger_test.go covering trigger creation, parameter resolution, and execution lifecycle. Existing workflow client tests pass with the expanded interface.

Test plan

• Ran the skill against 3 real commits (trivial, medium, large) via the skill-creator eval pipeline
• 83% pass rate (15/18 expectations) on first run
• Eval suite with 9 test cases checked into .claude/skills/write-pull-request-description/evals/

[donovanlopez]

@craigmarker I noticed that the commit titles will go from:
fix(ingester): use scheme.ObjectKinds() to resolve GVK, fixing controllermgr CrashLoopBackOff (#922)
to
Use scheme-based GVK resolution in ingester controller

I thought we were following the Conventional Commit convention before but it looks like we're moving away from that. Looking at our commit history, we were somewhat doing this but wanted to check if this is something we wanted to follow.

[craigmarker]

I thought we were following the Conventional Commit convention before but it looks like we're moving away from that. Looking at our commit history, we were somewhat doing this but wanted to check if this is something we wanted to follow.

I’m open to following the type prefixing (feat/fix/docs/etc). One concern I have about the type prefixing approach is that when we’re squashing and merging, a single PR of multiple commits becomes a single git history entry. It’s easy for several commits to satisfy multiple types.

If we supported rebase & merge, I wouldn’t be concerned about this problem.

What do you think?

[donovanlopez]

I thought we were following the Conventional Commit convention before but it looks like we're moving away from that. Looking at our commit history, we were somewhat doing this but wanted to check if this is something we wanted to follow.

I’m open to following the type prefixing (feat/fix/docs/etc). One concern I have about the type prefixing approach is that when we’re squashing and merging, a single PR of multiple commits becomes a single git history entry. It’s easy for several commits to satisfy multiple types.

If we supported rebase & merge, I wouldn’t be concerned about this problem.

What do you think?

Ah I see. In my last company, we actively tried to keep our PRs as small as possible to have it more focused and easier to review so the type prefixing made more sense since PRs covered only one of those. If we're not enforcing anything like that, it makes sense to not follow it.