deliverable-analysis
Skill2 starsChanged 7 months agoMITView on GitHub
Analyze and decompose any deliverable (documents, specs, presentations, reports, code) into discrete, critique-ready items with structural metadata. Use this skill when parsing work products for Japanese client review preparation, extracting analyzable items, identifying structural gaps, or breaking down deliverables for defense scenario generation. MUST trigger whenever a deliverable needs to be parsed into items for downstream critique.
In this repository10 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- jp-client-defenderSkill
- file-preprocessingSkill
- gap-analysisSkill
- decision-analysisSkill
- jp-client-critiqueSkill
- persuasion-scenariosSkill
- consulting-qaSkill
- html-report-generationSkill
- quality-gateSkill
The file
We split this skill into the rules it gives an agent
9 rules. About 0 are common, 8 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈8
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 52
Missing alternatives: Only one option presented with no comparison
- Distinctive: line 53
Missing risk assessment: No discussion of what could go wrong
- Distinctive: line 55
Missing timeline: No schedule or milestone information
- Distinctive: line 56
Missing ownership: No clear RACI or responsibility assignment
- Distinctive: line 57
Missing precedent: No reference to similar past implementations
- Distinctive: line 58
Missing rollback plan: No discussion of failure recovery
- Distinctive: line 63
Test mutual exclusivity: Does any element fit in 2+ categories?
- Distinctive: line 64
Test collective exhaustiveness: Is there any element that doesn't fit in any category?
- Very specific: line 69
Write structured JSON to {WORKSPACE}/01_analyst_items.json.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Deliverable Analysis Skill
{WORKSPACE}= timestamped run directory provided by the orchestrator (e.g.,_workspace/run_20260404_153000).
Purpose
Decompose any deliverable into a structured inventory of discrete items, each with enough context for independent critique and defense. This is the first step in the Japanese client defense pipeline.
When to Use
- A deliverable needs to be analyzed before critique
- Structural gaps need to be identified
- MECE categorizations need to be validated
- Implicit assumptions need to be surfaced
Methodology
Granularity Principle
Break items to the smallest independently defensible unit. The test: "Could a Japanese client raise a separate criticism about this specific point?" If yes, it's a separate item.
Too coarse: "Section 3: System Architecture" → This contains multiple claims, decisions, and assumptions. Right granularity: "ITEM-007: Choice of microservices over monolith", "ITEM-008: Database selection (PostgreSQL)", "ITEM-009: API authentication method (OAuth2)"
Item Categories
| Category | Description | Example |
claim | Factual assertion | "Response time will be under 200ms" |
decision | Choice made among alternatives | "We selected React over Vue" |
recommendation | Suggested action | "We recommend phased rollout" |
assumption | Stated or implied premise | "User base will grow 20% annually" |
data | Quantitative evidence | "Current system handles 10k requests/sec" |
design | Architectural or design choice | "Event-driven architecture for notifications" |
process | Methodology or workflow | "Agile sprints with 2-week cycles" |
definition | Terminology or scope definition | "Active user = logged in within 30 days" |
Assumption Surfacing
For every item, answer these questions:
- What must be true for this item to be valid?
- What external factors does this depend on?
- What technical constraints are assumed?
- What business rules are implied but not stated?
These surfaced assumptions become their own items with category assumption.
Gap Detection Patterns
Common gaps Japanese banking clients notice:
- Missing alternatives: Only one option presented with no comparison
- Missing risk assessment: No discussion of what could go wrong
- Missing quantification: Qualitative claims without numbers
- Missing timeline: No schedule or milestone information
- Missing ownership: No clear RACI or responsibility assignment
- Missing precedent: No reference to similar past implementations
- Missing rollback plan: No discussion of failure recovery
MECE Validation
For any categorization found in the deliverable:
- List all categories
- Test mutual exclusivity: Does any element fit in 2+ categories?
- Test collective exhaustiveness: Is there any element that doesn't fit in any category?
- Flag failures with specific overlap/gap description
Output Format
Write structured JSON to {WORKSPACE}/01_analyst_items.json. See the agent definition for the complete schema.
Quality Checklist
- Every item has at least 1 vulnerability hint
- All implicit assumptions surfaced
- Structural gaps include at least 3 critical missing elements
- MECE categorizations tested and results noted
- Items are sequentially and uniquely numbered
- Each item carries enough context to stand alone
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.