lsaint/aikito

Was macht aikito?

Zweck

Verwende Aikito als kanonische, Git-verwaltete Quelle für dauerhafte Agentenressourcen und synchronisiere diese Ressourcen in unterstützte Codierungsagenten und Projekte.

Gedankenmodell

Halte das CLI-Quellverzeichnis und den Benutzerarbeitsbereich getrennt:

~/aikito-src   CLI-Quellcode-Checkout
~/aikito       kanonischer Benutzerarbeitsbereich

Der Arbeitsbereich enthält die Quellen der Wahrheit:

~/aikito/
├── agents.toml
├── skills.toml
├── subagents.toml
├── mcps/
├── global/AGENTS.md
├── skills/
├── memory/
└── projects/<name>/

Agent-Konfigurationsverzeichnisse und Projekt-.agents/-Verzeichnisse sind Laufzeit-Einstiegspunkte, keine unabhängigen Quellen. Modifiziere zuerst die kanonischen Arbeitsbereichsdateien, dann synchronisiere sie mit dem CLI.

Verwende AIKITO_DIR, wenn der Arbeitsbereich nicht ~/aikito ist. Verwende den installierten aikito-Befehl und nimm nicht an, dass das CLI innerhalb des Arbeitsbereichs lebt.

Bootstrap

Wenn das CLI nicht installiert ist, verwende das offizielle Quell-Repository und halte dessen Checkout getrennt vom zukünftigen Arbeitsbereich:

git clone https://github.com/lsaint/aikito.git "$HOME/aikito-src"
export PATH="$HOME/aikito-src/bin:$PATH"

Überprüfe vor dem Klonen, dass das Ziel keine unrelated users data enthält. Überschreibe kein bestehendes Checkout ohne Anweisung des Benutzers.

Initialisiere und inspiziere einen Arbeitsbereich:

aikito init workspace ~/aikito
aikito status

aikito init workspace verweigert den CLI-Quellbaum, ein anderes Quell-Checkout und ein nicht erkanntes nicht-leeres Verzeichnis. Versuche nicht, diese Schutzmechanismen zu umgehen. Nach der Initialisierung überprüfe die generierten Dateien, bevor du etwas synchronisierst.

Sicherheitsprotokoll

• Beginne mit schreibgeschützter Erkundung: überprüfe relevante kanonische Dateien, führe aikito status aus und verwende ressourcenspezifische Statusbefehle.
• Führe aikito adopt ohne --apply zuerst aus. Zeige dem Benutzer den Übernahmeplan, Konflikte und die Handhabung von Anmeldeinformationen, bevor du ihn anwendest.
• Verwende --dry-run für Synchronisationsbefehle, die dies unterstützen.
• Behandle nicht verwaltete Ziele und widersprüchliche Anweisungen als Entscheidungen für den Benutzer. Überschreibe sie nicht stillschweigend.
• Halte API-Schlüssel, Tokens, Passwörter und OAuth-Material aus dem Aikito-Arbeitsbereich und Git fern. Speichere Umgebungsvariablenreferenzen in der kanonischen MCP-Konfiguration.
• Warne vor jeder expliziten Force- oder Prune-Operation und beschränke sie auf das überprüfte Ziel.
• Behandle ein lokales Git-Repository nicht als sicher zum Veröffentlichen. Überprüfe Speicher und Konfiguration auf private Daten, bevor du ein Remote hinzufügst oder pushest.
• Bewahre unrelated users changes sowohl im Arbeitsbereich als auch in der Ziel-Agenten-Konfiguration auf.

Ressourcen-Routing

Globale Anweisungen und Fähigkeiten

Kanonische Quellen:

~/aikito/global/AGENTS.md
~/aikito/skills.toml
~/aikito/skills/<skill-name>/

Nach der Überprüfung der Änderungen:

aikito sync global --dry-run
aikito sync global
aikito status
aikito show skills
aikito show skill <target>
aikito edit skill <target>

Bearbeite keine generierten Agent-native instruction or skill entries als unabhängige Quellen.

Beim Hinzufügen, Umbenennen oder Entfernen einer globalen Fähigkeit behandle die Änderung als Cross-Runtime-Migration und nicht als reine Verzeichnisbearbeitung:

• Aktualisiere skills.toml, die Public-Export-Whitelist und Verweise auf den alten Fähigkeitsnamen.
• Stelle sicher, dass jeder unterstützte Agent, der globale Fähigkeiten lädt, den richtigen skills_path in agents.toml und in der aikito init-Vorlage hat. Nimm nicht an, dass eine Agent-CLI und ihre IDE dasselbe globale Fähigkeitsverzeichnis verwenden.
• Führe die relevanten Tests aus, dann führe aikito sync global und aikito status aus.
• Überprüfe jedes verwaltete Agent-Ziel und bestätige, dass die neue Fähigkeit sichtbar ist und ein veralteter Link für den alten Namen verschwunden ist.
• Behalte eine globale Fähigkeit aus den Project agent.toml-Dateien, es sei denn, das Projekt überschreibt oder kopiert sie absichtlich.

Projekte

Ein Arbeitsbereich ist die zentrale Quelle der Wahrheit und existiert normalerweise einmal. Eine Projektregistrierung repräsentiert ein Code-Verzeichnis und seine projektspezifischen Agentenressourcen. Wenn eine angeforderte Anweisung, Fähigkeitsauswahl oder Gedächtnis projektspezifisch ist und das aktuelle Code-Verzeichnis nicht registriert ist, frage, ob der Benutzer es registrieren möchte. Registriere kein Projekt für eine globale Ressource.

Nach Bestätigung initialisiere das Projekt von seinem Code-Verzeichnis aus:

aikito init project

Der Verzeichnisname und der aktuelle Pfad sind die Standardwerte. Verwende explizite Argumente, wenn nötig:

aikito init project <name> <path>

Dieser Befehl erstellt das kanonische Projekt-Skelett und synchronisiert seine .agents/-Laufzeit. Behandle bestehende unverwaltete Laufzeitressourcen oder einen Projektnamen, der an einen anderen Pfad gebunden ist, als Konflikte für den Benutzer; umgehe sie nicht.

Die Projektkonfiguration gehört unter:

~/aikito/projects/<name>/agent.toml
~/aikito/projects/<name>/AGENTS.md
~/aikito/projects/<name>/memory/

Synchronisiere und überprüfe mit:

aikito show projects
aikito show project <name>
aikito sync project <name> --dry-run
aikito sync project <name>
aikito status
aikito diff
aikito show memory

Projektanweisungen und Gedächtnis bleiben mit kanonischen Quellen verknüpft. Projektfähigkeiten folgen sync_mode: link behält symbolische Links; copy erstellt verwaltete Kopien für die Git-Verfolgung im Projekt. Verwende aikito status, um Abweichungen von kopierten Fähigkeiten zu erkennen, und aikito diff, um sie mit der kanonischen Fähigkeit zu vergleichen. Die Synchronisation weigert sich, abweichende Kopien zu ersetzen; führe Änderungen zusammen, die überleben sollen, oder verwende aikito sync project <name> --force nur nach Überprüfung.

Die Zielverzeichnisse .agents/skills/ und .agents/memory/ werden ausschließlich von Aikito verwaltet. Unbekannte Einträge sind Konflikte und werden von der Projektsynchronisation nie gelöscht. Speichere dort keine unrelated files.

MCP-Server

Kanonische Quelle:

~/aikito/mcps/*.toml

Vorschau, anwenden und überprüfen:

aikito sync mcp --dry-run
aikito sync mcp
aikito show mcp

Verwende aikito show mcp --live nur, wenn Live-Agent-Checks nützlich sind. Verwende aikito auth mcp <agent> <server> für unterstützte Authentifizierungsabläufe. Gib niemals erfasste Anmeldeinformationen aus, speichere sie nicht und committe sie nicht.

Unteragenten

Kanonische Quellen:

~/aikito/subagents.toml
~/aikito/subagents/

Vorschau, anwenden und überprüfen:

aikito sync subagents --dry-run
aikito sync subagents
aikito show subagents
aikito show subagent <target>
aikito edit subagent <target>

Überprüfe verwaiste verwaltete Dateien, bevor du --prune verwendest. Erzwinge niemals ein unverwaltetes Ziel, nur um den Status grün zu machen.

Gedächtnis

Das globale Gedächtnis gehört unter ~/aikito/memory/. Das projektspezifische Gedächtnis gehört unter ~/aikito/projects/<name>/memory/.

aikito show memory [target]
aikito edit memory <target>

Verwende die separate durable-memory skill, um zu entscheiden, wann Wissen langlebig genug ist, um gespeichert zu werden, welcher Bereich es besitzt und wie es versioniert wird.

Übernahme

Zeige eine Vorschau der bestehenden Agentenkonfiguration an, bevor du sie importierst:

aikito adopt

Nur nachdem der Benutzer den Plan überprüft und Anweisungskonflikte gelöst hat:

aikito adopt --apply

Die Anwendung erstellt mit Zeitstempel versehene Sicherungen unter ~/.aikito/backups/adopt_<timestamp>. Die Übernahme importiert Ressourcen in den Arbeitsbereich; Änderungen an der nativen Agentenkonfiguration erfolgen nur während der expliziten Synchronisation.

Überprüfung und aktuelles Verhalten

Führe nach jedem Schreibvorgang den engsten relevanten Statusbefehl aus und überprüfe die gemeldeten Ziele. Verwende aikito <command> --help als Autorität für Optionen, die von der installierten Version unterstützt werden. Wenn du von einem Quell-Checkout aus arbeitest, konsultiere dessen root README und die zugehörige verlinkte Dokumentation für die aktuelle Architektur und das Sicherheitsmodell.