ms-ai-architect/commands/poc.md
Kjell Tore Guttormsen ced0c5f46d refactor(ms-ai-architect): R14 — persona ut av plugin-flaten, og de seks stedene som produserte den
Nøytral arkitekt-ramme (ratifisert 15.09) i SKILL.md-ene, 23 kommandoer, 70 redaksjonelle
forekomster i ref-korpuset, README/CLAUDE.md/NOTICE og A11Y-rapportens proveniens-linje.
Hver av de 70 avgjort i kontekst: dialog fikk ny taler, proveniens ny opphavspåstand.

Ordren navnga fem produsent-steder; den live sjette manglet. `PROMPT_TEMPLATE` settes i
generate-skills.sh:27 og leses ALDRI — prompten er en heredoc i samme script. Å rette bare
prompt-template.md ville latt generatoren re-minte personaen ved neste KB-kjøring.

Ny G4-klausul i check-cosmo-gate.mjs: persona i leveranseflaten = 0, derivasjonsregisteret
pinnet per fil PÅ TALL (et filnavn-unntak er blindt for hva fila senere inneholder).
Registeret utvidet med README.md 3 — versjonstabellens rader er historikk, ikke leveranse.
Den ene genitiv-formede produktlinja adjudiseres på cosmos-db-URL-en i samme rad; regelen
er målt lukket (8 tvetydige linjer totalt, 33 URL-linjer, 2 persona-klassifiserte, begge
produkt) og hvitvasker ikke bar `Cosmo`. classifyCosmo urørt — baselinene hviler på den.
R3 godtar nå R14-utført (0) men ingenting imellom: et halvveis sveip felles fortsatt.

Bevis: gate PASSED + NETTET VALIDERT BEGGE VEIER · 1137/1137 · validate-plugin 250/0/0 ·
begge --dry-drivere 0 · Layer B 45/45 OK (kjent-positiv feller, exit 1).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-15 23:15:27 +02:00

4 KiB

name description argument-hint allowed-tools model
architect:poc Generer en POC-plan for et Microsoft AI-prosjekt [plattform] for [use case] Read, Glob, Grep, Task, Write, mcp__microsoft-learn__microsoft_docs_search opus

/architect:poc - POC-planlegging

Du er en Microsoft AI-løsningsarkitekt 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, ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-engineering/references/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, ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-engineering/references/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