Skip to content

Conversation

@wileyj
Copy link
Contributor

@wileyj wileyj commented Oct 23, 2025

Description

Describe the changes that were made in this pull request. When possible start with the motivations behind the change.

@wileyj wileyj requested a review from kenny-stacks October 23, 2025 16:19
@claude
Copy link

claude bot commented Oct 23, 2025

PR Review: Merge new-docs to master

Overview

This PR introduces a substantial documentation reorganization, adding 278 changed files with 27,543 additions and 0 deletions. This appears to be a new documentation structure under docs/build/ that consolidates developer-focused content.


✅ Strengths

1. Excellent Developer Onboarding

The new docs/build/README.md provides a comprehensive 30-minute quickstart tutorial that:

  • Walks developers through their first Stacks app end-to-end
  • Includes wallet setup, Clarity contract writing, deployment, and frontend integration
  • Uses clear, progressive steps with practical examples
  • Provides a working message board application as the learning project

2. Well-Structured Content Architecture

The new structure logically organizes content by developer tasks:

  • bitcoin-integration/ - Bitcoin transaction handling
  • build-a-frontend/ - Stacks.js integration guides
  • create-tokens/ - FT and NFT creation
  • testing-smart-contracts/ - Testing methodologies
  • sbtc/ - sBTC integration and signer operations

3. Strong Technical Content

  • Clarity Crash Course: Provides a solid LISP-style introduction with hands-on examples
  • sBTC Builder Quickstart: Clear path to working with sBTC using both Hiro Platform and Clarinet
  • Security Awareness: Good inclusion of security considerations (e.g., tx-sender vs contract-caller warning in README.md:242)

4. Developer Experience Focus

  • Links to external tools (Clarity Playground, Stacks Explorer Sandbox)
  • Multiple development paths (Hiro Platform vs local Clarinet)
  • Comprehensive next steps and community resources

⚠️ Concerns & Recommendations

1. Code Quality

Issue: Hardcoded test data in production code

In docs/build/README.md:395-406, the message loading logic uses hardcoded message IDs:

for (let i = Math.max(1, count - 4); i <= count; i++) {
  messagePromises.push(
    fetchCallReadOnlyFunction({
      contractAddress: CONTRACT_ADDRESS,
      contractName: CONTRACT_NAME,
      functionName: "get-message",
      functionArgs: [uintCV(i)],
      // ...
    })
  );
}

Recommendation: This is actually fine for a tutorial, but consider adding a comment explaining why we're loading the last 5 messages.

Issue: Magic numbers in contract

In docs/build/README.md:106-116, the get-recent-messages function has hardcoded u1 u2 u3 u4 u5:

(map get-message (list u1 u2 u3 u4 u5))

Recommendation: Add a comment explaining Clarity's limitation (no dynamic loops) and why this is hardcoded to 5 messages.

2. Security Concerns

Issue: Insufficient error handling

Multiple locations lack proper error handling:

  • docs/build/README.md:422-446 - postMessage function catches errors but only logs them
  • docs/build/README.md:379-420 - loadMessages silently fails on error

Recommendation: For production apps, guide developers to display error messages to users:

} catch (error) {
  console.error("Error posting message:", error);
  alert("Failed to post message. Please try again.");
  setLoading(false);
}

Issue: No input validation

The contract accepts any string-utf8 280 without validation for empty strings or malicious content.

Recommendation: Add a note about input validation in production contracts:

(define-public (add-message (content (string-utf8 280)))
  (begin
    (asserts! (> (len content) u0) (err u400)) ;; Prevent empty messages
    (let ((id (+ (var-get message-count) u1)))
      ;; ... rest of function
    )))

3. Performance Considerations

Issue: Polling for connection status

docs/build/README.md:338-351 polls connection status every 500ms:

const intervalId = setInterval(checkConnection, 500);

Recommendation: This is fine for a tutorial, but mention that production apps should use event-based connection detection if available.

Issue: Sequential message loading

The loadMessages function makes multiple sequential API calls. While Promise.all is used, there's potential for optimization.

Recommendation: Add a note about batching strategies for production apps with many messages.

4. Test Coverage

Missing: No test examples are provided with the quickstart tutorial.

Recommendation:

  • Add a section showing how to test the contract in Clarity Playground
  • Reference the testing-smart-contracts/ section
  • Show basic unit test examples with expected outputs

5. Documentation Quality Issues

Issue: Inconsistent file naming

  • misc.-guides/ uses a period in the directory name (unconventional)
  • Image files have inconsistent naming: Frame 316125324.jpg, image (1).png, etc.

Recommendation:

  • Rename misc.-guides/ to miscellaneous-guides/ or additional-guides/
  • Use descriptive image names: stacks-message-board-ui.png, clarity-playground-screenshot.png

Issue: Missing accessibility considerations

No alt text guidance for the numerous images being added.

Recommendation: Ensure all images have descriptive alt text for accessibility.

6. Potential Bugs

Issue: Race condition in message posting

docs/build/README.md:438-441 uses a hardcoded 2-second delay:

setTimeout(() => {
  loadMessages();
  setLoading(false);
}, 2000);

Recommendation: Explain that production apps should:

  • Use transaction confirmation APIs
  • Subscribe to transaction status updates
  • Poll the blockchain until the transaction is confirmed

Issue: Contract address placeholder

Line 321: const CONTRACT_ADDRESS = "YOUR_CONTRACT_ADDRESS_HERE";

Recommendation: Add clear instructions about updating this value and what happens if developers forget (the app won't work).


📋 Action Items

High Priority

  • Add error handling examples and best practices
  • Include input validation patterns for production contracts
  • Add testing examples to the quickstart
  • Clarify transaction confirmation patterns

Medium Priority

  • Rename misc.-guides/ to follow conventions
  • Add comments explaining Clarity limitations (hardcoded lists, etc.)
  • Improve image naming conventions
  • Add accessibility alt text guidelines

Low Priority

  • Document performance optimization strategies
  • Add production deployment checklist
  • Include troubleshooting section

🎯 Summary

Overall Assessment: This is a high-quality documentation addition that significantly improves the developer onboarding experience for Stacks. The content is well-written, technically accurate, and follows a logical progression.

Main Concerns:

  1. Tutorial code should include more robust error handling examples
  2. Security best practices should be emphasized more prominently
  3. Production deployment considerations need more attention

Recommendation: ✅ Approve with minor revisions

The tutorial code is appropriate for learning but should include callouts about production-ready patterns. The documentation structure is sound and will serve developers well.


📚 Related to CLAUDE.md

Per the repository's documentation sync guidelines, this PR is introducing new developer-facing content that may need to be referenced when reviewing PRs from other Stacks repositories. Key new documentation sections that may need updates based on upstream changes:

  • docs/build/clarity-crash-course.md - May need updates when Clarity language features change
  • docs/build/sbtc/ - Should track sBTC protocol changes
  • docs/build/build-a-frontend/ - Should track Stacks.js API changes
  • docs/build/testing-smart-contracts/ - Should track Clarinet changes

Great work on this comprehensive documentation update! 🎉

@claude
Copy link

claude bot commented Oct 24, 2025

PR Review: Merge new-docs to master

Overview

This is a major documentation restructuring that adds a new docs/ directory with GitBook-formatted content. The PR includes:

  • 279 changed files with 27,604 additions
  • New documentation structure with separate build/, learn/, operate/, contribute/, and reference/ sections
  • GitBook configuration and assets
  • Extensive redirect mappings for legacy URLs

Positive Aspects ✅

  1. Comprehensive Content: The new documentation is extensive and well-organized, with 192 markdown files covering ~27,542 lines of content.

  2. Strong Developer Quickstart: The docs/build/README.md provides an excellent 30-minute quickstart tutorial that:

    • Walks users through wallet setup, contract development, deployment, and frontend integration
    • Includes clear, runnable code examples
    • Provides helpful context and explanations
    • Links to additional resources appropriately
  3. Good URL Migration Planning: The .gitbook.yaml includes 97 redirect mappings to preserve legacy URLs, which is critical for SEO and existing links.

  4. Well-Structured Organization: Clear separation between conceptual docs (learn/), practical guides (build/), and operational docs (operate/).

  5. Rich sBTC Documentation: Comprehensive coverage of sBTC including builder quickstart, signer setup, bridge usage, and rewards.

Issues & Concerns ⚠️

1. Placeholder Content (Priority: HIGH)

File: docs/build/README.md:321

const CONTRACT_ADDRESS = "YOUR_CONTRACT_ADDRESS_HERE";
  • This placeholder is in the quickstart tutorial, which is a high-visibility entry point
  • Users may miss the instruction to replace it
  • Recommendation: Consider using a real example contract address from testnet or add a validation check in the example code

2. TODO Comments in Production Code (Priority: MEDIUM)

Found in multiple files:

  • docs/operate/stacking-stx/operate-a-stacking-pool.md:367
  • docs/operate/stacking-stx/increase-stacked-position.md:457
  • docs/operate/stacking-stx/solo-stack.md:181

Example:

;; TODO: this must be authorized with a signature, or tx-sender allowance!
  • These appear to be code examples from contracts
  • Recommendation: Either complete these TODOs or add explanatory text clarifying that these are intentional learning examples

3. Missing PR Description (Priority: HIGH)

The PR body only contains:

"Describe the changes that were made in this pull request. When possible start with the motivations behind the change."

  • This is a major restructuring that deserves detailed documentation
  • Recommendation: Add comprehensive description covering:
    • Motivation for the restructure
    • Impact on existing documentation
    • Deployment/publishing plan
    • How this integrates with existing concepts/, guides-and-tutorials/, etc. directories
    • Whether old docs will be deprecated/removed

4. Duplicate Documentation Structure (Priority: HIGH - Needs Clarification)

The repository now has two parallel documentation structures:

  • Existing: /concepts/, /guides-and-tutorials/, /reference/
  • New: /docs/build/, /docs/learn/, /docs/operate/

Critical Questions:

  • Will the old structure be removed?
  • How will these coexist?
  • Which should contributors update going forward?
  • What's the migration timeline?

Without this clarity, the repository may have:

  • Confusion about which docs are canonical
  • Maintenance burden of duplicate content
  • Inconsistent information across documentation sets

5. Binary Assets (Priority: LOW)

Multiple images and PDFs added (~100+ asset files)

  • Increases repository size significantly
  • Recommendation: Consider using Git LFS or external asset hosting for large binary files

6. Test Coverage (Priority: MEDIUM)

  • No evidence of link checking or validation
  • Recommendation: Run link checker to ensure:
    • Internal links are valid
    • External links work
    • Redirect mappings are correct

Security Considerations 🔒

  • ✅ No sensitive credentials or secrets detected
  • ✅ Code examples follow security best practices
  • ✅ Warning about tx-sender vs contract-caller security implications included

Performance Considerations ⚡

  • Repository size will increase significantly due to binary assets
  • Consider implementing:
    • Image optimization/compression
    • Git LFS for assets
    • CDN hosting for images

Recommendations Before Merge 📋

Must Address:

  1. ✏️ Write comprehensive PR description explaining restructure strategy
  2. ✏️ Clarify relationship between old and new documentation structures
  3. ✏️ Replace placeholder YOUR_CONTRACT_ADDRESS_HERE with working example or better guidance
  4. ✏️ Address or document TODO comments in code examples

Should Address:
5. 🔍 Run automated link checker
6. 🔍 Verify all redirects work correctly
7. 📝 Add migration guide for contributors

Nice to Have:
8. 🖼️ Optimize image sizes
9. 📚 Add documentation versioning strategy
10. 🧪 Add CI checks for broken links

Questions for the Author ❓

  1. What is the deployment timeline for this new documentation?
  2. Will the old concepts/, guides-and-tutorials/ directories be removed?
  3. Has this been tested on the GitBook platform?
  4. Is there a staged rollout plan or will this go live immediately?
  5. How should community contributors know which docs to update?

Overall Assessment: This is excellent, comprehensive documentation work that will greatly benefit the Stacks ecosystem. However, the PR needs clarification on the restructuring strategy and migration plan before merging to avoid documentation fragmentation and contributor confusion.

Recommendation: Request changes to address the "Must Address" items above, particularly the PR description and documentation structure clarification.


Review generated with Claude Code

@claude
Copy link

claude bot commented Oct 24, 2025

PR Review: Merge new-docs to master

Thank you for this substantial documentation restructuring effort! This PR represents a major reorganization of the Stacks documentation. Here's my comprehensive review:

Overview

  • Changed Files: 280 files
  • Additions: 27,640 lines
  • Status: Draft PR, mergeable
  • Scope: Complete documentation restructure with new GitBook structure for docs/build/, docs/learn/, and docs/contribute/ directories

Positive Aspects

1. Excellent Content Quality

The new documentation demonstrates high quality:

  • Developer Quickstart (docs/build/README.md): Outstanding 30-minute tutorial with clear, actionable steps
  • Well-structured step-by-step guides using GitBook stepper components
  • Comprehensive code examples with detailed explanations
  • Good balance between beginner-friendly content and technical depth

2. Improved Information Architecture

The new structure is more logical:

  • Clear separation: build/ (developer docs), learn/ (conceptual), contribute/ (contributor guides)
  • Well-organized SUMMARY.md files providing clear navigation
  • Topic grouping (Bitcoin Integration, Create Tokens, Build Frontend, etc.)

3. Enhanced Learning Path

  • Progressive difficulty: Quickstart → Crash Course → Specialized Topics
  • Excellent "Clarity Crash Course" with interactive examples
  • Strong sBTC documentation with builder quickstart
  • Good use of hints, warnings, and expandable sections

4. Developer Experience

  • References to modern tooling (Vite, React, Clarinet, Hiro Platform)
  • Practical examples with deployment instructions
  • Links to external resources and community

Areas Requiring Attention

1. Critical: Missing PR Description

The PR body contains only the template placeholder:

"Describe the changes that were made in this pull request. When possible start with the motivations behind the change."

Recommendation: Add a comprehensive description covering:

  • Motivation for this restructure
  • High-level changes (new sections, reorganization, deprecated content)
  • Migration impact (broken links, redirects needed)
  • Testing performed
  • Deployment plan

2. Documentation Migration Concerns

a. Broken Internal Links

With 280 files changed and a major restructure, there's high risk of broken links. Need verification:

  • Links from existing docs to new structure
  • Cross-references between build/, learn/, and contribute/
  • Links in learn/README.md reference broken-reference (line 44)

Recommendation:

# Check for broken internal links
grep -r "](/" docs/ | grep -v ".gitbook"
# Verify all cross-references resolve

b. Asset Path Consistency

Multiple asset directories: docs/build/.gitbook/assets/, docs/learn/.gitbook/assets/

  • Some images have generic names: image (1).png, image (2).png, etc.
  • Risk of confusion and maintenance challenges

Recommendation: Establish naming conventions for assets (e.g., clarity-crash-course-example.png)

3. Code Examples: Hardcoded Values

In docs/build/README.md:320-322:

// Replace with your contract address
const CONTRACT_ADDRESS = "YOUR_CONTRACT_ADDRESS_HERE";
const CONTRACT_NAME = "message-board";

Issue: Users might miss the placeholder and encounter errors.

Recommendation:

  • Use environment variables: import.meta.env.VITE_CONTRACT_ADDRESS
  • Add validation to display helpful error if not set
  • Include .env.example in documentation

4. GitBook-Specific Syntax

Heavy use of GitBook-specific features:

  • {% stepper %}, {% hint %}, {% embed %}
  • May not render properly in GitHub or other Markdown viewers

Recommendation:

  • Document that these docs are GitBook-first
  • Consider providing a GitHub-compatible version or rendering instructions
  • Add note in README about required rendering engine

5. Outdated/Placeholder Content

docs/build/misc.-guides/build-a-borrowing-and-lending-protocol.md appears to be only 11 lines (based on additions count).

Recommendation: Review all files for completeness before merging to master.

6. Testing Coverage

No test files or CI configuration changes visible.

Recommendation:

  • Add link validation in CI
  • Implement automated checks for:
    • Broken internal links
    • Missing images
    • Markdown syntax errors
    • Code block syntax validation

Security Considerations

1. PDF Files

Multiple security audit PDFs added:

  • Blockstack_Desktop_Wallet_Pentest_Report_11-12-2020.pdf
  • Various audit reports from CoinFabrik, Ottersec, NCC Group, Quantstamp

Recommendation: Verify these are intended for public distribution and don't contain sensitive information.

2. Asset Files Without Review

280 files include many binary assets (images, PDFs). Binary files are harder to review.

Recommendation: Create a manifest or index of all binary files with descriptions.


Performance Considerations

1. Repository Size

Adding 27,640 lines (primarily documentation) plus binary assets significantly increases repo size.

Consideration:

  • Is Git LFS being used for large binaries?
  • Should assets be hosted externally (CDN)?

2. Build Time

If using GitBook or static site generator, build time may increase.

Recommendation: Profile build time before/after merge.


Best Practices & Suggestions

1. Documentation Standards

Consider creating a CONTRIBUTING_DOCS.md covering:

  • File naming conventions
  • Asset naming and organization
  • Style guide (tone, formatting)
  • Link formatting standards
  • Code example standards

2. Version Management

  • Are these docs versioned with Stacks releases?
  • How are breaking changes handled?
  • Consider adding version indicators if docs apply to specific Stacks versions

3. Accessibility

  • Image alt text: Some images use generic <figcaption> or empty alt attributes
  • Consider adding more descriptive alt text for accessibility

4. Maintenance Plan

With this much new content:

  • Who maintains each section?
  • How often is content reviewed for accuracy?
  • Process for community contributions?

Testing Recommendations

Before merging, verify:

  1. Link Validation

    # Find all markdown links
    find docs/ -name "*.md" -exec grep -H "](" {} \;
  2. Asset References

    # Ensure all referenced images exist
    find docs/ -name "*.md" -exec grep -H "assets/" {} \; | while read line; do
      # Extract and verify file path
    done
  3. Code Syntax Validation

    • Test all Clarity code examples in Clarity Tools/Clarinet
    • Test all JavaScript examples for syntax errors
    • Verify package versions in examples
  4. Deployment Preview

    • Deploy to staging environment
    • Test navigation flow
    • Verify search functionality
    • Mobile responsiveness check

Recommendations Summary

Before Merging (Required):

  1. Add comprehensive PR description
  2. Fix broken internal links (especially broken-reference in learn/README.md)
  3. Validate all code examples
  4. Review and complete partial/placeholder content
  5. Add link validation to CI

Consider for Follow-up (Suggested):

  1. 🔄 Establish asset naming conventions
  2. 🔄 Add environment variable examples for code samples
  3. 🔄 Create documentation contribution guide
  4. 🔄 Profile and optimize build performance
  5. 🔄 Improve image alt text for accessibility

Conclusion

This is high-quality documentation work that significantly improves the Stacks developer experience. The content is well-written, comprehensive, and follows modern documentation best practices.

However, given the scale of changes (280 files, 27K+ additions), thorough validation is essential before merging to master. The primary concerns are:

  • Broken links
  • Incomplete content
  • Deployment/migration planning

Recommendation: Keep as draft until validation checklist is complete, then merge with confidence.

Great work on this major documentation initiative! 🎉


Review generated by Claude Code. For questions about this review, please refer to the repository's CLAUDE.md guidelines.

@claude
Copy link

claude bot commented Oct 24, 2025

PR Review: Merge new-docs to master

This is a large-scale documentation migration PR with 281 files and 27,671 additions. Overall the content quality is excellent, but there are several issues that should be addressed before merging.

Strengths

  • Outstanding content quality with clear, comprehensive tutorials
  • Strong pedagogical structure with hands-on examples
  • Modern GitBook tooling with proper structure
  • No security concerns identified

Critical Issues Requiring Resolution

1. Broken Internal References (HIGH PRIORITY)
Found broken-reference placeholders in 8 files:

  • docs/learn/README.md
  • docs/reference/stacks-node-configuration.md
  • docs/reference/signer-configuration.md
  • docs/operate/run-a-signer/README.md
  • And 4 others

These must be resolved before merging to master.

2. Potential Link Breakage (HIGH PRIORITY)
This major restructuring may break external links. Consider setting up redirects from old paths to new paths.

3. Incomplete PR Description
For a 27k+ line PR, the description should explain motivation, migration plan, breaking changes, and testing performed.

Action Items Before Merge

Must Fix:

  • Replace all broken-reference placeholders with actual links
  • Write comprehensive PR description
  • Set up URL redirects to prevent broken external links
  • Test GitBook rendering of all pages

Should Fix:

  • Improve CONTRACT_ADDRESS placeholder with format example
  • Run broken link checker
  • Document migration path

Assessment

Content Quality: 5/5
Technical Implementation: 3/5

Recommendation: Request Changes

Great documentation work! Once broken references and redirects are addressed, this will significantly improve the developer experience.

@claude
Copy link

claude bot commented Oct 24, 2025

PR Review: Documentation Restructuring

Overview

This PR merges the new-docs branch into master, introducing a significant documentation reorganization with 282 changed files and 27,688 additions. The changes appear to reorganize the documentation into distinct sections: build/, learn/, operate/, contribute/, press-and-reports/, and reference/.

Key Observations

Structure & Organization ✅

The new structure is well-organized and follows a logical information architecture:

  • docs/build/: Developer-focused quickstart and tutorials (new content)
  • docs/learn/: Conceptual documentation about Stacks fundamentals
  • docs/operate/: Node and signer operations
  • docs/contribute/: Contribution guidelines
  • docs/reference/: Technical references

This separation of concerns (Learn → Build → Operate) creates a clearer user journey.

Content Quality ✅

The new quickstart tutorial (docs/build/README.md) is excellent:

  • Clear, step-by-step progression (30-minute tutorial)
  • Practical, hands-on approach with a working example (message board)
  • Good use of GitBook features (stepper, hints, collapsible sections)
  • Comprehensive coverage: wallet setup → Clarity contract → deployment → frontend integration
  • Links to external resources are appropriate

Documentation Best Practices ✅

  • Uses GitBook YAML configuration files
  • Includes SUMMARY.md files for navigation
  • Assets properly organized in .gitbook/assets/ directories
  • Appropriate use of markdown features and GitBook components

Areas of Concern

1. Missing PR Description ⚠️

Issue: The PR description is a template placeholder with no actual content describing the changes.

Impact: This makes it difficult to:

  • Understand the motivation behind the restructure
  • Know if this is intended to replace existing docs or augment them
  • Identify any breaking changes or deprecations
  • Review the scope and completeness of the migration

Recommendation: Please update the PR description to include:

  • Motivation for the restructure
  • Overview of what changed and where content was moved
  • Any deprecated or removed sections
  • Migration plan (if any) for existing documentation links
  • Testing/validation performed

2. Binary Files & Assets 📦

Observation: The PR includes numerous binary files (PDFs, images):

  • Audit reports (CoinFabrik, Ottersec, NCC Group, Quantstamp)
  • Images and JPEGs
  • PDF documentation

Questions:

  • Are these new assets or migrated from another location?
  • Have the PDFs been scanned for malware?
  • Are the file sizes optimized for web delivery?
  • Do we have proper licensing/permissions for all assets?

Recommendation: Consider using a CDN or external asset storage for large binary files to keep the repository lean.

3. Potential Link Breakage 🔗

Issue: This reorganization will likely break existing external links to the documentation.

Recommendations:

  • Set up redirects from old URLs to new URLs
  • Document the URL mapping in the PR description
  • Update any internal links in other repositories (stacks-core, clarinet, etc.)
  • Consider a deprecation notice period if URLs are changing

4. Code Examples in Quickstart 📝

In docs/build/README.md, line 321:

const CONTRACT_ADDRESS = "YOUR_CONTRACT_ADDRESS_HERE";

Recommendation: Consider adding a more prominent warning or validation that reminds users to replace this placeholder. New developers often miss this step.

5. External Link Dependencies 🌐

The tutorial relies on several external services:

  • leather.io
  • Stacks Explorer (explorer.hiro.so)
  • Clarity Playground (play.hiro.so)

Recommendation: Add a note about these dependencies and what to do if any service is unavailable.

6. Testing & Validation ✅

Questions:

  • Has this been tested in GitBook?
  • Have all links been validated?
  • Have the code examples been tested end-to-end?
  • Is there a preview deployment we can review?

Security Considerations

Low Risk ✅

This is primarily a documentation change with no code execution, so security risk is minimal. However:

  • The Clarity contract example is simple and appears safe
  • The React frontend code follows standard practices
  • No credentials or secrets detected in the changes

Performance Considerations

Potential Issue: Large Repository Size 📊

Adding 27,688 lines and numerous binary assets will increase repository size significantly.

Recommendations:

  • Use Git LFS for large binary files (PDFs, high-res images)
  • Optimize images before committing
  • Consider external hosting for audit reports and large PDFs

Recommendations Summary

Before Merging (Required):

  1. Fill out the PR description with detailed information about the changes
  2. Document URL mapping and set up redirects for breaking changes
  3. Test in GitBook and share a preview link
  4. Validate all internal and external links

Consider (Optional):

  1. Add placeholder validation in code examples
  2. Move large binary files to Git LFS or external hosting
  3. Add a changelog or migration guide for users of the old docs structure
  4. Update CLAUDE.md if the documentation structure significantly impacts the sync system

Overall Assessment

Quality: High - The content is well-written and the structure is an improvement
Completeness: Cannot fully assess without PR description
Risk Level: Low - Documentation only, no code changes
Recommendation: Approve with required changes - Please update the PR description before merging.


Review generated by Claude Code. For questions about this review, check the repository's CLAUDE.md.

@claude
Copy link

claude bot commented Oct 24, 2025

PR Review: Merge new-docs to master

Overview

This is a major documentation restructure adding 283 files with 27,718 additions and 0 deletions. This appears to be a new GitBook-based documentation structure being merged into the main branch, creating two main documentation sections: docs/build/ and docs/learn/.

Summary of Changes

New Documentation Structure:

  • docs/build/: New developer-focused documentation with quickstart guides, tutorials, and how-to content
  • docs/learn/: Conceptual documentation with redirect mappings from old structure
  • Binary Assets: 20+ images in docs/build/.gitbook/assets/ and 60+ assets in docs/learn/.gitbook/assets/ including PDFs (audit reports)

Key New Content:

  • Developer Quickstart guide (686 lines) - comprehensive 30-minute tutorial
  • Clarity Crash Course
  • sBTC guides (builder quickstart, signer operations, bridge usage)
  • Bitcoin integration guides
  • Token creation tutorials (NFT/FT)
  • Frontend development guides (Stacks.js integration)
  • Testing guides (fuzz testing)
  • Price oracle documentation
  • Contribution guidelines

Review Feedback

✅ Strengths

  1. Excellent Developer Onboarding: The new Developer Quickstart (docs/build/README.md:1-687) is comprehensive and well-structured:

    • Clear 30-minute time commitment
    • Step-by-step wallet setup, contract writing, deployment, and frontend integration
    • Real working code examples
    • Good use of GitBook stepper components for progressive disclosure
  2. Strong Clarity Content: The Clarity tutorials demonstrate best practices:

    • Clear explanations of LISP-style syntax
    • Proper use of define-map, define-data-var, define-public, define-read-only
    • Good security warnings about tx-sender vs contract-caller (docs/build/README.md:241-245)
    • Links to external resources (Clarity Book, Clarity Universe)
  3. Well-Organized Structure: The SUMMARY.md files provide clear navigation hierarchies

  4. Redirect Configuration: Proper redirect mappings in .gitbook.yaml files ensure old URLs still work


⚠️ Issues and Concerns

1. Missing PR Description (Critical)

The PR body contains only a placeholder template without any actual description of the changes. For a PR of this magnitude, this is unacceptable.

Required Information:

  • What is the motivation for this restructure?
  • Is this replacing existing documentation or supplementing it?
  • How does this relate to the existing directory structure?
  • What testing has been done?
  • Are there any breaking changes to existing documentation URLs?
  • What is the rollout/deployment plan?

2. No Testing Evidence

With 27,718 lines of new content, there's no evidence of:

  • Link validation (internal and external links)
  • Code example testing (does the Clarity code actually work?)
  • Frontend code testing (does the React app run?)
  • Asset verification (are all images displaying correctly?)
  • Redirect testing (do old URLs properly redirect?)

Recommendations:

  • Run automated link checking across all markdown files
  • Test contract deployment examples on testnet
  • Verify the React frontend code compiles and runs
  • Validate all contract-call? examples in Clarity Playground
  • Test redirect configuration in GitBook

3. Hardcoded Placeholder Values

In docs/build/README.md:321-322:

const CONTRACT_ADDRESS = "YOUR_CONTRACT_ADDRESS_HERE";
const CONTRACT_NAME = "message-board";

Issue: While the tutorial instructs users to replace this (line 633-637), this pattern can lead to confusion and copy-paste errors.

Recommendation: Consider using environment variables or a more obvious placeholder like process.env.VITE_CONTRACT_ADDRESS with clear setup instructions.


4. Incomplete Error Handling in Frontend Code

In docs/build/README.md:422-445, the postMessage function has minimal error handling:

} catch (error) {
  console.error("Error posting message:", error);
  setLoading(false);
}

Issue: No user feedback when transactions fail. Users see console errors but no UI indication.

Recommendation: Add user-visible error states and retry mechanisms for better UX.


5. Potential Race Condition

In docs/build/README.md:437-441:

// Reload messages after a delay to allow the transaction to process
setTimeout(() => {
  loadMessages();
  setLoading(false);
}, 2000);

Issue: Using a fixed 2-second delay is unreliable. Transactions may take longer or complete faster.

Recommendation: Poll transaction status or use WebSocket subscriptions to detect when transactions are confirmed.


6. Security Consideration in Clarity Example

The tutorial correctly warns about tx-sender vs contract-caller (docs/build/README.md:241-245), which is excellent. However, the message board contract doesn't implement any access controls or spam prevention.

Recommendation: Consider adding a note about production considerations:

  • Rate limiting
  • Message size validation (already has 280 char limit)
  • Deletion/moderation capabilities
  • Potential abuse vectors

7. GitBook Asset Management

Observations:

  • 20 assets in docs/build/.gitbook/assets/
  • 60+ assets in docs/learn/.gitbook/assets/
  • Includes large PDFs (audit reports)
  • Generic filenames like "image (1).png" through "image (27).png"

Issues:

  • Large binary files in git repository bloat history
  • Non-descriptive filenames make maintenance difficult
  • No documentation about what each asset represents

Recommendations:

  • Use descriptive asset names (e.g., stacks-wallet-setup-step-1.png instead of image (1).png)
  • Consider using Git LFS for large binary files
  • Add a manifest documenting each asset's purpose
  • Consider hosting assets via CDN instead of in repository

8. Code Style Inconsistencies

Clarity Code:

  • Some examples use 2-space indentation, others use 4-space
  • Inconsistent comment styles

JavaScript/JSX:

  • Generally good, but mixing template literals and string concatenation

Recommendation: Establish and document code style guidelines for documentation examples.


9. Dependency Versions Not Specified

In docs/build/README.md:288-298, package installations don't specify versions:

npm create vite@latest my-message-board -- --template react
npm install @stacks/connect @stacks/transactions @stacks/network

Issue: Without pinned versions, examples may break as packages update with breaking changes.

Recommendation: Specify exact versions that are known to work:

npm install @stacks/[email protected] @stacks/[email protected] @stacks/[email protected]

10. Missing Accessibility Considerations

  • No alt text pattern established for images
  • Some images have empty <figcaption> or generic text
  • No mention of accessibility best practices for dApp development

Recommendation: Add guidance on wallet accessibility and inclusive design.


🔒 Security Review

  1. Audit Reports: PDFs in docs/learn/.gitbook/assets/ appear to be legitimate security audits (NCC Group, CoinFabrik, Ottersec, Quantstamp). These add credibility. ✅

  2. External Links: Should validate all external links point to official/trusted sources:

    • leather.io ✅
    • xverse.app ✅
    • hiro.so ✅
    • clarity-lang.org ✅
  3. Testnet Emphasis: Good practice encouraging testnet usage throughout. ✅

  4. Private Key Handling: No examples show private key handling (good). ✅


📊 Performance Considerations

  1. Large PR Size: 27,718 additions make this difficult to review thoroughly. Consider breaking into smaller, themed PRs in the future.

  2. Asset Optimization: Images should be optimized (compressed, appropriately sized) before committing.

  3. Build Times: Adding 283 files will impact documentation build times. Ensure CI/CD pipelines can handle this.


✏️ Minor Issues

  1. Typos/Grammar: Would need detailed review, but spot-checked sections look clean

  2. Broken Internal Links: Need automated checking for links like:

    • [Clarity Crash Course](clarity-crash-course.md) (docs/build/README.md:64)
    • [Post Conditions](build-a-frontend/post-conditions-with-stacks.js.md) (docs/build/README.md:272)
  3. External Link Freshness: Links like https://play.hiro.so/ and https://explorer.hiro.so/ should be validated


Recommendations Before Merge

Must-Have:

  1. Add comprehensive PR description explaining motivation, impact, and testing
  2. Run automated link checker to validate all internal and external links
  3. Test all code examples - especially the contract deployment and React app
  4. Document rollout plan - is this replacing or supplementing existing docs?
  5. Pin dependency versions in tutorials

Should-Have:

  1. Improve frontend error handling in examples
  2. Add asset naming/organization documentation
  3. Implement transaction status polling instead of setTimeout
  4. Add production security considerations to tutorials
  5. Optimize and possibly Git LFS-track large binary assets

Nice-to-Have:

  1. Break into smaller PRs for future restructures
  2. Add code style guidelines document
  3. Include accessibility best practices
  4. Add automated testing for documentation builds

Conclusion

This is a significant improvement to the Stacks documentation with excellent developer-focused content. The new structure, tutorials, and quickstart guides are well-written and will greatly help new developers.

However, the PR lacks critical context, testing evidence, and has several technical issues that should be addressed before merging to production.

Recommendation: Request changes to address the critical issues (PR description, testing, link validation) before approval. The content quality is high, but the process quality needs improvement for a change of this magnitude.


Questions for PR Author

  1. What is the relationship between this new structure and existing documentation?
  2. Has this been tested in a staging GitBook environment?
  3. What is the migration plan for existing documentation URLs?
  4. Have all code examples been manually tested?
  5. Are there any known issues or follow-up work planned?

cc: @wileyj

@claude
Copy link

claude bot commented Oct 27, 2025

PR Review: Merge new-docs to master

Thank you for this substantial documentation restructure! I've reviewed this PR which adds 298 files with 27,849 additions across multiple documentation sections. Here's my comprehensive feedback:


📋 Overview

This PR appears to be a major documentation reorganization that:

  • Creates new GitBook-structured documentation in docs/build/, docs/learn/, docs/operate/, docs/reference/, and other sections
  • Adds extensive redirect mappings in .gitbook.yaml files to maintain backward compatibility
  • Introduces new tutorial content including a Developer Quickstart, sBTC guides, token creation guides, and more
  • Includes numerous assets (images, PDFs) for the documentation

✅ Strengths

1. Comprehensive Documentation Structure

The new structure follows GitBook conventions with clear separation:

  • build/ - Developer-focused tutorials and guides
  • learn/ - Conceptual documentation
  • operate/ - Operational guides
  • reference/ - Technical reference material

2. Excellent Redirect Handling

The .gitbook.yaml files include thorough redirect mappings (e.g., docs/learn/.gitbook.yaml), ensuring that existing links continue to work. This is critical for maintaining SEO and user bookmarks.

3. Strong Developer Quickstart (docs/build/README.md)

The new quickstart tutorial is well-structured with:

  • Clear learning objectives and prerequisites
  • Step-by-step progression (wallet setup → contract → deployment → frontend)
  • Good use of code examples with explanations
  • Helpful hints and warnings (e.g., tx-sender vs contract-caller security note)
  • Appropriate links to deeper resources

4. Good Documentation of Security Concerns

The quickstart includes important security warnings like the tx-sender vs contract-caller distinction at line 241-245 of docs/build/README.md.


⚠️ Issues & Concerns

1. Missing PR Description

Severity: High

The PR body contains only the template text:

"Describe the changes that were made in this pull request. When possible start with the motivations behind the change."

Recommendation: Please provide:

  • Clear motivation for this restructure
  • Summary of what's being migrated vs. what's new
  • Migration plan for existing documentation
  • How this affects existing users/links
  • Testing performed (broken link checks, etc.)

2. Unclear Merge Strategy

Severity: High

Questions that need answers:

  • Is this replacing existing documentation entirely, or augmenting it?
  • Are there files in master that will be orphaned?
  • How does this relate to existing documentation structure?
  • What happens to pages not included in the redirects?

3. Potential Hardcoded Values

Severity: Medium

In docs/build/README.md:321:

const CONTRACT_ADDRESS = "YOUR_CONTRACT_ADDRESS_HERE";
const CONTRACT_NAME = "message-board";

While this is clearly a placeholder for a tutorial, consider:

  • Adding a code comment indicating this is a placeholder
  • Or using a live example contract address on testnet that users can reference

4. Large Binary Files

Severity: Medium

The PR includes many binary assets (images, PDFs). Considerations:

  • Are these optimized for web delivery?
  • Could large PDFs be hosted externally to reduce repo size?
  • Are audit PDFs in docs/learn/.gitbook/assets/ necessary in the repo vs. linking to external sources?

5. Incomplete Clarity Example

Severity: Low

The get-recent-messages function in the quickstart (lines 107-116) has a limitation - it hardcodes returning 5 messages regardless of the count parameter. This could confuse developers. Consider:

  • Either making it truly dynamic
  • Or adding a comment explaining it's simplified for the tutorial

6. Network Configuration

Severity: Low

In docs/build/README.md:318, the network is hardcoded as a string:

const network = "testnet";

Consider showing users how to import from @stacks/network:

import { StacksTestnet } from '@stacks/network';
const network = new StacksTestnet();

This is more aligned with Stacks.js best practices.


🔍 Security Considerations

1. Post Conditions Warning

The quickstart mentions post conditions (line 272) but doesn't explain their security importance. Consider adding:

  • Why post conditions matter (prevent unexpected token transfers)
  • Link to the dedicated post conditions page earlier in the tutorial

2. Private Key Handling

While the tutorial uses wallet connections (good!), ensure somewhere in the docs there's clear guidance about NEVER committing private keys or seed phrases.


📊 Code Quality & Best Practices

1. React Code Quality

The React example in the quickstart is generally good, but has some considerations:

Polling for connection status (lines 338-351):

const intervalId = setInterval(checkConnection, 500);

This polling approach works but could be improved with event listeners if Stacks Connect supports them.

Timeout-based message refresh (lines 437-441):

setTimeout(() => {
  loadMessages();
  setLoading(false);
}, 2000);

This 2-second delay is a workaround. Consider mentioning this is for demo purposes and production apps should use transaction confirmation events.

2. Error Handling

The frontend code has console.error statements but no user-facing error messages. For a tutorial, consider showing how to:

  • Display errors to users
  • Handle transaction failures gracefully

3. Accessibility

The CSS and JSX don't include accessibility considerations (ARIA labels, keyboard navigation, etc.). While not critical for a tutorial, mentioning accessibility as a "next step" would be valuable.


🧪 Testing Coverage

Questions:

  • Have all the code examples been tested?
  • Have the links and redirects been validated?
  • Has someone followed the quickstart end-to-end?
  • Are the smart contract examples deployed and verified on testnet?

Recommendation: Add a testing checklist to the PR description showing what's been validated.


📈 Performance Considerations

  1. Large file count: 298 files is substantial. Ensure your build system handles this efficiently.
  2. Image optimization: Verify all images are web-optimized (compressed, appropriate dimensions).
  3. PDF sizes: Several audit PDFs are included - these can be large. Consider external hosting.

🎯 Recommendations

Before Merging:

  1. Fill out the PR description with comprehensive context
  2. Validate all redirects work correctly
  3. Test the quickstart tutorial end-to-end with a fresh setup
  4. Check for broken links using a link checker tool
  5. Verify image alt text for accessibility and SEO
  6. Consider a staged rollout given the scope of changes

Post-Merge:

  1. Monitor 404s using analytics to catch any broken redirects
  2. Gather user feedback on the new structure
  3. Update any automation that depends on the old structure
  4. Consider versioning the docs if this is a breaking change

📝 Minor Issues

  • Some commit messages are generic ("GitBook: No commit message")
  • Consider adding a CHANGELOG or migration guide
  • The PR is marked as Draft - is it ready for review?

Summary

This is an impressive documentation overhaul with strong content, particularly the new Developer Quickstart. The main concerns are:

  1. Lack of context in the PR description
  2. Need for clarity on migration strategy
  3. Testing validation needed

Once these are addressed, this should significantly improve the Stacks documentation experience!

Recommendation: Address the high-severity issues above before merging, particularly the PR description and testing validation.


Review completed by Claude Code. Questions? Let me know!

@claude
Copy link

claude bot commented Oct 27, 2025

PR Review: Documentation Restructuring into GitBook Spaces

Summary

This PR represents a major reorganization of the Stacks documentation, restructuring content from the existing concepts/, guides-and-tutorials/, and reference/ directories into new GitBook "spaces" under docs/build/, docs/learn/, docs/operate/, docs/reference/, and docs/press-and-reports/. The PR adds 27,849 lines across 298 files with no deletions, indicating this is primarily additive content.


Positive Aspects

1. High-Quality Content

The new documentation is well-written with excellent examples:

  • The Developer Quickstart (docs/build/README.md) provides a comprehensive 30-minute tutorial with clear steps
  • The Clarity Crash Course offers practical examples with good explanations
  • The sBTC Builder Quickstart is concise and actionable

2. Excellent Structure & Navigation

  • Clear separation of concerns: Learn vs Build vs Operate vs Reference
  • GitBook stepper components make tutorials easy to follow
  • Proper use of hints, warnings, and collapsible sections for additional details

3. Proper Redirects

The .gitbook.yaml files include comprehensive redirect mappings from old paths to new paths, which is crucial for:

  • SEO preservation
  • Preventing broken external links
  • Smooth user experience during migration

4. Good Use of Visual Aids

  • Includes relevant images and diagrams
  • Embedded YouTube videos for complex concepts
  • Code examples with syntax highlighting

Critical Issues to Address

1. Missing PR Description

The PR body only contains a template placeholder: "Describe the changes that were made in this pull request..."

Impact: High - Without proper documentation:

  • Reviewers don't understand the motivation
  • Future maintainers can't understand the context
  • It's unclear if this is a migration, duplication, or replacement

Recommendation: Update the PR description with:

  • Why this restructuring is happening
  • What happens to the old documentation
  • Migration/deprecation timeline
  • Impact on existing links and bookmarks
  • Testing performed (link validation, redirects, etc.)

2. Potential Content Duplication

The PR adds 27,849 lines with 0 deletions. This suggests:

  • Old documentation at root level (concepts/, guides-and-tutorials/, etc.) still exists
  • New documentation in docs/ subdirectories is being added

Impact: High - Duplicate content leads to:

  • Confusion about which docs are canonical
  • Maintenance burden (updating content in two places)
  • SEO issues (duplicate content penalties)
  • Stale documentation if only one copy is updated

Questions to answer:

  1. Is this a complete replacement or parallel structure?
  2. Will old docs be deprecated/removed in a follow-up PR?
  3. How will external links to old paths be handled beyond redirects?
  4. What's the long-term maintenance plan?

Recommendation:

  • Add a clear migration plan in the PR description
  • Consider deprecation notices in old docs pointing to new locations
  • Plan a follow-up PR to remove old content after validation period

3. Hard-Coded Contract Addresses

In docs/build/sbtc/sbtc-builder-quickstart.md:94 and docs/build/README.md:321:

(define-constant sbtc-token 'SM3VDXK3WZZSA84XXFKAFAF15NNZX32CTSG82JFQ4.sbtc-token)
const CONTRACT_ADDRESS = "YOUR_CONTRACT_ADDRESS_HERE";

Impact: Medium

  • The sBTC contract address appears to be a testnet address (starts with SM...)
  • Using hard-coded addresses in tutorial code could cause confusion if addresses change
  • The placeholder YOUR_CONTRACT_ADDRESS_HERE is good, but the hard-coded sBTC address should be clearly labeled

Recommendation:

  • Add comments indicating this is a testnet/devnet address
  • Consider if this should reference mainnet addresses for production use
  • Ensure consistency across all examples

4. Broken Internal References

Several files contain references that may not resolve correctly:

In docs/build/README.md:272:

there is a dedicated docs page talking about [Post Conditions](build-a-frontend/post-conditions-with-stacks.js.md)

In docs/learn/README.md:44:

There is an entire section of these docs dedicated to explaining[ sBTC](broken-reference).

Note the literal "broken-reference" in the link

Impact: Medium - Broken links harm user experience and credibility

Recommendation:

  • Audit all internal links for correctness
  • Fix the "broken-reference" link to point to the actual sBTC section
  • Ensure relative paths work correctly in GitBook's rendering

5. External GitBook References

Multiple files reference app.gitbook.com URLs:

Examples:

  • docs/build/sbtc/sbtc-builder-quickstart.md:22: https://app.gitbook.com/o/.../s/.../
  • docs/learn/README.md:62: https://app.gitbook.com/o/.../s/.../

Impact: Medium-Low

  • External GitBook URLs with organization/space IDs suggest these may be from a staging environment
  • These may break if the GitBook project structure changes
  • Better to use relative paths or final published URLs

Recommendation:

  • Replace app.gitbook.com URLs with relative paths where possible
  • If external references are necessary, use the final published docs.stacks.co URLs
  • Document why external URLs are used if they're intentional

Security Considerations

No Security Issues Found

  • No sensitive information (API keys, secrets) in the documentation
  • Contract examples are educational and appropriate
  • External links appear legitimate

Performance Considerations

Large Binary Files

The PR includes many image assets in .gitbook/assets/:

  • Binary files increase repository size
  • Consider using Git LFS for large assets
  • Optimize images for web (compression, appropriate formats)

Recommendation:

  • Run images through optimization (e.g., imageoptim, tinypng)
  • Consider if all images are necessary or if some are duplicates

Testing Recommendations

Before Merging:

  1. Link Validation:

    • Run a link checker on all markdown files
    • Verify all internal references resolve correctly
    • Test redirect mappings work as expected
  2. Build Testing:

    • Ensure GitBook builds without errors
    • Check that navigation structure renders correctly
    • Verify search functionality works with new content
  3. Content Review:

    • Have subject matter experts review technical accuracy
    • Check code examples actually work (especially the contract examples)
    • Verify all commands and installation instructions are current
  4. Migration Testing:

    • Test that old URLs properly redirect to new locations
    • Verify no 404 errors for existing external links pointing to old docs
    • Check that search engines can find the new content

Minor Issues

1. Inconsistent Heading Style

Some files use title case, others sentence case - consider standardizing

2. Code Comment Clarity

In docs/build/README.md:242:
The warning about tx-sender vs contract-caller is excellent, but the explanation could be even clearer about the security implications

3. Placeholder Content

docs/build/misc.-guides/build-a-borrowing-and-lending-protocol.md appears to have minimal content (11 lines). Verify if this is intentional or needs expansion.


Overall Assessment

Code Quality: ⭐⭐⭐⭐ (4/5)

  • Well-written documentation with good examples
  • Clear structure and organization
  • Good use of GitBook features

Completeness: ⭐⭐⭐ (3/5)

  • Missing critical context in PR description
  • Unclear migration/deprecation plan
  • Some broken references need fixing

Risk Level: Medium

  • Large structural change without clear migration plan
  • Potential for duplicate/stale content
  • Broken internal links need resolution

Recommendation: Request Changes

This is excellent documentation work, but the PR needs:

  1. A comprehensive description explaining the migration
  2. Clarification on duplicate content handling
  3. Fix for broken internal references
  4. Link validation testing

Once these issues are addressed, this will be a significant improvement to the Stacks documentation.


Action Items for PR Author

  • Add comprehensive PR description with migration plan
  • Fix broken internal reference to sBTC section
  • Audit and fix all internal links
  • Replace app.gitbook.com URLs with appropriate alternatives
  • Clarify contract address usage (testnet vs mainnet)
  • Document plan for old documentation (deprecate, remove, or keep?)
  • Run link validation tools
  • Optimize image assets
  • Plan follow-up PR for old content removal if applicable

Great work on creating comprehensive, high-quality documentation! Once these issues are addressed, this will significantly improve the developer experience. 🚀

@claude
Copy link

claude bot commented Oct 27, 2025

PR Review: Merge new-docs to master

This PR introduces a substantial documentation reorganization with 298 changed files and 27,849 additions. I've reviewed the structure, content quality, and organization of this major documentation update.

Overall Assessment

Positive aspects:

  • Well-structured content: The new documentation follows a clear, logical hierarchy with separate /build, /learn, and /contribute sections
  • High-quality tutorials: The Developer Quickstart (README.md) is exceptionally well-written with step-by-step guidance, code examples, and clear explanations
  • Comprehensive coverage: Includes important topics like sBTC, Bitcoin integration, token creation, testing, and frontend development
  • Good use of GitBook features: Proper use of steppers, hints, collapsible sections, and formatted code blocks
  • Practical examples: Real, working code examples with explanations (e.g., message board tutorial, sBTC quickstart)

Content Quality Review

Strengths

  1. Developer Quickstart (docs/build/README.md):

    • Clear 30-minute tutorial format
    • Covers essential workflow: wallet setup → contract writing → deployment → frontend
    • Excellent code quality with helpful comments
    • Good pedagogical approach with progressive disclosure (basic concepts + deep dive sections)
    • Proper security warnings (e.g., tx-sender vs contract-caller)
  2. sBTC Documentation (docs/build/sbtc/):

    • Comprehensive quickstart for builders
    • Multiple deployment options (Hiro Platform + local Clarinet)
    • Clear examples of SIP-010 token usage
    • Practical focus on the most common operations
  3. Clarity Resources:

    • Crash course provides good foundation
    • References authoritative external resources (Clarity Book, Clarity Universe)
    • Shows both interactive tools (Clarity Playground, Clarity Tools)
  4. Frontend Integration:

    • Good coverage of Stacks.js usage
    • Important security concept (post conditions) properly explained
    • Links to sample applications

Areas for Improvement

1. PR Description

The PR description is essentially empty:

## Description
Describe the changes that were made in this pull request. When possible start with the motivations behind the change.

Recommendation: Add a comprehensive description explaining:

  • What is being reorganized and why
  • Migration path from old structure to new structure
  • Breaking changes for existing doc links
  • Any deprecated content being removed

2. Documentation Concerns

Clarity Crash Course (docs/build/clarity-crash-course.md:47-64):

  • The example code has a bug: current-count is defined but never used
  • Line 52: (current-count count) should use (var-get count)
  • The example would fail because count is a var, not a value

Creating a FT (docs/build/create-tokens/creating-a-ft.md:50):

  • Uses hardcoded testnet trait address: 'SP3FBR2AGK5H9QBDH3EEN6DF8EK8JY7RX8QJ5SVTE.sip-010-trait-ft-standard.sip-010-trait
  • Should clarify this is testnet-only or provide guidance for mainnet

Developer Quickstart (docs/build/README.md:321-322):

  • Placeholder text: YOUR_CONTRACT_ADDRESS_HERE
  • Consider adding example address format or pointing to where users find their address more prominently

3. Testing & Validation

  • No evidence of link validation: With 298 changed files, broken internal links are likely
  • No evidence of code testing: Sample contracts should be tested in Clarinet
  • No screenshots validation: Multiple image files added but can't verify they display correctly

Recommendations:

  • Run a link checker on all markdown files
  • Test all code examples in their respective environments
  • Verify GitBook rendering (formatting, images, etc.)

4. Missing Elements

  • No CHANGELOG: For a major documentation reorganization, a changelog would help users understand what changed
  • No migration guide: Users with bookmarks to old docs will be lost
  • No redirect strategy: If old URLs are changing, redirects should be planned
  • Inconsistent code examples: Some use clarity code blocks, some use clarity

Security Considerations

Good security practices observed:

  • Proper warning about tx-sender vs contract-caller (README.md:241-245)
  • Post conditions properly explained as security feature
  • References to audit reports in learn/.gitbook/assets/

Potential issues:

  • Sample code uses testnet addresses without clear warnings
  • No discussion of private key management in tutorials
  • Should emphasize testnet vs mainnet more prominently throughout

Performance Considerations

  • GitBook assets folder size not optimized (many JPEGs, PNGs)
  • Consider image optimization to reduce repository size
  • No apparent caching strategy for external resources

Recommendations

High Priority:

  1. ✅ Fix the Clarity Crash Course code bug
  2. ✅ Add comprehensive PR description
  3. ✅ Run link validation across all docs
  4. ✅ Test all code examples
  5. ✅ Add migration guide for users of old docs

Medium Priority:
6. Optimize image assets
7. Add CHANGELOG
8. Clarify testnet vs mainnet throughout
9. Ensure consistent code block formatting
10. Add redirect mapping for changed URLs

Low Priority:
11. Consider adding more cross-references between related topics
12. Add estimated completion times to more tutorials
13. Include troubleshooting sections

Conclusion

This is a high-quality documentation update that significantly improves the developer experience. The content is well-written, practical, and comprehensive. However, given the scale of changes (298 files), thorough testing and validation is critical before merging to avoid breaking existing documentation users rely on.

Recommendation: Request changes to address the code bug and add PR description, then approve after validation.


Note: Due to the diff size exceeding GitHub's limit, I could not review every individual file change. This review focused on key documentation files and overall structure.

@eric-stackslabs eric-stackslabs self-requested a review October 27, 2025 13:26
@eric-stackslabs eric-stackslabs marked this pull request as ready for review October 27, 2025 13:26
@eric-stackslabs eric-stackslabs requested a review from a team as a code owner October 27, 2025 13:26
@eric-stackslabs
Copy link
Collaborator

@kenny-stacks ready for review and merge

@claude
Copy link

claude bot commented Oct 27, 2025

PR Review: Merge new-docs to master

Overview

This PR merges the new-docs branch into master, adding a comprehensive new documentation structure with 100 changed files and 27,849 additions. The changes introduce two major documentation sections: docs/build/ and docs/learn/, along with complete GitBook configuration for both.

Summary

Excellent work overall! This is a substantial documentation overhaul that significantly improves the developer experience with:

  • A well-structured 30-minute quickstart guide
  • Clear separation between "build" (practical) and "learn" (conceptual) documentation
  • Comprehensive coverage of Clarity, sBTC, frontend development, and token creation
  • Proper GitBook integration with redirects for backward compatibility

Positive Highlights

1. Outstanding Developer Quickstart (docs/build/README.md)

  • Excellent structure: Clear 30-minute timeline with 4 well-defined steps
  • Hands-on approach: Students build an actual working message board app
  • Progressive learning: Starts simple, includes optional deep-dives for curious readers
  • Complete code examples: Both Clarity contract and full React frontend included
  • Good warnings: Proper security warnings about tx-sender vs contract-caller
  • Strong next steps: Clear pathways for continued learning

2. Well-Organized Documentation Structure

The separation of concerns is excellent:

  • docs/build/ - Practical, hands-on tutorials
  • docs/learn/ - Conceptual deep-dives
  • Clear SUMMARY.md files for navigation
  • GitBook configuration with proper redirects

3. Comprehensive Coverage

  • sBTC: Both builder quickstart and conceptual documentation
  • Frontend Development: Stacks.js integration, authentication, post conditions
  • Token Standards: NFT and FT creation guides
  • Testing: Fuzz testing documentation
  • Bitcoin Integration: Transaction parsing, verification, and sending

4. Good Documentation Practices

  • Consistent formatting and voice
  • Code examples with proper syntax highlighting
  • Clear prerequisites and setup instructions
  • Links to external resources (Hiro docs, Clarity Book, etc.)

Issues & Recommendations

🔴 High Priority

1. Broken/Outdated Internal Links

Several links in the quickstart reference old URL structures:

# In docs/build/README.md:
[**Clarity Reference**](https://docs.stacks.co/docs/clarity)
[**Clarity Crash Course**](https://docs.stacks.co/docs/clarity-crash-course)

Recommendation: Update these to point to the new documentation structure (e.g., clarity-crash-course.md or the appropriate relative path).

2. Clarity Crash Course Code Example Issue

In docs/build/clarity-crash-course.md lines 47-60, there's a potential confusion:

(define-data-var count int 0)
(define-public (add-number (number int))
    (let
        (
            (current-count count)  # This declares but never uses current-count
        )
        (var-set count (+ 1 number))  # This always adds 1 + number, not to existing count
        (ok (var-get count))
    )
)

Issue: The code declares current-count but doesn't use it, and the var-set doesn't actually add to the existing count—it just sets it to 1 + number.

Recommendation: Either:

  • Fix the code to actually increment: (var-set count (+ current-count number))
  • Or clarify the explanation to note this is setting, not adding

3. Missing Contract Address Placeholder Validation

In docs/build/README.md line 321:

const CONTRACT_ADDRESS = "YOUR_CONTRACT_ADDRESS_HERE";

Recommendation: Add a validation check or clearer instructions to prevent users from running the code without updating this. Consider adding a console.warn or error check.

🟡 Medium Priority

4. HTTP Link in Quickstart

Line 645 in docs/build/README.md:

Visit `http://localhost:5173` and you should...

Recommendation: While http://localhost is technically fine, consider mentioning that Vite might use port 5174 if 5173 is occupied, or reference npm run dev output for the actual port.

5. sBTC Contract Reference Might Change

In docs/build/sbtc/sbtc-builder-quickstart.md line 94:

clarinet requirements add SM3VDXK3WZZSA84XXFKAFAF15NNZX32CTSG82JFQ4.sbtc-deposit

Recommendation: Verify this is the correct mainnet/testnet contract address and consider adding a note about network-specific addresses.

6. Incomplete Post Conditions Example

docs/build/build-a-frontend/post-conditions-with-stacks.js.md shows code snippets but doesn't demonstrate integrating them into a complete transaction.

Recommendation: Add a complete example showing post conditions in a transaction with openContractCall or similar.

7. Missing Code Comment in Post Conditions

Line 75 in post-conditions-with-stacks.js.md redeclares variables without mentioning it:

const assetAddress = "SP62M8MEFH32WGSB7XSF9WJZD7TQB48VQB5ANWSJ";
const assetContractName = "test-asset-contract";
const fungibleAssetInfo = createAssetInfo(assetAddress, assetContractName);

These were already declared above. Recommendation: Add a comment noting this is a separate example, or use different variable names.

🟢 Low Priority / Suggestions

8. Consider Adding Error Handling Examples

The quickstart's React code (lines 309-510) could benefit from showing error handling patterns with try-catch, especially for:

  • Wallet connection failures
  • Transaction rejections
  • Network errors

9. Add Estimated Gas/Fee Information

Consider adding a brief note about transaction fees in the quickstart, especially since users might see fee prompts in their wallet.

10. GitBook Asset Organization

There are 22+ image files in .gitbook/assets/. Consider:

  • Adding descriptive names instead of generic "image (1).png"
  • Including alt text descriptions in the markdown
  • Optimizing image sizes for faster page loads

11. Clarity Tools vs Clarity Playground Naming

The Clarity Crash Course references "Clarity Tools" (clarity.tools) while the quickstart uses "Clarity Playground" (play.hiro.so). Ensure consistency or clarify they're different tools.


Testing Recommendations

Since this is a docs-only PR, here's what should be verified:

  1. Build the GitBook site and ensure all internal links work
  2. Test all code examples in the quickstart (especially the React app and Clarity contract)
  3. Verify external links aren't broken (leather.io, explorer.hiro.so, etc.)
  4. Check mobile responsiveness of the documentation
  5. Test redirects defined in .gitbook.yaml work correctly
  6. Validate image paths in all markdown files

Security Review

No security concerns - This is documentation only with:

  • Appropriate warnings about tx-sender vs contract-caller
  • Good post-conditions explanation
  • Testnet examples (not exposing mainnet keys)
  • No sensitive credentials or API keys

Conclusion

This is excellent work that will significantly improve the developer onboarding experience for Stacks. The documentation is comprehensive, well-structured, and practical.

Recommendation: Approve with minor fixes

The issues identified are mostly minor and can be addressed in follow-up PRs. The only critical issue is the Clarity Crash Course code logic (issue #2), which should be fixed before merge to avoid confusing new developers.

Next Steps

  1. Fix the add-number function logic in clarity-crash-course.md
  2. Update internal links to use relative paths instead of absolute URLs
  3. Verify all code examples actually work as written
  4. Consider the medium-priority recommendations for future improvements

Great work on this comprehensive documentation update! 🎉

Copy link
Collaborator

@eric-stackslabs eric-stackslabs left a comment

Choose a reason for hiding this comment

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

lgtm

@eric-stackslabs eric-stackslabs merged commit ac6a341 into master Oct 27, 2025
10 checks passed
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.

5 participants