kiro-bootstrap

Set up a Kiro environment from one repo with one script. Steering files, hooks, and skills land in ~/.kiro/, configured from a single file, on every machine you work on.

Fork it, edit config.env, delete what you do not need, and run the installer.

Quick start

git clone <your-fork> kiro-bootstrap
cd kiro-bootstrap
cp config.env config.local.env     # optional — keeps your values out of git
$EDITOR config.local.env           # set your Atlassian site, project key, GitLab group
./install.sh

Restart Kiro and you are done.

./install.sh --dry-run reports every change first and writes nothing. Re-runs are idempotent: identical files are skipped, replaced ones are backed up as <name>.bak.<timestamp>.

Flag	Effect
--config <file>	Read a specific config file
--dry-run	Report what would change, write nothing
-h, --help	Usage summary

Without --config, the installer uses config.local.env when it exists and config.env otherwise.

What you get

Component	Installed to	What it does
steering/*.md	~/.kiro/steering/	Always-on conventions — shell safety, secret handling, git, AWS/CDK
hooks/*	~/.kiro/hooks/	Blocks malicious package installs, runs npm audit, lints .gitlab-ci.yml
skills/*/	~/.kiro/skills/	GitLab, JIRA, and Confluence workflows
AWS + Datadog skills	~/.kiro/skills/	Fetched from upstream at install time, not vendored

Everything the installer writes lives under ~/.kiro/, with one documented exception: ~/.config/pup/config.yaml when INSTALL_PUP_CONFIG=true, because pup reads its config from nowhere else. Existing keys there are preserved and the previous file backed up.

Skills

Skills activate on relevant work, or you can invoke them explicitly. Their instructions load on demand, so an unused skill costs almost no context.

Skill	Invoke	Purpose
gitlab	/gitlab	glab workflows — commit/push/MRs, review comments, code search
jira	/jira	Work items via acli + REST — create, edit, search, sprint reports
confluence	/confluence	Read and write pages via acli + a bundled stdlib-only helper

Plus curated sets fetched from aws/agent-toolkit-for-aws (aws-cdk, aws-cloudformation, aws-serverless, aws-containers, aws-compute) and datadog-labs/agent-skills (dd-pup, dd-logs, dd-apm, dd-docs, dd-monitors). Pick the ones you want with AWS_SKILLS and DATADOG_SKILLS in config.env, or set them to "".

These are fetched rather than vendored because upstream refreshes them on its own cadence. They install as real directories, not symlinks — Kiro silently ignores symlinked skill folders in ~/.kiro/skills/ (kirodotdev/Kiro#6401).

Hooks

Hook	Trigger	Behaviour
package-safety-check	Before any execute_bash	Blocks installs of packages with an OSV.dev MAL-* advisory; warns on non-existent or suspiciously new ones
security-audit-npm	On package.json save	npm audit --audit-level=high, advisory only
gitlab-ci-lint	On .gitlab-ci.yml save	glab ci lint

Configuration

One file, plain shell. Values marked (template) in config.env are substituted into the installed skill and steering copies, so the sources stay generic and git pull never conflicts with your local values.

ATLASSIAN_SITE="acme.atlassian.net"
JIRA_PROJECT_KEY="ACME"
JIRA_BOARD_ID="42"
GITLAB_GROUP="acme-corp"

AWS_SKILLS="aws-cdk aws-cloudformation"
DATADOG_SKILLS=""

The installer warns if the shipped placeholders are still in place, since the skills would otherwise be installed pointing at a site that does not exist.

Some values need looking up:

Value	Where to find it
JIRA_BOARD_ID	The numeric ID in your board URL
JIRA_STORY_POINTS_FIELD	acli jira workitem view <KEY> --json | grep -i story — commonly customfield_10016
CONFLUENCE_SITE_CLOUD_ID / _SPACE_ID / _CONTEXT_ID	Only needed when CONFLUENCE_MERMAID_VIEWER=true. See the Mermaid Diagrams Viewer Forge app. Find the values from a page's storage format

Authentication

No credential goes in config.env. The installer only checks that credentials are present and prints the command to fix it when they are not — it never reads or echoes a secret, and never edits your shell profile.

Atlassian (jira + confluence skills). Create a plain API token at id.atlassian.com, then store it in the macOS Keychain with your Atlassian email as the account:

security add-generic-password -s atlassian-api-token -a you@example.com -w <API_TOKEN>
acli jira auth login --token
acli confluence auth login --token

Both the email and the token are read from that single Keychain item. acli keeps Jira and Confluence auth separate, hence two logins. On non-macOS, export ATLASSIAN_EMAIL and ATLASSIAN_API_TOKEN instead.

GitLab. Create a personal access token with scopes api, read_repository, write_repository, then:

glab auth login --hostname gitlab.com --use-keyring

Use --use-keyring rather than a GITLAB_TOKEN export: an env var overrides stored credentials and leaves a plaintext token in your shell profile. If you already have one, the installer offers to migrate it into the keyring and tells you which file to clean up.

Datadog. pup auth login. Access tokens last about an hour and refresh silently.

Choosing what gets installed

Everything in steering/, hooks/, and skills/ installs as-is. There are no per-file switches — to opt out of one, delete it from your clone:

rm steering/datadog-standards.md    # not using Datadog
rm hooks/gitlab-ci-lint.json        # not using GitLab CI
rm -rf skills/confluence            # not using Confluence

Already-installed copies under ~/.kiro/ are not removed by deleting the source — delete those too if you want them gone.

The remaining switches live in config.env:

Switch	Controls
AWS_SKILLS	Which AWS skills to fetch. "" skips them
DATADOG_SKILLS	Which Datadog skills to fetch. "" skips them
INSTALL_PUP_CONFIG	Whether to manage ~/.config/pup/config.yaml

Making it yours

The steering files are opinions, not rules. agent-standards.md reflects one team's conventions — branch naming, commit format, which shell patterns to avoid. Read it and edit it. Anything in steering/ is paid for on every single turn, so delete what does not apply to you rather than leaving it to burn context.

Same for the skills: they document the exact CLI invocations that work, including the flags that do not exist and the ones that hang without a pager override. If your tooling differs, the file to fix is right there in skills/.

Skills and steering are resolved from config.env into a staging copy before being compared with what is installed, so editing config and re-running is always enough — you never hand-edit the installed copies under ~/.kiro/.

Requirements

• Kiro, and Bash
• Python 3.11+ for the Confluence helper and the package-safety hook
• Node.js 20+ only to fetch the external AWS/Datadog skills
• Optional CLIs per skill: glab (GitLab), acli (Jira/Confluence), pup (Datadog)

The installer reports what is missing instead of failing.

Troubleshooting

Skills do not appear in Kiro. Confirm they are real directories, not symlinks: ls -la ~/.kiro/skills/.

{{PLACEHOLDER}} visible in an installed skill. The key is missing from your config. Add it and re-run the installer.

A glab command hangs. glab ignores the generic PAGER variable and uses GLAB_PAGER. Prefix long-output commands with GLAB_PAGER=cat.

Confluence writes fail with "site is not configured". ATLASSIAN_SITE is unset. Set it and re-run the installer, or export CONFLUENCE_SITE for a one-off.

pup refuses to write. That is the shipped default (read_only: true in datadog/pup-config.yaml). pup has no per-command override, so allowing a write means changing that file and re-running the installer.

An installer run replaced something you wanted. Every replaced file is kept as <name>.bak.<timestamp> next to it.

Repo layout

.
├── install.sh              # the only moving part
├── config.env              # template values + install switches
├── steering/               # always-on agent context
├── hooks/                  # Kiro hook definitions
├── skills/                 # on-demand skill bundles
└── datadog/pup-config.yaml # pup CLI defaults (opt-in)

License

GPL-3.0 — see LICENSE.

The AWS and Datadog skills are fetched from their upstream repositories at install time and are not redistributed here.