| name | lgs-1920-studio-github-issues |
| description | Manage LGS1920 GitHub issues and Project planning, including triage, issue templates, workflow status, target releases, milestone migration, project views, and issue-to-pull-request tracking. Use when creating, reviewing, triaging, updating, or planning issues in the LGS1920 organization Project. |
GitHub Issues and Project Workflow
Use this skill to keep issue metadata, the organization Project, branches, pull
requests, and releases aligned with the GitHub Project release and branch
workflow specification.
Scope and source of truth
- Work in the LGS1920 organization Project used by the repository
lgs1920/studio and related repositories.
- Keep one shared Project across releases. Do not create a Project per version.
- Use the Project
Status field for delivery workflow only.
- Use the Project
Target release field as the cross-repository source of truth
for version planning.
- Keep issue and Project documentation in English, as required by the
repository rules.
- Read
PROJECT_RULES.md before creating or changing issues, and preserve
unrelated working-tree changes.
Create or update an issue
- Clarify the request and ask for missing information before creating an issue.
- Prepare the complete proposed issue and obtain explicit user validation before
creating it. Do not create an issue from an unvalidated draft.
- Select the repository template:
.github/ISSUE_TEMPLATE/bug_report.md for a bug or regression.github/ISSUE_TEMPLATE/feature_request.md for a feature or improvement
- Preserve the hidden issue-type marker in the template body:
<!-- issue-type: bug --> or <!-- issue-type: feature -->.
- Write an English title and body with context, requested behavior, observable
acceptance criteria, and technical notes. For bugs, include reproducible
actions, expected result, actual result, and reproducibility.
- Add the issue to the organization Project before editing Project fields.
- Set only fields that are known or explicitly requested: repository, assignee,
labels, issue type, priority, target release, milestone, and status.
- Re-read the issue and Project item after each mutation and report the final
values.
Project fields
Use these workflow statuses and meanings:
Triage: new work needing clarification, ownership, or prioritizationBacklog: accepted work that is not ready to startReady: scoped work with acceptance criteria and a target releaseIn Progress: active implementationReview: a pull request is openQA: automated or manual validation is in progressBlocked: an explicit dependency or decision prevents progressDone: the linked pull request is merged and the work is complete
Use these Target release options when available:
Unplanned1.0.0-beta.41.1.01.2.01.3.0
Add a new release option only after the release has been approved. Do not encode
versions in labels or statuses when Target release already contains them.
Treat Milestone as repository-level historical metadata during the migration:
- Do not require a milestone for a new issue when
Target release is known.
- For an issue with a milestone, copy the exact milestone title to the matching
Target release option when one exists.
- If there is no approved matching option, use
Unplanned and report the
mismatch rather than inventing a release value.
- Do not clear or delete milestones automatically. Keep them until the
migration has been reviewed and dependent reporting has been checked.
- Do not overwrite an existing explicit
Target release without comparing both
values and reporting the conflict first.
Issue and pull request lifecycle
- Start a new issue in
Triage with context, requested behavior, and
acceptance criteria.
- Complete ownership, labels, priority, repository, and
Target release during
triage. Use Target release: Unplanned for accepted work without a release
commitment.
- Move accepted unscheduled work to
Backlog.
- Move scoped work with testable acceptance criteria and a release target to
Ready.
- Use one short-lived branch per issue or deliberately grouped set of issues.
- Link the pull request to the issue and move the Project item to
Review.
- Move the item to
QA after review approval while validation runs.
- Move the item to
Done only after the pull request is merged and the release
or deployment consequence is known.
Use these branch patterns:
feature/issue-<number>-<slug> for new functionalityfix/issue-<number>-<slug> for bugs and regressionsdocs/issue-<number>-<slug> for documentation-only changeschore/issue-<number>-<slug> for maintenancerelease/<version> for temporary release stabilizationhotfix/<version>-<slug> for urgent fixes from a released version
Create feature, fix, documentation, and maintenance branches from main.
Reserve release branches for stabilization and merge them back into main.
Project views
Preserve the stable operational views and their intent:
Inbox / Triage: Status: TriageProduct backlog: Status: BacklogDelivery flow: all items except Done, grouped by workflow statusCurrent release - 1.0.0-beta.4: current release items except DoneNext release - 1.1.0: next release items except DoneRoadmap: planned items for 1.1.0, 1.2.0, and 1.3.0QA / Release: items with Status: Review or Status: QA
Include unfinished triage and backlog items in the relevant release views. Do
not delete or rename historical views without explicit approval and a verified
replacement.
Safe mutations and verification
- Inspect the current issue, Project item, fields, views, and existing values
before writing.
- Use the connected GitHub integration for issue and pull request data. Use
gh or the available Project API for Project v2 fields and views when the
connector does not expose them.
- Batch Project item mutations in small groups. Keep batches at 20 items or
fewer to avoid Project GraphQL resource limits encountered in practice.
- Before a bulk migration, state the deterministic mapping and its scope. Stop
on missing release options or conflicting explicit values.
- Never delete issues, Project items, views, tags, branches, or milestones as
part of routine triage.
- Do not commit or push repository changes unless the user explicitly asks.
- After mutations, re-read the affected items and report counts, skipped items,
conflicts, and remaining legacy metadata.
