golang-pro

Design Community
Interpretation is structured for decision-making; original keeps the upstream SKILL.md unchanged.

Decide Fit First

  • Core job: Implements concurrent Go patterns using goroutines and channels, designs and builds microservices with gRPC or REST, optimizes G…
  • Best fit: Use it when the task has reusable inputs, steps, and validation criteria rather than a one-off answer.
  • Avoid forcing it: If the source lacks commands, platform support, or external-service evidence, keep those fields unknown instead of guessing.

Design Intent

  • Structure: The skill is organized around “Guardrails”, “Core Workflow”, “Reference Guide”, “Core Pattern Example”, showing how the author expects the agent to judge fit, collect context, and produce verifiable output.
  • Trigger evidence: Prioritize the author’s wording around when to use it, what context to collect, and what output shape to produce.
  • Evidence boundary: Author text states facts, repository files prove commands and paths, and Fluxly only adds fit, limits, and usage judgment.

How To Use It

  • Inputs: Provide target material, scope, expected result, forbidden changes, and validation method.
  • Invocation: Name golang-pro directly; if the source includes slash commands, start with the command and then add task context.
  • Validation: Start small and check whether the result follows “Guardrails / Core Workflow / Reference Guide” before expanding.

Boundaries And Review

  • Dependencies: It usually needs no extra API key, so start with a small validation task.
  • Permissions: Declared permissions include read / write / env-read; ask the agent to state file, command, and rollback boundaries before acting.
  • Quality bar: A useful result names the deliverable, evidence, and next action. Generic prose means the task needs tighter context.
Fluxly profile Author and license come from source; runtime, permissions, and network are Fluxly detections or estimates
Fluxly category
Design
Author-declared agents
No explicit declaration found; this is not inferred or tested compatibility
Static check
88 / 100 · heuristic scan, not runtime safety proof
Author / version / license
@tomevault-io · no license declared
Fluxly token estimate
Lean
Fluxly setup estimate
Plug-and-play
External API key
No requirement detected
Detected OS requirements
macOS · Linux · Windows
Runtime requirements
Unspecified
Detected file/system behavior
  • Read-only
  • Write / modify
  • Env read
Detected network behavior
Local-only
Install commands
None (reference only)

Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.

Heads up: 未限定 allowed-tools,默认拥有全部工具权限。

Output preview golang-pro.preview
# Core Pattern Example

// worker runs until ctx is cancelled or an error occurs.
// Errors are returned via the errCh channel; the caller must drain it.
func worker(ctx context.Context, jobs <-chan Job, errCh chan<- error) {
    for {
        select {
        case <-ctx.Done():
            errCh <- fmt.Errorf("worker cancelled: %w", ctx.Err())
            return
        case job, ok := <-jobs:
            if !ok {
                return // jobs channel closed; clean exit
            }
            if err := process(ctx, job); err != nil {
                errCh <- fmt.Errorf("process job %v: %w", job.ID, err)
                return
            }
        }
    }
}

func runPipeline(ctx context.Context, jobs []Job) error {
    ctx, cancel := context.WithTimeout(ctx, 30*time.Second)
    defer cancel()

    jobCh := make(chan Job, len(jobs))
    errCh := make(chan error, 1)

    go worker(ctx, jobCh, errCh)

    for _, j := range jobs {
        jobCh <- j
    }
    close(jobCh)

    select {
    case err := <-errCh:
        return err
    case <-ctx.Done():
        return fmt.Errorf("pipeline timed out: %w", ctx.Err())
    }
}

Discussion

Powered by GitHub Discussions. Sign in with GitHub to comment, react, or subscribe.