Good explanation has already been done in the davido's long read.

---

You asked:

... I am specifically looking for the yml settings for the resources I have in the json file.

It should be a part of Makefile.PL. For example:

my %WriteMakefileArgs = (
    NAME             => 'File::Slurp::Affix',
...
    META_MERGE => {
        resources => {
            homepage   => 'https://github.com/LadyAleena/File-Slurp-Af
+fix',
            bugtracker => 'https://github.com/LadyAleena/File-Slurp-Af
+fix/issues',
            repository => 'https://github.com/LadyAleena/File-Slurp-Af
+fix.git',
        },
    },
...
    clean => { FILES => 'File-Slurp-Affix-*' },
);
[download]

Unfortunately, this part is not explained clearly. I learnt it looking on other projects, especially what is written in ExtUtils::MakeMaker itself. There are two version of META_ADD/META_MERGE. In my example above I used the first version.

---

Once module-starter executed, you've got the following directory structure:

lib/
t/
xt/
Changes
ignore.txt (or .gitignore when module-starter --git)
Makefile.PL
MANIFEST
README
[download]

lib/ is the stuff you are working on.

t/ and xt/ contain the stuff used for testing the module. You can check how tests wok:

prove -l -v
[download]

You can put here any code you'd like for proving your module. All (or almost all) aspects should be covered by these tests. It is template for your future tests, you can remove them and write your own tests.

Changes is used for the history. You will write here significant changes in current version since last one.

ignore.txt, .gitignore are used to skip some temporary files.

Makefile.PL creates MYMETA.* and Makefile. In general, there are no special reasons to keep them in you repo.

README is the first thing is read by others (usually). In it you need to explain your module. POD of the module is applicable as well. Check it and convert if no errors:

podchecker lib/File/Slurp/Affix.pm
pod2text lib/File/Slurp/Affix.pm > README
[download]

MANIFEST is for declaring the content of your package. You also need to create MANIFEST.SKIP to declare the stuff that is not in MANIFEST and should be excluded from the package. It can be the same as .gitignore. Also you can add anything what you need to keep in the repo but should be skipped in the package. The following simple script will show what is not good with manifests.

#!/usr/bin/env perl

use Test::More tests => 2;
use ExtUtils::Manifest;
 
is_deeply [ ExtUtils::Manifest::manicheck() ], [], 'missing';
is_deeply [ ExtUtils::Manifest::filecheck() ], [], 'extra';
[download]