SinachPat
0dae13cfd3
- 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)
3.7 KiB
name, description
| name | description |
|---|---|
| wursor-precheck | 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/, ore2e/ - 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
-
Read the task. Understand what the user is asking and why. If the request is ambiguous, ask a targeted clarifying question before proceeding.
-
Open a todo list. The first item is always: understand the current state of the relevant module(s) before changing anything.
-
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).
-
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."
-
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?
-
Do the work. Execute the playbook. Keep the todo list updated. Surface findings in the reply as you go.
-
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.