Execute qualquer Skill no Manus
com um clique

Execute qualquer Skill no Manus com um clique

Começar

commit

Estrelas32

Forks0

Atualizado4 de abril de 2026 às 00:17

Commit changes with govctl integration — check work item status, update journal or notes, and run govctl check

Instalação

Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.

Executar no Manus

Fonte

lucifer1004

lucifer1004/typub

Abrir repositório GitHub Ver repositórios do creator

Download

Executar no Manus

Ocupações relacionadasSOC

Baseado na classificação ocupacional SOC

Desenvolvedores de softwareInformática e Matemática·SOC 15-1252

SKILL.md

readonly

name	commit
description	Commit changes with govctl integration — check work item status, update journal or notes, and run govctl check
allowed-tools	Read, Write, Edit, Bash, Glob, Grep, TodoWrite
argument-hint	["optional commit message hint"]

/commit — Commit with Govctl Integration

Commit changes using the project's version control system, with govctl-aware checks.

Outputs: Recorded VCS commit, updated work-item memory when applicable, and a clean post-commit working copy.

WORKFLOW

CRITICAL: Steps MUST be executed in exact order. Do NOT skip ahead.

This is the only workflow that should issue raw jj or git commit commands.
Do not perform RFC/ADR lifecycle verbs here, except work-item journal/notes/tick/move updates that belong to commit bookkeeping.
Implementation-bearing commits should belong to an active work item.
Spec-only governance commits may proceed without a work item only when the diff is limited to governance artifacts, rendered governance docs, embedded skill/agent templates, or related metadata.

Step 1: Detect VCS

Run jj root first. If succeeds, use Jujutsu. If fails, run git rev-parse --git-dir. If succeeds, use Git. If both fail, stop and inform user.

Step 2: Govctl Pre-Commit Checks

Before committing, run govctl checks:

govctl check

If check fails, stop. Show the diagnostics, fix the issue, and rerun govctl check before committing.

Step 3: Work Item Status Check

Check for active work items:

govctl work list pending

If active work item exists:

Determine whether the active work item actually matches this diff.
If the diff is spec-only governance maintenance unrelated to the active work item, the commit may remain work-item-free even while another work item is active.
If the active work item applies, then:
- Ask whether to add a journal entry documenting what was done and what happened
- Ask whether any durable notes should be recorded
- Check whether any acceptance criteria can be ticked:
```
govctl work show <WI-ID>
```
  If criteria match the completed work, suggest ticking them:
```
govctl work tick <WI-ID> acceptance_criteria "<pattern>" -s done
```
If the active work item does not apply and the diff is not spec-only, ask whether to switch to a different work item or create a new one before committing

If no active work item:

If the changes are spec-only governance maintenance, a work item is optional. Typical examples:
- gov/** artifact files
- rendered governance docs under docs/rfc/** or docs/adr/**
- embedded skill or agent templates under .claude/**
- supporting metadata such as CLAUDE.md, build.rs, or src/cmd/new.rs that only wire governance assets
Otherwise, ask whether these changes should be attached to an existing work item or a new one
In the standard govctl workflow, create or activate a work item before committing
If the user explicitly says this commit is outside tracked work, record that exception in your summary

Step 4: Inspect Changes

If Jujutsu:

jj status
jj diff --stat

If Git:

git status
git diff --stat

Step 5: Compose Message

Format (mandatory):

<type>(<area>): <short summary>

<body (optional)>

Type	When to use
`feat`	New feature
`fix`	Bug fix
`refactor`	Code restructuring
`docs`	Documentation
`test`	Tests
`chore`	Maintenance

If $ARGUMENTS provided, use as basis. Otherwise derive from diff.

Step 6: Execute Commit

Jujutsu

Single-line:

jj describe -m "<type>(<area>): <summary>"
jj new

Multi-line:

jj describe --stdin <<'EOF'
<type>(<area>): <short summary>

<body>
EOF
jj new

Git

git add -A
git commit -m "<type>(<area>): <summary>"

Step 7: Post-Commit Work Item Update

After successful commit, if work item exists:

Add journal entry (if user confirmed in Step 3):

govctl work add <WI-ID> journal "Committed <summary>; govctl check passes"
govctl work add <WI-ID> journal --scope <scope> --stdin <<'EOF'
<multi-line progress summary>
EOF

Add notes only when there is a durable constraint, retry rule, or learning to preserve:

govctl work add <WI-ID> notes "Do not retry X; it fails because Y"

Tick acceptance criteria (if applicable)
Check if work item should be marked done:
- All criteria ticked? Suggest: govctl work move <WI-ID> done
- Still in progress? Keep active

QUICK REFERENCE

# Govctl checks
govctl check                    # Validate all artifacts
govctl work list pending        # List active work items
govctl work show <WI-ID>        # Show work item details
govctl work add <WI-ID> journal "Progress update"
govctl work tick <WI-ID> acceptance_criteria "<pattern>" -s done

# VCS commands
jj status                       # Jujutsu
jj diff --stat
git status                      # Git
git diff --stat

COMMON SCENARIOS

Scenario 1: Active Work Item with Progress

1. Detect active WI-XXXX
2. govctl check → passes
3. Confirm the active WI actually matches this diff
4. If yes: ask about journal entry and criterion ticks
5. If no, but diff is spec-only: proceed without attaching the commit to that WI
6. If no and diff is implementation-bearing: switch/create the correct WI first
7. Commit changes
8. Ask: "Mark work item as done?" (if all criteria ticked)

Scenario 2: No Active Work Item

1. No pending work items
2. govctl check → passes
3. Check whether the diff is spec-only governance maintenance
   - If yes: proceed with a spec-only commit and mention no WI was used
   - Otherwise: ask "Which work item should this commit belong to?"
4. If implementation work applies:
   - If existing work applies: activate or use it
   - Otherwise: create WI with `govctl work new --active`
5. Commit changes

Scenario 3: Govctl Check Fails

1. govctl check → fails
2. Show diagnostics
3. Fix the issue
4. Rerun `govctl check`
5. Commit only after it passes

OUTPUT

Report:

Commit subject line
Work item status updates (if any)
govctl check result

BEGIN EXECUTION NOW.

Mais deste repositório

mesmo repositório

adr-writer

lucifer1004/typub

Write effective Architecture Decision Records. Use when: (1) Creating a new ADR, (2) Recording a design decision, (3) User mentions ADR, decision, trade-off, or alternatives

2026-04-0432

discuss

lucifer1004/typub

Facilitate design discussion — research context, clarify requirements, draft RFC/ADR

2026-04-0432

gov

lucifer1004/typub

Execute governed implementation workflow with work items, RFC/ADR checks, phase gates, testing, and closure. Use when: (1) User invokes /gov, (2) A non-trivial change needs work item tracking, (3) Implementation may require RFC/ADR handling

2026-04-0432

guard-writer

lucifer1004/typub

Write well-structured Verification Guards. Use when: (1) Creating a new guard, (2) Editing guard check commands or patterns, (3) User mentions guard, verification, or check

2026-04-0432

migrate

lucifer1004/typub

Adopt govctl in an existing project. Discovers undocumented decisions, backfills ADRs/RFCs, annotates source code. Use when: (1) Project has no governance yet, (2) User mentions migrate, adopt, onboard, or brownfield

2026-04-0432

quick

lucifer1004/typub

Execute the fast path for trivial changes with minimal governance ceremony. Use when: (1) User invokes /quick, (2) Change is doc-only or non-behavioral, (3) No RFC or ADR work is needed

2026-04-0432

name	commit
description	Commit changes with govctl integration — check work item status, update journal or notes, and run govctl check
allowed-tools	Read, Write, Edit, Bash, Glob, Grep, TodoWrite
argument-hint	["optional commit message hint"]

/commit — Commit with Govctl Integration

Commit changes using the project's version control system, with govctl-aware checks.

Outputs: Recorded VCS commit, updated work-item memory when applicable, and a clean post-commit working copy.

WORKFLOW

CRITICAL: Steps MUST be executed in exact order. Do NOT skip ahead.

This is the only workflow that should issue raw jj or git commit commands.
Do not perform RFC/ADR lifecycle verbs here, except work-item journal/notes/tick/move updates that belong to commit bookkeeping.
Implementation-bearing commits should belong to an active work item.
Spec-only governance commits may proceed without a work item only when the diff is limited to governance artifacts, rendered governance docs, embedded skill/agent templates, or related metadata.

Step 1: Detect VCS

Run jj root first. If succeeds, use Jujutsu. If fails, run git rev-parse --git-dir. If succeeds, use Git. If both fail, stop and inform user.

Step 2: Govctl Pre-Commit Checks

Before committing, run govctl checks:

govctl check

If check fails, stop. Show the diagnostics, fix the issue, and rerun govctl check before committing.

Step 3: Work Item Status Check

Check for active work items:

govctl work list pending

If active work item exists:

Determine whether the active work item actually matches this diff.
If the diff is spec-only governance maintenance unrelated to the active work item, the commit may remain work-item-free even while another work item is active.
If the active work item applies, then:
- Ask whether to add a journal entry documenting what was done and what happened
- Ask whether any durable notes should be recorded
- Check whether any acceptance criteria can be ticked:
```
govctl work show <WI-ID>
```
  If criteria match the completed work, suggest ticking them:
```
govctl work tick <WI-ID> acceptance_criteria "<pattern>" -s done
```
If the active work item does not apply and the diff is not spec-only, ask whether to switch to a different work item or create a new one before committing

If no active work item:

If the changes are spec-only governance maintenance, a work item is optional. Typical examples:
- gov/** artifact files
- rendered governance docs under docs/rfc/** or docs/adr/**
- embedded skill or agent templates under .claude/**
- supporting metadata such as CLAUDE.md, build.rs, or src/cmd/new.rs that only wire governance assets
Otherwise, ask whether these changes should be attached to an existing work item or a new one
In the standard govctl workflow, create or activate a work item before committing
If the user explicitly says this commit is outside tracked work, record that exception in your summary

Step 4: Inspect Changes

If Jujutsu:

jj status
jj diff --stat

If Git:

git status
git diff --stat

Step 5: Compose Message

Format (mandatory):

<type>(<area>): <short summary>

<body (optional)>

Type	When to use
`feat`	New feature
`fix`	Bug fix
`refactor`	Code restructuring
`docs`	Documentation
`test`	Tests
`chore`	Maintenance

If $ARGUMENTS provided, use as basis. Otherwise derive from diff.

Step 6: Execute Commit

Jujutsu

Single-line:

jj describe -m "<type>(<area>): <summary>"
jj new

Multi-line:

jj describe --stdin <<'EOF'
<type>(<area>): <short summary>

<body>
EOF
jj new

Git

git add -A
git commit -m "<type>(<area>): <summary>"

Step 7: Post-Commit Work Item Update

After successful commit, if work item exists:

Add journal entry (if user confirmed in Step 3):

govctl work add <WI-ID> journal "Committed <summary>; govctl check passes"
govctl work add <WI-ID> journal --scope <scope> --stdin <<'EOF'
<multi-line progress summary>
EOF

Add notes only when there is a durable constraint, retry rule, or learning to preserve:

govctl work add <WI-ID> notes "Do not retry X; it fails because Y"

Tick acceptance criteria (if applicable)
Check if work item should be marked done:
- All criteria ticked? Suggest: govctl work move <WI-ID> done
- Still in progress? Keep active

QUICK REFERENCE

# Govctl checks
govctl check                    # Validate all artifacts
govctl work list pending        # List active work items
govctl work show <WI-ID>        # Show work item details
govctl work add <WI-ID> journal "Progress update"
govctl work tick <WI-ID> acceptance_criteria "<pattern>" -s done

# VCS commands
jj status                       # Jujutsu
jj diff --stat
git status                      # Git
git diff --stat

COMMON SCENARIOS

Scenario 1: Active Work Item with Progress

1. Detect active WI-XXXX
2. govctl check → passes
3. Confirm the active WI actually matches this diff
4. If yes: ask about journal entry and criterion ticks
5. If no, but diff is spec-only: proceed without attaching the commit to that WI
6. If no and diff is implementation-bearing: switch/create the correct WI first
7. Commit changes
8. Ask: "Mark work item as done?" (if all criteria ticked)

Scenario 2: No Active Work Item

1. No pending work items
2. govctl check → passes
3. Check whether the diff is spec-only governance maintenance
   - If yes: proceed with a spec-only commit and mention no WI was used
   - Otherwise: ask "Which work item should this commit belong to?"
4. If implementation work applies:
   - If existing work applies: activate or use it
   - Otherwise: create WI with `govctl work new --active`
5. Commit changes

Scenario 3: Govctl Check Fails

1. govctl check → fails
2. Show diagnostics
3. Fix the issue
4. Rerun `govctl check`
5. Commit only after it passes

OUTPUT

Report:

Commit subject line
Work item status updates (if any)
govctl check result

BEGIN EXECUTION NOW.