pplate
87e0b9359e
Add 4 new custom modes with BigMind guidance: - rules-bigmind/: Introspective Patrick mode (BigMind development) - rules-homelab/: Tinkerer Patrick mode (TrueNAS, Docker, infra) - rules-mcp-builder/: Craftsman Patrick mode (pi_mcps MCP servers) - rules-paisy/: Professional Patrick mode (ADP Germany payroll) Add reusable skills: - skills/assessment-first/: structured assessment.md before implementation - skills/bigmind-session-ritual/: mandatory session start/end ritual - skills/gitea-push/: conventional commit + Gitea push workflow - skills/new-mcp-server/: FastMCP scaffold procedure - skills-bigmind/, skills-homelab/, skills-mcp-builder/, skills-paisy/: mode-specific skill dirs Update existing rules: - rules-architect, rules-ask, rules-code, rules-debug, rules-orchestrator: add BigMind session guidance (search before task, announce focus, hypotheses) Add plans/MODES_AND_SKILLS_PLAN.md: full architecture document
2.5 KiB
2.5 KiB
name, description
| name | description |
|---|---|
| assessment-first | Writes a structured assessment.md before any implementation task. Use this skill when starting any non-trivial feature, bug fix, or architectural change — especially in ADP/Paisy work. Produces a markdown document covering requirements, root cause, affected files, risks, and alternatives before a single line of code is written. |
Assessment-First
When to use
Use this skill before implementing any non-trivial task:
- ADP/Paisy Jira tickets (mandatory)
- New MCP server design
- BigMind schema changes
- Homelab service deployment with unknowns
When NOT to use
- Trivial one-liner fixes (typos, config values)
- Tasks already covered by a prior assessment
Inputs required
- Task description or Jira ticket reference
- Affected module / file paths (if known)
- Any error logs, stack traces, or existing symptoms
Workflow
-
Name the file —
{MODULE}_{TICKET}_Assessment.mdfor Paisy, orPLAN.mdfor new builds -
Write the header section:
# Assessment: [Task Title] *Author: Lumen | Date: YYYY-MM-DD | Ticket: TICKET-ID* -
Requirements — What exactly needs to happen? What's the success criterion?
-
Root Cause Analysis (for bug fixes) — Why is this happening? Reference BigMind for known patterns:
memory_search_facts("bug-pattern [domain]")memory_search_chunks("[symptom keywords]")
-
Affected Files — List every file that will need to change
-
Risks — What could go wrong? DB migrations? API contract changes? Concurrent access?
-
Alternatives Considered — At least 2 alternatives, with brief rationale for the chosen approach
-
Implementation Plan — Ordered steps, numbered
-
Open Questions — Anything needing clarification before starting (tag with person's name if relevant)
Example (Paisy bug fix)
# Assessment: EAU FEX NPE + ORA-00001
*Author: Lumen | Date: 2026-04-01 | Ticket: ESIDEPAISY-12021*
## Root Cause
Two bugs: (1) NPE — getSendungsHeader() null for never-transmitted Anträge.
(2) ORA-00001 — duplicate hashes from ADVFEX C/S→PA migration.
## Affected Files
- CSVController.java:428 (null-check)
- AntragManager.java:766 (duplicate hash handling)
## Implementation Plan
1. Add null-check guard in CSVController
2. Add duplicate detection before batch flush in AntragManager
Troubleshooting
- If open questions block the assessment, write them down and ping the right person — don't guess
- For Paisy: assessment doc goes in
docs/within the relevant module