bigpowers / rules
Cursor rule288 starsChanged 5 days agoMITView on GitHub
DISCOVER-PHASE ADVANCER — Drive the discover-phase checklist (specs/planning-status.yaml) through survey-context → scope-work → research-first → elaborate-spec → plan-release → slice-tasks. NOT a duplicate of plan-work or the planning spine; it orchestrates the pre-coding discover phase only.
Where files are headingNew Cursor rule files have more rules about planning and tracking tasks, and fewer about code style.
Of the Cursor rule files we read, the 4,187 first seen in the last six months, against the older ones: the kind of rule that gained most share, and the kind that lost most. About files like this in general, not this one, and an estimate, since a kind is a pattern in the words.
In this repository162 other files it gives its agents.
- AGENTS.mdAGENTS.md
- docs/AGENTS.mdAGENTS.md
- website/AGENTS.mdAGENTS.md
- .cursor/rules/align-grid.mdcCursor rule
- .cursor/rules/assess-impact.mdcCursor rule
- .cursor/rules/audit-code.mdcCursor rule
- .cursor/rules/audit-plan.mdcCursor rule
- .cursor/rules/build-epic.mdcCursor rule
- .cursor/rules/change-request.mdcCursor rule
- .cursor/rules/commit-message.mdcCursor rule
- .cursor/rules/compose-workflow.mdcCursor rule
- .cursor/rules/craft-skill.mdcCursor rule
- .cursor/rules/deepen-architecture.mdcCursor rule
- .cursor/rules/define-language.mdcCursor rule
- .cursor/rules/define-success.mdcCursor rule
- .cursor/rules/delegate-task.mdcCursor rule
- .cursor/rules/deploy.mdcCursor rule
- .cursor/rules/design-interface.mdcCursor rule
- .cursor/rules/develop-tdd.mdcCursor rule
- .cursor/rules/diagnose-root.mdcCursor rule
- .cursor/rules/diagnose-stall.mdcCursor rule
- .cursor/rules/dispatch-agents.mdcCursor rule
- .cursor/rules/edit-document.mdcCursor rule
- .cursor/rules/elaborate-spec.mdcCursor rule
- .cursor/rules/enforce-first.mdcCursor rule
- .cursor/rules/evolve-skill.mdcCursor rule
- .cursor/rules/execute-plan.mdcCursor rule
- .cursor/rules/extract-design.mdcCursor rule
- .cursor/rules/find-way.mdcCursor rule
- .cursor/rules/fix-bug.mdcCursor rule
- .cursor/rules/gate-trace.mdcCursor rule
- .cursor/rules/generate-allure-report.mdcCursor rule
- .cursor/rules/grill-me.mdcCursor rule
- .cursor/rules/grill-with-docs.mdcCursor rule
- .cursor/rules/guard-git.mdcCursor rule
- .cursor/rules/harden-vps.mdcCursor rule
- .cursor/rules/hook-commits.mdcCursor rule
- .cursor/rules/inspect-quality.mdcCursor rule
- .cursor/rules/investigate-bug.mdcCursor rule
- .cursor/rules/kickoff-branch.mdcCursor rule
- .cursor/rules/maintain-wiki.mdcCursor rule
- .cursor/rules/map-codebase.mdcCursor rule
- .cursor/rules/migrate-spec.mdcCursor rule
- .cursor/rules/model-domain.mdcCursor rule
- .cursor/rules/orchestrate-project.mdcCursor rule
- .cursor/rules/organize-workspace.mdcCursor rule
- .cursor/rules/plan-refactor.mdcCursor rule
- .cursor/rules/plan-release.mdcCursor rule
- .cursor/rules/plan-tests.mdcCursor rule
- .cursor/rules/plan-work.mdcCursor rule
- .cursor/rules/publish-package.mdcCursor rule
- .cursor/rules/quick-fix.mdcCursor rule
- .cursor/rules/release-branch.mdcCursor rule
- .cursor/rules/request-review.mdcCursor rule
- .cursor/rules/research-first.mdcCursor rule
- .cursor/rules/reset-baseline.mdcCursor rule
- .cursor/rules/respond-review.mdcCursor rule
- .cursor/rules/run-benchmark.mdcCursor rule
- .cursor/rules/run-evals.mdcCursor rule
- .cursor/rules/scope-work.mdcCursor rule
- The first 60 shown.
The file
We split this run-planning.mdc into the rules it gives an agent
6 rules. About 0 are common, 1 is distinctive, and 5 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
5
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 20
After orchestrate-project hands off to the Discover phase
- Very specific: line 21
When a new epic emerges from change-request and needs to go through full discovery
- Very specific: line 52
If context is < 24h old, ask: "Planning context from Xh ago exists for '<feature_name>'.
- Distinctive: line 53
If context is ≥ 24h old or absent, run elaborate-spec normally.
- Very specific: line 65
Before marking any workflow key status: done, run:
- Very specific: line 69
If the artifact assertion fails, do NOT advance status.
≈ “Common” is an estimate: at least 1 in 5 of the 6,668 Cursor rule 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.
Files
---
description: "DISCOVER-PHASE ADVANCER — Drive the discover-phase checklist (specs/planning-status.yaml) through survey-context → scope-work → research-first → elaborate-spec → plan-release → slice-tasks. NOT a duplicate of plan-work or the planning spine; it orchestrates the pre-coding discover phase only."
alwaysApply: false
---
<!-- story: e24s03 -->
# Run Planning
> **HARD GATE** — Before running planning skills, confirm the epic capsule exists and the active story is clear. Planning without a target is noise.
>
> **Role:** DISCOVER-PHASE ADVANCER — orchestrates the discover-phase sequence; hands off to the scope-work → slice-tasks → plan-work spine for implementation planning.
Updates `specs/planning-status.yaml` as discover-phase skills complete. This is NOT a duplicate of plan-work — it orchestrates the *pre-coding* discovery phase only (Discover phase in the 6-phase PMBOK lifecycle), handing off to the planning spine for implementation detail.
## When to use
- Starting a brand-new feature or initiative with no prior planning artifacts
- Returning to a stalled initiative and needing to resume the discovery workflow
- After `orchestrate-project` hands off to the Discover phase
- When a new epic emerges from `change-request` and needs to go through full discovery
## Pre-flight
- [ ] Does `specs/planning-status.yaml` exist? If not, create it with the default workflow keys.
- [ ] Does `specs/state.yaml` have `active_flow: planning`? Set it if not already.
- [ ] Is the epic identified in `release-plan.yaml`? The epic must exist before discovery begins.
## Workflows (default keys)
- `survey-context` → `scope-work` → `research-first` → `elaborate-spec` (optional) → `plan-release` → `slice-tasks`
Each key maps to a skill invocation. Optional keys can be skipped; required keys must complete before the phase advances.
## Process
1. **Read state** — Read `specs/planning-status.yaml` and `specs/state.yaml`. Understand where discovery stands: which workflow keys are `done`, which are `pending`, and which are `optional` (can be skipped).
2. **Find next step** — Find the first workflow key with `status: pending`. If the key is `optional`, check if the user wants to run it. If not, mark it `skipped`.
2a. **Context capsule check** — Before invoking `elaborate-spec`, check whether a fresh `specs/planning-context.yaml` exists:
```bash
test -f specs/planning-context.yaml && python3 -c "
import yaml, datetime
d = yaml.safe_load(open('specs/planning-context.yaml'))
written = d.get('written_at','')
if written:
age = (datetime.datetime.now(datetime.timezone.utc) - datetime.datetime.fromisoformat(written)).total_seconds() / 3600
print(f'Context age: {age:.1f}h')
" 2>/dev/null || echo "No context or no written_at"
```
- If context is **< 24h old**, ask: `"Planning context from Xh ago exists for '<feature_name>'. Re-run elaborate-spec? [y/N]"`. Skip elaborate-spec on N.
- If context is **≥ 24h old** or absent, run elaborate-spec normally.
- On planning cycle completion (all required keys done), clear the capsule: delete `specs/planning-context.yaml` and set `planning-status.yaml` `context_capsule: null`.
3. **Invoke the matching skill** — Run the skill that matches the workflow key:
- `survey-context` — where are we?
- `scope-work` — what's in and out?
- `research-first` — what already exists?
- `elaborate-spec` — refine the idea (optional)
- `plan-release` — sequence epics by WSJF
- `slice-tasks` — cut vertical slices
4. **Mechanical artifact assertion before status update (HARD GATE — Issue #183):**
Before marking any workflow key `status: done`, run:
```bash
bash scripts/lib/assert-planning-artifacts.sh <workflow-key>
```
If the artifact assertion fails, do NOT advance status. Remediate missing output files before continuing. On success, set `status: done` for that workflow key in `planning-status.yaml`.
5. **Advance** — Set `state.yaml` `active_flow: planning` while in this chain. When all required keys are done, set `handoff.next_skill` to `plan-work`.
## Workflow Keys Schema
In `specs/planning-status.yaml`:
```yaml
context_capsule: # written by elaborate-spec; cleared on cycle completion
written_at: "2026-06-22T03:00:00Z"
written_by: elaborate-spec
feature_name: "add dark mode"
workflows:
survey-context:
required: true
status: done
scope-work:
required: true
status: pending
research-first:
required: false
status: optional
note: "Skip if no external dependencies"
elaborate-spec:
required: false
status: optional
plan-release:
required: true
status: pending
slice-tasks:
required: true
status: pending
```
## Verify
→ verify: `test -f specs/planning-status.yaml && [ "$(grep -c 'status: done' specs/planning-status.yaml)" -ge 3 ]`
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
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.

