Review the content provided by the user from a context engineering perspective, automatically identify the content type and select the most relevant review dimensions, and output a structured review report.
Workflow
Step 0: Obtain the review target
Determine the input type of $ARGUMENTS :
- File path：
$ARGUMENTSlooks like a file path (containing/or.extension) → use Read to read the file - Glob pattern：
$ARGUMENTScontains wildcards (*、**) → use Glob to expand and then read one by one (limit 5 files; if exceeded, prioritize entry files and core modules) - Direct content：
$ARGUMENTSis a piece of code or text → use directly as the review content - Empty argument：
$ARGUMENTSis empty → ask the user to provide a file path or paste content
For multi-file input, first use Read to read each file and merge them into the review content. If the total volume is too large (>500 lines), use Grep to scan key features to assist determination, and prioritize in-depth review of core files.
Step 1: Identify the content type
Read the identification rules in references/content-type-rules.md .
Based on the file extension, file name, content keywords, and structural features, determine which of the following types the content belongs to:
- Prompt type — AI behavior instructions, system prompts, role definitions
- Agent code type — code implementations using LLM frameworks
- Architecture document type — system architecture, component interaction descriptions
- Design document type — PRD, RFC, technical proposals
- Skill/Workflow definition type — Agent skill or workflow definitions
- General text — cannot be classified into the above categories
Match according to rule priority, and stop as soon as the first match is found. If the content type is ambiguous and difficult to determine, confirm with the user before continuing.
Step 2: Select review dimensions
According to the dimension selection mapping matrix in references/content-type-rules.md :
- Select allrequired dimensions
- for that content type. Scan the content for specific features, and referring to thefeature-driven dimension additionrules, select 1-2 highly relevant candidate dimensions from the candidate dimensions
- Ensure the final number of dimensions is between 3-5between
Report the identified content type and selected review dimensions to the user, then continue.
Step 3: Review dimension by dimension
For each dimension selected in Step 2:
- Read the paragraph for the corresponding dimension in references/dimension-checklist.md (read only the selected dimensions, not the full text)
- Review the content item by item against the checklist
- Record each finding and mark its severity level:
- Critical — will directly cause context failure, severe performance degradation, or systemic failure
- Important — affects context quality or efficiency, but will not cause system failure
- Suggestion — optimization suggestions; adopting them can improve context quality
- Provide specific improvement suggestions for each finding, pointing to concrete locations in the content (line numbers or paragraphs)
Review principles:
- Evidence-based: each finding must point to a concrete location in the content
- Do not invent: skip when a checkpoint does not apply; do not force annotations
- CE focus: focus on perspectives specific to context engineering; do not repeat content already covered by general code review
- For content not related to AI/agents: focus on general context principles (information organization, structuring, attention management), and note this in the report
Step 4: Generate review report
Read references/report-template.md to get the report template, and generate a complete report according to the template format.
The report includes:
- Basic information (content type, review dimensions, date, input source)
- Review summary (1-3 sentences of overall evaluation)
- Dimension-by-dimension findings (in table form, including severity level, location, finding, suggestion)
- Statistics (counts by severity level)
- Improvement priorities (Top 3-5, sorted by impact)
- Recommended reading (pointing to relevant CE skills)
Step 5: Quality verification
Check item by item; when omissions are found, return to the corresponding step to fix them:
- Content type is correctly identified and supported by evidence
- The number of selected dimensions is between 3-5
- Each finding points to a concrete location in the content
- Each finding has a corresponding improvement suggestion
- Severity levels are assigned reasonably (Critical is used only for truly severe issues)
- No non-existent issues were invented
- Report format matches the template
- Improvement priorities are sorted by impact
Edge Cases
- Content is too short (<20 lines): reduce dimensions to 2-3, and simplify the report
- Content is too long (>500 lines): review in sections; first scan the overall structure, then deeply analyze key paragraphs
- Content not related to AI/agents: it can still be reviewed from general context principles (information organization, structuring, attention management); note at the beginning of the report that the review focuses on general CE principles
- Binary or non-text files: inform the user that this is not supported, and suggest providing the corresponding document or source code
- File does not exist or is unreadable: report the error and terminate
- Mixed-type content: use the main file type to drive dimension selection, and note in the report that multiple types are involved