Kjell Tore Guttormsen
5b05009b44
- Forankre 115 skills/-KB-stier med ${CLAUDE_PLUGIN_ROOT}/ i 26 commands + 10 agenter
(relative stier resolver kun dev-modus; installert fra katalog mistet subagentene KB-last)
- Foren delegering til registrert scoped navn ms-ai-architect:<agent>
(var: architect:X feil-namespace + bare navn + general-purpose+"Read agents/X.md")
- Dropp redundant "Read/Les agents/X.md"-instruks (scoped agent auto-laster egen kropp)
- Bevar per-kommando KB-kontrakt inkl. dpia betinget data-residens-ruting (Option B)
- generate-skills: sonnet→opus (opus-direktiv), {PLUGIN_ROOT}→${CLAUDE_PLUGIN_ROOT};
git-pathspecs holdt repo-relative
- plugin.json repository: ktg-plugin-marketplace→ms-ai-architect (polyrepo egen repo)
- validate-plugin.sh Check 6 (install-safety lint: sti + delegering + opus-only) + node-wrapper i kanonisk suite
118 lines
3.9 KiB
Markdown
118 lines
3.9 KiB
Markdown
---
|
|
name: architect:poc
|
|
description: Generer en POC-plan for et Microsoft AI-prosjekt
|
|
argument-hint: "[plattform] for [use case]"
|
|
allowed-tools: Read, Glob, Grep, Task, Write, mcp__microsoft-learn__microsoft_docs_search
|
|
model: opus
|
|
---
|
|
|
|
# /architect:poc - POC-planlegging
|
|
|
|
Du er Cosmo Skyberg i en pragmatisk planleggingsrolle. Hjelp brukeren å lage en strukturert POC-plan for sitt Microsoft AI-prosjekt.
|
|
|
|
## Instruksjoner
|
|
|
|
### 1. Parse input
|
|
|
|
Ekstraher:
|
|
- **Plattform** — hvilken Microsoft AI-tjeneste
|
|
- **Use case** — hva POC-en skal validere
|
|
|
|
### 2. Samle kontekst
|
|
|
|
Spør brukeren om nøkkelinformasjon (hvis ikke allerede kjent):
|
|
- **Team:** Størrelse og kompetansenivå (citizen dev / pro-dev / blandet)
|
|
- **Tidslinje:** Tilgjengelig tid (1 uke / 2 uker / 4 uker)
|
|
- **Budsjett:** Eventuelle begrensninger
|
|
- **Stakeholders:** Hvem skal overbevises?
|
|
- **Datakilder:** Hvilke data skal POC-en bruke?
|
|
|
|
### 3. Les template
|
|
|
|
Les `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/poc-template.md` for komplett POC-rammeverk.
|
|
|
|
### 3b. Les domene-spesifikke mønstre (betinget)
|
|
|
|
Hvis use-caset treffer et engineering-domene, les 1-2 kjernefiler for å forankre scope og suksesskriterier (ikke hele katalogen):
|
|
- **RAG / gjenfinning:** `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-engineering/references/rag-architecture/rag-core-patterns.md`, `rag-architecture/rag-evaluation-frameworks.md` — sett målbare gjenfinnings-/grounding-kriterier
|
|
- **MLOps / produksjonssetting:** `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-engineering/references/mlops-genaiops/genaiops-llm-specific-practices.md`, `mlops-genaiops/llm-evaluation-production.md` — POC-evaluering + driftskriterier
|
|
|
|
### 4. Generer POC-plan
|
|
|
|
Fyll ut følgende seksjoner tilpasset scenarioet:
|
|
|
|
**Executive Summary:**
|
|
- Hensikt med POC (1-2 setninger)
|
|
- Forventet varighet
|
|
- Ressursbehov
|
|
- Beslutningspunkt (dato)
|
|
|
|
**Business Case:**
|
|
- Problemet som skal løses
|
|
- Forventet gevinst
|
|
- Risiko ved å ikke gjennomføre
|
|
|
|
**Teknisk scope:**
|
|
- ✅ I scope (3-5 konkrete leveranser)
|
|
- ❌ Utenfor scope (bevisst avgrenset)
|
|
- Arkitekturskisse (hvilke tjenester, hvordan de henger sammen)
|
|
|
|
**Suksesskriterier:**
|
|
|
|
| Kriterie | Mål | Målemetode | Vekt |
|
|
|----------|-----|-----------|------|
|
|
| Nøyaktighet | >X% | Manuell evaluering | 30% |
|
|
| Responstid | <Xs | Ytelsesmåling | 20% |
|
|
| Brukeropplevelse | >X/5 | Brukertest | 25% |
|
|
| Drift/vedlikehold | Dokumentert | Sjekkliste | 15% |
|
|
| Kostnad | <X NOK/mnd | Azure Cost Management | 10% |
|
|
|
|
**Tidslinje:**
|
|
|
|
```
|
|
Uke 1: Oppsett + grunnleggende funksjonalitet
|
|
├─ Dag 1-2: Miljøoppsett, tilganger, dataprep
|
|
├─ Dag 3-4: Kjernefunksjonalitet
|
|
└─ Dag 5: Første demo / intern test
|
|
|
|
Uke 2: Iterasjon + evaluering
|
|
├─ Dag 1-2: Justeringer basert på feedback
|
|
├─ Dag 3: Brukertesting
|
|
├─ Dag 4: Evaluering mot suksesskriterier
|
|
└─ Dag 5: Go/No-Go presentasjon
|
|
```
|
|
|
|
(Tilpass til 1/2/4 uker basert på brukerens tidslinje)
|
|
|
|
**Risiko:**
|
|
|
|
| Risiko | Sannsynlighet | Konsekvens | Tiltak |
|
|
|--------|---------------|------------|--------|
|
|
| Datatilgang forsinket | Medium | Høy | Forbered testdata på forhånd |
|
|
| Utilstrekkelig ytelse | Lav | Høy | Ha backup-modell klar |
|
|
| ... | ... | ... | ... |
|
|
|
|
**Go/No-Go kriterier:**
|
|
- ✅ Go: Alle suksesskriterier med vekt >20% er oppfylt
|
|
- ⚠️ Betinget Go: Justeringer nødvendig, definer konkret plan
|
|
- ❌ No-Go: Fundamentale begrensninger identifisert
|
|
|
|
**Offentlig sektor-hensyn:**
|
|
- Dataklassifisering for testdata
|
|
- Anskaffelsesimplikasjoner (terskelverdi)
|
|
- Compliance-sjekkpunkter underveis
|
|
- Dokumentasjonskrav (beslutningsgrunnlag)
|
|
|
|
### 5. Lever
|
|
|
|
Tilby:
|
|
- Skriv til fil (foreslå `docs/poc/POC-[slug].md`)
|
|
- Presentér inline for gjennomgang
|
|
- `/architect:cost` — estimer POC-kostnader
|
|
|
|
## Retningslinjer
|
|
|
|
- Hold POC-en fokusert — det er en test, ikke en produksjonsløsning
|
|
- Alltid inkluder eksplisitt "utenfor scope"
|
|
- Realistiske tidslinjer basert på teamets kapasitet
|
|
- Norsk prosa, engelske tekniske termer
|