Add: Syntropic Development Pipeline methodology rules#172
Add: Syntropic Development Pipeline methodology rules#172petercholford-ship-it wants to merge 1 commit intoPatrickJS:mainfrom
Conversation
A process-focused .cursorrules that defines HOW to work rather than WHAT tech to use. Includes: Implementation Pipeline (Full/Lightweight/Minimum), Pre-flight checks, Hypothesis-driven debugging, No-workarounds rule, Live site testing, Session continuity. Also available for Claude Code, Windsurf, Copilot via npx syntropic init.
📝 WalkthroughWalkthroughA new Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Tip Issue Planner is now in beta. Read the docs and try it out! Share your feedback on Discord. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
rules/syntropic-development-pipeline-cursorrules-prompt-file/.cursorrules (1)
46-49: PRISM acronym is not expanded, leaving the section opaque.
PRISM Methodologyis introduced but never defined. Readers without prior knowledge of thesyntropicpackage cannot apply it. Consider expanding the acronym inline or linking to documentation.✏️ Suggested improvement
## Efficiency (PRISM Methodology) +<!-- PRISM: Prioritize → Reduce → Iterate → Simplify → Measure (or expand with the actual definition) --> Before complex tasks: estimate cost vs. value. After cycles: note what worked and what was wasteful. Better output AND fewer resources. Never sacrifice quality to save tokens.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@rules/syntropic-development-pipeline-cursorrules-prompt-file/.cursorrules` around lines 46 - 49, Expand the opaque "PRISM Methodology" reference under the "## Efficiency (PRISM Methodology)" section by adding a brief inline expansion and/or one-line definition of PRISM (e.g., what each letter stands for and a short description of the process) and optionally include a link to the syntropic package docs; update the heading text or the paragraph to read something like "PRISM (Plan, Review, Iterate, Score, Measure) Methodology — brief description..." so readers unfamiliar with PRISM can immediately apply the guidance.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@rules/syntropic-development-pipeline-cursorrules-prompt-file/.cursorrules`:
- Around line 13-36: The rule file skips IDs EG4, EG6, and EG7 which can confuse
readers; update the .cursorrules content to add a brief clarifying note near the
top (e.g., after the "Core Rules" header or before "Pre-Flight Loop (EG1)")
stating that rule IDs correspond to the full syntropic package and that only a
subset (EG1, EG2, EG3, EG5, EG8, EG9) is included here, referencing the existing
rule IDs EG1/EG2/EG3/EG5/EG8/EG9 so maintainers understand the omission is
intentional and not a deletion.
- Around line 17-19: Update the EG2 rule text so it explicitly scopes to
non-production environments to avoid conflicting with EG8: change the EG2
header/body ("Ship and Iterate (EG2)" and "Default: Build → Deploy → Show
result.") to something like "Default for non-production/staging: Build → Deploy
→ Show result." and keep the "Only ask if: Destructive, Expensive, or
Irreversible." line; ensure EG2 references "non-production" or "staging" to make
clear it does not authorize production changes and does not override EG8 ("DO
NOT modify production without explicit approval").
---
Nitpick comments:
In `@rules/syntropic-development-pipeline-cursorrules-prompt-file/.cursorrules`:
- Around line 46-49: Expand the opaque "PRISM Methodology" reference under the
"## Efficiency (PRISM Methodology)" section by adding a brief inline expansion
and/or one-line definition of PRISM (e.g., what each letter stands for and a
short description of the process) and optionally include a link to the syntropic
package docs; update the heading text or the paragraph to read something like
"PRISM (Plan, Review, Iterate, Score, Measure) Methodology — brief
description..." so readers unfamiliar with PRISM can immediately apply the
guidance.
| ### Pre-Flight Loop (EG1) | ||
| BEFORE every deploy: build must pass, no localhost/127.0.0.1 references in source. | ||
| AFTER every deploy: verify the live URL works. | ||
|
|
||
| ### Ship and Iterate (EG2) | ||
| Default: Build → Deploy → Show result. | ||
| Only ask if: Destructive, Expensive, or Irreversible. | ||
|
|
||
| ### Hypothesis-Driven Debugging (EG3) | ||
| 1. State hypothesis ("X because Y") | ||
| 2. Test WITHOUT code changes (logs, DB, API) | ||
| 3. Only code if confirmed | ||
| 4. 3rd attempt same issue → STOP, deep investigation | ||
|
|
||
| ### No Workarounds Without Approval (EG5) | ||
| Never implement bypass code, temporary hardcoded values, or "fix later" shortcuts without explicit approval. | ||
|
|
||
| ### Live Site Testing (EG8) | ||
| All new features go to the test page FIRST. | ||
| DO NOT modify production without explicit approval. | ||
| Workflow: Build on test → push → verify live → promote with approval. | ||
|
|
||
| ### Session Continuity (EG9) | ||
| On session reset: re-read this file, check git status, verify current state before proceeding. |
There was a problem hiding this comment.
Non-contiguous rule IDs (EG4, EG6, EG7 absent) may cause confusion.
The Core Rules jump from EG3 → EG5 → EG8 → EG9. If these IDs are drawn from a larger ruleset defined in the syntropic package, a brief note here (e.g., "IDs match the full syntropic ruleset; only the rules relevant to this file are included") would prevent teams from wondering whether EG4/EG6/EG7 were accidentally dropped or are intentionally omitted.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@rules/syntropic-development-pipeline-cursorrules-prompt-file/.cursorrules`
around lines 13 - 36, The rule file skips IDs EG4, EG6, and EG7 which can
confuse readers; update the .cursorrules content to add a brief clarifying note
near the top (e.g., after the "Core Rules" header or before "Pre-Flight Loop
(EG1)") stating that rule IDs correspond to the full syntropic package and that
only a subset (EG1, EG2, EG3, EG5, EG8, EG9) is included here, referencing the
existing rule IDs EG1/EG2/EG3/EG5/EG8/EG9 so maintainers understand the omission
is intentional and not a deletion.
| ### Ship and Iterate (EG2) | ||
| Default: Build → Deploy → Show result. | ||
| Only ask if: Destructive, Expensive, or Irreversible. |
There was a problem hiding this comment.
EG2 "Ship and Iterate" should explicitly scope to non-production to avoid ambiguity with EG8.
As written, EG2 says the default is "Build → Deploy → Show result" with no qualification. EG8 then says "DO NOT modify production without explicit approval." A reader applying EG2 to a production deploy could misread it as authorization. Consider tightening EG2:
✏️ Suggested clarification
### Ship and Iterate (EG2)
-Default: Build → Deploy → Show result.
-Only ask if: Destructive, Expensive, or Irreversible.
+Default (non-production): Build → Deploy → Show result.
+Only ask if: Destructive, Expensive, or Irreversible.
+See EG8 for production deploy policy.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| ### Ship and Iterate (EG2) | |
| Default: Build → Deploy → Show result. | |
| Only ask if: Destructive, Expensive, or Irreversible. | |
| ### Ship and Iterate (EG2) | |
| Default (non-production): Build → Deploy → Show result. | |
| Only ask if: Destructive, Expensive, or Irreversible. | |
| See EG8 for production deploy policy. |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@rules/syntropic-development-pipeline-cursorrules-prompt-file/.cursorrules`
around lines 17 - 19, Update the EG2 rule text so it explicitly scopes to
non-production environments to avoid conflicting with EG8: change the EG2
header/body ("Ship and Iterate (EG2)" and "Default: Build → Deploy → Show
result.") to something like "Default for non-production/staging: Build → Deploy
→ Show result." and keep the "Only ask if: Destructive, Expensive, or
Irreversible." line; ensure EG2 references "non-production" or "staging" to make
clear it does not authorize production changes and does not override EG8 ("DO
NOT modify production without explicit approval").
What is this?
The Syntropic Development Pipeline — a process-focused
.cursorrulesthat defines HOW to work rather than WHAT tech to use.Most entries here define tech-stack preferences ("you are a React expert"). This defines a development process that works regardless of tech stack.
What it includes
Multi-tool
Also available as a CLI for Claude Code, Windsurf, and GitHub Copilot:
npm: https://www.npmjs.com/package/syntropic
Summary by CodeRabbit