feat: ai-pattern-killer skill with 3-agent humanization pipeline#10
feat: ai-pattern-killer skill with 3-agent humanization pipeline#10
Conversation
|
Warning Rate limit exceeded
⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📝 WalkthroughWalkthroughAdds a comprehensive AI Pattern Killer skill featuring a three-agent pipeline (Detector, Rewriter, Scorer) with documentation, configuration files, and pattern databases to identify and rewrite AI-isms in content while learning from user feedback. Changes
Sequence DiagramsequenceDiagram
participant User
participant Humanize as /humanize Command
participant Detector as Detector Agent
participant Rewriter as Rewriter Agent
participant Scorer as Scorer Agent
participant PatternDB as Pattern Databases
participant LearningEngine as Learning Engine
User->>Humanize: Submit draft + voice examples
Humanize->>Detector: Load draft & config
Detector->>PatternDB: Read banned words/phrases/structures
Detector->>Detector: Scan draft line-by-line
Detector-->>Humanize: Return detection report with flags
Humanize->>Rewriter: Pass detected flags & draft
Rewriter->>PatternDB: Load rewriting strategies & examples
Rewriter->>Rewriter: Infer user voice from examples
Rewriter->>Rewriter: Rewrite flagged sections by priority
Rewriter-->>Humanize: Return rewritten draft with change log
Humanize->>Scorer: Pass rewritten draft
Scorer->>PatternDB: Load scoring rubric & calibration data
Scorer->>Scorer: Score sentences 1-10 on humanization
Scorer-->>Humanize: Return humanization scorecard
alt Low scores detected
Humanize->>Detector: Re-pass low-scoring sentences
Detector-->>Humanize: Return new flags
Humanize->>Rewriter: Rewrite again
end
Humanize->>LearningEngine: Log results & user corrections
LearningEngine->>PatternDB: Update pattern frequencies & severity
LearningEngine-->>User: Present final results & recommendation
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~22 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 9
🤖 Fix all issues with AI agents
In @.claude-plugin/plugin.json:
- Around line 30-33: The JSON array in plugin.json is missing a comma after the
"./agents/scorer.md" entry which breaks parsing; open the array containing
"./agents/detector.md", "./agents/rewriter.md", "./agents/scorer.md", and
"./agents/scout.md" and add a trailing comma after the "./agents/scorer.md"
element so the list is valid JSON (ensure the entries around
"./agents/scorer.md" and "./agents/scout.md" are separated by a comma).
In `@agents/detector.md`:
- Around line 14-18: The document currently instructs the detector to load four
pattern files but omits error handling; update the spec for the detector pattern
loader (the "Load all pattern files" step that reads
skills/ai-pattern-killer/patterns/banned_words.json, banned_phrases.json,
banned_structures.json, exceptions.json) to define concrete behavior: treat
missing pattern files as empty arrays and log a warning, treat malformed JSON as
a fatal error with a clear message, allow empty arrays ([]) and if all pattern
files are empty emit a "No patterns loaded" notice, treat missing
exceptions.json as "no exceptions" and proceed, and require validation that each
file is a JSON array with required fields and log the count of patterns loaded
per file.
- Line 27: Clarify and codify the regex behavior for banned_phrases: update
detector.md (and optionally SKILL.md) to state whether entries in
banned_phrases.json are treated as literals by default or as regex, define the
exact regex dialect supported (e.g., JavaScript/ECMAScript regex), and give
explicit escaping rules and an escape convention (recommendation: treat phrases
as literals by default and require a "regex:" prefix for regex entries), and add
examples showing a literal containing regex metacharacters and a prefixed regex
entry; reference the banned_phrases key and the "(regex-aware)" note on line 27
so implementers know to follow this specification.
In `@agents/scorer.md`:
- Around line 31-36: Clarify and revise the scoring weights so binary checks and
subjective assessments are normalized before combining: treat "Vocabulary" and
"Phrasing" (banned_words.json, banned_phrases.json) as binary flags with fixed
small weights (e.g., each 10–20% total) or convert them to a normalized scale,
and assign the remaining weight to the subjective dimensions "Structure", "Voice
match", and "Rhythm" so their combined influence is larger and more granular;
update the scorer documentation in agents/scorer.md to list the new
weights/normalization method and an example calculation showing how scores from
Vocabulary, Phrasing, Structure, Voice match, and Rhythm are scaled and
aggregated into the final score.
In `@skills/ai-pattern-killer/feedback/processing.md`:
- Around line 33-39: Implement the missing bulk-import handler for the "/flag
import" command (e.g., function handle_flag_import or process_flag_import) and
enforce the described security checks: validate the provided path using
os.path.abspath and allowlist it to the project root or a designated import
directory, enforce a 1MB file size limit before reading, parse and validate the
JSON against a strict schema (require "pattern" and "type", disallow additional
properties), sanitize each "pattern" by rejecting shell metacharacters (; | $ `)
and limiting length to 200 characters, and ensure regex safety by either
pre-compiling with a timeout/safe-regex checker or using a library that detects
catastrophic backtracking; reject the import and return clear errors when any
check fails.
In `@skills/ai-pattern-killer/learning/engine.md`:
- Around line 18-21: Add a new subsection that defines the exact comparison
rules used by the cross-referencing step: specify that a "detector miss" means
the Detector did not flag a span in the original text but the Scorer (which
re-checks against the pattern DB per agents/scorer.md) assigns a failing score
or identifies the same banned pattern in the rewritten text; state the "rewriter
low score" rule using the existing min_pass_score threshold (default 7) so any
sentence scored < min_pass_score by Scorer is flagged for re-pass and triggers
marking the Rewriter strategy for review; and define "three-agent agreement"
concretely as Detector not flagging the original span, Rewriter leaving the
sentence text unchanged, and Scorer giving a high pass score (e.g., 9–10) — in
which case the sentence is recorded as an exception or candidate for adding to
the exceptions list or relaxed rules; include the resulting actions: add missed
patterns to pattern DB, flag rewriting strategies on low scores, and add
agreed-ok items to exceptions.
- Around line 44-48: Add a short implementation spec for enforcing the "keep
last 500 corrections (FIFO)" rule for feedback_log.json: describe a
pruneFeedbackLog(maxEntries=500) routine that is called from
writeFeedbackEntry(entry) after appending, which loads feedback_log.json, trims
the oldest entries to maxEntries, and atomically writes back (write to temp file
then rename) to avoid corruption; note concurrency protection (file lock or
single-writer guarantee), memory considerations (stream or JSON-per-line if file
may be large), and include test cases: verify trimming after N+1 writes, atomic
replace behavior, and that changelog.json/examples.json are untouched. Reference
feedback_log.json, pruneFeedbackLog, writeFeedbackEntry, loadFeedbackLog, and
saveFeedbackLog so implementers can find where to add the logic.
In `@skills/ai-pattern-killer/patterns/banned_phrases.json`:
- Around line 13-14: The JSON entries mix regex-like patterns (e.g., the
"phrase" values "This is where .* comes in" and "Whether you're a .* or a") with
plain literal strings without indicating which are regex; update each object
(including the entries around the other flagged lines) to include a
discriminator field like "type": "regex" or "type": "literal" and ensure regex
entries use "type":"regex" while plain phrases use "type":"literal" (or adopt a
single documented convention and apply it consistently) so the detector can
unambiguously handle matching.
In `@skills/ai-pattern-killer/SKILL.md`:
- Line 97: Fix the stray bracket in the JSON phrase entry by replacing the value
"a]testament to" with "a testament to" so the inline JSON row (the object with
"phrase": "a]testament to", "alternative": "shows", "severity": "high") is valid
and will copy correctly into banned_phrases.json; update the phrase field to the
corrected string and run a quick JSON/markdown lint to ensure no other typos
remain.
🧹 Nitpick comments (18)
commands/humanize.md (2)
7-11: Add language specifier to fenced code block.Static analysis (markdownlint MD040) flags this code block as missing a language specifier. Since these are usage examples,
```textor```bashwould be appropriate.Proposed fix
-``` +```text /humanize [paste or reference your draft] /humanize file:path/to/draft.md /humanize clipboard</details> --- `69-78`: **Add language specifier to fenced code block.** Same markdownlint MD040 finding. `` ```markdown `` fits this results template block. <details> <summary>Proposed fix</summary> ```diff - ``` + ```markdown ## Humanized Draftcommands/flag.md (1)
7-12: Add language identifiers to fenced code blocks to satisfy markdownlint (MD040).The usage examples at lines 7, 39, 46, and 60 all lack a language identifier. Using
```textfor plain-text blocks would resolve the lint warnings throughout this file.Example fix for the first block
-``` +```text /flag "leverage" -> "use" /flag "In today's rapidly evolving" -> [cut] /flag structure: "triple bullets after every heading" -> "vary list lengths" /flag exception: "robust" reason: "I actually use this word" -``` +```skills/ai-pattern-killer/SKILL.md (1)
34-34: Doc hardcodes "Opus" as the orchestrator, butconfig.yamlassigns different models per agent.
config.yamlmaps detector→sonnet, rewriter→opus, scorer→haiku. Saying "Opus spawns 3 sub-agents" here could mislead users about which model does what. Consider replacing with a generic term like "the pipeline spawns 3 sub-agents."skills/ai-pattern-killer/config.yaml (1)
3-5: Clarify whethermax_rewrite_passes: 2means total passes or retries.SKILL.md says sentences scoring below 7 "get sent back to Agent 2 for another pass." With
max_rewrite_passes: 2, it's ambiguous whether this means 2 total passes (initial + 1 retry) or 2 additional retries (3 total). A brief inline comment in the YAML would prevent misinterpretation by the agents.Example clarification
scoring: min_pass_score: 7 - max_rewrite_passes: 2 + max_rewrite_passes: 2 # additional retries after initial rewriteagents/rewriter.md (1)
38-56: Add language identifiers to fenced code blocks (MD040).Both output example blocks (lines 38 and 45) lack language tags. Using
```textwould resolve the markdownlint warnings, consistent with the rest of the docs.skills/ai-pattern-killer/learning/engine.md (2)
35-35: Document the calibration bootstrap process.Line 35 references
rewriting/examples.jsonfor calibration, but per the PR description, examples.json is gitignored. This means:
- New users start with zero user samples
- Initial scorer calibration will be inaccurate
- First few
/humanizeruns may produce inconsistent scoresConsider documenting the cold-start calibration strategy and how users should populate initial samples.
📋 Suggested addition after line 35
**Cold Start (No User Samples):** - Scorer uses general "professional writing" baseline - First 3-5 `/humanize` runs: prompt user to save good rewrites as samples - Command: `/humanize --save-as-sample` to add rewritten text to examples.json - Minimum 5 samples recommended before calibration is reliable
40-40: Clarify the model version tracking fields.Line 40 mentions "track model version in feedback_log" but doesn't specify:
- Which field name (
model_version,ai_model,llm_version)?- What format (e.g.,
"gpt-4","claude-3-opus-20240229")?- Is this required or optional?
📋 Suggested clarification
- New AI models introduce new patterns (track model version in feedback_log) + - Field: `detected_by_model` (string, optional) + - Format: `"model-name"` or `"model-name@version"` + - Example: `"gpt-4"`, `"claude-3-opus-20240229"` + - Use to correlate pattern emergence with specific model releasesskills/ai-pattern-killer/feedback/processing.md (3)
11-14: Consider more conservative severity promotion thresholds.The current thresholds promote patterns quickly:
- 3 flags → medium severity
- 6 flags → high severity
This might cause false positives if a user is experimenting or flags a pattern multiple times while testing. Once a pattern reaches "high" severity, it will be flagged in "relaxed" mode (per detector.md line 23), potentially disrupting users who prefer lighter detection.
⚖️ Alternative threshold suggestion
Consider more conservative thresholds:
3. Check severity promotion thresholds - - 1-2 flags: low - - 3-5 flags: medium - - 6+ flags: high + - 1-4 flags: low + - 5-9 flags: medium + - 10+ flags: highOr add a time-decay factor:
- Flags within 24 hours count as 1 - Flags within 7 days count as 0.5 - Flags older than 30 days count as 0.25 - Prevents rapid promotion from repeated testing
36-39: Add language identifier to fenced code block.The code block at line 36 is missing a language identifier, which affects syntax highlighting and documentation rendering.
📝 Proposed fix
Users can seed patterns from external sources: -``` +```bash /flag import path/to/patterns.json-Format: array of
{"pattern": "...", "alternative": "...", "type": "word|phrase|structure"}
+
+Format: JSON array of objects with:
+```json
+[
- {
- "pattern": "leverage",
- "alternative": "use",
- "type": "word"
- },
- {
- "pattern": "in today's rapidly evolving",
- "alternative": "[cut entirely]",
- "type": "phrase"
- }
+]
+```</details> --- `19-25`: **Specify validation for pattern type detection.** The automatic pattern type detection (lines 22-24) needs validation rules: - What if a phrase starts with "structure:" by accident? - What about multi-word structures like "triple bullet syndrome"? - How are regex special characters in phrases handled? Without validation, the auto-detection could misclassify patterns. <details> <summary>📋 Suggested validation rules</summary> Add after line 25: ```markdown **Pattern Type Validation:** - **Single word:** - Must match `^\w+$` (alphanumeric + underscore only) - No spaces, no special characters - Automatically lowercase before storing - **Multi-word phrase:** - Contains spaces but not prefixed with "structure:" - Escape regex special characters before storing - Store both literal and regex-safe versions - **Structural description:** - Must start with exactly "structure:" prefix - Strip prefix before storing: "structure: triple bullets" → "triple bullets" - Store in banned_structures.json with detection pattern (not literal match) **Ambiguous Cases:** - `"before_after_pattern"`: treat as single word (underscore allowed) - `"structure: foo"` with trailing spaces: trim before checking prefix - Emoji or unicode: escape and store as phraseagents/scorer.md (4)
15-15: Document the default min_pass_score value.Line 15 says "usually 7" but line 38 says "default 7". The documentation should consistently specify:
- The default value if config.yaml is missing or doesn't contain min_pass_score
- The valid range (presumably 1-10)
- Whether this is configurable per-user or global
📋 Suggested clarification
1. Load scoring materials: - - `skills/ai-pattern-killer/config.yaml` (min_pass_score, usually 7) + - `skills/ai-pattern-killer/config.yaml` (min_pass_score: integer 1-10, default 7 if not set) - `skills/ai-pattern-killer/patterns/banned_words.json`
48-71: Clarify output format flexibility.The output format example (lines 48-71) shows a specific markdown structure, but it's unclear:
- Is this the exact required format, or an example?
- Can implementations adjust formatting (e.g., remove table borders, change headings)?
- Are all sections required (e.g., Score Distribution)?
If this is a strict template, implementations need clear specification. If it's flexible, that should be stated.
📋 Suggested clarification
Add before line 49:
**Format Requirements:** - Output must be valid markdown - Required sections: Overall score, Per-Sentence Scores, Below Threshold, Verdict - Optional sections: Score Distribution, additional analysis - Format can be adjusted for readability but must include all required data **Example Output:**
49-71: Add language identifiers to fenced code blocks.Multiple fenced code blocks (lines 49-71 and others in the file) are missing language identifiers. This affects syntax highlighting and documentation tooling.
📝 Proposed fix
## Output Format -``` +```markdown ## Humanization Scorecard ...Apply the same fix to other code blocks throughout the file (lines showing example command-line output should use `text` or `plaintext`). </details> --- `73-77`: **Expand cold-start calibration guidance.** Lines 73-77 describe calibration with varying sample counts, but "no user samples" (the initial state per PR description where examples.json is gitignored) gets only one line: "use general 'human writing' baseline." This lacks specifics: - What defines a "human writing baseline"? - How does the scorer assess voice match with 0 samples? - Should voice match be skipped entirely? New users will encounter this scenario immediately and need clearer guidance. <details> <summary>📋 Suggested expansion</summary> ```diff ## Calibration Notes -- With no user samples: use general "human writing" baseline +- **With 0 user samples:** + - Skip "Voice match" dimension (score as N/A, use 4 dimensions only) + - Use general "professional blog post" baseline for rhythm + - Prioritize vocabulary/phrasing/structure dimensions (binary + objective) + - Recommend user run `/humanize --save-sample` to build calibration data - With 1-5 samples: basic voice matching (sentence length + vocabulary)agents/detector.md (3)
41-41: Clarify pre-rewrite score methodology.Line 41 references "Estimated humanization score (pre-rewrite)" but doesn't explain how this is calculated. Without methodology, implementations will:
- Use inconsistent scoring approaches
- Produce scores that don't align with the scorer's post-rewrite rubric
- Confuse users when pre/post scores are calculated differently
This score should either be removed or clearly specified.
📋 Suggested specification
5. Summary stats: - Total flags by severity - Most common pattern type (word/phrase/structure) - - Estimated humanization score (pre-rewrite) + - Estimated humanization score (pre-rewrite): + - Start at 10 + - Subtract 2 per high-severity flag + - Subtract 1 per medium-severity flag + - Subtract 0.5 per low-severity flag + - Minimum score: 1 + - Note: This is a rough estimate; final score from Agent 3 may differAlternative: Remove this line entirely if the estimation methodology is unreliable.
29-29: Specify exception matching logic.Line 29 says "Skip anything in exceptions.json" but doesn't explain:
- How are exceptions matched (exact string, regex, structural pattern)?
- Do exceptions apply to words, phrases, structures, or all?
- What if an exception overlaps with a banned pattern (e.g., exception allows "leverage" in technical contexts)?
Without matching logic, implementations may inconsistently apply exceptions.
📋 Suggested matching specification
Add after line 29:
**Exception Matching Logic:** - Exceptions apply to specific pattern types (word/phrase/structure) - Match exceptions before checking banned patterns (exception takes precedence) - Exception matching: - Words: exact match, case-insensitive - Phrases: literal substring match in sentence - Structures: pattern name match - Exception with context (e.g., "leverage in technical docs"): - Check if context keywords present in surrounding sentences - Context must be within 2 sentences before/after
32-36: Add language identifiers to fenced code blocks.The example output blocks (lines 32-36, 44-57) are missing language identifiers. This affects documentation rendering and syntax highlighting.
📝 Proposed fix
4. Output flagged version with inline annotations: - ``` + ```text Line 3: "leverage" [WORD:high] -> "use" ... ``` ## Output Format -``` +```markdown ## Detection Report ...</details> Also applies to: 44-57 </blockquote></details> </blockquote></details> <!-- This is an auto-generated comment by CodeRabbit for review status -->
| ## Bulk Import | ||
|
|
||
| Users can seed patterns from external sources: | ||
| ``` | ||
| /flag import path/to/patterns.json | ||
| ``` | ||
| Format: array of `{"pattern": "...", "alternative": "...", "type": "word|phrase|structure"}` |
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major
🧩 Analysis chain
🏁 Script executed:
# First, let's understand the repository structure
find . -type f -name "processing.md" | head -20Repository: rohitg00/pro-workflow
Length of output: 114
🏁 Script executed:
# List the main directory structure
ls -la | head -20Repository: rohitg00/pro-workflow
Length of output: 1266
🏁 Script executed:
# Search for files in the skills/ai-pattern-killer directory
fd . skills/ai-pattern-killer --type f | head -30Repository: rohitg00/pro-workflow
Length of output: 590
🏁 Script executed:
# Read the processing.md file with line numbers to verify the content at lines 33-39
cat -n skills/ai-pattern-killer/feedback/processing.mdRepository: rohitg00/pro-workflow
Length of output: 1545
🏁 Script executed:
# Search for any bulk import implementation in the codebase
rg -n "flag.*import|bulk.*import" --type-list | head -10
rg -n "flag.*import|bulk.*import" -A 10Repository: rohitg00/pro-workflow
Length of output: 1196
🏁 Script executed:
# Search for flag command implementation
rg -n "flag" -i --type py --type js --type md -A 5 | head -100Repository: rohitg00/pro-workflow
Length of output: 8243
🏁 Script executed:
# Check if there's any Python implementation or command handler
fd "\.py$|\.js$" skills/ai-pattern-killerRepository: rohitg00/pro-workflow
Length of output: 47
🏁 Script executed:
# Look for any actual command implementation
fd "\.py$|\.js$" | head -50Repository: rohitg00/pro-workflow
Length of output: 262
🏁 Script executed:
# Check if there's a commands directory with implementation
ls -la commands/
cat -n commands/flag.mdRepository: rohitg00/pro-workflow
Length of output: 3234
🏁 Script executed:
# Search for any implementation of the flag command or import logic
rg -n "import.*json|parse.*json|sanitize|validate" --type py --type jsRepository: rohitg00/pro-workflow
Length of output: 47
🏁 Script executed:
# Check the main skill file and configuration
cat -n skills/ai-pattern-killer/SKILL.mdRepository: rohitg00/pro-workflow
Length of output: 13329
🏁 Script executed:
# Search for any implementation of the flag command or JSON import handling
rg -n "import.*patterns|parseJSON|readFile.*json" --type py --type js -A 5Repository: rohitg00/pro-workflow
Length of output: 47
🏁 Script executed:
# Check if there's any JavaScript in the commands directory or elsewhere that implements the flag command
find . -name "*.js" -o -name "*.ts" | xargs grep -l "flag\|import.*json" 2>/dev/null | head -20Repository: rohitg00/pro-workflow
Length of output: 47
🏁 Script executed:
# Look at package.json to understand what the project is
cat -n package.jsonRepository: rohitg00/pro-workflow
Length of output: 1792
🏁 Script executed:
# Search more broadly for any file that might contain the implementation
rg -n "def.*import|function.*import|export.*import" --type py --type js -B 2 -A 5Repository: rohitg00/pro-workflow
Length of output: 47
🏁 Script executed:
# Check if there's a TypeScript/JavaScript source directory for the actual implementation
find . -type d -name "src" -o -type d -name "lib" -o -type d -name "dist"Repository: rohitg00/pro-workflow
Length of output: 70
🏁 Script executed:
# Look for any implementation files related to the flag command
find . -name "*.ts" -o -name "*.js" | xargs grep -l "flag.*import\|bulk.*import" 2>/dev/nullRepository: rohitg00/pro-workflow
Length of output: 49
🏁 Script executed:
# Check the entire structure to understand if this is documentation or actual code
tree -L 3 --gitignoreRepository: rohitg00/pro-workflow
Length of output: 1500
🏁 Script executed:
# Let's examine what the repository actually contains
git ls-files | head -100Repository: rohitg00/pro-workflow
Length of output: 1864
🏁 Script executed:
# Check the TypeScript source files for any flag command implementation
find src -name "*.ts" -type f -exec cat -n {} +Repository: rohitg00/pro-workflow
Length of output: 16349
🏁 Script executed:
# Search specifically for flag or import handling in source
rg -n "flag|import.*json|bulk" src/ --type ts -A 5Repository: rohitg00/pro-workflow
Length of output: 47
🏁 Script executed:
# Check what's in the agents directory - these might contain implementation logic
ls -la agents/Repository: rohitg00/pro-workflow
Length of output: 544
🏁 Script executed:
# Verify this is truly a template/documentation project by checking if there's any actual command implementation
rg -n "process.argv|commander|yargs|flag.*command" src/ scripts/ --type ts --type jsRepository: rohitg00/pro-workflow
Length of output: 47
🏁 Script executed:
# Check if the flag command is actually implemented anywhere or just documented
cat -n commands/flag.md | head -70Repository: rohitg00/pro-workflow
Length of output: 2393
Secure the bulk import feature before implementation.
The /flag import path/to/patterns.json feature is currently documented but not implemented. When building this feature, enforce these validation requirements:
- Path validation: Restrict file access to allowed directories using allowlist pattern (e.g.,
os.path.abspath()must start with project root or designated import directory) - File size limit: Reject files exceeding 1MB to prevent denial-of-service
- JSON schema validation: Enforce required fields (
pattern,type) and reject unknown fields - Pattern sanitization: Block patterns containing shell metacharacters (
;,|,$,`) and limit length to 200 characters - Regex safety: Validate regex patterns don't cause catastrophic backtracking
🧰 Tools
🪛 markdownlint-cli2 (0.20.0)
[warning] 36-36: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🤖 Prompt for AI Agents
In `@skills/ai-pattern-killer/feedback/processing.md` around lines 33 - 39,
Implement the missing bulk-import handler for the "/flag import" command (e.g.,
function handle_flag_import or process_flag_import) and enforce the described
security checks: validate the provided path using os.path.abspath and allowlist
it to the project root or a designated import directory, enforce a 1MB file size
limit before reading, parse and validate the JSON against a strict schema
(require "pattern" and "type", disallow additional properties), sanitize each
"pattern" by rejecting shell metacharacters (; | $ `) and limiting length to 200
characters, and ensure regex safety by either pre-compiling with a
timeout/safe-regex checker or using a library that detects catastrophic
backtracking; reject the import and return clear errors when any check fails.
| ## Data Retention | ||
|
|
||
| - feedback_log.json: keep last 500 corrections (FIFO) | ||
| - changelog.json: keep indefinitely (audit trail) | ||
| - examples.json: keep all (training data) |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
find . -type f -name "*.md" | grep -i engine | head -20Repository: rohitg00/pro-workflow
Length of output: 110
🏁 Script executed:
#!/bin/bash
# First, let's find the file and check its content
fd "engine\.md" -type fRepository: rohitg00/pro-workflow
Length of output: 235
🏁 Script executed:
#!/bin/bash
# Search for FIFO/pruning/retention logic across the codebase
rg -n "FIFO|prune|trim|rotate|feedback_log" --type=py --type=js --type=ts --type=json -A 3Repository: rohitg00/pro-workflow
Length of output: 2871
🏁 Script executed:
#!/bin/bash
# Check for retention or cleanup related functions
rg -n "retention|cleanup|max.*500|array.*length|feedback" --type=py --type=js --type=ts -A 2 | head -100Repository: rohitg00/pro-workflow
Length of output: 47
🏁 Script executed:
cat -n ./skills/ai-pattern-killer/learning/engine.mdRepository: rohitg00/pro-workflow
Length of output: 2058
🏁 Script executed:
#!/bin/bash
# Search for feedback_log across all files
rg "feedback_log" -n -A 3 -B 3Repository: rohitg00/pro-workflow
Length of output: 2568
🏁 Script executed:
#!/bin/bash
# Check the structure of ai-pattern-killer directory
find ./skills/ai-pattern-killer -type f -name "*.py" -o -name "*.js" -o -name "*.ts" | head -20Repository: rohitg00/pro-workflow
Length of output: 47
🏁 Script executed:
#!/bin/bash
# List all files in ai-pattern-killer
find ./skills/ai-pattern-killer -type f | head -30Repository: rohitg00/pro-workflow
Length of output: 612
🏁 Script executed:
#!/bin/bash
# Check if feedback_log.json exists or is referenced
rg "feedback_log\.json" -n -B 2 -A 2Repository: rohitg00/pro-workflow
Length of output: 1618
🏁 Script executed:
#!/bin/bash
# Search for code that writes/processes feedback_log (broader search)
rg "feedback" -n --type-list | head -20Repository: rohitg00/pro-workflow
Length of output: 454
🏁 Script executed:
#!/bin/bash
# Search for any code files that might handle feedback_log logic
find . -type f \( -name "*.py" -o -name "*.js" -o -name "*.ts" \) -exec grep -l "feedback_log\|FIFO\|prune\|retention" {} \; | head -20Repository: rohitg00/pro-workflow
Length of output: 47
🏁 Script executed:
cat ./skills/ai-pattern-killer/feedback/feedback_log.jsonRepository: rohitg00/pro-workflow
Length of output: 354
🏁 Script executed:
cat ./skills/ai-pattern-killer/config.yamlRepository: rohitg00/pro-workflow
Length of output: 539
🏁 Script executed:
#!/bin/bash
# Broad search across entire repo for any code implementation
find . -type f \( -name "*.py" -o -name "*.js" -o -name "*.ts" -o -name "*.sh" \) | wc -lRepository: rohitg00/pro-workflow
Length of output: 67
🏁 Script executed:
#!/bin/bash
# Search in scripts directory for any feedback handling
find ./scripts -type f -name "*.js" -o -name "*.sh" | xargs grep -l "feedback\|log\|prune" 2>/dev/nullRepository: rohitg00/pro-workflow
Length of output: 278
🏁 Script executed:
#!/bin/bash
# Check each script for feedback/log/retention handling
for script in ./scripts/*.js; do
echo "=== $script ==="
grep -i "feedback\|log.*json\|retention\|prune" "$script" || echo "No matches"
doneRepository: rohitg00/pro-workflow
Length of output: 430
🏁 Script executed:
#!/bin/bash
# Check if there are implementation details in the SKILL.md
cat ./skills/ai-pattern-killer/SKILL.mdRepository: rohitg00/pro-workflow
Length of output: 11362
Document the FIFO pruning implementation for feedback_log.json before implementation begins.
Line 46 specifies "keep last 500 corrections (FIFO)" but provides no enforcement mechanism. No code in the repository currently implements this constraint. Without automated pruning, the log file will grow indefinitely, causing increased disk usage, slower I/O, and potential memory issues when loaded.
Add implementation details after line 48:
Recommended documentation addition
- feedback_log.json: keep last 500 corrections (FIFO)
- changelog.json: keep indefinitely (audit trail)
- examples.json: keep all (training data)
+
+### Retention Implementation
+
+**feedback_log.json pruning:**
+- After each write, check array length
+- If length > 500, keep only the last 500: `corrections = corrections[-500:]`
+- Preserve the structure: `{"corrections": [...], "_schema": {...}}`
+
+**changelog.json:**
+- Append-only, no pruning
+
+**examples.json:**
+- No pruning, but validate max file size (warn if > 10MB)📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| ## Data Retention | |
| - feedback_log.json: keep last 500 corrections (FIFO) | |
| - changelog.json: keep indefinitely (audit trail) | |
| - examples.json: keep all (training data) | |
| ## Data Retention | |
| - feedback_log.json: keep last 500 corrections (FIFO) | |
| - changelog.json: keep indefinitely (audit trail) | |
| - examples.json: keep all (training data) | |
| ### Retention Implementation | |
| **feedback_log.json pruning:** | |
| - After each write, check array length | |
| - If length > 500, keep only the last 500: `corrections = corrections[-500:]` | |
| - Preserve the structure: `{"corrections": [...], "_schema": {...}}` | |
| **changelog.json:** | |
| - Append-only, no pruning | |
| **examples.json:** | |
| - No pruning, but validate max file size (warn if > 10MB) |
🤖 Prompt for AI Agents
In `@skills/ai-pattern-killer/learning/engine.md` around lines 44 - 48, Add a
short implementation spec for enforcing the "keep last 500 corrections (FIFO)"
rule for feedback_log.json: describe a pruneFeedbackLog(maxEntries=500) routine
that is called from writeFeedbackEntry(entry) after appending, which loads
feedback_log.json, trims the oldest entries to maxEntries, and atomically writes
back (write to temp file then rename) to avoid corruption; note concurrency
protection (file lock or single-writer guarantee), memory considerations (stream
or JSON-per-line if file may be large), and include test cases: verify trimming
after N+1 writes, atomic replace behavior, and that changelog.json/examples.json
are untouched. Reference feedback_log.json, pruneFeedbackLog,
writeFeedbackEntry, loadFeedbackLog, and saveFeedbackLog so implementers can
find where to add the logic.
Self-updating AI pattern detector and humanizer that learns from corrections. Spawns 3 sub-agents (detector, rewriter, scorer) to flag, rewrite, and score content. Includes 30 banned words, 25 banned phrases, 10 banned structures as seed data, with /flag and /humanize commands.
rohitg00
force-pushed
the
feat/ai-pattern-killer
branch
from
cdc0dd7 to
561c5b8
Compare
- detector.md: add error handling spec for pattern file loading (missing=empty, malformed=fatal) - detector.md: define phrase matching rules (literal default, regex: prefix, ECMAScript dialect) - scorer.md: replace equal weights with normalized scoring (20% binary checks, 80% subjective) - processing.md: add bulk import security spec (path validation, 1MB limit, schema check, regex safety) - engine.md: define cross-reference rules (detector miss, rewriter low score, 3-agent agreement) - engine.md: add pruneFeedbackLog spec (FIFO 500, atomic write, test cases) - banned_phrases.json: add "type": "literal"|"regex" discriminator to all entries - SKILL.md: fix "a]testament to" typo, update inline examples with type field
|
Addresses: #11 |
|
Closing — ai-pattern-killer is a writing/content humanization tool which doesn't align with pro-workflow's scope (DevOps/coding workflows). The PR is also outdated and would conflict with the v3.0 agent and plugin structure. Thanks for the contribution! |
1 participant
Summary
ai-pattern-killerskill — self-updating AI pattern detector and humanizer/flag(add patterns) and/humanize(run the pipeline)Files
skills/ai-pattern-killer/— 10 files across 5 folders (patterns, feedback, rewriting, learning)agents/detector.md,agents/rewriter.md,agents/scorer.md— 3 specialized agentscommands/flag.md,commands/humanize.md— 2 user-facing commands.claude-plugin/plugin.json— registered new agentsTest plan
/flag "leverage" -> "use"and verify banned_words.json updates/humanizeon a draft and verify 3-agent pipeline executes/flagcallsSummary by CodeRabbit
New Features
Documentation
Chores