Todos os prompts usados pelo orchestrator (src/dev-team-orchestrator.ts), em ordem lógica de execução.
Variáveis em {{duplas chaves}} são substituídas em runtime pelo TypeScript.
| #!/bin/bash | |
| # Read the JSON input from stdin | |
| input=$(cat) | |
| # Extract the cwd from the JSON | |
| if command -v jq &> /dev/null; then | |
| cwd=$(echo "$input" | jq -r '.cwd') | |
| # If cwd is empty or null, use workspace_roots[0] as fallback | |
| if [ -z "$cwd" ] || [ "$cwd" == "null" ]; then |
.env or any environment variable files—only the user may change them.git reset --hard, rm, git checkout/git restore to an older commit) unless the user gives an explicit, written instruction in this conversation. Treat tYou are Kiro, an AI assistant and IDE built to assist developers.
When users ask about Kiro, respond with information about yourself in first person.
You are managed by an autonomous process which takes your output, performs the actions you requested, and is supervised by a human user.
You talk like a human, not like a bot. You reflect the user's input style in your responses.
This guide will walk you through creating a custom MCP (Model Context Protocol) server that integrates with Claude Code, allowing you to extend Claude's capabilities with external tools, APIs, or even other AI models.
MCP (Model Context Protocol) is a protocol that allows Claude to communicate with external servers to access tools and capabilities beyond its built-in features. Think of it as a plugin system for Claude.
| # /etc/nixos/configuration.nix | |
| { config, pkgs, ... }: | |
| { | |
| imports = | |
| [ | |
| ./hardware-configuration.nix | |
| ]; | |
| boot.loader.systemd-boot.enable = true; |
| { | |
| config, | |
| pkgs, | |
| lib, | |
| inputs, | |
| ... | |
| }: let | |
| ipu6-camera-bin = with pkgs; | |
| stdenv.mkDerivation rec { | |
| pname = "ipu6-camera-bin"; |
In a previous post
I explained how to manage Neovim plugins with Nix and Home Manager.
In this post I want to go further and show how to migrate Neovim configuration
from ~/.config/nvim to ~/.config/home-manager entirely. The end result will
be to split our Neovim setup into multiple modules that colocate plugin sourcing
and configuration.
If you haven't read the post linked above, do so now. We will assume the
Highly extensible software like Emacs, Vim, and Neovim tend to grow their own package managers. A software developer, for example, might want to install editor plugins that hook into a particular programming language's linter or language server. The programmer's text editor is therefore extended to support managing additional software to extend the text editor. If this loop continues for too long, the programmer's editor becomes more delicate and complex. The remedy for this problem is to manage software using dedicated tools apart
| [package] | |
| name = "testcontainers-sample" | |
| version = "0.1.0" | |
| edition = "2021" | |
| [dev-dependencies] | |
| async_once = "0.2.6" | |
| aws-sdk-s3 = "0.28.0" | |
| ctor = "0.2.4" | |
| lazy_static = "1.4.0" |