initiative/.claude/commands/sync-issue.md

description

description
Update a Gitea issue with business-level acceptance criteria extracted from the feature spec's user stories.

User Input

$ARGUMENTS

You MUST provide an issue number as the argument (e.g. /sync-issue 42). If $ARGUMENTS is empty or not a valid number, ask the user for the issue number.

Prerequisites

1. Verify the GITEA_TOKEN_ISSUES environment variable is set:

test -n "$GITEA_TOKEN_ISSUES" && echo "TOKEN_OK" || echo "TOKEN_MISSING"

If missing, tell the user to set it:

export GITEA_TOKEN_ISSUES="your-gitea-personal-access-token"

Then abort.

2. Parse the git remote to extract the Gitea API base URL, owner, and repo:

git config --get remote.origin.url

Expected format: ssh://git@<host>:<port>/<owner>/<repo>.git or https://<host>/<owner>/<repo>.git

Extract:

• GITEA_HOST — the hostname
• OWNER — the repo owner/org
• REPO — the repo name (strip .git suffix)
• API_BASE — https://<GITEA_HOST>/api/v1

3. Locate the spec file. Run:

.specify/scripts/bash/check-prerequisites.sh --json --paths-only

Parse FEATURE_SPEC from the output. If it fails, ask the user to ensure they're on a feature branch with a spec. For single quotes in args, use escape syntax: e.g 'I'\''m Groot' (or double-quote if possible: "I'm Groot").

Execution

Step 1 — Read the spec

Load the spec file at FEATURE_SPEC. Parse the User Scenarios & Testing section, specifically:

• Each ### User Story N - [Title] block
• The Acceptance Scenarios numbered list within each story (Given/When/Then format)
• The Edge Cases section

Step 2 — Condense into business-level acceptance criteria

For each user story, extract the acceptance scenarios and rewrite them as concise, business-level checkbox items. Group by user story title.

Transformation rules:

• Strip Given/When/Then syntax — write as plain outcomes
• Remove implementation details (API names, database references, component names, file paths, config values, tool names)
• Focus on what the user can do or can see
• Keep each item to one line
• Preserve the grouping by user story for readability

Example transformation:

Input (from spec):

**Given** no sources are cached, **When** the user clicks the import button in the top bar,
**Then** the stat block side panel opens showing a descriptive explanation, an editable
pre-filled base URL, and a "Load All" button.

Output (for issue):

- [ ] Clicking the import button opens a panel with a description, editable URL, and "Load All" button

Also include edge cases as a separate group if they describe user-facing behavior.

Step 3 — Fetch the existing issue

curl -sf -H "Authorization: token $GITEA_TOKEN_ISSUES" "$API_BASE/repos/$OWNER/$REPO/issues/<NUMBER>"

Extract the current body from the response.

Step 4 — Update the issue body

Merge the acceptance criteria into the existing issue body:

• If the body already has an ## Acceptance Criteria section, replace its contents (everything between ## Acceptance Criteria and the next ## heading or end of body).
• If the body does not have an ## Acceptance Criteria section, insert it after the ## Summary section (or at the end if no Summary exists).

Preserve all other sections of the issue body unchanged.

The acceptance criteria section should look like:

## Acceptance Criteria

### <User Story 1 Title>
- [ ] <criterion from acceptance scenario>
- [ ] <criterion from acceptance scenario>

### <User Story 2 Title>
- [ ] <criterion from acceptance scenario>

### Edge Cases
- [ ] <edge case behavior>

Step 5 — Preview and confirm

Show the user:

• The full updated issue body
• A diff summary of what changed (sections added/replaced)

Ask for confirmation before updating.

Step 6 — Push the update

On confirmation:

curl -sf -X PATCH \
  -H "Authorization: token $GITEA_TOKEN_ISSUES" \
  -H "Content-Type: application/json" \
  "$API_BASE/repos/$OWNER/$REPO/issues/<NUMBER>" \
  -d @- <<'PAYLOAD'
{
  "body": "<updated body>"
}
PAYLOAD

Report success with the issue URL.

Behavior Rules

• Never modify the issue title, labels, milestone, or assignees — only the body.
• Always preview before updating — never push without user confirmation.
• If the spec has no user stories or acceptance scenarios, abort with a clear message suggesting the user run /speckit.specify first.
• Acceptance criteria must be business-level. If you find yourself writing implementation details, rewrite at a higher level of abstraction.
• Use curl for all API calls — do not rely on gh CLI.
• Always use HEREDOC for the JSON payload to handle special characters in the body.
• Escape double quotes and newlines properly in the JSON body.