baa2d0220b
Add /ultraresearch-local for structured research combining local codebase analysis with external knowledge via parallel agent swarms. Produces research briefs with triangulation, confidence ratings, and source quality assessment. New command: /ultraresearch-local with modes --quick, --local, --external, --fg. New agents: research-orchestrator (opus), docs-researcher, community-researcher, security-researcher, contrarian-researcher, gemini-bridge (all sonnet). New template: research-brief-template.md. Integration: --research flag in /ultraplan-local accepts pre-built research briefs (up to 3), enriches the interview and exploration phases. Planning orchestrator cross-references brief findings during synthesis. Design principle: Context Engineering — right information to right agent at right time. Research briefs are structured artifacts in the pipeline: ultraresearch → brief → ultraplan --research → plan → ultraexecute. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
66 lines
2.5 KiB
Markdown
66 lines
2.5 KiB
Markdown
---
|
|
name: architect:adr
|
|
description: Generer en Architecture Decision Record (ADR) basert på sesjonens arkitekturbeslutninger
|
|
argument-hint: "[valgfritt: tittel for ADR]"
|
|
allowed-tools: Read, Glob, Grep, Task, Write
|
|
model: opus
|
|
---
|
|
|
|
# /architect:adr - Architecture Decision Record
|
|
|
|
Generer en ADR i MADR v3.0-format basert på arkitekturbeslutninger tatt i denne sesjonen. Ingen persona — dette er et dokumentasjonsverktøy.
|
|
|
|
## Instruksjoner
|
|
|
|
### 1. Identifiser beslutning
|
|
|
|
Gjennomgå samtalehistorikken og identifiser arkitekturbeslutninger:
|
|
- Plattformvalg (Copilot Studio vs Azure AI Foundry, etc.)
|
|
- Deployment-modeller (Standard vs PTU, serverless vs managed)
|
|
- Dataarkitektur (RAG-strategi, søketjeneste, datakilder)
|
|
- Sikkerhetsmodeller (identity, network, content safety)
|
|
- Integrasjonsvalg (connectors, API-er, protocols)
|
|
|
|
Hvis flere beslutninger finnes, spør brukeren hvilken som skal dokumenteres. Hvis ingen tydelig beslutning finnes, hjelp brukeren å formulere den.
|
|
|
|
### 2. Samle kontekst
|
|
|
|
Fra samtalehistorikken, ekstraher:
|
|
- **Bakgrunn:** Forretningskonteksten som drev beslutningen
|
|
- **Problem statement:** Det spesifikke arkitekturproblemet
|
|
- **Beslutningsdrivere:** Hva som var viktigst (kostnad, sikkerhet, tid, kompetanse)
|
|
- **Alternativer:** Hvilke løsninger ble vurdert
|
|
- **Valgt løsning:** Hva ble besluttet og hvorfor
|
|
- **Pro/con:** Fordeler og ulemper per alternativ
|
|
|
|
Hvis `/architect:compare` ble brukt, inkluder sammenligningstabellen.
|
|
Hvis `/architect:security` ble brukt, inkluder sikkerhetsscoren.
|
|
Hvis `/architect:cost` ble brukt, inkluder kostnadsestimatet.
|
|
|
|
### 3. Deleger til adr-writer-agent
|
|
|
|
Bruk Task-verktøyet til å delegere ADR-generering:
|
|
|
|
```
|
|
Task(general-purpose): "Read agents/adr-writer-agent.md for your role and instructions.
|
|
Generate an ADR based on the current session context.
|
|
Beslutning: [beslutningstittel]
|
|
Bakgrunn: [forretningskontekst]
|
|
Alternativer: [vurderte alternativer]
|
|
Valgt løsning: [beslutning med begrunnelse]
|
|
Les også: skills/ms-ai-advisor/references/architecture/adr-template.md"
|
|
```
|
|
|
|
### 4. Skriv til fil
|
|
|
|
Spør brukeren om plassering. Foreslå:
|
|
- `docs/adr/ADR-NNN-[slug].md` (prosjektets ADR-mappe)
|
|
- Bruk Write-verktøyet til å lagre filen
|
|
|
|
## Retningslinjer
|
|
|
|
- ADR skal være selvforsynt — lesbar uten sesjonskontekst
|
|
- ALLTID inkluder compliance-seksjon, selv om den er "Ikke vurdert"
|
|
- Bruk faktisk info fra sesjonen, ikke generisk fyll
|
|
- Norsk prosa, engelske tekniske termer
|
|
- Hold ADR fokusert — én beslutning per dokument
|