メニュー
Log a proactive discovery that needs attention. Creates a factual record of WHAT was found with classification and a Findings Tracker. Use for analysis discoveries, review findings, or inspection results.
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/fluxforgeai/wrought-plugin --skill findingコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
Produce an adversarially-verified, source-cited, full-stack, interactive HTML decision brief for informed go/no-go sign-off at a human decision boundary. MVP mode: pivot-review. Extends /ux-design; consumes /research and /design; feeds /design on GO.
Deep multi-agent code review with algorithmic complexity analysis, data structure review, paradigm enforcement, and efficiency analysis. Complements /simplify with deeper dimensions.
End session and create all handoff documentation
SOC 職業分類に基づく
SKILL.md を表示中
| name | finding |
| description | Log a proactive discovery that needs attention. Creates a factual record of WHAT was found with classification and a Findings Tracker. Use for analysis discoveries, review findings, or inspection results. |
| disable-model-invocation | false |
| argument-hint | [description] |
| allowed-tools | Read, Grep, Glob, Write |
| effort | high |
| wrought | {"version":"1.0","tools":{"capabilities":["read_file","search_content","find_files","write_file"]},"platforms":{"claude-code":{"allowed-tools":"Read, Grep, Glob, Write","disable-model-invocation":false}},"agent":{"role":"Finding Classifier","expertise":["defect classification","risk assessment","findings tracking"],"non_goals":["fixing issues","investigation","design work"]},"execution":{"default_mode":"react","stop_conditions":["Finding report written to docs/findings/","Findings tracker created or updated","User instructed to stop"]},"output":{"format":"markdown","template":"docs/findings/{YYYY-MM-DD_HHMM}_{name}.md","required_sections":["Finding title","Classification","Evidence","Recommended next step"],"prohibited_content":["speculation","blame"]},"pipeline":{"track":"audit","standalone":true,"prerequisites":[],"produces":["docs/findings/*.md","docs/findings/*_FINDINGS_TRACKER.md"],"suggested_next":["investigate","research","design"]}} |
Trigger: Use /finding {description} to log a proactive discovery -- something found by analysis, review, or inspection that needs attention.
Purpose: Create a factual record of WHAT was found. Not FIX it -- that's for downstream skills.
Examples:
/finding Missing companyId filter in invoice WHERE clauses -- authorization gap/finding Deprecated bcrypt v2.1 in auth service -- known CVE/finding Config drift: staging environment has debug logging enabled in productionThis skill is standalone — it can be invoked at any time without prerequisites. It is a pipeline entry point: it creates the Findings Tracker that downstream skills require.
If this invocation is part of an active workflow, check docs/findings/*_FINDINGS_TRACKER.md
for a relevant tracker and note it for context, but do not enforce stage requirements.
docs/findings/{YYYY-MM-DD_HHMM}_{name}.mddocs/reference/github_projects_sync_protocol.md and follow Protocol ADo NOT proceed with fixes, investigations, or design work -- that is the job of downstream skills.
DO: "WHERE clause in invoices.py:47 filters by user_id but not company_id"
DON'T: "Authorization is broken" or "Security is poor"
| Type | Description | Resolution Branch |
|---|---|---|
| Defect | Known bug found proactively (not via incident) | /investigate then /rca-bugfix |
| Vulnerability | Security issue with known exposure | /investigate then /rca-bugfix |
| Debt | Technical debt requiring remediation | /design {mode} |
| Gap | Missing expected capability or coverage | /design {mode} |
| Drift | Configuration, documentation, or code divergence from intent | /design {mode} or /rca-bugfix |
| Severity | Criteria |
|---|---|
| Critical | Active security exposure, data loss risk, or production breakage imminent |
| High | Significant impact on reliability, security, or core functionality |
| Medium | Moderate impact, workaround exists, not immediately dangerous |
| Low | Minor issue, cosmetic, or optimization opportunity |
See report_template.md for the full finding report template.
Write to: docs/findings/{YYYY-MM-DD_HHMM}_{name}.md
After writing the individual finding report(s), create or update a Findings Tracker. Each group of related findings gets its own named tracker. Multiple trackers can coexist in docs/findings/ — one per investigation, analysis, or problem domain.
Naming convention: docs/findings/{YYYY-MM-DD_HHMM}_{findings_name}_FINDINGS_TRACKER.md
The {findings_name} is a concise snake_case descriptor of what the findings are about.
Examples:
2026-02-02_1639_iterable_extraction_pipeline_FINDINGS_TRACKER.md2026-03-15_0900_auth_authorization_gaps_FINDINGS_TRACKER.md2026-04-01_1400_api_rate_limiting_FINDINGS_TRACKER.mddocs/findings/ for existing *_FINDINGS_TRACKER.md files{findings_name}When in doubt, create a new tracker. It is better to have two focused trackers than one bloated tracker mixing unrelated concerns.
The overview table is always sorted by severity (most critical first): Critical → High → Medium → Low. Within the same severity level, maintain creation order. Finding detail sections in the document follow the same order as the table.
Auto-generate resolution tasks based on the finding's classification:
Defect or Vulnerability (Corrective Route):
- [ ] **FN.1**: Investigate — confirm root cause and scope (→ /investigate → Stage: Investigating)
- [ ] **FN.2**: RCA + fix design (→ /rca-bugfix → Stage: RCA Complete)
- [ ] **FN.3**: Implementation plan (→ /plan → Stage: Planned)
- [ ] **FN.4**: Implement fix (Stage: Implementing → Resolved)
- [ ] **FN.5**: Code review (→ /forge-review → Stage: Reviewed)
- [ ] **FN.6**: Verify fix in production/test (Stage: Verified)
Debt, Gap, or Drift (Design Route):
- [ ] **FN.1**: Design approach (→ /design → Stage: Designing)
- [ ] **FN.2**: Blueprint + implementation prompt (→ /blueprint → Stage: Blueprint Ready)
- [ ] **FN.3**: Implementation plan (→ /plan → Stage: Planned)
- [ ] **FN.4**: Implement changes (Stage: Implementing → Resolved)
- [ ] **FN.5**: Code review (→ /forge-review → Stage: Reviewed)
- [ ] **FN.6**: Verify implementation (Stage: Verified)
The recommended downstream skill for each task should be included inline:
/investigate/rca-bugfix/design tradeoff or /design migrate or /design from-scratchIf the finding report provides enough detail to make tasks more specific (exact file paths, exact code changes), replace the generic tasks with specific ones. The templates above are fallbacks.
Write to: docs/findings/{YYYY-MM-DD_HHMM}_{findings_name}_FINDINGS_TRACKER.md
**{YYYY-MM-DD HH:MM} UTC**
# {Findings Name} — Findings Tracker
**Created**: {YYYY-MM-DD HH:MM} UTC
**Last Updated**: {YYYY-MM-DD HH:MM} UTC
**Origin**: {What triggered these findings, e.g., "Systems analysis of Notification extraction"}
**Session**: {Session number, if known}
**Scope**: {One-line description of what this tracker covers, e.g., "Stripe batch extraction reliability and monitoring"}
---
## Overview
{One sentence describing the scope of tracked findings.}
| # | Finding | Type | Severity | Status | Stage | Report |
|---|---------|------|----------|--------|-------|--------|
| F1 | {Brief title} | {Type} | **{Severity}** | Open | Open | [Report]({relative_path_to_finding_report}) |
**Status legend**: `Open` → `In Progress` → `Resolved` → `Verified`
**Stage legend**: `Open` → `Investigating` / `Designing` → `RCA Complete` / `Blueprint Ready` → `Planned` → `Implementing` → `Reviewed` → `Resolved` → `Verified`
---
## Dependency Map
No dependencies mapped yet. Update as relationships between findings are identified.
---
## F1: {Brief Title} ({Severity} {Type})
**Summary**: {One-line factual summary from the finding report's "What Was Found"}
**Root cause**: {From the finding report's Preliminary Assessment — "Likely cause"}
**Resolution tasks**:
{Auto-generated tasks based on finding type — see Resolution Tasks section above}
**Recommended approach**: {Downstream skill from Classification Taxonomy — e.g., `/rca-bugfix` or `/design tradeoff`}
**Status**: Open
**Stage**: Open
**Resolved in session**: —
**Verified in session**: —
**Notes**: —
**GitHub Issue**: —
**Project Item ID**: —
**Lifecycle**:
| Stage | Timestamp | Session | Artifact |
|-------|-----------|---------|----------|
| Open | {YYYY-MM-DD HH:MM} UTC | {N} | [Finding Report]({relative_path_to_finding_report}) |
---
## Changelog
| Date | Session | Action |
|------|---------|--------|
| {YYYY-MM-DD HH:MM} UTC | {N} | Created tracker. F1 logged ({Severity} {Type}). |
---
## Cross-References
| Document | Description |
|----------|-------------|
| {finding_report_path} | F1 finding report |
When findings are related to an existing *_FINDINGS_TRACKER.md, add them to it:
FN logged ({Severity} {Type})Last Updated timestamp at top of trackerWhen a single /finding invocation produces multiple findings (e.g., from a comprehensive analysis):
Created tracker. F1-FN logged from {source}. (for creation) or FN-FM added from {source}. (for update)Every downstream skill that processes a finding MUST update the Findings Tracker. This ensures the tracker reflects the true state of each finding at all times.
F1, F2, etc.) is the stable identifier used across all skills. Downstream skills accept F{N} as input to identify the findingCorrective Route (Defect / Vulnerability):
Open → Investigating → RCA Complete → Planned → Implementing → Reviewed → Resolved → Verified
/investigate /rca-bugfix /plan (code work) /forge-review session-end session-end
Design Route (Debt / Gap / Drift):
Open → Designing → Blueprint Ready → Planned → Implementing → Reviewed → Resolved → Verified
/design /blueprint /plan (code work) /forge-review session-end session-end
| Stage | Status |
|---|---|
| Open | Open |
| Investigating / Designing | In Progress |
| RCA Complete / Blueprint Ready | In Progress |
| Planned | In Progress |
| Implementing | In Progress |
| Reviewed | In Progress |
| Resolved | Resolved |
| Verified | Verified |
Status is the coarse view (4 states) — preserved for backward compatibility. Stage is the fine-grained view (7 states) — tracks pipeline position.
| Skill | Sets Stage To | Checks Task | Lifecycle Row Artifact |
|---|---|---|---|
/investigate | Investigating | FN.1 | Investigation report |
/rca-bugfix | RCA Complete | FN.2 | RCA + Prompt |
/design | Designing | FN.1 (design route) | Design analysis |
/blueprint | Blueprint Ready | FN.2 (design route) | Blueprint + Prompt |
/plan (via handoff) | Planned | FN.3 | Plan |
| code implementation | Implementing → Resolved | FN.4 | Commit/PR |
/forge-review | Reviewed | FN.5 | Review report |
| verification | Verified | FN.6 | Test/validation |
When a downstream skill processes a tracked finding, it MUST:
Stage column to the new stageStatus column per the Stage ↔ Status mapping[x])| {date} | {session} | FN stage → {Stage}. {Artifact}: {path} |Last Updated timestamp at top of trackerdocs/reference/github_projects_sync_protocol.md, follow Protocol A (Finding Creation) for new findings or Protocol B (Stage Update) for existing ones. If gh fails, warn and continue.After writing the finding report, suggest the next step based on the finding type:
Finding logged: docs/findings/{YYYY-MM-DD_HHMM}_{name}.md
Tracker updated: docs/findings/{YYYY-MM-DD_HHMM}_{findings_name}_FINDINGS_TRACKER.md (FN)
GitHub Projects: {issue_url or "sync skipped"}
Summary: {One-line factual summary}
Type: {Defect | Vulnerability} | Severity: {level}
This is a corrective fix candidate. Recommended next steps:
1. /investigate {tracker_path} (F{N}) -- to confirm scope and impact
2. /rca-bugfix {tracker_path} (F{N}) -- if cause is already clear
Awaiting your instructions.
Finding logged: docs/findings/{YYYY-MM-DD_HHMM}_{name}.md
Tracker updated: docs/findings/{YYYY-MM-DD_HHMM}_{findings_name}_FINDINGS_TRACKER.md (FN)
GitHub Projects: {issue_url or "sync skipped"}
Summary: {One-line factual summary}
Type: {Debt | Gap | Drift} | Severity: {level}
This needs a design decision. Recommended next steps:
1. /design tradeoff F{N} {topic} -- if multiple approaches exist
2. /design migrate F{N} {topic} -- if moving between implementations
3. /design from-scratch F{N} {topic} -- if building a new capability
Awaiting your instructions.
Findings logged:
F1: docs/findings/{YYYY-MM-DD_HHMM}_{name1}.md — {Severity} {Type}
F2: docs/findings/{YYYY-MM-DD_HHMM}_{name2}.md — {Severity} {Type}
...
Tracker: docs/findings/{YYYY-MM-DD_HHMM}_{findings_name}_FINDINGS_TRACKER.md
GitHub Projects: {issue_urls or "sync skipped"}
{For each finding, list its one-line summary and recommended next step}
Awaiting your instructions.
CRITICAL PIPELINE RULE: Suggest ONLY the next pipeline step listed in the handoff above. Do NOT offer to implement. Do NOT offer to skip pipeline steps. Do NOT offer to combine steps.
/investigate or /rca-bugfix/designDo NOT continue. Do NOT add commentary suggesting any pipeline step could be skipped or is unnecessary. Wait for the user to decide how to proceed.