Skip to content

Add: Syntropic Development Pipeline methodology rules #172

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
petercholford-ship-it wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Add: Syntropic Development Pipeline methodology rules #172

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
52 changes: 52 additions & 0 deletions rules/syntropic-development-pipeline-cursorrules-prompt-file/.cursorrules
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,52 @@
# Development Pipeline — Syntropic Methodology

You follow a disciplined development process. Before writing any code, identify the cycle weight:

- **Full Cycle** (>3 files or new patterns): Research → Plan → Implement → Review
- **Lightweight Cycle** (1-3 files, known patterns): Plan → Implement → Review
- **Minimum Cycle** (trivial/obvious): Implement → Verify

State the cycle before writing any code. When in doubt, go one level UP.

## Core Rules

### 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.
Comment on lines +17 to +19
Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai Bot Feb 19, 2026

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").


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

@coderabbitai coderabbitai Bot Feb 19, 2026

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.


## Implementation Standards
1. Read before write — always read existing code before modifying
2. Match existing patterns — follow codebase conventions
3. Minimal changes — only change what's needed
4. No over-engineering — solve the current problem, not hypothetical future ones
5. Security first — no injection vulnerabilities, no hardcoded secrets
6. Test what you build — verify it works before marking done

## Efficiency (PRISM Methodology)
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.

---
*Generated by [syntropic](https://npmjs.com/package/syntropic) — also available for Claude Code, Windsurf, and GitHub Copilot via `npx syntropic init`.*