Behöver ert företag hjälp med att implementera AI? Kontakta oss och få prisoffert här →
AI Skolan ›
January 22, 2026

Från openai till github: godkända handböcker

Rickard Andersson Partner, Nodenordic.se

Handboken är ”nästan klar” tills någon upptäcker ett fel, en intressent vill göra en justering och plötsligt har du tre versioner som flyter runt i e-post, Docs och på någons skrivbord.

Den här OpenAI GitHub-automationen slår hårdast mot Ops-ansvariga och kunskapsansvariga, helt ärligt. Men byråägare som underhåller kundplaybooks känner också av det. Du får ett korrekt formaterat utkast, ett tydligt godkännandesteg via e-post och sedan en GitHub-uppdatering som faktiskt speglar det som godkändes.

Nedan ser du hur arbetsflödet körs, vad det automatiserar och de praktiska delarna i konfigurationen så att du kan sluta jaga ”final_v7_really_final.md”.

Så här fungerar automatiseringen

Hela n8n-arbetsflödet, från trigger till slutresultat:

n8n Workflow Template: Från openai till github: godkända handböcker

Problemet: uppdateringar av handboken blir snabbt röriga

Handböcker och intern dokumentation är inte svåra för att skrivandet är svårt. De är svåra för att samordningen är svår. Någon skapar ett utkast på ett ställe, feedback kommer in någon annanstans och den ”godkända” versionen är oftast en känsla, inte en fil. Sedan ska du publicera, och då gissar du vilka ändringar som faktiskt blev godkända. Med tiden skapar det en tyst skatt: dubbelt arbete, inkonsekvent policyspråk och riskabla ”nästan korrekta” instruktioner som nyanställda följer utan att ifrågasätta.

Ingen av de här sakerna är problemet var för sig. Tillsammans är de det.

  • Granskningar sker i spridda trådar, så beslut fångas inte där innehållet faktiskt bor.
  • Folk fortsätter redigera efter ”godkännande”, vilket skapar diskussioner senare om vad man kom överens om.
  • Publicering till GitHub blir ett manuellt måsten, och det skjuts ofta upp till ”sen” i flera veckor.
  • Utan en versionshistorik blir revisioner och onboarding till gissningslek och minnestest.

Lösningen: OpenAI skriver utkast, människor godkänner, GitHub hålls uppdaterat

Det här arbetsflödet gör skapandet av handboken till en repeterbar pipeline med tydligt ägarskap inbyggt. Det startar när du skickar en JSON-förfrågan till en n8n-webhook (titel, text, taggar och om du kräver mänskligt godkännande). Därifrån fungerar OpenAI som ett litet ”redaktionsteam” som kan sammanfatta, syntetisera, granska och förbättra utkastet tills det klarar kvalitetskontrollerna. När det är redo mejlar arbetsflödet en granskare med en korrekt formaterad begäran om godkännande och väntar sedan. Om granskaren godkänner sparas innehållet i en databas för spårbarhet och committas till ett GitHub-repo för versionshantering. Om de avslår loggar arbetsflödet även det utfallet, så att du kan se vad som hände och varför.

Arbetsflödet börjar vid webhooken och validerar din databasanslutning. Därefter avgör en meta-orkestrerare vilka specialistagenter som ska köras (sammanfattning, syntes, peer review, sensemaking, promptförbättringar, onboardinghjälp). Till sist avgör en e-postbaserad godkännandegrind vad som sparas och pushas till GitHub.

Det här får du: automatisering kontra resultat

Exempel: så här ser det ut i praktiken

Säg att du uppdaterar 5 avsnitt i handboken varje vecka. Manuell hantering kan innebära cirka 30 minuter för att skriva varje avsnitt, ytterligare 20 minuter för att jaga feedback och sedan 10 minuter för att kopiera in sluttexten i GitHub, alltså ungefär 5 timmar totalt. Med det här arbetsflödet skickar du in förfrågan på en minut eller två, låter AI-granskningsloopen köra och sedan lägger en granskare cirka 20 minuter på att godkänna (eller avslå med kommentarer). GitHub uppdateras automatiskt efter godkännande, så du får tillbaka runt 2 till 3 timmar de flesta veckor, plus betydligt färre ”Vilken version är rätt?”-meddelanden.

Det här behöver du

  • n8n-instans (testa n8n Cloud gratis)
  • Alternativ för egen drift om du föredrar det (Hostinger fungerar bra)
  • OpenAI för att generera, granska och förbättra utkast
  • GitHub för att lagra godkända handboksversioner
  • PostgreSQL-uppgifter (skapa i n8n som ”Postgres Pyragogy DB”)

Kunskapsnivå: Medel. Du kopplar upp inloggningar, ställer in några miljövariabler och klistrar in en test-JSON-payload i en webhook.

Vill du inte sätta upp det här själv? Prata med en automationsexpert (gratis konsultation i 15 minuter).

Så fungerar det

En webhook-förfrågan startar allt. Du skickar JSON till /webhook/pyragogy/process med en handbokstitel, källtext, taggar och en valfri flagga för ”kräv mänsklig granskning”.

Arbetsflödet planerar utkast- och granskningssekvensen. En koordinatoragent (OpenAI) avgör vilka specialistagenter som ska köras, och sedan routar n8n innehållet genom sammanfattning, syntes, peer review och sensemaking baserat på den planen.

Nya utkast skapas automatiskt när kvalitetskontroller misslyckas. Om granskningspanelen flaggar ett större problem loopar arbetsflödet tillbaka med specifik feedback så att synthesizer-agenten kan skriva om, istället för att du manuellt ska ”försöka igen”.

Godkännande hanteras via e-post, och publicering sker automatiskt. n8n skickar ett granskningsmejl, väntar på beslutet via en webhook-callback, lagrar resultatet i Postgres och committar den godkända Markdown-filen till GitHub om GitHub är aktiverat.

Du kan enkelt ändra godkännandelogiken för att stödja flera granskare eller olika regler för ”godkänn/avslå” utifrån dina behov. Se den fullständiga implementationsguiden nedan för anpassningsalternativ.

Steg-för-steg-guide för implementering

Steg 1: Konfigurera webhook-triggern

Sätt upp den inkommande webhooken så att externa system kan starta multi-agent-handboksflödet.

  1. Lägg till och öppna Inbound Webhook Trigger.
  2. Ställ in HTTP Method på POST.
  3. Ställ in Path på pyragogy/process.
  4. Kopiera produktions-webhook-URL:en för användning av ert uppströms system.
Säkerställ att er inkommande JSON innehåller en body.input-payload eftersom Interpret Orchestration Plan och Assemble Agent Input är beroende av den.

Steg 2: Anslut databastjänster

Konfigurera PostgreSQL-anslutning för validering och lagring av handboksinnehåll och agentbidrag.

  1. Öppna Validate DB Link och ställ in Operation på executeQuery.
  2. Ställ in Query på SELECT 1; -- Verifica connessione DB.
  3. Öppna Store Handbook Entry och bekräfta att Table är handbook_entries med Columns inställda på title, content, version, created_by, tags, phase, rhythm.
  4. Öppna Record Agent Contribution och bekräfta att Table är agent_contributions med Columns inställda på entry_id, agent_name, contribution_type, details.
  5. Autentiseringsuppgifter krävs: Anslut era Postgres-autentiseringsuppgifter för Validate DB Link, Store Handbook Entry och Record Agent Contribution.
⚠️ Vanlig fallgrop: Om Postgres-autentiseringsuppgifter saknas kommer arbetsflödet att stoppa innan någon AI-bearbetning börjar.

Steg 3: Sätt upp AI-orkestreringen och agentloopen

Konfigurera orkestreringshubben och agentloopen för att dynamiskt routa uppgifter över flera AI-agenter.

  1. Öppna Coordinator AI Hub och ställ in Resource på chat med Model inställd på gpt-4o.
  2. Autentiseringsuppgifter krävs: Anslut era OpenAI-autentiseringsuppgifter för Coordinator AI Hub.
  3. Öppna Interpret Orchestration Plan och behåll den tillhandahållna Function Code för att tolka agentsekvensen och initiera loopräknare.
  4. Öppna More Agents Pending? och säkerställ att den booleska villkorssatsen använder {{$workflow.currentAgentIndex < $workflow.agentSequence.length}}.
  5. Öppna Assemble Agent Input och behåll logiken som sätter agentInput från tidigare utdata eller omarbetningsfeedback.
  6. Öppna Agent Routing Switch och ställ in Mode på json för agentspecifik routing.
  7. Anslut OpenAI-autentiseringsuppgifter för alla agentnoder: Summary Agent, Synthesis Agent, Peer Review Agent, Sensemaking Analyst, Prompt Design Agent och Onboarding Guide Agent. Var och en använder Resource chat och Model gpt-4o.
Agentloopen går vidare i den här ordningen: Interpret Orchestration Plan → More Agents Pending? → Assemble Agent Input → Agent Routing Switch → agentnoder → Process Agent Results → tillbaka till More Agents Pending?.

Steg 4: Konfigurera logik för granskning, omarbetning och godkännande

Sätt upp granskningsflödet som sammanställer utkastet, skickar godkännandelänkar och hanterar omarbetningscykler.

  1. Öppna Attach Handbook Metadata och behåll standardvärdena för title, tags, phase och rhythm.
  2. Öppna Compose Review Draft för att behålla genereringen av YAML front matter och finalMarkdownContent.
  3. Öppna Create Review Identifier och behåll crypto.randomUUID() för unika ID:n.
  4. Öppna Dispatch Review Email och ställ in To Email på [YOUR_EMAIL] och From Email på [YOUR_EMAIL].
  5. I Dispatch Review Email uppdaterar ni godkännande-URL:erna till er n8n-bas-URL: your_n8n_url/webhook/pyragogy/review-feedback?reviewId={{ $json.reviewId }}&status=approved och your_n8n_url/webhook/pyragogy/review-feedback?reviewId={{ $json.reviewId }}&status=rejected.
  6. Autentiseringsuppgifter krävs: Anslut era SMTP/EmailSend-autentiseringsuppgifter för Dispatch Review Email.
  7. Öppna Await Human Approval för att pausa arbetsflödet och invänta webhook-svaret för godkännande.
  8. Öppna Human Decision Branch och säkerställ att villkoret använder {{$json.query.status === 'approved'}}.
  9. Öppna Evaluate Review Board och behåll logiken som sätter redraftNeeded och redraftFeedback.
  10. Öppna Redraft Required? och bekräfta att den använder {{$json.redraftNeeded && $workflow.redraftLoopCount < 2}} för att begränsa loopar.
  11. Öppna Process Redraft Cycle för att säkerställa att feedback läggs till i redraftInput inför nästa agentpass.
⚠️ Vanlig fallgrop: Om er webhook-URL för godkännande inte matchar webhooken i Await Human Approval kommer arbetsflödet att stanna i vänteläge.

Steg 5: Konfigurera utdata-destinationer (databas, GitHub, Slack, webhook-svar)

Slutför det godkända innehållet genom att lagra det, valfritt committa till GitHub, notifiera Slack och returnera ett svar till den som begärde det.

  1. Öppna Store Handbook Entry för att spara godkänt innehåll i er databas.
  2. Öppna Prepare Approved Contribution för att säkerställa att bidragsmetadata är satt för Record Agent Contribution.
  3. Öppna Build GitHub File Path och behåll sökvägsformatet med slug och tidsstämpel.
  4. Öppna GitHub Active? och bekräfta att den kontrollerar {{$env.GITHUB_ACCESS_TOKEN}}.
  5. Öppna Commit Approved to GitHub och ställ in Owner på {{$env.GITHUB_REPOSITORY_OWNER}}, Repository på {{$env.GITHUB_REPOSITORY_NAME}} och File Path på {{$json.githubFilePath}}.
  6. Autentiseringsuppgifter krävs: Anslut era GitHub-autentiseringsuppgifter för Commit Approved to GitHub.
  7. Öppna Slack Notifications On? och säkerställ att den kontrollerar {{$env.SLACK_WEBHOOK_URL}}.
  8. Öppna Send Slack Update och verifiera att meddelandet använder {{$json.body.input}}, {{JSON.stringify($json.output)}} och {{$workflow.agentSequence.join(', ')}}.
  9. Autentiseringsuppgifter krävs: Anslut era Slack-autentiseringsuppgifter för Send Slack Update.
  10. Öppna Return Final Response och bekräfta att Respond With är json och att Response Body är {{ { finalOutput: $json.output, contributions: $json.contributions, agentSequence: $workflow.agentSequence } }}.
Om GitHub Active? utvärderas till false kommer arbetsflödet att hoppa över GitHub och gå direkt till Merge Archivist Outcomes, vilket säkerställer att pipelinen ändå slutförs.

Steg 6: Testa och aktivera ert arbetsflöde

Kör ett end-to-end-test för att verifiera agentorkestrering, godkännandeflöde, lagring och notifieringar.

  1. Klicka på Execute Workflow och skicka en test-POST-begäran till Inbound Webhook Trigger med en JSON-body som innehåller body.input, body.title och body.tags.
  2. Bekräfta att agentloopen körs och att Dispatch Review Email skickar godkännandemejlet.
  3. Klicka på godkännandelänken för att trigga Await Human Approval, och verifiera sedan att Store Handbook Entry och Record Agent Contribution skapar poster.
  4. Om GitHub är aktiverat, verifiera att Commit Approved to GitHub skapar eller uppdaterar filen på {{$json.githubFilePath}}.
  5. Kontrollera Slack för meddelandet från Send Slack Update och verifiera att Return Final Response returnerar JSON med finalOutput, contributions och agentSequence.
  6. När allt är verifierat, slå på arbetsflödets Active-reglage för produktion.
🔒

Lås upp fullständig steg-för-steg-guide

Få den kompletta implementeringsguiden + nedladdningsbar mall

Vanliga fallgropar

  • GitHub-inloggningar kan löpa ut eller kräva specifika behörigheter. Om det skapar fel, kontrollera först scope för din personal access token och miljövariablerna för repo-ägare/namn.
  • Om du använder Wait-noder eller extern bearbetning varierar tajmingen. Öka väntetiden om efterföljande noder misslyckas för att godkännande-webhooken kom in för sent.
  • Standardprompter i OpenAI-agenterna är generiska. Lägg in din ton, formateringsregler och riktlinjer för ”det här ska du inte göra” tidigt, annars kommer du redigera utdata för alltid.

Relaterade arbetsflöden

Om ditt team också behöver routa inkommande frågor till rätt ”ägare” innan dokumentationsändringar begärs, passar Slack + Gemini: routa frågor till rätt AI-agent bra ihop med en handbokspipeline med godkännande.

För team som kör snabb intern kommunikation parallellt med dokumentation hjälper Google Gemini + Slack, snabba uppdateringar vid begäran dig att publicera en ”vad som ändrades”-sammanfattning direkt efter att en handboksuppdatering landar.

När schemaläggning och onboarding krockar kan Google Sheets + Google Calendar, bokningar utan fram-och-tillbaka minska adminbördan så att handboksägarskap inte blir en kalenderkatastrof.

Behöver supportteamet svara konsekvent medan handboken utvecklas? Google Docs + Gemini: konsekventa chatsvar, snabbt är ett praktiskt komplement, särskilt vid policyändringar.

Slutligen, om du vill ha en korrekt formaterad, revisionsvänlig kalkylbladslogg över innehållsutdata och beslut är Mistral till Google Sheets, korrekt formaterad AI-utdata varje gång användbart för rapportering och styrning.


Snabbreferens:

Vanliga frågor

Hur lång tid tar det att sätta upp den här OpenAI GitHub-automationen?

Cirka 45 minuter om du redan har uppgifterna redo.

Behöver jag kunna koda för att automatisera godkännanden av handboken?

Ingen kodning krävs. Du kopplar mest konton, klistrar in miljövariabler och testar webhook-payloaden.

Är n8n gratis att använda för det här OpenAI GitHub-automationsarbetsflödet?

Ja. n8n har ett gratis alternativ för egen drift och en gratis provperiod på n8n Cloud. Molnplaner börjar på 20 USD/månad för högre volymer. Du behöver också räkna in kostnader för OpenAI API, vilket för handboksutkast i textformat vanligtvis är några dollar i månaden för små team.

Var kan jag hosta n8n för att köra den här automationen?

Två alternativ: n8n Cloud (hanterat, enklast att komma igång) eller egen drift på en VPS. För egen drift är Hostinger VPS prisvärt och hanterar n8n bra. Egen drift ger obegränsade körningar men kräver grundläggande serverhantering.

Kan jag anpassa det här OpenAI GitHub-automationsarbetsflödet för flera godkännare?

Ja, men du behöver justera godkännandegrinden. Det enklaste är att ändra webhook-callbacken ”Await Human Approval” så att den accepterar svar från fler än en granskare, och sedan uppdatera logiken i ”Human Decision Branch” så att den kräver alla godkännanden (eller en majoritet). Vanliga anpassningar är att lägga till en godkännandelista från Google Sheets, routa baserat på taggar och skriva till olika GitHub-sökvägar för olika avdelningar.

Varför misslyckas min GitHub-anslutning i det här arbetsflödet?

Oftast beror det på en utgången token eller saknade repo-behörigheter. Skapa en ny GitHub access token, bekräfta att den kan skriva till målrepo:t och kontrollera sedan miljövariablerna för repo-ägare/namn igen, eftersom ett enda skrivfel stoppar commits. Om det bara misslyckas ibland kan du också slå i API-begränsningar när många objekt körs samtidigt.

Hur många handboksinlägg kan den här OpenAI GitHub-automationen hantera?

Många, och den verkliga begränsningen är dina exekveringsgränser i n8n och din server. På n8n Cloud begränsas du av din månatliga exekveringspott (Starter räcker för små team, Pro hanterar tyngre användning). Om du kör egen drift finns ingen plattformsgräns för exekveringar, men du blir ändå begränsad av CPU och minne när flera AI-anrop sker parallellt. I praktiken kör de flesta team några handboksuppdateringar per dag utan att ens tänka på skala.

Är den här OpenAI GitHub-automationen bättre än att använda Zapier eller Make?

För just det här arbetsflödet har n8n några fördelar: det hanterar förgreningar och loopar snyggt (vilket du behöver för nya utkast och granskningsgrindar), det kan köras i egen drift för obegränsade körningar och det är enklare att hålla godkännandelogiken samlad på ett ställe istället för att sprida den över flera zaps. Zapier eller Make kan fortfarande fungera om du bara vill ha ”utkast → e-post → uppladdning”, men då tappar du sannolikt den iterativa granskningsloopen och databasloggningen om du inte bygger på med extra steg. Om din handbok ens är lite compliance-känslig spelar den explicita modellen ”vänta på godkännande” roll. Prata med en automationsexpert om du är osäker på vad som passar.

När det här väl är igång slutar handboksuppdateringar att vara ett samordningsprojekt. Du får ett utkast, ett godkännandespår och en GitHub-commit som matchar det som godkändes.

Kontakta oss

Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.

Våra tjänster Om Node Nordic
×

Använd mall

Få direkt tillgång till denna n8n-arbetsflödes JSON-fil

Kopiera och importera JSON-arbetsflödet i ditt n8n-arbetsflöde