Improve onboarding instructions to include d2 installation#449
Conversation
…tructions - Added D2 CLI as a requirement in the contributing guidelines. - Updated installation steps to include `pnpm install:d2` for D2 CLI. - Enhanced the install script to detect OS and architecture for D2 installation. - Included error handling and instructions for adding D2 to the PATH.
saif-at-scalekit
requested review from
amitash1912 and
ravibits
as code owners
WalkthroughThis change introduces D2 CLI tooling support to the project by documenting its installation requirements in contributor guidelines, adding an npm script to automate setup, and replacing the installation script with a robust implementation that detects operating systems and architectures, handles downloads, validates installations, and manages PATH configuration. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes 🚥 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)
Comment |
✅ Deploy Preview for scalekit-starlight ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@scripts/install-d2.sh`:
- Around line 54-63: The script currently writes to fixed /tmp paths which can
collide; create an isolated temp directory with mktemp -d (e.g., TMPDIR=$(mktemp
-d)) and use that for downloads and extraction (curl -o "$TMPDIR/d2.tar.gz" and
tar -C "$TMPDIR" -xzf "$TMPDIR/d2.tar.gz"), replace any references to
/tmp/d2-$VERSION with "$TMPDIR"/d2-$VERSION, and add a trap to clean it up on
exit (trap 'rm -rf "$TMPDIR"' EXIT) so DOWNLOAD_URL downloads and tar extraction
use the unique temp dir and are removed afterward.
ℹ️ Review info
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (3)
CONTRIBUTING.mdpackage.jsonscripts/install-d2.sh
📜 Review details
🧰 Additional context used
📓 Path-based instructions (3)
**/*.{yml,yaml,md,mdx}
📄 CodeRabbit inference engine (.cursor/rules/browsecentral-labels.mdc)
**/*.{yml,yaml,md,mdx}: BrowseCentral labels should be maximum 3-5 words - keep concise but add context when needed
BrowseCentral labels should be action-oriented - start with verbs when possible
BrowseCentral labels should be specific and clear - add context when simple labels are ambiguous
BrowseCentral labels should be outcome-focused - describe what users accomplish and the context
BrowseCentral labels should use 'Action + Object' pattern (e.g., 'Invite users', 'Restrict sign-up', 'Set up SCIM')
BrowseCentral labels should use feature names (e.g., 'Enterprise SSO', 'Passwordless quickstart')
BrowseCentral labels should describe task completion (e.g., 'Run migrations', 'Migrate auth', 'Merge identities')
BrowseCentral labels should include specific context when needed (e.g., 'Configure Scalekit MCP server', 'Validate incoming API requests')
BrowseCentral labels should use integration context when applicable (e.g., 'Build MCP auth with your existing auth system')
BrowseCentral labels should avoid instructional prefixes: 'How to', 'Guide to', 'Implement', 'Configure', 'Learn', 'Understand'
BrowseCentral labels should avoid verbose phrases: 'Step-by-step guide', 'Complete tutorial', 'Detailed documentation'
BrowseCentral labels should avoid weak verbs: 'Enable', 'Allow', 'Provide', 'Support'
Files:
CONTRIBUTING.md
**/*.{md,mdx}
📄 CodeRabbit inference engine (.cursor/rules/deno-docs-style.mdc)
**/*.{md,mdx}: Use sentence case for all titles and headings in MD/MDX documentation
Keep page titles short and descriptive (3–7 words when possible) in MD/MDX documentation
Use outcome-focused headings that describe results, not categories (e.g., 'Run a script' not 'Scripts')
Avoid gerunds in headings when an imperative works - prefer 'Configure proxies' over 'Configuring proxies'
Keep sidebar labels concise (1–3 words), use sentence case, and focus on outcomes or objects
Use sentence case in sidebar labels without punctuation
Set frontmatter title in sentence case with a clear outcome; description in one sentence (≤160 chars); sidebar.label as shorter form of title; enable tableOfContents on longer pages
Start documentation pages with a one-paragraph overview explaining what the page covers and when to use it
Present the primary use case (80% path) first in documentation, with edge cases later
Use numbered steps for task-focused sections in documentation, with each step beginning with a verb
Break up long documentation sections with subheadings every 3–6 paragraphs
Use asides for important notes, tips, cautions, and references in documentation
Provide runnable, minimal code examples that work as-is in documentation
Prefer CLI-first examples and show file layout when helpful in documentation
Label code blocks with titles for context (e.g., 'Terminal', 'main.ts') in documentation
Keep code block annotations brief and purposeful - annotate only what matters
Use consistent variable and file names across a documentation page
Use descriptive link text in documentation (e.g., 'See permission flags' not 'click here')
Prefer relative links for internal documentation pages and include anchors for section references
Reference APIs consistently using backticks for code, file names, CLI flags, and endpoints
Use backticks for code, file names, CLI flags, and endpoints in documentation
Use lists for options and features in documentation; tables only when comparisons are cleare...
Files:
CONTRIBUTING.md
**/*.{js,ts,tsx,jsx,py,java,cs,go,cpp,c,rb,php,swift,kt,scala,rs,m,mm,groovy,gradle,xml,json}
📄 CodeRabbit inference engine (.cursor/rules/comment-standards.mdc)
Comments should not duplicate the code - avoid comments that simply restate what the code does; comments should add value beyond what's obvious from reading the code
Files:
package.json
🧠 Learnings (2)
📚 Learning: 2026-02-25T18:40:05.343Z
Learnt from: CR
Repo: scalekit-inc/developer-docs PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-02-25T18:40:05.343Z
Learning: Use pnpm for package management
Applied to files:
CONTRIBUTING.md
📚 Learning: 2026-02-25T18:40:05.343Z
Learnt from: CR
Repo: scalekit-inc/developer-docs PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-02-25T18:40:05.343Z
Learning: Format checking with Prettier, build process without errors, Git hook validations, and content structure validation must pass for all changes
Applied to files:
CONTRIBUTING.md
🔇 Additional comments (4)
scripts/install-d2.sh (2)
13-45: Good platform detection and fail-fast handlingThe OS/architecture normalization and explicit unsupported-platform exits are solid and improve installer reliability.
49-59: D2 releases do not publish integrity assetsLine 54 downloads a binary archive without checksum or signature verification. While this is a valid supply-chain security concern, D2 releases do not publish checksums, signatures, or similar integrity assets—only the binary artifacts themselves. HTTPS provides transport security, but additional verification is not feasible without D2 publishing integrity metadata. Consider noting this limitation in documentation or monitoring for future D2 improvements to their release process.
package.json (1)
12-12: Script wiring looks goodAdding
install:d2inscriptscleanly exposes the installer and aligns with the updated contributor workflow.CONTRIBUTING.md (1)
43-43: Documentation update is clear and actionableThe new D2 prerequisite, install step, command table entry, and pre-push/build note are consistent and reduce onboarding friction.
Based on learnings: Use pnpm for package management.
Also applies to: 62-66, 78-78, 140-140, 146-146
…tructions (#449) - Added D2 CLI as a requirement in the contributing guidelines. - Updated installation steps to include `pnpm install:d2` for D2 CLI. - Enhanced the install script to detect OS and architecture for D2 installation. - Included error handling and instructions for adding D2 to the PATH.
…tructions (#449) - Added D2 CLI as a requirement in the contributing guidelines. - Updated installation steps to include `pnpm install:d2` for D2 CLI. - Enhanced the install script to detect OS and architecture for D2 installation. - Included error handling and instructions for adding D2 to the PATH.
2 participants
…tructions
pnpm install:d2for D2 CLI.Summary by CodeRabbit
New Features
Documentation