pat/wursor
1
0
Fork 0
Code Issues Actions Packages Projects Releases Wiki Activity

feat: add pstack-style rigor skill family for Zed

Browse Source 
- wursor-precheck: router skill, entry point for non-trivial tasks
- wursor-principles: 21 engineering principles adapted for Wursor
- wursor-tdd, wursor-bug-fix, wursor-feature, wursor-investigation,
  wursor-review, wursor-decision-log: playbook skills
- AGENTS.md: repo guide wiring the skill routing table
- Fix: double-quote YAML frontmatter descriptions (colon-space in
  plain scalars broke Zed's skill loader)
This commit is contained in:
SinachPat
2026-08-14 14:23:06 +01:00
parent dfb3c9372b
commit 0dae13cfd3
9 changed files with 591 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.agents/skills/wursor-precheck/SKILL.md
+63
View File
@@ -0,0 +1,63 @@
---
name: wursor-precheck
description: "The entry point for any non-trivial Wursor task. Reads the task, routes it to the right playbook skill, opens a todo list, and establishes the verification bar before any work starts. Use this whenever a task involves changing code, fixing a bug, building a feature, or investigating how the Wursor codebase works. Modeled on Cursor's pstack poteto-mode."
---
# Wursor Precheck (Router)
This is the default entry point for non-trivial work in the Wursor repository. Its job is to make sure the right rigor applies to every task — before a single line is written.
## When to use
Use this skill at the start of any task that is more than a trivial one-line change. This includes:
- Building or editing any module in `api/`, `web/`, `plugin/`, `infrastructure/`, or `e2e/`
- Fixing a bug, with or without a repro
- Adding a feature or changing behavior
- Investigating how something works, or why it was built a certain way
- Reviewing a diff or a pull request
- Writing a decision trail that should be reviewable later
Do **not** use this for: trivial copy edits, one-line doc fixes, or tasks the user explicitly says are quick.
## What to do on activation
1. **Read the task.** Understand what the user is asking and why. If the request is ambiguous, ask a targeted clarifying question before proceeding.
2. **Open a todo list.** The first item is always: *understand the current state of the relevant module(s) before changing anything.*
3. **Route the task to the right playbook.** Read the request and pick the closest match:
| Task shape | Route to skill |
|---|---|
| A read-only question — "how does X work", "why was Y built this way", "are we sure Z" | `wursor-investigation` |
| A defect with a symptom — reproduce, root-cause, fix with runtime evidence | `wursor-bug-fix` |
| New or changed behavior, built from a named data shape | `wursor-feature` |
| A behavior-preserving change to structure or shape | `wursor-feature` (refactoring mode) |
| A diff or PR that needs to be broken | `wursor-review` |
| Any code change that has a cheap test path | `wursor-tdd` (write the failing test first) |
| You want the decisions captured for later review | `wursor-decision-log` |
When a task spans multiple playbooks, apply them in sequence: investigation first (understand), then bug-fix or feature (change), then review (verify).
4. **Copy the playbook steps in verbatim.** Read the routed skill's SKILL.md and follow its steps exactly. Do not improvise a lighter version because the task "feels small."
5. **Set the verification bar.** Before starting, state what "done" means for this task:
- What test will prove the change works?
- What command will the user (or a reviewer) run to verify?
- What artifact is the proof — a passing test, a screenshot, a running sandbox, a clean diff?
6. **Do the work.** Execute the playbook. Keep the todo list updated. Surface findings in the reply as you go.
7. **Report unslopped.** When done, write a reply framed for the person who asked, plus a short note for the maintainer (what changed, why, what the verification was).
## Sticky behavior
Once this skill has been activated for a session, keep applying it to subsequent turns in the same session if the task still matches a playbook. Stay out of the way when the user is clearly doing something trivial. The user can opt out at any time by saying so.
## Hard rules
- Never skip the todo list.
- Never skip stating the verification bar.
- Never mark a task done without the proof defined in step 5 — a self-report ("it compiles") is not proof.
- Never touch the live WordPress site, production credentials, or real user data from this repo. Everything here is code and infrastructure definitions; if a task seems to require live data, stop and ask.