v3.2.0: distill universal Drupal-edit discipline as plugin skill
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 45/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Quiet
- Tech stack
- php
- Domain
- documentation, tooling
Research direction
First review the source at ~/Code/eviltickets/.claude/skills/drupal-edit-discipline/SKILL.md and compare its rules with the universal and project-specific lists in this issue. Check that marketplace-restructure PR #1 has merged and v3.1.0 has shipped before proceeding. Done means a published plugin skill contains only broadly applicable Drupal/PHP discipline, with project-specific rules left out.
Written by the indexing model from the issue text.
Description
Background
In eviltickets we evolved a project-scoped drupal-edit-discipline skill (.claude/skills/drupal-edit-discipline/SKILL.md) from clustered behavior instincts. About 70% of its content is project-specific (references /modules/custom/, /themes/beaudjango/, scripts/guide-content-*.php, .gsd/PUBLISHING-POLICY.md), but ~30% is universal Drupal/PHP discipline that would be valuable as a published plugin skill.
Universal subset worth extracting
These rules apply to any Drupal codebase:
- No quick hacks: reject
display: none/visibility: hidden/ opacity 0 to mask structural problems; fix the structural cause or flag the hack explicitly - Read before Edit on unfamiliar files: don't blind-edit
- No
git add -A/git add .: always explicit file names (avoids committing.env, credentials, large binaries) - Theme/template search pattern: Grep -> Read -> Edit, not Edit blindly
- Content scripts: Write the script, then Bash to verify before re-running
- Multiline
drush ev: better readability than single-line for entity load + inspection accessCheck(FALSE): required on admin-context entityQuery to avoid silent empty results
Out of scope (stays project-specific)
- Image generation prompt rules (eviltickets editorial style)
- NID portability (eviltickets-flavored, though general rule of avoiding hardcoded entity IDs is universal)
- CONTEXT.md / phase scaffolding (gsd-specific)
- Em dash / en dash content rule (eviltickets voice & tone)
- Hardcoded path conventions
Decision criteria
Worth doing only if there's evidence Tom or others use this rule set across multiple Drupal projects. If it stays a one-project asset, leave it where it is.
Source for distillation
~/Code/eviltickets/.claude/skills/drupal-edit-discipline/SKILL.md (committed at eviltickets .gsd/lessons/... / current HEAD)
When to do this
After the marketplace-restructure PR (#1) merges and v3.1.0 ships. This would be a v3.2.0 candidate.
- Dominant language
- PHP
- Stars
- 1
- Forks
- 0
- PR merge metrics
- No merged PRs in 30d
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from proofoftom/drupal-skills
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
All issues in proofoftom/drupal-skills
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
glpi-project/glpi#25842 ·
Maintainers usually reply within 1 day
-
sync-en
Difficulty 1/5 Under an hour Newbie friendliness 83/100
Maintainers usually reply within 1 day
-
sync-en
Difficulty 1/5 Under an hour Newbie friendliness 86/100
Maintainers usually reply within 3 days
-
Перевод устарел
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
Difficulty 1/5 Under an hour Newbie friendliness 85/100
Maintainers usually reply within 1 day