maria tzanidaki

Posted on Sep 8

I Built My Own Kiro Assistant Without Writing the Implementation: A Practical Runbook

#aws #awscommunitybuilders #kiro #ai

I wanted a personal assistant for my Obsidian vault—one that could summarize the notes I wrote during the week, find drafts that were close to publication, search my knowledge base with links to the original notes, and help me prepare for AWS Community Builder meetings from my Mac’s Calendar.

I did not want to begin by manually writing the implementation.

Instead, I started with a project brief, safety rules, acceptance tests, and a sequence of prompts. Kiro generated the agent configuration, reusable commands, and the deterministic code required for local Calendar access. I reviewed each phase, tested the result, and decided what it was allowed to do.

That distinction is important:

“Zero code” in this project means zero implementation code handwritten by me. The final project still contains code—Kiro produced it from my requirements and prompts.

This article is the practical runbook for rebuilding that workflow.

What I wanted to build

My assistant, which I called Vault Secretary, needed to support these commands:

/vault-menu
/organize-inbox
/morning-briefing
/community-builder-meeting-prep
/weekly-review
/weekly-notes-summary
/publishing-pipeline
/search-vault <question>

It also needed strict boundaries:

Calendar access must remain local to macOS and read-only.
No Google Cloud project or OAuth credentials.
No automatic publication.
No silent renaming, moving, rewriting, or deletion of notes.
Organization must begin with a proposal.
Approved changes require a backup and a diff.
Vault answers must link back to the real Obsidian sources.
Missing information must be reported instead of invented.

What I prepared before opening Kiro

My zero-code starter contained only Markdown files:

vault-secretary-zero-code/
├── README.md
├── PROJECT_BRIEF.md
├── MASTER_PROMPT.md
├── TEST_CHECKLIST.md
├── BUILD_LOG.md
└── Inbox/
    └── security-notes.md

There was no Python, shell script, agent JSON, .kiro directory, or finished integration.

The files had different purposes:

PROJECT_BRIEF.md described the problem, desired capabilities, and non-negotiable boundaries.
MASTER_PROMPT.md divided the build into controlled phases.
TEST_CHECKLIST.md defined what “working” meant.
BUILD_LOG.md recorded decisions, failures, and changes.
Inbox/security-notes.md provided harmless sample data for the first test.

This gave Kiro context without giving it a prebuilt solution.

Step 1: Start Kiro in the project folder

Kiro CLI was already installed and signed in on my Mac.

I opened Terminal in the zero-code folder:

cd ~/Desktop/vault-secretary-zero-code
kiro-cli

Then I gave it one instruction:

Read MASTER_PROMPT.md and begin Phase 1.
Do not write any implementation files yet.

The final sentence matters. My first goal was not code generation—it was to see whether the proposed architecture respected my requirements.

Step 2: Make Kiro design before it builds

For Phase 1, my master prompt required Kiro to:

Restate the problem.
Propose the smallest useful architecture.
Identify privacy, permission, data-loss, and hallucination risks.
List every file it wanted to create.
Separate deterministic operations from AI judgment.
Explain how local macOS Calendar access would work.
Define the shared Calendar cache format.
Propose a safe test sequence.
Wait for approval.

I was looking for an architecture similar to this:

macOS Calendar
      │ local read-only automation
      ▼
Normalized private cache
      │
      ├──────────────┐
      ▼              ▼
Kiro skills      Obsidian notes
      │              │
      └──────┬───────┘
             ▼
     Briefings and proposals
             │
             ▼
        Human approval

If Kiro had proposed Google credentials, direct access to the Calendar database, unrestricted vault writes, or automatic publication, I would have rejected the plan before any implementation existed.

Step 3: Ask Kiro to build the agent foundation

After approving the architecture, I continued with a tightly scoped prompt:

Proceed with Phase 2 only.

Create the minimum safe vault foundation:
- a custom Kiro agent;
- least-privilege read and write configuration;
- always-on safety steering;
- proposal-only Inbox organization;
- strictly read-only vault search with source wikilinks.

Do not implement Calendar access yet.
Show every file you create and run safe validation.

The expected project structure was:

.kiro/
├── agents/
│   └── vault-secretary.json
├── steering/
│   └── vault-rules.md
└── skills/
    ├── organize-inbox/
    │   └── SKILL.md
    └── search-vault/
        └── SKILL.md

The agent configuration defines the assistant’s identity, tools, automatic permissions, write restrictions, resources, and system prompt.

The steering file contains rules that should apply throughout the session, such as preserving source notes and treating meeting data as private.

The skill files define reusable workflows that can be invoked as commands.

How a Kiro command is created

This was the part I initially wanted to understand most.

A command such as:

/weekly-notes-summary

comes from a skill stored in:

.kiro/skills/weekly-notes-summary/SKILL.md

I did not need to write that file manually. I described the command to Kiro:

Create a reusable Kiro skill named weekly-notes-summary.

When invoked, it must:
1. Find Markdown notes created or modified during the last seven days.
2. Exclude .kiro, .obsidian, .vault-secretary, Briefings, Proposals,
   templates, backups, and generated summaries.
3. Summarize the notes, topics, documented decisions, unfinished tasks,
   Community Builder activity, and article ideas.
4. Select exactly three priorities for next week.
5. Add an Obsidian wikilink to every source.
6. Label inferences and never invent facts.
7. Write only to Briefings.
8. Never change the source notes.

Show me the proposed SKILL.md before saving it.

Kiro generated a SKILL.md containing front matter similar to:

---
name: weekly-notes-summary
description: "Summarize notes created or modified during the last seven days."
---

The remaining Markdown describes the workflow and constraints. After restarting the agent, the skill becomes available through its command name.

The general pattern is:

My requirement
    ↓
Prompt to Kiro
    ↓
.kiro/skills/<skill-name>/SKILL.md
    ↓
/<skill-name>

Step 4: Test note safety before adding Calendar access

I did not connect the Calendar first. I tested the smallest risky action: note organization.

My sample note contained AWS Security topics and an article idea. I started the generated agent from the vault root:

kiro-cli --agent vault-secretary

Then I ran:

/organize-inbox

The generated command behaved as intended:

Read the note in Inbox/.
Leave the original untouched.
Create a Markdown proposal under Proposals/.
Suggest a title, destination, properties, tasks, and related links.
Explain uncertainties.
Require explicit approval before applying anything.

It analyzed the sample Security note, suggested a destination, extracted tasks and an article idea, created a proposal, and left the original untouched. My acceptance test was not simply “the output looks intelligent.” It was:

Is the original file still exactly where it was, with exactly the same content?

Only after that passed did I continue.

Step 5: Add local macOS Calendar access

The Calendar integration required deterministic code because a Kiro skill alone does not automatically gain access to every application on a Mac.

I still did not write that code manually. I prompted Kiro:

Proceed with Phase 3 only.

Build a local, read-only macOS Calendar integration.

Requirements:
- Do not use Google Cloud, OAuth credentials, AWS credentials, or direct
  access to the Calendar database.
- Use the supported macOS automation interface.
- Read events only from the configurable lookahead window.
- Normalize calendar name, title, start and end time, location,
  description, all-day status, and available display alerts.
- Detect Community Builder events using configurable keywords.
- Store the result in a private ignored local cache.
- Never create, edit, accept, decline, or delete an event.
- Add clear permission errors and a deterministic briefing generator.
- Show all proposed files before writing them.

This is where “zero code written by me” differs from “no code.” Kiro needed to generate a small deterministic bridge between macOS Calendar and the files its skills could read.

What Kiro actually generated

I had deliberately specified the behavior rather than the exact library it should use. Kiro chose Python with the native macOS EventKit framework through PyObjC.

It generated:

a Calendar synchronization script;
EventKit permission handling;
normalization for titles, calendars, dates, locations, notes, all-day events, and display alerts;
configurable Community Builder keyword matching;
a private JSON cache;
and a deterministic briefing formatter.

The resulting flow was:

Calendar automation → normalized JSON → Kiro interpretation

That separation kept authentication, retrieval, parsing, and date handling deterministic, while Kiro handled note relationships, preparation questions, and prioritization.

Kiro generating the native macOS EventKit integration from my requirements. I defined the behavior, privacy boundaries, and acceptance criteria; Kiro created the implementation.

Step 6: Generate the remaining commands

Once the foundation and Calendar test passed, I asked Kiro to create the rest of the menu:

Create reusable Kiro skills for:

- vault-menu
- morning-briefing
- community-builder-meeting-prep
- weekly-review
- publishing-pipeline

Use the safety rules already defined by the agent.
Generated summaries may go only to Briefings.
Publishing-pipeline must never publish content.
Meeting preparation must not expose private URLs, attendees, or descriptions
in public drafts.
Show the proposed SKILL.md files before saving them.

I tested the menu with:

/vault-menu

Then I tested each workflow independently instead of running everything at once.

Step 7: Use the vault as a source, not as inspiration

For vault search, I wanted strict source grounding.

Example:

The generated skill was required to separate:

Found in my notes — statements directly supported by note content.
Possible connections — clearly labeled interpretations.
Not documented — relevant gaps.
Sources — unique Obsidian wikilinks.

If the information did not exist, the expected response was:

This is not documented in the vault.

This makes the assistant useful as a personal knowledge source without silently mixing my notes with model knowledge.

Step 8: Keep a build log

I used BUILD_LOG.md to record:

what Kiro proposed;
what I accepted;
what I changed;
which tests passed;
which failures occurred;
where my judgment was necessary.

This is particularly useful when writing about an AI-assisted project. A clean final repository hides the most valuable part: the decisions and corrections made along the way.

My prompt pattern for new commands

For any future command, I can reuse this template:

Create a reusable Kiro skill named <command-name>.

Trigger/use case:
<When should this skill be used?>

Inputs:
<Which folders, files, cache, or user question may it read?>

Exclusions:
<Which folders or private data must it ignore?>

Output:
<What should it return or where may it write?>

Grounding:
<How must it cite sources and handle missing information?>

Safety boundaries:
<What must it never modify, publish, expose, or invent?>

Validation:
<How will we know it worked?>

Show the proposed SKILL.md before saving it.

This is more reliable than asking, “Create a command that organizes everything,” because it defines the trigger, inputs, exclusions, output, evidence, permissions, and test.

What I typed versus what Kiro generated

I provided	Kiro generated
Product requirements	Project structure
Privacy boundaries	Agent configuration
Desired command behavior	`SKILL.md` files
Calendar constraints	EventKit integration through PyObjC
Acceptance criteria	Validation and test commands
Approvals and corrections	Revised implementation

The important skill was not memorizing syntax. It was learning how to specify behavior precisely and verify the result.

Final checklist

Before treating the assistant as usable, I ran the checklist and confirmed:

The custom agent loads from the vault root.
Inbox organization creates proposals without touching originals.
Search is read-only and cites actual notes.
Weekly summaries exclude generated content and backups.
Drafts are not marked ready based on a title or outline alone.
Calendar access stays local and read-only.
A test Community Builder event is detected.
No Calendar event can be changed.
Private cache, .env, credentials, and virtual environments are excluded from distribution.
The README describes what was actually tested.

Final thoughts

Kiro can be shaped into a highly personal assistant through your own prompts, but the quality of the result depends on more than describing features.

You need to define:

what the assistant may read;
what it may write;
what it must exclude;
how it proves its answers;
when it must ask for approval;
and how you will test it.

I did not need to handwrite the implementation to make those decisions. My role was to provide the requirements, boundaries, examples, approvals, and verification.

That is the part I find most interesting about building with Kiro:

You are not limited to using a predefined assistant. With well-structured prompts, you can build the assistant around your own workflow—and keep control of what it is allowed to do.

DEV Community