菜单
Use to diagnose problems in the app using looply artifacts (stories, specs, code graph, knowledge graph) as primary source, with deep dive into the codebase as fallback when artifacts are insufficient.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use to list, inspect or manage linked looply sessions from chat. Shows session details and resume commands.
Use to open a new session tab for a feature. Registers the session in session-links.json and provides the resume command for the new tab.
Use to review architecture and design independently. Identifies structural improvements, validates against existing ADRs, and verifies compliance with codebase design principles.
Use to execute structured code review like GitHub and CodeRabbit. Reviews code changes, classifies findings by severity and generates actionable suggestions. Formal delivery gate with approval checklist.
Use to prepare and validate a software release. Includes security, performance, monitoring, rollback and operability checklist. Final delivery gate before production deploy.
Use when a delivery story already exists and needs technical design, implementation, review and release preparation. Do not use before discovery and planning are complete.
| name | looply-problem-evaluator |
| description | Use to diagnose problems in the app using looply artifacts (stories, specs, code graph, knowledge graph) as primary source, with deep dive into the codebase as fallback when artifacts are insufficient. |
Use this skill when the user explicitly invokes $looply-problem-evaluator, asks to run /looply:problem-evaluator, or clearly requests the problem-evaluator workflow.
Workflow phase: diagnosis.
Primary orchestrator: problem-investigator.
Quick usage:
$looply-problem-evaluator <feature-name> <scope-reference> "[problem-description]" "[constraints...]"
Primary references:$looply-problem-evaluator/looply:problem-evaluator and $looply-problem-evaluator depending on host$looply-problem-evaluator <feature-name> <scope-reference> [problem-description] [constraints...]
Example:onlooply refresh-code-context --check to auto-detect and auto-refresh stale code-context and knowledge-graph before starting diagnosis..looply/custom/features/<feature-name>/workflow-status.md before advancing stages..looply/custom.status: empty, status: draft or status: stale, validate it against the local codebase before trusting it..looply/state/code-context.json for module graphs and .looply/state/knowledge-graph.json for database schema and module dependencies. Run looply refresh-code-context if the code graph is missing or stale.codebase-investigation stage is conditional: run it only when looply artifacts (stories, specs, code-context, knowledge-graph) are insufficient to identify the root cause with confidence. If artifact-triage already produced a conclusive root cause, skip directly to diagnosis-report..looply/state/interaction-policy.json, after each stage estimate context consumption against the stage's context_budget hint from execution-hints.codex.json. Track in workflow-status.md (## Session Context). At yellow (70-85%), compact state. At red (>85%), require /looply:resume in a fresh session.The sections below were pre-composed by looply from agent context_slots. Inline sections contain content resolved during install/sync. Reference sections list files the host should read at runtime.
Define the architectural patterns, frameworks and module boundaries that agents must respect when making design and implementation decisions.