Add agentic workflow repo-assist

[dsyme]

Add agentic workflow repo-assist

[Copilot]

Pull request overview

Adds the “repo-assist” agentic workflow to the repository and extends the interactive add wizard to detect scheduled workflows and offer a schedule-frequency selection step, plus adjusts PR-creation scripting around workflow context and permission-error handling.

Changes:

• Add new repo-assist workflow source (.md) and compiled lock workflow (.lock.yml).
• Add interactive schedule detection/classification, option building, and a new schedule selection step in the add wizard (with unit tests).
• Update create_pull_request.cjs to guard context access and adjust run URL construction and permission-error handling.

Reviewed changes

Copilot reviewed 5 out of 6 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
pkg/cli/add_interactive_schedule.go	Implements schedule detection/classification and an interactive prompt to adjust frequency before creating the PR.
pkg/cli/add_interactive_schedule_test.go	Adds unit tests for schedule detection/classification and option ordering/labels.
pkg/cli/add_interactive_orchestrator.go	Invokes schedule-frequency selection as a new step in the interactive add flow.
actions/setup/js/create_pull_request.cjs	Updates context guarding and changes permission-error behavior / footer URL construction.
.github/workflows/repo-assist.md	Introduces the repo-assist workflow definition (frontmatter + instructions).
.github/workflows/repo-assist.lock.yml	Adds the compiled workflow output (generated).

Comments suppressed due to low confidence (1)

pkg/cli/add_interactive_schedule.go:103

• detectWorkflowScheduleInfo treats any non-empty schedule: array as updatable but only reads the first entry. For workflows with multiple schedule entries, the wizard would classify based on the first item and later updates would likely collapse/overwrite the rest. Safer behavior would be to mark multi-entry schedule arrays as not updatable (or explicitly handle updating all entries consistently).

		// Schedule as array (e.g., "schedule:\n  - cron: daily")
		if schedArray, ok := schedValue.([]any); ok && len(schedArray) > 0 {
			if item, ok := schedArray[0].(map[string]any); ok {
				if cronVal, ok := item["cron"].(string); ok {
					return scheduleDetection{
						RawExpr:        cronVal,

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The workflow description says it “runs daily”, but the configured schedule is every 1h (hourly). Please align the description with the actual schedule (or adjust the schedule) to avoid misleading users.

[Copilot]

There are good unit tests for frequency classification/detection, but there’s no test that exercises the actual frontmatter update behavior in selectScheduleFrequency() (especially for on: maps with schedule + workflow_dispatch and multi-trigger cases). Adding a test that asserts the wizard updates on.schedule without introducing a top-level schedule: field (and without dropping other triggers) would prevent regressions.

[Copilot]

When the workflow uses an on: map, the schedule is nested under on.schedule. Updating with UpdateFieldInFrontmatter(..., "schedule", ...) writes/overwrites a top-level schedule: field instead of on.schedule, leaving the actual trigger unchanged and potentially producing invalid/unknown frontmatter. Also, updating the entire on field to a scalar schedule expression will drop workflow_dispatch (and any other triggers) for map-based workflows. Consider always updating the nested field (e.g., via the existing SetFieldInOnTrigger helper) when on is a map, regardless of whether it is “multi-trigger”.

This issue also appears on line 98 of the same file.

Suggested change

	// For multi-trigger on: maps, update the "schedule" sub-field to preserve other triggers.
	// For simple on: strings, update the "on" field directly.
	updateField := "on"
	if detection.IsMultiTrigger {
	updateField = "schedule"
	}
	updatedContent, err := UpdateFieldInFrontmatter(content, updateField, newExpr)
	if err != nil {
	scheduleWizardLog.Printf("Failed to update schedule (field=%s): %v", updateField, err)
	// For multi-trigger on: maps, update the "schedule" sub-field under "on" to preserve other triggers.
	// For simple on: strings, update the "on" field directly.
	var updatedContent string
	if detection.IsMultiTrigger {
	// When "on" is a map (multi-trigger), update the nested on.schedule field.
	updatedContent, err = SetFieldInOnTrigger(content, "schedule", newExpr)
	} else {
	// When "on" is a scalar schedule expression, update the "on" field itself.
	updatedContent, err = UpdateFieldInFrontmatter(content, "on", newExpr)
	}
	if err != nil {
	scheduleWizardLog.Printf("Failed to update schedule: %v", err)

[Copilot]

This permission-error path sets a step output (core.setOutput("error_message", ...)) but the workflow’s conclusion step (handle_create_pr_error.cjs) looks for CREATE_PR_ERROR_MESSAGE and the generated workflow doesn’t pass this output through, so the permission issue will be silently skipped now that the fallback issue creation block was removed. Either keep the previous fallback issue behavior here, or plumb the error message through the safe-outputs job outputs/env so the conclusion job can act on it.