It’s not possible.

For SHAKE128 this is trivially true, because there is no normal SHA3 hash function which has the same "capacity" (~internal state size), as we can see in section 6 of the SHA-3 specification, where the capacity defined for each function is indicated between the [brackets]:

SHA3-224(M) = KECCAK[448] (M || 01, 224);
SHA3-256(M) = KECCAK[512] (M || 01, 256);
SHA3-384(M) = KECCAK[768] (M || 01, 384);
SHA3-512(M) = KECCAK[1024](M || 01, 512)

SHAKE128(M, d) = KECCAK[256] (M || 1111, d),
SHAKE256(M, d) = KECCAK[512] (M || 1111, d).

For SHAKE256, SHA3-256 does have the same capacity, and the functions are very similar. However, SHAKE256 is not constructed from instances of SHA3-256. It's constructed from repeating the the "squeezing" step of the SHA3's sponge construction until the desired number of bits have been generated. It's not possible to obtain the internal state from this output (that would violate the security properties of the algorithm), so it's not possible to take a SHA3-256 output and use it to produce a longer SHAKE256 output for the same output.

If that was all that was going on, it would at least be possible to take a SHA3-256 output and truncate it to produce a SHAKE256 output of a up to 256 bits, but there's another major element which prevents that: domain separation.

It is considered undesirable for two different algorithms to produce the same output, even if their internal structure is identical. In the case of SHA-3, this property is ensured by by appending a distinct suffix to the input indicating the mode that the algorithm is operating in, before generating any output. In the function specifications above, we can see that that for normal SHA3 hash functions, the suffix is the bits 01, while for SHAKE functions it is the bits 1111. This also is mentioned in section 6 of the specification:

The bolded suffix (i.e., 11) supports domain separation: it distinguishes the inputs to KECCAK[c] that arise from RawSHAKE128 and RawSHAKE256 from the inputs arising from the SHA3 hash functions defined in Sec. 6.1, as well as other domains that may be defined in the future.

Therefore it is not possible to produce any bits of a SHAKE digest if the only thing you have to work with are complete instances of normal SHA3 hash functions.

This is not possible.

For SHAKE128 this is trivially true, because there is no normal SHA3 hash function which has the same "capacity" (~internal state size), as we can see in section 6 of the SHA-3 specification, where the capacity defined for each function is indicated between the [brackets]:

SHA3-224(M) = KECCAK[448] (M || 01, 224);
SHA3-256(M) = KECCAK[512] (M || 01, 256);
SHA3-384(M) = KECCAK[768] (M || 01, 384);
SHA3-512(M) = KECCAK[1024](M || 01, 512)

SHAKE128(M, d) = KECCAK[256] (M || 1111, d),
SHAKE256(M, d) = KECCAK[512] (M || 1111, d).

For SHAKE256, SHA3-256 does have the same capacity, and the functions are very similar. However, SHAKE256 is not constructed from instances of SHA3-256. It's constructed from repeating the the "squeezing" step of the SHA3's sponge construction until the desired number of bits have been generated. It's not possible to obtain the internal state from this output (that would violate the security properties of the algorithm), so it's not possible to take a SHA3-256 output and use it to produce a longer SHAKE256 output for the same input.

If that was all that was going on, it would at least be possible to take a SHA3-256 output and truncate it to produce a SHAKE256 output of up to 256 bits, but there's another major element which prevents that: domain separation.

It is considered undesirable for two different algorithms to produce the same output, even if their internal structure is identical. In the case of SHA-3, this property is ensured by appending a distinct suffix to the input indicating the mode that the algorithm is operating in, before generating any output. In the function specifications above, we can see that that for normal SHA3 hash functions, the suffix is the bits 01, while for SHAKE functions it is the bits 1111. This also is mentioned in section 6 of the specification:

The bolded suffix (i.e., 11) supports domain separation: it distinguishes the inputs to KECCAK[c] that arise from RawSHAKE128 and RawSHAKE256 from the inputs arising from the SHA3 hash functions defined in Sec. 6.1, as well as other domains that may be defined in the future.

Therefore it is not possible to produce any bits of a SHAKE digest if the only thing you have to work with are complete instances of normal SHA3 hash functions.

It’s not possible. Among other issues, section 6.3 of the SHA-3 paper describes how distinct bits are appended to the message in SHAKE mode to explicitly create domain separation that would prevent digests from normal SHA-3 from being equivalent to those created during SHAKE operations:

The bolded suffix (i.e., 11) supports domain separation: it distinguishes the inputs to KECCAK[c] that arise from RawSHAKE128 and RawSHAKE256 from the inputs arising from the SHA-3 hash functions defined in Sec. 6.1, as well as other domains that may be defined in the future.

It’s not possible.

For SHAKE128 this is trivially true, because there is no normal SHA3 hash function which has the same "capacity" (~internal state size), as we can see in section 6 of the SHA-3 specification, where the capacity defined for each function is indicated between the [brackets]:

SHA3-224(M) = KECCAK[448] (M || 01, 224);
SHA3-256(M) = KECCAK[512] (M || 01, 256);
SHA3-384(M) = KECCAK[768] (M || 01, 384);
SHA3-512(M) = KECCAK[1024](M || 01, 512)

SHAKE128(M, d) = KECCAK[256] (M || 1111, d),
SHAKE256(M, d) = KECCAK[512] (M || 1111, d).

For SHAKE256, SHA3-256 does have the same capacity, and the functions are very similar. However, SHAKE256 is not constructed from instances of SHA3-256. It's constructed from repeating the the "squeezing" step of the SHA3's sponge construction until the desired number of bits have been generated. It's not possible to obtain the internal state from this output (that would violate the security properties of the algorithm), so it's not possible to take a SHA3-256 output and use it to produce a longer SHAKE256 output for the same output.

If that was all that was going on, it would at least be possible to take a SHA3-256 output and truncate it to produce a SHAKE256 output of a up to 256 bits, but there's another major element which prevents that: domain separation.

It is considered undesirable for two different algorithms to produce the same output, even if their internal structure is identical. In the case of SHA-3, this property is ensured by by appending a distinct suffix to the input indicating the mode that the algorithm is operating in, before generating any output. In the function specifications above, we can see that that for normal SHA3 hash functions, the suffix is the bits 01, while for SHAKE functions it is the bits 1111. This also is mentioned in section 6 of the specification:

The bolded suffix (i.e., 11) supports domain separation: it distinguishes the inputs to KECCAK[c] that arise from RawSHAKE128 and RawSHAKE256 from the inputs arising from the SHA3 hash functions defined in Sec. 6.1, as well as other domains that may be defined in the future.

Therefore it is not possible to produce any bits of a SHAKE digest if the only thing you have to work with are complete instances of normal SHA3 hash functions.