Skip to content

Add: Syntropic Development Pipeline methodology rules#172

Open
petercholford-ship-it wants to merge 1 commit intoPatrickJS:mainfrom
petercholford-ship-it:add-syntropic-pipeline
Open

Add: Syntropic Development Pipeline methodology rules#172
petercholford-ship-it wants to merge 1 commit intoPatrickJS:mainfrom
petercholford-ship-it:add-syntropic-pipeline

Conversation

@petercholford-ship-it
Copy link

@petercholford-ship-it petercholford-ship-it commented Feb 19, 2026

What is this?

The Syntropic Development Pipeline — a process-focused .cursorrules that 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

  • Implementation Pipeline (Full/Lightweight/Minimum cycles) — scale process to task size
  • Pre-flight checks — build must pass, no localhost refs before deploy
  • Hypothesis-driven debugging — test without code changes first
  • No-workarounds rule — no bypasses without approval
  • Live site testing — test page first, production only with approval
  • Session continuity — re-read rules on context reset

Multi-tool

Also available as a CLI for Claude Code, Windsurf, and GitHub Copilot:

npx syntropic init

npm: https://www.npmjs.com/package/syntropic

Summary by CodeRabbit

  • Documentation
    • Added development pipeline documentation defining process cadence levels, core operational rules, code implementation standards including security and testing requirements, structured workflow with explicit approval gates for build and deployment, and efficiency evaluation methodology.

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.
@coderabbitai
Copy link
Contributor

coderabbitai bot commented Feb 19, 2026

📝 Walkthrough

Walkthrough

A new .cursorrules configuration file has been added that documents the Syntropic Methodology Development Pipeline, including explicit process cadences, core development rules, implementation standards, workflow steps with approval gates, and the PRISM efficiency evaluation framework.

Changes

Cohort / File(s) Summary
Development Pipeline Configuration
rules/syntropic-development-pipeline-cursorrules-prompt-file/.cursorrules
New documentation file establishing Syntropic Methodology with process cadences (Full, Lightweight, Minimum cycles), core rules (Pre-Flight Loop, Ship and Iterate, Hypothesis-Driven Debugging, etc.), implementation standards, workflow stages, and PRISM efficiency methodology for task evaluation.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

Poem

🐰 A pipeline so neat, with cycles so fine,
Pre-flight checks and gates in a syntropic line,
Ship, iterate, test—oh what delight!
This ruleset keeps workflows running just right!

🚥 Pre-merge checks | ✅ 3
✅ Passed checks (3 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title clearly and concisely summarizes the main change: adding a new Syntropic Development Pipeline methodology rules file to the repository.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 Methodology is introduced but never defined. Readers without prior knowledge of the syntropic package 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.

Comment on lines +13 to +36
### 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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

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.

Comment on lines +17 to +19
### Ship and Iterate (EG2)
Default: Build → Deploy → Show result.
Only ask if: Destructive, Expensive, or Irreversible.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

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.

Suggested change
### 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").

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant