docs: add Kosli Capture Managed Service page - #380
Conversation
|
Preview deployment for your docs. Learn more about Mintlify Previews.
|
|
Claude finished @gsavage's task in 2m 39s —— View job Doc review —
|
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
dangrondahl
changed the title
|
|
||
| ## Automatically creating physical environments | ||
|
|
||
| The [Kosli Capture Managed Service](/administration/kosli_capture) will automatically snapshot your infrastructure according to rules you define. Kosli Capture will create physical environments as needed. |
There was a problem hiding this comment.
Improvement — this page claims something the Kosli Capture page doesn't. "Kosli Capture will create physical environments as needed" is a real capability claim, but administration/kosli_capture.md never mentions creating environments — it only says tags "determine which Kosli environment should hold the snapshots", which reads as routing into environments that already exist. A reader who follows the link won't find the auto-creation behaviour confirmed. Worth adding a sentence to the "Finding resources" section of the Kosli Capture page, since auto-creation is arguably its biggest selling point over Terraform-managed environments.
Two smaller points on the same block:
- Heading level. This is an H2, so it sits as a sibling of "Managing physical environments" and "Managing logical environments" — but it is about physical environments, and it's wedged between the two.
### Automatically creating physical environments, appended to the physical-environments section, nests correctly. It also sidesteps the mild scope clash with line 13 ("This page covers managing environments via Terraform"), since Kosli Capture isn't a Terraform mechanism. - Tense. "will automatically snapshot" / "will create" → present tense reads better for a capability that exists today.
| The [Kosli Capture Managed Service](/administration/kosli_capture) will automatically snapshot your infrastructure according to rules you define. Kosli Capture will create physical environments as needed. | |
| ### Automatically creating physical environments | |
| The [Kosli Capture Managed Service](/administration/kosli_capture) automatically snapshots your infrastructure according to rules you define, creating physical environments as needed. |
(Note the suggestion changes the heading to H3 — if you take it, move the block above ## Managing logical environments stays as-is, it's already in the right position.)
3eac9e2 to
5eec2c7
Compare
|
|
||
| Kosli Capture can filter out resources based on your tags. | ||
|
|
||
| As your cloud environment evolves, such as the addition of new ECS clusters or the retirement of existing Lambdas, Kosli Capture automatically detects the changes. Because Kosli Capture creates physical environments as needed, when your infrastructure changes, Kosli will keep up. No changes to the configuration created during the initial setup are required. |
There was a problem hiding this comment.
Improvement — environment auto-creation is now stated twice. Line 38 ends with "Kosli Capture will create physical environments for you", and this sentence repeats it four lines later ("Because Kosli Capture creates physical environments as needed..."). The claim only needs to land once; here the useful new information is that evolving infrastructure is handled without reconfiguration.
| As your cloud environment evolves, such as the addition of new ECS clusters or the retirement of existing Lambdas, Kosli Capture automatically detects the changes. Because Kosli Capture creates physical environments as needed, when your infrastructure changes, Kosli will keep up. No changes to the configuration created during the initial setup are required. | |
| As your cloud environment evolves, such as the addition of new ECS clusters or the retirement of existing Lambdas, Kosli Capture automatically detects the changes and creates any new physical environments needed. No changes to the configuration created during the initial setup are required. |
If you take this, drop the trailing sentence on line 38 ("Kosli Capture will create physical environments for you.") so the claim appears once, in the paragraph that explains why it matters.
|
|
||
| ## Current status | ||
|
|
||
| Kosli Capture currently supports ECS and Lambda running within AWS. Support for S3 snapshots and for other cloud providers is in active development. A limitation in Amazon's AWS API currently prevents Kosli Capture from snapshotting EKS clusters; support for Kubernetes running on other cloud providers (e.g. Azure) will be added shortly. |
There was a problem hiding this comment.
Suggestion — "Amazon's AWS API" is redundant (AWS is already Amazon's).
| Kosli Capture currently supports ECS and Lambda running within AWS. Support for S3 snapshots and for other cloud providers is in active development. A limitation in Amazon's AWS API currently prevents Kosli Capture from snapshotting EKS clusters; support for Kubernetes running on other cloud providers (e.g. Azure) will be added shortly. | |
| Kosli Capture currently supports ECS and Lambda running within AWS. Support for S3 snapshots and for other cloud providers is in active development. A limitation in the AWS API currently prevents Kosli Capture from snapshotting EKS clusters; support for Kubernetes running on other cloud providers (e.g. Azure) will be added shortly. |
|
|
||
| ### Automatically creating physical environments | ||
|
|
||
| The [Kosli Capture Managed Service](/administration/kosli_capture) will automatically snapshot your infrastructure according to rules you define. Kosli Capture will create physical environments as needed. |
There was a problem hiding this comment.
Improvement — the new section sits outside this page's stated scope. The H3 nesting under "Managing physical environments" is right, but line 13 tells the reader "This page covers managing environments via Terraform. For creating environments via the CLI or UI, see [Getting started: Environments]" — and Kosli Capture is neither Terraform, CLI, nor UI. A reader who took that <Info> at its word won't expect to find this here.
Simplest fix: say explicitly that this is the exception, so the section justifies its own presence.
| The [Kosli Capture Managed Service](/administration/kosli_capture) will automatically snapshot your infrastructure according to rules you define. Kosli Capture will create physical environments as needed. | |
| The [Kosli Capture Managed Service](/administration/kosli_capture) creates physical environments for you, without Terraform. It snapshots your infrastructure according to rules you define, creating environments as needed. |
(Also switches "will automatically snapshot" / "will create" to present tense — it's a capability that exists today, not a future one.)
| @@ -0,0 +1,3 @@ | |||
| --- | |||
| title: "Magic Link" | |||
| --- | |||
There was a problem hiding this comment.
Critical — this page is empty but is wired into navigation, so it will publish as a blank page.
config/navigation.json:51 lists administration/authentication/single_sign_on and :52 lists administration/authentication/magic_link; :60 lists administration/managing_users/automated_user_provisioning. All three files contain only a title. Since deployment is automatic on merge to main, merging this PR puts three empty pages into the live Administration sidebar.
Three separate problems in each of the three files:
- No body content. Either write the pages before merging, or drop the three nav entries and keep the stubs off
main. - Missing
description. CLAUDE.md makes it a required front matter field, and every sibling page has one (api_key_rotation.md,service_accounts.md,roles_in_kosli.md). - Title Case titles. CLAUDE.md asks for sentence case; the siblings follow it — "API key rotation", "Service accounts", "Mapping users to roles". So: "Magic link", "Single sign-on", "Automated user provisioning".
These are also outside the stated scope of this PR (the description covers only the Kosli Capture page) — a separate PR for the auth/provisioning pages, once they have content, would keep this one reviewable.
| --- | |
| title: Magic link | |
| description: <one sentence describing the page purpose> | |
| --- |
| Kosli Capture finds all supported resources within your AWS accounts, and examines the tags on those resources to determine which Kosli environment should hold the snapshots. Kosli Capture will create physical environments for you. | ||
|
|
||
| Kosli Capture can filter out resources based on your tags. | ||
|
|
||
| As your cloud environment evolves, such as the addition of new ECS clusters or the retirement of existing Lambdas, Kosli Capture automatically detects the changes. Because Kosli Capture creates physical environments as needed, when your infrastructure changes, Kosli will keep up. No changes to the configuration created during the initial setup are required. |
There was a problem hiding this comment.
Improvement — environment auto-creation is still stated twice. Line 38 ends with "Kosli Capture will create physical environments for you", and line 42 repeats it ("Because Kosli Capture creates physical environments as needed, when your infrastructure changes, Kosli will keep up"). The second sentence in line 42 is also circular — it restates the claim as the reason for itself.
Fold the capability into the paragraph that explains why it matters, and drop it from line 38:
| Kosli Capture finds all supported resources within your AWS accounts, and examines the tags on those resources to determine which Kosli environment should hold the snapshots. Kosli Capture will create physical environments for you. | |
| Kosli Capture can filter out resources based on your tags. | |
| As your cloud environment evolves, such as the addition of new ECS clusters or the retirement of existing Lambdas, Kosli Capture automatically detects the changes. Because Kosli Capture creates physical environments as needed, when your infrastructure changes, Kosli will keep up. No changes to the configuration created during the initial setup are required. | |
| Kosli Capture finds all supported resources within your AWS accounts, and examines the tags on those resources to determine which Kosli environment should hold the snapshots. | |
| Kosli Capture can filter out resources based on your tags. | |
| As your cloud environment evolves, such as the addition of new ECS clusters or the retirement of existing Lambdas, Kosli Capture automatically detects the changes and creates any new physical environments needed. No changes to the configuration created during the initial setup are required. |
|
|
||
| ## Current status | ||
|
|
||
| Kosli Capture currently supports ECS and Lambda running within AWS. Support for S3 snapshots and for other cloud providers is in active development. A limitation in Amazon's AWS API currently prevents Kosli Capture from snapshotting EKS clusters; support for Kubernetes running on other cloud providers (e.g. Azure) will be added shortly. |
There was a problem hiding this comment.
Suggestion — "Amazon's AWS API" is redundant (AWS is already Amazon's). Punctuation is fixed now; this is the last thing left in the sentence.
| Kosli Capture currently supports ECS and Lambda running within AWS. Support for S3 snapshots and for other cloud providers is in active development. A limitation in Amazon's AWS API currently prevents Kosli Capture from snapshotting EKS clusters; support for Kubernetes running on other cloud providers (e.g. Azure) will be added shortly. | |
| Kosli Capture currently supports ECS and Lambda running within AWS. Support for S3 snapshots and for other cloud providers is in active development. A limitation in the AWS API currently prevents Kosli Capture from snapshotting EKS clusters; support for Kubernetes running on other cloud providers (e.g. Azure) will be added shortly. |
| Kosli Capture finds all supported resources within your AWS accounts, and examines the tags on those resources to determine which Kosli environment should hold the snapshots. Kosli Capture will create physical environments for you. | ||
|
|
||
| Kosli Capture can filter out resources based on your tags. | ||
|
|
||
| As your cloud environment evolves, such as the addition of new ECS clusters or the retirement of existing Lambdas, Kosli Capture automatically detects the changes. Because Kosli Capture creates physical environments as needed, when your infrastructure changes, Kosli will keep up. No changes to the configuration created during the initial setup are required. |
There was a problem hiding this comment.
Improvement — environment auto-creation is still claimed twice, and the second one is circular.
Line 38 ends with "Kosli Capture will create physical environments for you", then line 42 says "Because Kosli Capture creates physical environments as needed, when your infrastructure changes, Kosli will keep up" — which restates the claim as the reason for itself. The genuinely new information in that paragraph is that evolving infrastructure needs no reconfiguration; folding the auto-creation into it lands the claim once, in the place where it matters.
| Kosli Capture finds all supported resources within your AWS accounts, and examines the tags on those resources to determine which Kosli environment should hold the snapshots. Kosli Capture will create physical environments for you. | |
| Kosli Capture can filter out resources based on your tags. | |
| As your cloud environment evolves, such as the addition of new ECS clusters or the retirement of existing Lambdas, Kosli Capture automatically detects the changes. Because Kosli Capture creates physical environments as needed, when your infrastructure changes, Kosli will keep up. No changes to the configuration created during the initial setup are required. | |
| Kosli Capture finds all supported resources within your AWS accounts, and examines the tags on those resources to determine which Kosli environment should hold the snapshots. | |
| Kosli Capture can filter out resources based on your tags. | |
| As your cloud environment evolves, such as the addition of new ECS clusters or the retirement of existing Lambdas, Kosli Capture automatically detects the changes and creates any new physical environments needed. No changes to the configuration created during the initial setup are required. |
|
|
||
| ## Current status | ||
|
|
||
| Kosli Capture currently supports ECS and Lambda running within AWS. Support for S3 snapshots and for other cloud providers is in active development. A limitation in Amazon's AWS API currently prevents Kosli Capture from snapshotting EKS clusters; support for Kubernetes running on other cloud providers (e.g. Azure) will be added shortly. |
There was a problem hiding this comment.
Suggestion — "Amazon's AWS API" is redundant (AWS is already Amazon's). Everything else in this sentence is resolved; this is the last bit.
| Kosli Capture currently supports ECS and Lambda running within AWS. Support for S3 snapshots and for other cloud providers is in active development. A limitation in Amazon's AWS API currently prevents Kosli Capture from snapshotting EKS clusters; support for Kubernetes running on other cloud providers (e.g. Azure) will be added shortly. | |
| Kosli Capture currently supports ECS and Lambda running within AWS. Support for S3 snapshots and for other cloud providers is in active development. A limitation in the AWS API currently prevents Kosli Capture from snapshotting EKS clusters; support for Kubernetes running on other cloud providers (e.g. Azure) will be added shortly. |
| ### Automatically creating physical environments | ||
|
|
||
| The [Kosli Capture Managed Service](/administration/kosli_capture) will automatically snapshot your infrastructure according to rules you define. Kosli Capture will create physical environments as needed. |
There was a problem hiding this comment.
Improvement — heading style breaks with its siblings, and the tense reads as unreleased.
The H3 nesting under "Managing physical environments" is right, but the two sibling H3s on this page are imperative verb phrases — "Create a physical environment" (line 23), "Import an existing physical environment" (line 35) — so a gerund heading stands out. And "will automatically snapshot" / "will create" describes a capability that exists today.
One more thing worth a sentence: line 13 tells the reader "This page covers managing environments via Terraform", and Kosli Capture is not Terraform. Saying so explicitly stops the section reading as out of place.
| ### Automatically creating physical environments | |
| The [Kosli Capture Managed Service](/administration/kosli_capture) will automatically snapshot your infrastructure according to rules you define. Kosli Capture will create physical environments as needed. | |
| ### Create physical environments automatically | |
| The [Kosli Capture Managed Service](/administration/kosli_capture) creates physical environments for you, without Terraform. It snapshots your infrastructure according to rules you define, creating environments as needed. |
be89ec0 to
5eec2c7
Compare
Documents the 1MB size limit on the `--attestation-data` payload for `kosli attest custom`. Ref: kosli-dev/server#5388 --------- Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com> Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>
Reviewed the last 20 non-bot PRs (14 touched docs) against what `doc-write` and `doc-review` actually ask for, then fixed what the record showed was wrong. No site content changes — this is all agent tooling. ## Why `doc-review` produced **0 Critical, 5 Improvement and ~20 Suggestion** findings across those 14 PRs. Its genuinely valuable catches were all cross-file consistency checks the skill never asked for: - a changelog entry documenting `kosli update attestation-type`, a command with no reference page (#371) - `template-reference/flow_template.md` out of sync with the schema the same PR regenerated (#296) - the one file an approvals-removal sweep missed, `understand_kosli/how_kosli_works.md:22` (#345) Its weakest findings were prose polish, some already fixed at branch head. Meanwhile its written checklist was dominated by things that always pass or are already enforced by `vale-spellcheck`. Two structural gaps the PR record made obvious: - **Placement was never questioned.** In #305 a pure reference page was authored into `integrations/`, and a human reviewer had to ask for the move — commit `9e7a121 docs: move GitHub Action reference into the Reference section`. That question should come from the review. - **Generated pages were handled inconsistently.** #375 got it right and said so. #374 wrote *"the durable fix is in the `kosli-dev/cli` generator — a hand-edit here is overwritten by the next release"* and then emitted a `Fix this` link scoped to `repo=kosli-dev/docs` telling an agent to edit the generated file anyway, plus 4 inline comments on regenerated files. ## What changed **`doc-review`** — promoted the three accidental wins to named checks, each carrying its precedent. Added placement, redirects and anchor stability. Added an explicit *what not to report* bar and an 8-finding cap. Stopped hand-checking spelling. Dropped the "what looks good" recital that the sticky comment re-renders on every push. **Generated pages** — split into three categories rather than one blanket ban: deterministically regenerated (edit is deleted), agent-synced (edit survives but drifts), and hand-authored despite the directory (`client_reference/overview.md`, `output_and_verbosity.md`). Includes the filename→source mapping, verified upstream: `kosli_attest_sonar.md` ← `cmd/kosli/attestSonar.go`. Also records that **`^` is the CLI's backtick convention** in Go long descriptions, substituted by `kosli docs`. That makes the `^jq^` defect #374 found a generator escaping bug in the Accordion-title path, not a typo in the Go string — so a reviewer can point at the right fix. Worth filing upstream separately. **`doc-write`** — added a Diátaxis→tab placement table so #305 can't recur, plus redirects, anchor stability, and the generated-paths table. **New `doc-structure` skill + monthly workflow** — audits navigation shape and changelog coverage, which per-PR review structurally cannot see, and files issues. Read-only against docs; issues are its only write. Capped at 8 issues, deduplicating against open issues first — its headline check reproduces the `/getting_started/attestations` summary gap, which is already open as #364. **New `scripts/audit_navigation.py` + 22 tests** — the audit's mechanical checks, extracted from an inline heredoc. Three payoffs: 1. `pr-quality.yml` already runs `pytest tests/`, so **CLAUDE.md core rule 2 is now enforced deterministically** — a page file with no `navigation` entry fails the build. No new job needed. 2. `doc-structure.yml` can allow `Bash(python3 scripts/audit_navigation.py:*)` instead of `Bash(python3:*)`, which was arbitrary code execution. 3. Determinism. The inline version had already shipped a bug: `sed 's|\.mdx\?$||'` is a no-op on BSD sed, so every page looked orphaned on macOS. That case is now a regression test. Integrity findings (orphans, dangling entries) are separated from shape findings (single-child groups, deep nesting, Title Case labels, oversized groups, inconsistent icons). Only integrity can fail a build — the script cannot tell a group that should be merged from one deliberately kept separate. `Reference ▸ CLI Reference` is exempt from shape checks: `update-cli-nav.py` generates it from the CLI's command tree, so a single-child `kosli allow` group is upstream truth. Without that exemption the audit reported 54 findings, 21 of them proposing to reshape generated navigation — the same mistake being fixed in `doc-review`. It now reports 33, all hand-maintained. **New `docs-restructure` issue template** — Markdown, not a YAML form: `gh issue create --body` doesn't apply templates mechanically and YAML forms can't be filled from the CLI, so a form would help humans and do nothing for the job. Its URL-impact section encodes the distinction that decides whether a restructure is safe — a group rename changes no URLs, a moved page file needs a `config/redirects.json` entry. `config.yml` keeps blank issues enabled. **`CLAUDE.md`** — documented the six automated PR checks, the generated-page source map, the audit script, and the three skills. Removed the pointer to a `changelog-creator` skill that doesn't exist in this repo. ## Anti-rot pass Swept all three skills for dated claims. Counts ("three of the last fourteen PRs") and current-state assertions ("link-rot reports skipping on most PRs") became durable rules. The link-rot guidance now routes through `gh pr checks` so it self-heals if Mintlify starts running it reliably. Past-tense `Precedent:` items were kept — they're what make the checks concrete. ## Verification - `python3 -m pytest tests/` — 44 passed (22 pre-existing + 22 new) - `python3 scripts/audit_navigation.py --check` — exit 0, integrity clean - `mint broken-links` — no new broken links - Both workflows parse; triggers and permissions confirmed ## Follow-ups, not in this PR - `tutorials/working_with_controls.mdx:24` links to `/getting_started/service-accounts`, which has never existed — the page is `/administration/authentication/service_accounts`. Broken on `main` since #154; `link-rot` reports `skipping`, which is why it went unseen. - The `mintlify-docs` plugin in `kosli-plugins` still ships near-duplicate `doc-writer`/`doc-reviewer` agents that say "update `docs.json` navigation" — the pre-`config/` layout. Needs its own PR there. - The reviews twice asked for `python3` in `doc-review.yml`'s `--allowedTools` to validate JSON payloads and fence balance. Left alone — `Bash(python3:*)` is a security-surface call worth making deliberately.
|
|
||
| ## IAM permissions | ||
|
|
||
| For Kosli Capture to snapshot your environment, you must grant a set of read-only permissions. Kosli's CloudFormation template lists these. The permissions are typically "Describe" or "List" permissions. The [Kosli Capture Security](./kosli_capture_security) page provides a deep-diver into the structure of the permissions needed. |
There was a problem hiding this comment.
Critical — relative link. ./kosli_capture_security is the only relative internal link in the repo; CLAUDE.md requires root-relative paths, and relative paths break when a page moves. Two other things on this line: "deep-diver" should be "deep dive", and there's a double space after "permissions."
| For Kosli Capture to snapshot your environment, you must grant a set of read-only permissions. Kosli's CloudFormation template lists these. The permissions are typically "Describe" or "List" permissions. The [Kosli Capture Security](./kosli_capture_security) page provides a deep-diver into the structure of the permissions needed. | |
| For Kosli Capture to snapshot your environment, you must grant a set of read-only permissions. Kosli's CloudFormation template lists these. The permissions are typically "Describe" or "List" permissions. The [Kosli Capture security](/administration/kosli_capture_security) page provides a deep dive into the structure of the permissions needed. |
|
|
||
| ## Kosli capture permissions | ||
|
|
||
| The Kosli Capture managed service uses the public AWS, GCP and Azure APIs to extract information about your cloud environments. In order to do this, you need to provide Kosli with an IAM role that allows access to these APIs. The role is created and owned by you. Kosli publishes a CloudFormation template, for use in AWS, showing the permissions needed. The template is publicly accessible and can be used directly within an `aws cloudformation create-stack` call. |
There was a problem hiding this comment.
Improvement — GCP and Azure are claimed here but nowhere else, and "supported resources" is now undefined.
This sentence says Kosli Capture "uses the public AWS, GCP and Azure APIs", but the rest of this page is AWS-only (IAM role, CloudFormation, ECS/Lambda/S3 statements), and administration/kosli_capture.md only ever talks about AWS accounts. A reader on GCP or Azure is told the service uses their provider's API and then given no mechanism to grant access.
This got worse when the "Current status" section was dropped from kosli_capture.md: line 52 there now says Kosli Capture "finds all supported resources within your AWS accounts" and nothing on either page says which resource types those are. The IAM policy below is the only signal (ECS, Lambda, S3).
Suggest scoping this sentence to what exists today and naming the supported resource types on the main page (or restoring a short scope statement there).
| The Kosli Capture managed service uses the public AWS, GCP and Azure APIs to extract information about your cloud environments. In order to do this, you need to provide Kosli with an IAM role that allows access to these APIs. The role is created and owned by you. Kosli publishes a CloudFormation template, for use in AWS, showing the permissions needed. The template is publicly accessible and can be used directly within an `aws cloudformation create-stack` call. | |
| The Kosli Capture managed service uses the public AWS APIs to extract information about your cloud environments. In order to do this, you need to provide Kosli with an IAM role that allows access to these APIs. The role is created and owned by you. Kosli publishes a CloudFormation template, for use in AWS, showing the permissions needed. The template is publicly accessible and can be used directly within an `aws cloudformation create-stack` call. |
|
|
||
| ## Hands-off operation | ||
|
|
||
| Kosli Capture has been designed to operate with no on-going support from you. Once the initial security permissions have been created, Kosli capture will continue to operate without needing additional support. Monitoring, maintenance and rotation of API keys is all handed automatically. As your cloud infrastructure changes over time, Kosli capture will continue to find resources according to your tagging scheme without you needing to do anything; your application teams do not need to take any action in order to onboard their products and services into Kosli. |
There was a problem hiding this comment.
Improvement — this over-claims against the tag-driven model, and there's a word-level typo.
"your application teams do not need to take any action in order to onboard their products and services into Kosli" contradicts line 18 ("architected to be driven by your tagging scheme") and line 52 (tags decide which environment holds the snapshot). A new service that isn't tagged to your scheme can't be routed — so the action app teams do need to take is tagging their resources. Saying so is more useful than claiming zero action, and it's the one thing a platform team will want to tell their app teams.
Also "rotation of API keys is all handed automatically" → "handled". Vale won't catch that one.
| Kosli Capture has been designed to operate with no on-going support from you. Once the initial security permissions have been created, Kosli capture will continue to operate without needing additional support. Monitoring, maintenance and rotation of API keys is all handed automatically. As your cloud infrastructure changes over time, Kosli capture will continue to find resources according to your tagging scheme without you needing to do anything; your application teams do not need to take any action in order to onboard their products and services into Kosli. | |
| Kosli Capture has been designed to operate with no on-going support from you. Once the initial security permissions have been created, Kosli Capture will continue to operate without needing additional support. Monitoring, maintenance and rotation of API keys is all handled automatically. As your cloud infrastructure changes over time, Kosli Capture will continue to find resources according to your tagging scheme; as long as application teams tag their resources to that scheme, their products and services are onboarded into Kosli with no further action. |
(The suggestion also fixes "Kosli capture" → "Kosli Capture" twice — the product name is capitalized everywhere else on the page. The same lowercase form appears in the kosli_capture_security.md:12 heading.)
|
|
||
| <Steps> | ||
| <Step title="Prepare your environment"> | ||
| Create an IAM role in your AWS account specifically for Kosli Capture. Kosli provides a CloudFormation template to simplify this process. The template requires a shared secret, which Kosli provides to you during onboarding. |
There was a problem hiding this comment.
Improvement — the CloudFormation template is the one artifact the reader has to get hold of, and it's still not linked. It's named four times across the two pages (here, line 64, and kosli_capture_security.md:14), and the security page now says it "is publicly accessible and can be used directly within an aws cloudformation create-stack call" — which makes the missing URL more conspicuous, not less. A reader who wants to review the permissions before contacting Customer Success is stuck.
If the URL is public, link it here and on the security page. If it isn't public yet, say that explicitly ("Kosli provides the template during onboarding") so the reader stops looking.
| - lambda:GetFunction | ||
| - lambda:GetLayerVersion | ||
| Resource: "*" | ||
| ```` |
There was a problem hiding this comment.
Suggestion — closing fence has four backticks, and neither code block declares a language.
The four-backtick close does still terminate the block under CommonMark, so it renders — but it's a stray character, and neither block (line 20 and line 46) tags a language, so both lose syntax highlighting on what is otherwise a page of YAML.
Change ``` → ```yaml on lines 20 and 46, and:
| ```` |
3 participants
Adds a new "Kosli Capture Managed Service" page to the Getting started section, based on a customer-facing overview drafted by Graham.
getting_started/kosli_capture.md(sidebar label: "Kosli Capture")Generated by Mintlify Agent.
Requested by: graham@kosli.com via Slack
Mintlify session: slack_1782915660.508229_D0AM66349C1