Condividere il lavoro AI tra repository e collaboratori
Mantiene riconoscibile la relazione tra modifiche locali, commit e sorgente condivisa.
Quando più assistenti o persone lavorano sullo stesso progetto e il risultato non deve restare nascosto in un checkout locale.
Competenza tecnica · Builder e sistemi · Edizione pubblica 0.3.2
Due persone lavorano sullo stesso checkout. La competenza identifica il cambiamento selezionato e condivide solo quello, lasciando il contributo dell'altra persona intatto.
Il punto da capire. Comprende lo stato del repository selezionato e porta avanti le modifiche pertinenti preservando lavoro concorrente e identità della revisione condivisa.
Situazione illustrativa da adattare al tuo lavoro. Leggere i casi completi ↓
Il contesto lo porti tu: una ricerca, un servizio, un progetto creativo o il lavoro di un gruppo. Gli esempi rendono visibile il metodo; per adattarlo si conservano le relazioni che lo fanno funzionare e si comprendono di nuovo scopo, fonti, persone e mezzi del tuo lavoro.
Descrivi alla tua AI che cosa vuoi ottenere, che cosa esiste già e una situazione concreta da affrontare. Chiedile come questa competenza cambia il lavoro e quali conoscenze del tuo dominio devono partecipare. La provenienza MAIOS identifica il sapere condiviso; puoi usarlo direttamente nella tua AI o comporlo con un kernel esistente.
Esempi di adattamento in altri contesti ↗Un lavoro salvato può restare invisibile a chi deve continuarlo. Questa competenza collega il risultato locale alla sorgente condivisa del progetto, mantenendo chiaro che cosa appartiene alla modifica selezionata.
La continuità comprende le ragioni del cambiamento, i contributi concorrenti e la revisione che il collaboratore può davvero leggere. Commit, condivisione e pubblicazione del prodotto restano effetti distinti.
Raggiungi il repository che possiede il lavoro e le sue istruzioni attuali. Comprendi che cosa deve diventare condiviso e perché serve al seguito. Una cartella contenitore può ospitare più repository: non trattarli come un unico oggetto. La continuità diventa pertinente a un risultato significativo o a un passaggio di consegne, non richiede una chiusura Git dopo ogni modifica o una pubblicazione durante una richiesta di sola lettura.
Distingui file di lavoro, commit locali, riferimento di tracciamento, revisione remota verificata e artefatti generati o ignorati. Usa gli strumenti Git e l'accesso previsti dal progetto per vedere ramo, differenze e rapporto con il remoto. Un riferimento locale può essere vecchio; un fetch riuscito non dimostra che il contenuto selezionato sia già condiviso. Evita di stampare o salvare credenziali mentre acquisisci queste informazioni.
Leggi il significato delle modifiche prima di preparare il commit. Seleziona solo i file o le porzioni appartenenti al lavoro autorizzato. Un cambiamento vecchio o non ancora salvato in un commit non è per questo rumore eliminabile. Con contributi locali e remoti indipendenti, integra preservando entrambe le linee; se si sovrappongono sullo stesso oggetto, risolvi la relazione prima di scegliere il contenuto. Non ottenere ordine apparente cancellando lavoro valido.
Quando il mandato corrente copre commit e condivisione, controlla il contenuto pertinente, esegui verifiche proporzionate, crea un commit coerente e condividi sul ramo previsto attraverso l'autenticazione del destinatario. Non trasferire la policy di credenziali o di push di un altro ambiente. Se l'effetto non è autorizzato o il mezzo manca, conserva il lavoro e indica il passaggio specifico ancora aperto senza dichiarare la sorgente condivisa.
Dopo la condivisione, verifica la revisione remota e la relazione con il risultato locale e il tracking. Se una riconciliazione produce identità diverse, spiega quali commit o contenuti corrispondono e quali restano distinti. Dai al collaboratore un riferimento esatto con ragioni e controlli rilevanti. Una sorgente raggiungibile non prova che sia stata letta, installata o eseguita. Deploy, release e attivazione richiedono il loro riscontro.
Conserva nella guida del progetto il cambiamento utile, il perché, la revisione, le verifiche e l'eventuale lavoro rimasto locale. Se un nuovo caso espone una perdita o una procedura superflua, correggi il metodo di continuità. Il suo scopo è rendere il lavoro condivisibile e ricostruibile, non creare un rituale di Git o mantenere tutti i repository dell'ambiente sincronizzati per forza.
I casi illustrano situazioni, differenze causali e scelte da adattare al proprio lavoro.
I tre casi sono illustrativi: mostrano come il metodo cambia il lavoro. Non sono dichiarazioni di risultati verificati in installazioni esterne.
Due persone lavorano sullo stesso checkout. La competenza identifica il cambiamento selezionato e condivide solo quello, lasciando il contributo dell'altra persona intatto. La pulizia complessiva del checkout non è l'obiettivo.
Per provarlo, fornisci le fonti pertinenti del tuo caso e chiedi all'AI di applicare il metodo, conservando ciò che è osservato e ciò che resta da capire.
Un commit locale e uno remoto modificano oggetti indipendenti. Ricostruisci le linee, integra nel metodo previsto dal progetto e verifica il risultato condiviso. Non usare la divergenza come motivo per eliminare una delle due linee.
Per provarlo, fornisci le fonti pertinenti del tuo caso e chiedi all'AI di applicare il metodo, conservando ciò che è osservato e ciò che resta da capire.
Un assistente consegna una revisione precisa e una breve ragione del cambiamento. Il collega può leggere quella sorgente e continuare. La consegna non afferma che la revisione sia già distribuita al sito o attiva nel runtime.
Per provarlo, fornisci le fonti pertinenti del tuo caso e chiedi all'AI di applicare il metodo, conservando ciò che è osservato e ciò che resta da capire.
Un caso successivo mostra se il lavoro arriva alla sorgente condivisa senza perdita e senza dover ricostruire la situazione. Un controllo tecnico resta legato alla revisione che ha effettivamente verificato.
Comprende lo stato del repository selezionato e porta avanti le modifiche pertinenti preservando lavoro concorrente e identità della revisione condivisa.
Identifica checkout proprietario, branch, percorsi selezionati, modifiche locali, upstream e identità remota reale. Il contenitore di lavoro può avere repository indipendenti. Non attribuire ogni file sporco alla task. Conserva corsie concorrenti e lavoro già staged; prepara soltanto il contributo selezionato. Il tracking è osservazione memorizzata finché non aggiornato con il meccanismo credenziali autorizzato.
Se locale e remoto sono cambiati indipendentemente, comprendi sovrapposizioni pertinenti e conserva entrambi i contributi validi. Usa l'integrazione minima che continua il lavoro; reset o sincronizzazione forzata possono cancellare sapere estraneo. Prima di condividere rivedi diff selezionato e controlli pertinenti. Commit e push seguono autorità e policy credenziali esistenti, senza stampare o conservare segreti.
Verifica ciò che contiene il remoto effettivo e distingui condivisione sorgente da installazione, deploy e comportamento pubblico. In alcuni progetti il push attiva un deploy separato: comprendi la relazione prima di invocarlo. Conserva identità condivisa e condizione di recupero se servono al seguito. Un checkout pulito non stabilisce correttezza del prodotto e i soli conteggi ahead/behind non decidono quale significato prevale.
Condividere il lavoro AI tra repository e collaboratori
Mantiene riconoscibile la relazione tra modifiche locali, commit e sorgente condivisa.
Comprende lo stato del repository selezionato e porta avanti le modifiche pertinenti preservando lavoro concorrente e identità della revisione condivisa.
Usa questa competenza: quando più assistenti o persone lavorano sullo stesso progetto e il risultato non deve restare nascosto in un checkout locale.
Un lavoro salvato può restare invisibile a chi deve continuarlo. Questa competenza collega il risultato locale alla sorgente condivisa del progetto, mantenendo chiaro che cosa appartiene alla modifica selezionata.
La continuità comprende le ragioni del cambiamento, i contributi concorrenti e la revisione che il collaboratore può davvero leggere. Commit, condivisione e pubblicazione del prodotto restano effetti distinti.
Raggiungi il repository che possiede il lavoro e le sue istruzioni attuali. Comprendi che cosa deve diventare condiviso e perché serve al seguito. Una cartella contenitore può ospitare più repository: non trattarli come un unico oggetto. La continuità diventa pertinente a un risultato significativo o a un passaggio di consegne, non richiede una chiusura Git dopo ogni modifica o una pubblicazione durante una richiesta di sola lettura.
Distingui file di lavoro, commit locali, riferimento di tracciamento, revisione remota verificata e artefatti generati o ignorati. Usa gli strumenti Git e l'accesso previsti dal progetto per vedere ramo, differenze e rapporto con il remoto. Un riferimento locale può essere vecchio; un fetch riuscito non dimostra che il contenuto selezionato sia già condiviso. Evita di stampare o salvare credenziali mentre acquisisci queste informazioni.
Leggi il significato delle modifiche prima di preparare il commit. Seleziona solo i file o le porzioni appartenenti al lavoro autorizzato. Un cambiamento vecchio o non ancora salvato in un commit non è per questo rumore eliminabile. Con contributi locali e remoti indipendenti, integra preservando entrambe le linee; se si sovrappongono sullo stesso oggetto, risolvi la relazione prima di scegliere il contenuto. Non ottenere ordine apparente cancellando lavoro valido.
Quando il mandato corrente copre commit e condivisione, controlla il contenuto pertinente, esegui verifiche proporzionate, crea un commit coerente e condividi sul ramo previsto attraverso l'autenticazione del destinatario. Non trasferire la policy di credenziali o di push di un altro ambiente. Se l'effetto non è autorizzato o il mezzo manca, conserva il lavoro e indica il passaggio specifico ancora aperto senza dichiarare la sorgente condivisa.
Dopo la condivisione, verifica la revisione remota e la relazione con il risultato locale e il tracking. Se una riconciliazione produce identità diverse, spiega quali commit o contenuti corrispondono e quali restano distinti. Dai al collaboratore un riferimento esatto con ragioni e controlli rilevanti. Una sorgente raggiungibile non prova che sia stata letta, installata o eseguita. Deploy, release e attivazione richiedono il loro riscontro.
Conserva nella guida del progetto il cambiamento utile, il perché, la revisione, le verifiche e l'eventuale lavoro rimasto locale. Se un nuovo caso espone una perdita o una procedura superflua, correggi il metodo di continuità. Il suo scopo è rendere il lavoro condivisibile e ricostruibile, non creare un rituale di Git o mantenere tutti i repository dell'ambiente sincronizzati per forza.
Questa è una competenza tecnica di continuità sorgente. Il numero di repository o di agenti non le attribuisce automaticamente un livello meta.
Il metodo può diventare oggetto di apprendimento quando un passaggio di consegne mostra che una modifica condivisa non era raggiungibile dal collaboratore. Correggere quell'ingresso cambia il modo di conservare la continuità. È diverso da un processo autonomo che esegue push a intervalli, e non autorizza tale processo.
Un caso successivo mostra se il lavoro arriva alla sorgente condivisa senza perdita e senza dover ricostruire la situazione. Un controllo tecnico resta legato alla revisione che ha effettivamente verificato.
Nel primo uso, parti dal contesto e dalle fonti effettivamente disponibili. Il metodo può essere esercitato in chat; persistenza, strumenti e azioni esterne dipendono dai mezzi e dal mandato del destinatario. Le istruzioni rendono la capacità utilizzabile, mentre il suo comportamento e il suo valore richiedono osservazione nel lavoro reale.
Raggiungi GUIDA_OPERATIVA_IT.md come parte di questo metodo mentre formi il lavoro. Conserva sapere pratico, relazioni decisionali e mezzi della capacità. L'avvio completo include questo sapere e i casi articolati, rendendolo utilizzabile senza fonti private. Conserva l'identità sorgente pubblica e adatta attraverso i mezzi reali del ricevente.
Questa è una competenza tecnica di continuità sorgente. Il numero di repository o di agenti non le attribuisce automaticamente un livello meta.
Il metodo può diventare oggetto di apprendimento quando un passaggio di consegne mostra che una modifica condivisa non era raggiungibile dal collaboratore. Correggere quell'ingresso cambia il modo di conservare la continuità. È diverso da un processo autonomo che esegue push a intervalli, e non autorizza tale processo.
Competenza, meta e autologica: la guida concettuale ↗Un caso successivo mostra se il lavoro arriva alla sorgente condivisa senza perdita e senza dover ricostruire la situazione. Un controllo tecnico resta legato alla revisione che ha effettivamente verificato.
Allega o incolla AVVIO_CHAT_IT.txt, che contiene l'intero metodo, e aggiungi il tuo contesto. L'AI può lavorare nella lingua della conversazione. Conserva il risultato e la guida utile se vuoi riprenderli in una nuova chat.
Rendi leggibile la cartella della competenza e fai leggere SKILL.md prima del lavoro pertinente. Collega fonti e strumenti reali secondo le istruzioni dell'ambiente. Il kit non installa account, memoria o esecuzioni ricorrenti.
Con un kernel esistente, collega il metodo alla competenza o guida che già possiede il lavoro. Senza kernel, applica direttamente le istruzioni e conserva la conoscenza utile nel progetto o in una nota riutilizzabile.
Leggi o copia l’avvio completo italiano e aggiungi il tuo contesto. Il kit comprende il metodo inglese originale e la versione italiana.
