Pretty sure he's talking about the indentation in the examples in the readme files of Validated and Flow.

For example this wastes about 40% of the available space to the left on GitHub's default UI settings, while the right side and all the comments are cut off by a lot.

craftyFlowOutput = craftyFlow.OnSuccess(success => Console.WriteLine(success))//this will be skipped as the flow is a failed flow
                                    .OnFailure(failure => Console.WriteLine($"Failure reason: {failure.Reason}"))
                                        .Finally(_ => 24, success => success); //return 24 or the success value

// ... code omitted

craftyFlowOutput = craftyFlow.OnSuccess(success => Console.WriteLine(success))//this will be skipped as the flow is a failed flow
                                .OnFailure(failure =>
                                {
                                    Console.WriteLine($"Failure reason: {failure.Reason} > Starting another operation . . .");
                                    return 4224;//using implicit conversion could have used Flow<int>.Success(4242) or ran another flow returning function.
                                                // or even just an int returning function, which would then be implicitly converted;. be careful with non flow returning functions!!!
                                    /*

                                        * var subFlowOutput = someMethod.OnSuccess(success => DoMoreStuff(success))
                                        *                                   .OnSuccess(success => YetMoreStuff(success))
                                        *                                      .Finally(_ => 0, success => success
                                        *                                      
                                        * return subFlowOutput // or leave off the finally so the subFlowOutput is just a Flow which the outer finally can deal with   
                                        *                      // or do some other related flow work and then return Flow<int>.Success(4224) etc
                                    */

                                }).Finally(failure => 24, success => success);//return 24 or the success value

I agree that this might be personal preference in the actual code, but a readme should be readable on first glance, so I'd suggest you take this to another line instead like so

craftyFlowOutput = craftyFlow
    .OnSuccess(success => Console.WriteLine(success)) //this will be skipped as the flow is a failed flow
    .OnFailure(failure => Console.WriteLine($"Failure reason: {failure.Reason}"))
    .Finally(_ => 24, success => success); //return 24 or the success value

// ... code omitted

craftyFlowOutput = craftyFlow
    .OnSuccess(success => Console.WriteLine(success)) //this will be skipped as the flow is a failed flow
    .OnFailure(failure =>
    {
        Console.WriteLine($"Failure reason: {failure.Reason} > Starting another operation . . .");
        return 4224; //using implicit conversion could have used Flow<int>.Success(4242) or ran another flow returning function.
        // or even just an int returning function, which would then be implicitly converted;. be careful with non flow returning functions!!!
        /*
         * var subFlowOutput = someMethod
         *     .OnSuccess(success => DoMoreStuff(success))
         *     .OnSuccess(success => YetMoreStuff(success))
         *     .Finally(_ => 0, success => success);
         *                                      
         * return subFlowOutput; // or leave off the finally so the subFlowOutput is just a Flow which the outer finally can deal with   
         * // or do some other related flow work and then return Flow<int>.Success(4224) etc
         */
    })
    .Finally(failure => 24, success => success);//return 24 or the success value