원클릭으로 Manus에서 모든 스킬 실행

$pwd:

fetch-ci-build

Name: Fetch Ci Build
Author: Dicklesworthstone

// Fetch CI build results and diagnose failures. Auto-detects provider from project files or URLs. Supports GitHub Actions, Buildkite, and CircleCI.

Manus에서 실행

$ git log --oneline --stat

stars:1,089

forks:132

updated:2026년 2월 5일 06:56

파일 탐색기

6 개 파일

SKILL.md

readonly

name	fetch-ci-build
description	Fetch CI build results and diagnose failures. Auto-detects provider from project files or URLs. Supports GitHub Actions, Buildkite, and CircleCI.

Fetch CI Build

Overview

Fetch CI build results, diagnose failures, extract actionable error information, and suggest fixes. Supports multiple CI providers with automatic detection.

Supported Providers

Provider	Detection	Tool
GitHub Actions	`.github/workflows/` or `github.com` URL	`gh` CLI
Buildkite	`.buildkite/` or `buildkite.com` URL	Python script
CircleCI	`.circleci/` or `circleci.com` URL	Python script

Auto-Detection

From URL

If the user provides a CI URL, detect provider:

github.com/.../actions/runs/... → GitHub Actions
buildkite.com/... → Buildkite
app.circleci.com/... or circleci.com/... → CircleCI

From Project Files

Check for CI configuration directories:

# GitHub Actions
test -d .github/workflows && echo "github"

# Buildkite
test -d .buildkite && echo "buildkite"

# CircleCI
test -d .circleci && echo "circleci"

Workflow

digraph workflow {
    rankdir=TB;
    node [shape=box];
    
    detect [label="1. Detect CI provider"];
    load [label="2. Load provider reference"];
    fetch [label="3. Fetch build results"];
    check [label="4. Check for failures" shape=diamond];
    passed [label="Report: Build passed!"];
    read [label="5. Read failing source files"];
    present [label="6. Present failures + proposed fixes"];
    ask [label="7. Ask: Apply fix?" shape=diamond];
    apply [label="Apply the fix"];
    complex [label="Complex failure?" shape=diamond];
    debug [label="Use systematic-debugging skill"];
    next [label="Next failure?" shape=diamond];
    done [label="Done"];
    
    detect -> load;
    load -> fetch;
    fetch -> check;
    check -> passed [label="passed"];
    check -> read [label="failed"];
    read -> present;
    present -> ask;
    ask -> apply [label="yes"];
    ask -> complex [label="no"];
    apply -> next;
    complex -> debug [label="yes"];
    complex -> next [label="no"];
    debug -> next;
    next -> read [label="yes"];
    next -> done [label="no"];
}

Step-by-Step Process

1. Detect CI Provider

First, check if the user provided a URL. If not, detect from project files.

2. Load Provider Reference

Read the appropriate reference file for provider-specific commands:

3. Fetch Build Results

Use the provider-specific commands to fetch build information and failures.

4. For Each Failure

Read the relevant source file to understand context:

For test failures: read the test file at the indicated line
For lint errors: read the source file at the indicated line
For TypeScript errors: read the file and understand the type issue

5. Present Findings and Propose Fix

Show the user:

What failed (test name, file, line)
Error message
Proposed fix based on the error

6. Ask User What To Do

Ask how to proceed:

"Apply the suggested fix"
"Investigate further before fixing"
"Skip this failure"
"Use systematic-debugging for deeper investigation"

7. Complex Failures

If the failure requires deeper investigation (e.g., unclear root cause, flaky test, environmental issue), recommend the systematic-debugging skill.

Error Types Detected

Type	Detection	Common Fixes
Test failure	Minitest/RSpec/Jest/pytest output	Fix assertion, update expected value, fix test setup
Lint error	Rubocop/ESLint/Biome violations	Auto-fix with linter's fix command
TypeScript	TSC compilation errors	Add types, fix type mismatches
Build error	Compilation failures	Fix syntax, missing dependencies

Common Mistakes

Mistake	Solution
Can't detect provider	Specify provider explicitly or provide CI URL
Missing credentials	Check provider reference for required env vars/auth
Build still running	Wait for completion or check partial results
Rate limiting	Wait and retry

Integration with Other Skills

systematic-debugging: Use for complex failures requiring root cause analysis
test-driven-development: After fixing, ensure tests follow TDD principles
verification-before-completion: Run tests locally before pushing fix

related-skills.json

같은 저장소

skill-creator.md

from "Dicklesworthstone/pi_agent_rust"

Create or update Pi skills (SKILL.md plus optional scripts, references, or assets). Use when someone asks to design a new Pi skill, refine an existing one, or structure skills for Pi discovery or packaging.

2026-02-061.1k

extending-pi.md

from "Dicklesworthstone/pi_agent_rust"

Guide for extending Pi — decide between skills, extensions, prompt templates, themes, context files, or custom models, then create and package them. Use when someone wants to extend Pi, add capabilities, create a skill, build an extension, or make a Pi package.

2026-02-061.1k

ralph-wiggum.md

from "Dicklesworthstone/pi_agent_rust"

Long-running iterative development loops with pacing control and verifiable progress. Use when tasks require multiple iterations, many discrete steps, or periodic reflection with clear checkpoints; avoid for simple one-shot tasks or quick fixes.

2026-02-061.1k

interactive-shell.md

from "Dicklesworthstone/pi_agent_rust"

Cheat sheet + workflow for launching interactive coding-agent CLIs (Claude Code, Gemini CLI, Codex CLI, Cursor CLI, and pi itself) via the interactive_shell overlay or headless dispatch. Use for TUI agents and long-running processes that need supervision, fire-and-forget delegation, or headless background execution. Regular bash commands should use the bash tool instead.

2026-02-061.1k

ask-questions-if-underspecified.md

from "Dicklesworthstone/pi_agent_rust"

Clarify requirements before implementing. Do not use automatically, only when invoked explicitly.

2026-02-051.1k

brave-search.md

from "Dicklesworthstone/pi_agent_rust"

Web search and content extraction via Brave Search API. Use for searching documentation, facts, or any web content. Lightweight, no browser required.

2026-02-051.1k

package.json

"author": "Dicklesworthstone"

"repository": "Dicklesworthstone/pi_agent_rust"

GitHub 저장소 열기 Creator 저장소 보기

$ install --global

$ download --local

Manus에서 실행

$ useful --forSOC

소프트웨어 개발자컴퓨터 및 수학직15-1252L4

name	fetch-ci-build
description	Fetch CI build results and diagnose failures. Auto-detects provider from project files or URLs. Supports GitHub Actions, Buildkite, and CircleCI.

Fetch CI Build

Overview

Fetch CI build results, diagnose failures, extract actionable error information, and suggest fixes. Supports multiple CI providers with automatic detection.

Supported Providers

Provider	Detection	Tool
GitHub Actions	`.github/workflows/` or `github.com` URL	`gh` CLI
Buildkite	`.buildkite/` or `buildkite.com` URL	Python script
CircleCI	`.circleci/` or `circleci.com` URL	Python script

Auto-Detection

From URL

If the user provides a CI URL, detect provider:

github.com/.../actions/runs/... → GitHub Actions
buildkite.com/... → Buildkite
app.circleci.com/... or circleci.com/... → CircleCI

From Project Files

Check for CI configuration directories:

# GitHub Actions
test -d .github/workflows && echo "github"

# Buildkite
test -d .buildkite && echo "buildkite"

# CircleCI
test -d .circleci && echo "circleci"

Workflow

digraph workflow {
    rankdir=TB;
    node [shape=box];
    
    detect [label="1. Detect CI provider"];
    load [label="2. Load provider reference"];
    fetch [label="3. Fetch build results"];
    check [label="4. Check for failures" shape=diamond];
    passed [label="Report: Build passed!"];
    read [label="5. Read failing source files"];
    present [label="6. Present failures + proposed fixes"];
    ask [label="7. Ask: Apply fix?" shape=diamond];
    apply [label="Apply the fix"];
    complex [label="Complex failure?" shape=diamond];
    debug [label="Use systematic-debugging skill"];
    next [label="Next failure?" shape=diamond];
    done [label="Done"];
    
    detect -> load;
    load -> fetch;
    fetch -> check;
    check -> passed [label="passed"];
    check -> read [label="failed"];
    read -> present;
    present -> ask;
    ask -> apply [label="yes"];
    ask -> complex [label="no"];
    apply -> next;
    complex -> debug [label="yes"];
    complex -> next [label="no"];
    debug -> next;
    next -> read [label="yes"];
    next -> done [label="no"];
}

Step-by-Step Process

1. Detect CI Provider

First, check if the user provided a URL. If not, detect from project files.

2. Load Provider Reference

Read the appropriate reference file for provider-specific commands:

3. Fetch Build Results

Use the provider-specific commands to fetch build information and failures.

4. For Each Failure

Read the relevant source file to understand context:

For test failures: read the test file at the indicated line
For lint errors: read the source file at the indicated line
For TypeScript errors: read the file and understand the type issue

5. Present Findings and Propose Fix

Show the user:

What failed (test name, file, line)
Error message
Proposed fix based on the error

6. Ask User What To Do

Ask how to proceed:

"Apply the suggested fix"
"Investigate further before fixing"
"Skip this failure"
"Use systematic-debugging for deeper investigation"

7. Complex Failures

If the failure requires deeper investigation (e.g., unclear root cause, flaky test, environmental issue), recommend the systematic-debugging skill.

Error Types Detected

Type	Detection	Common Fixes
Test failure	Minitest/RSpec/Jest/pytest output	Fix assertion, update expected value, fix test setup
Lint error	Rubocop/ESLint/Biome violations	Auto-fix with linter's fix command
TypeScript	TSC compilation errors	Add types, fix type mismatches
Build error	Compilation failures	Fix syntax, missing dependencies

Common Mistakes

Mistake	Solution
Can't detect provider	Specify provider explicitly or provide CI URL
Missing credentials	Check provider reference for required env vars/auth
Build still running	Wait for completion or check partial results
Rate limiting	Wait and retry

Integration with Other Skills

systematic-debugging: Use for complex failures requiring root cause analysis
test-driven-development: After fixing, ensure tests follow TDD principles
verification-before-completion: Run tests locally before pushing fix

fetch-ci-build

Fetch CI Build

Overview

Supported Providers

Auto-Detection

From URL

From Project Files

Workflow

Step-by-Step Process

1. Detect CI Provider

2. Load Provider Reference

3. Fetch Build Results

4. For Each Failure

5. Present Findings and Propose Fix

6. Ask User What To Do

7. Complex Failures

Error Types Detected

Common Mistakes

Integration with Other Skills

이 저장소의 다른 Skills

이 저장소의 다른 Skills

Fetch CI Build

Overview

Supported Providers

Auto-Detection

From URL

From Project Files

Workflow

Step-by-Step Process

1. Detect CI Provider

2. Load Provider Reference

3. Fetch Build Results

4. For Each Failure

5. Present Findings and Propose Fix

6. Ask User What To Do

7. Complex Failures

Error Types Detected

Common Mistakes

Integration with Other Skills