This is a pattern where subdomain, or part of it, is implemented in multiple bounded contexts and it used by multiple teams. This is usually the case when you use authorisation. Because it is used in multiple places, it has to be consistent across all of the bounded contexts that are using it.
Shared kernel is usually used as a package that exposes a contract that can be used by other bounded contexts or in a monorepo where the same source file is referenced by multiple bounded contexts. The most important is to make sure that the integration tests are triggered for all bounded contexts.
When to use Shared Kernel Pattern
This pattern should be used mainly when the cost of duplication is higher than the cost of coordination; essentially, when coordination is just too complex and time consuming. This pattern introduces strong dependencies between contexts so you have to be careful when you use it and how you use it.
You can use this pattern when you want to gradually modernise the legacy system, but this should only be implemented as a temporary solution.
This can also be a good fit in a case where bounded contexts are integrated and owned by the same team. It is in a sense similar to partnership pattern, but it eliminates the ad hoc integration and you don’t have to coordinate two teams working together.