메뉴
Triage a failing pre-commit hook (skylos or fallow). For each finding, look up the rule in the day-1 playbook and present three options — fix in code, suppress with a required
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use to create or update the per-author Ghost style guide from all available signals — interview answers, reference docs, and the published corpus — and to fold a newly approved post into it. Triggers on "build my style guide", "update the style guide", "learn my voice from my posts", and is invoked by push-draft after a successful push.
Use to write the first full draft of a Ghost blog post locally, matching the author's style guide, then self-audit it against the anti-pattern checklist. Triggers on "draft a post about X", "write the first draft", "start a new blog post".
Use to revise an existing local Ghost draft section by section with the author, improving formatting, voice, and accuracy. Triggers on "revise this post", "let's go through it section by section", "tighten this draft".
Use when first connecting a project to a Ghost site for the ghost plugin, or whenever Ghost credentials are missing/unverified — onboards the Ghost Admin API key, enables the plugin at project level, and verifies the connection. Triggers on "set up ghost", "connect my ghost site", "ghost credentials", "the ghost mcp isn't working".
Use to push a finished local Ghost draft to the Ghost site as a draft (never published) — pull-guards against in-editor edits, uploads the feature image, creates or updates the post, verifies links, and feeds the approved post back into the style guide. Triggers on "push this to ghost", "send the draft to ghost", "publish to ghost as a draft".
Use to write a Ghost blog post end to end, walking the full plan→draft→revise→push flow in one guided pass. Triggers on "write a post about X end to end", "take this from idea to a ghost draft", "guide me through writing a post".
| name | quality-unblock |
| description | Triage a failing pre-commit hook (skylos or fallow). For each finding, look up the rule in the day-1 playbook and present three options — fix in code, suppress with a required |
| user-invocable | true |
| allowed-tools | Read, Bash |
You are executing the UNBLOCK workflow — triage failures from skylos or fallow pre-commit hooks. Per the design (v0.2.0 MVP): you produce a structured proposal per finding. The user decides which proposal to apply. This skill does NOT modify code itself — the user (or a follow-up subagent dispatch) applies the chosen fix.
When a pre-commit hook fails, three legitimate responses exist:
# Why: comment explaining why the finding is wrong or why the fix is worse than living with it. Legitimate for false positives, deliberately-coalesced state containers, parameterized SQL the linter mis-flags, etc.The failure mode this plugin was built to prevent: agents reaching for option 2 every time because it's the cheapest path through the gate. Suppression is a last resort. This skill enforces that by requiring a defensible # Why: on every suppress action and capping suppressions per session.
$ARGUMENTS is one of:
skylos agent pre-commit --format json or fallow audit --format json--from-clipboard — explicitly read from clipboardIf the user pasted the failure output:
{ and a "findings"/"quality"/"danger" array).If the user said "run the hook for me":
PLUGIN_ROOT="${CLAUDE_PLUGIN_ROOT}"
python3 -c "
import sys
sys.path.insert(0, '$PLUGIN_ROOT/skills/shared/lib')
from pathlib import Path
from skylos_adapter import run_agent_pre_commit
findings = run_agent_pre_commit(Path('.').resolve())
import json
print(json.dumps([f.to_dict() for f in findings], indent=2))
"
If there are no findings, tell the user the hook isn't currently failing and stop.
PLUGIN_ROOT="${CLAUDE_PLUGIN_ROOT}"
python3 -c "
import sys
sys.path.insert(0, '$PLUGIN_ROOT/skills/shared/lib')
from pathlib import Path
from playbook import load_default_playbooks
pbs = load_default_playbooks(Path('$PLUGIN_ROOT'))
for tool, pb in pbs.items():
print(f'{tool}: {len(pb.rules)} rules + fallback')
"
For each QualityFinding:
skylos or fallow).resolve_actions(playbook, finding.rule_id).### Finding 1 of 3 — SKY-Q301 (HIGH severity)
File: pi/orchestrator/listener.py:45
Function: process_event
Message: Cyclomatic complexity is 17 (threshold: 10).
Action options:
[a] FIX (refactor)
Suggestion: Extract helper functions for independent branches. Replace nested ifs with early returns.
Agent prompt: "Refactor pi/orchestrator/listener.py:45 (process_event) to reduce cyclomatic complexity..."
[b] SUPPRESS (requires # Why:)
Why template: "Complexity intrinsic to {what} — splitting would scatter {logic} across {N} files."
NOTE: A vague suppression like "complexity" without a real reason will be flagged by impl-review. Write a defensible justification.
[c] DEFER (capture as tech-debt epic)
Title: "Reduce cyclomatic complexity in pi/orchestrator/listener.py"
Use the action's kind to label [a] FIX / [b] SUPPRESS / [c] DEFER. If the playbook only has two actions, only show two options.
After presenting all findings + options, ask the user:
"Which option for each finding? Reply with
1a, 2c, 3bor similar."
If they reply with a b (suppress), prompt for the # Why: text:
"What's the justification for suppressing finding 2? (free-form text; will be added as a
# Why:comment above the suppression directive)"
Refuse to proceed with a bare suppression. If the user types nothing or just complexity, push back:
"That's the failure mode this plugin was built to catch. Either write a real justification (one-sentence explanation of why this finding shouldn't be silenced) or pick FIX or DEFER instead."
For each chosen action, output a structured proposal:
## Proposal — Finding 1 (FIX)
File: pi/orchestrator/listener.py:45
Refactor target: process_event
Suggested approach: Extract helper functions for independent branches.
To apply: dispatch a subagent with this prompt:
> Refactor pi/orchestrator/listener.py:45 (process_event) to reduce cyclomatic
> complexity. Extract helpers for independent branches; flatten guards with
> early returns; preserve behavior. Run the test suite.
## Proposal — Finding 2 (SUPPRESS)
File: pi/orchestrator/state.py:7
Insert above the line:
```python
# Why: State is intentionally one container — splitting scatters mutations
# across the codebase for no maintainability gain.
# skylos: ignore SKY-Q501
To apply: edit the file at the indicated line.
### For DEFER actions:
```markdown
## Proposal — Finding 3 (DEFER)
Capture as a tech-debt epic via `/feature-workflow:feature-capture`:
- Title: Reduce cyclomatic complexity in pi/orchestrator/listener.py
- Type: Tech Debt
- Category: tech-debt
- Body: includes finding details + suggested approach
To apply: invoke `/feature-workflow:feature-capture` with the above.
Do not edit any files in this skill. The skill ends with proposals on the screen. The user (or autopilot) applies them in a separate step.
After all proposals are rendered, check how many were SUPPRESS. If more than 2:
⚠️ You're proposing 4 new suppressions in this triage. The plugin's pre-
commit-compat policy caps suppressions at 2 per PR — the autopilot's
impl-review prompt will flag this as a Critical Finding.
Either pick FIX for some of them, or split the work across multiple PRs.
See the suppression-discipline skill for the suppression rules.
This mirrors the impl-review prompt enforcement in feature-workflow v9.8.1.
/quality-verify-hook/quality-auditfrom skylos_adapter import run_agent_pre_commit; ...${CLAUDE_PLUGIN_ROOT}/playbooks/ ship day-1 coverage for ~25 rule_ids across skylos and fallow. Unknown rules fall through to a fallback action set.