The key to making kibitz work is the judicious use of -input and -output flags. As with all manual pages, the words might be literally correct but they are open to some interpretation:

To send output to multiple processes, list each spawn id list prefaced by a -output flag. Input for a group of output spawn ids may be determined by a spawn id list prefaced by a -input flag. (Both -input and -output may take lists in the same form as the -i flag in the expect command, except that any_spawn_id is not meaningful in interact.) All following flags and strings (or patterns) apply to this input until another -input flag appears. If no -input appears, -output implies "-input $user_spawn_id -output". (Similarly, with patterns that do not have -input.) If one -input is specified, it overrides $user_spawn_id. If a second -input is specified, it overrides $spawn_id. Additional -input flags may be specified.

The two implied input processes default to having their outputs specified as $spawn_id and $user_spawn_id (in reverse). If a -input flag appears with no -output flag, characters from that process are discarded.

The -i flag introduces a replacement for the current spawn_id when no other -input or -output flags are used. A -i flag implies a -o flag.

It is possible to change the processes that are being interacted with by using indirect spawn ids. (Indirect spawn ids are described in the section on the expect command.) Indirect spawn ids may be specified with the -i, -u, -input, or -output flags.

How (some aspects of) that should be interpreted as is that -input and -output arguments come in pairs even when some of them are implied.

In particular, with respect to the kibitz command there are in the simplest case two expect processes, the originator (who is asking user for help), process 1, and the responder, process 2. If the originator ask for user@host then process 3 is used to shuffle data between the originator and a remote shell on host.

Process 2, the responder looks easy:

interact \
        -output $userout \
        -input $userin

but the manual has been deceptive. Where it says If no -input appears, -output implies "-input $user_spawn_id -output" you might be deceived by the presence of the -input on the command line above.

What it should say is if no -input appears before a -output .... Furthermore, there is an implied -output after the given -input which the manual states will be $user_spawn_id.

So, the command should say:

interact \
  -input $user_spawn_id \
  -output $userout \
  -input $userin \
  -output $user_spawn_id

Looking at the command this way, you can better see the input/output pairs and what they are doing. In order, from above, they can be seen as input one, i1, passed on to output one, o1 and input two, i2, passed on to output two, o2. As in the diagram but with $spawn_id replaced with the FIFOs $userin/$userout. Notice that nothing has been spawned by process 2.

Process 1, the originator is much more complex. It is going to have the user interact with the spawned shell and read/write to/from the FIFOs used to communicate with process 2. It reads as:

interact {
    -output $shell \
            -input $userin eof {
        wait -i $userin
        close -i $shell
        return
    } -output $shell \
            -input $shell eof {
        close -i $userout
        wait -i $userout
        return
    } -output "$user_spawn_id $userout"
}

and if we remove the reactive eof string/pattern pairs it looks like:

interact {
    -output $shell \
    -input $userin
    -output $shell \
    -input $shell
    -output "$user_spawn_id $userout"
}

which is a bit more intelligible. Again, there's an initial implied -input which then gives us:

interact {
    -input $user_spawn_id \
    -output $shell \
    -input $userin
    -output $shell \
    -input $shell
    -output "$user_spawn_id $userout"
}

So, the second diagram gives us the following three input/output pairs:

1. $user_spawn_id, i1, is passed onto the spawned $shell, o1
2. $userin, i2 (the input typed by the responder) is passed onto the shell as well, o2
3. $shell, i3 (the output from the shell) is passed onto both the original user, $user_spawn_id and the responder, $userout, o3

In fact, the order of these isn't especially important so long as you give interact at least two sets of input/output pairs.

Further, after each -input you have the option of specifying as outputs:

1. a single spawn id: -output $id
2. a space separated list of spawn ids: -output "$id1 $id2 ..."
3. a single (global) spawn id name which can expand to either of the above: -output idname
4. multiple output statements all of whom will get the output of the previous -input

Notice too, that the reactive string/pattern pairs are tied to the preceding -input.