Claude Skill

he-learn

Prevent verified repeated failures and preserve lasting decisions in terse ADRs. Use when failures recur, prevention needs strengthening, or accepted decisions and steering need durable capture; skip ordinary one-off fixes and routine task updates.

LLM Mart · 0 points · 0 views 0 listing impressions 0 install-command copies
Virus-scanned Reviewed automatically before listing.

Full trust report

Download sgaabdu4-building-flutter-apps-.agents_skills_he-learn-c396097.zip · 3 KB
Part of sgaabdu4/building-flutter-apps — 14 skills

Install

skills CLI npx skills add https://github.com/sgaabdu4/building-flutter-apps/tree/main/.agents/skills/he-learn
Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install sgaabdu4-building-flutter-apps@llmmart
Git git clone https://github.com/sgaabdu4/building-flutter-apps.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole sgaabdu4/building-flutter-apps collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

Hard Eng Learn

  • Input = current task + observed attempts/results or explicit decision/steering. Reuse its authorization + participation mode. Hook checkpoints request this judgment; they do not establish recurrence, a cause, or permission to change other projects/global memory.
  • Outcome = verified prevention at its narrowest owner, an applicable decision record, or an explicit no-op/blocker. Keep proof + pending work in the same plan; no learning ledger or new task status. Existing tests/docs that already preserve the lesson need no duplicate record.
flowchart TD
  E[Current evidence] --> T{What changed?}
  T -->|Repeated failure| R[Research: confirm common cause]
  T -->|Lasting decision or steering| A[Decision capture]
  T -->|No durable gap| N[Continue without new files]
  R --> P[Repair cause and existing deterministic prevention]
  P --> L{Adequate executable prevention?}
  L -->|Yes| V[Original failure + nearby valid case]
  L -->|No; limitation demonstrated| S[Writing Great Skills: smallest procedural repair]
  S --> V
  A --> U[Check authority, applicability and future retrieval]
  V --> U
  U --> D[Record actual result; resume current stage]
  click R "../research/references/troubleshooting.md"
  click A "references/decisions.md"
  click S "../writing-great-skills/SKILL.md"
  click V "../he/references/testing.md"

Repeated failure → prevention

  • Recurrence = compare the actual attempts, failing boundary + conditions; identical error wording is insufficient. Use Research for distinguishing evidence before another similar retry. A first confirmed false-pass/protected-boundary defect still warrants immediate repair through its current owner.
  • Preference = remove the cause → repair existing invariant/type/test/checker/lint/hook/CI → add the smallest missing deterministic check. Reuse project-native tools. A new script needs repeated fragile logic or a required boundary existing commands cannot check; no checker per incident.
  • Proof = the real violating case must fail before repair and pass after it; a nearby valid case must remain valid. Put the check where recurrence would be caught, retain required gates, and name coverage limits. Do not weaken a check or turn a passing command into proof without inspecting its result.
  • Skill = last resort for the part executable prevention cannot adequately cover. State that limitation from evidence; reuse/repair an existing skill before adding one. Follow Writing Great Skills, including its repair route. Canonical location = .agents/skills/<name>/SKILL.md; only needed references/scripts belong beside it.
  • Behavioral proof = exercise the original request + nearby valid/non-trigger case. Material trigger, authority, action-order or completion changes need actual agent execution; a wording/metadata check alone is insufficient. Verify the future consumer reaches the rule when relevant. Failed/unknown proof stays unfinished; never promise universal non-recurrence.

Apply + continue

  • Decisions/steering = terse ADR capture. Inspect relevant accepted ADRs before applying a past lesson; current user instructions + verified applicability govern. A code/decision conflict may be a product regression, not stale documentation.
  • Scope = authorized local prevention continues through HE Build with affected checks; post-ship edits need fresh proof and separately authorized HE Ship delivery. Source-toolkit/global/cross-project changes require their own existing authority.
  • Progress = fix risk at the affected stage; learning does not seize unrelated work. No useful durable gap → no new artifact. Missing evidence/authority → retain the concrete next action in the existing plan. A checkpoint, ADR or skill is never a substitute for implementation and proof.
Files (building-flutter-apps)
  • references
    • decisions.md 2.5 KB
      # Decisions + steering
      
      Load when a user or authorized workflow makes, changes or questions a lasting project decision. Writing style = [Writing Great Skills](../../writing-great-skills/SKILL.md): minimal prose, explicit meaning, one owner, conditional detail only when needed.
      
      - Durable = a choice that constrains future architecture, interfaces, data, checks or working practice; retain its reason + material consequence. Routine progress, tentative ideas and one-task sequencing stay in the existing plan. Do not turn every user message into an ADR.
      - Location = `docs/adr/NNNN-short-name.md`; inspect existing records and preserve their numbering/conventions. Default to the next unused four-digit number. No separate index is needed while filenames + relevant links suffice. Product-wide current facts still belong in PRODUCT/DESIGN or their existing owner.
      - Authority = distinguish the user's accepted choice from a proposal, inferred preference or unverified assumption. A request to investigate is not acceptance. Existing authorization covers routine implementation choices; a record adds no new authority.
      - Capture = inspect source evidence, compare existing decisions, then write the smallest record below. Include only alternatives that explain the choice. Link the source decision/task and applicable proof; pending verification stays pending. Never copy secrets or raw transcripts.
      - Change = fix factual errors in place; a materially different accepted decision gets a new ADR and marks the previous record Superseded with a link. Preserve why the earlier choice existed. Uncertain drift → investigate; do not silently rewrite an active requirement to match possibly broken code.
      - Use = read the relevant Accepted record at the next affected planning/design/review step. Verify referenced paths + actual scope; an obsolete version or different project may invalidate applicability. Briefly record that use in the existing task evidence when validating a new learning route.
      
      ```markdown
      # NNNN — Decision
      
      Status: Proposed | Accepted | Superseded by [NNNN](NNNN-name.md)
      
      ## Context
      Constraint or evidence that made the choice necessary.
      
      ## Decision
      The choice, its scope and material exception.
      
      ## Consequences
      Benefit, tradeoff and any required follow-up.
      
      ## Evidence
      Decision source + actual verification, or the precise pending check.
      ```
      
      Select one Status. Use short paragraphs or parallel bullets; use a small Mermaid diagram only when it clarifies a real flow or relationship. Do not fill space with generic rationale or certify implementation from an Accepted decision.
      
  • SKILL.md 4.2 KB
    ---
    name: he-learn
    description: Prevent verified repeated failures and preserve lasting decisions in terse ADRs. Use when failures recur, prevention needs strengthening, or accepted decisions and steering need durable capture; skip ordinary one-off fixes and routine task updates.
    ---
    
    # Hard Eng Learn
    
    - Input = current task + observed attempts/results or explicit decision/steering. Reuse its authorization + participation mode. Hook checkpoints request this judgment; they do not establish recurrence, a cause, or permission to change other projects/global memory.
    - Outcome = verified prevention at its narrowest owner, an applicable decision record, or an explicit no-op/blocker. Keep proof + pending work in the same plan; no learning ledger or new task status. Existing tests/docs that already preserve the lesson need no duplicate record.
    
    ```mermaid
    flowchart TD
      E[Current evidence] --> T{What changed?}
      T -->|Repeated failure| R[Research: confirm common cause]
      T -->|Lasting decision or steering| A[Decision capture]
      T -->|No durable gap| N[Continue without new files]
      R --> P[Repair cause and existing deterministic prevention]
      P --> L{Adequate executable prevention?}
      L -->|Yes| V[Original failure + nearby valid case]
      L -->|No; limitation demonstrated| S[Writing Great Skills: smallest procedural repair]
      S --> V
      A --> U[Check authority, applicability and future retrieval]
      V --> U
      U --> D[Record actual result; resume current stage]
      click R "../research/references/troubleshooting.md"
      click A "references/decisions.md"
      click S "../writing-great-skills/SKILL.md"
      click V "../he/references/testing.md"
    ```
    
    ## Repeated failure → prevention
    
    - Recurrence = compare the actual attempts, failing boundary + conditions; identical error wording is insufficient. Use [Research](../research/references/troubleshooting.md) for distinguishing evidence before another similar retry. A first confirmed false-pass/protected-boundary defect still warrants immediate repair through its current owner.
    - Preference = remove the cause → repair existing invariant/type/test/checker/lint/hook/CI → add the smallest missing deterministic check. Reuse project-native tools. A new script needs repeated fragile logic or a required boundary existing commands cannot check; no checker per incident.
    - Proof = the real violating case must fail before repair and pass after it; a nearby valid case must remain valid. Put the check where recurrence would be caught, retain required gates, and name coverage limits. Do not weaken a check or turn a passing command into proof without inspecting its result.
    - Skill = last resort for the part executable prevention cannot adequately cover. State that limitation from evidence; reuse/repair an existing skill before adding one. Follow [Writing Great Skills](../writing-great-skills/SKILL.md), including its [repair route](../writing-great-skills/references/repair.md). Canonical location = `.agents/skills/<name>/SKILL.md`; only needed references/scripts belong beside it.
    - Behavioral proof = exercise the original request + nearby valid/non-trigger case. Material trigger, authority, action-order or completion changes need actual agent execution; a wording/metadata check alone is insufficient. Verify the future consumer reaches the rule when relevant. Failed/unknown proof stays unfinished; never promise universal non-recurrence.
    
    ## Apply + continue
    
    - Decisions/steering = [terse ADR capture](references/decisions.md). Inspect relevant accepted ADRs before applying a past lesson; current user instructions + verified applicability govern. A code/decision conflict may be a product regression, not stale documentation.
    - Scope = authorized local prevention continues through [HE Build](../he-build/SKILL.md) with affected checks; post-ship edits need fresh proof and separately authorized [HE Ship](../he-ship/SKILL.md) delivery. Source-toolkit/global/cross-project changes require their own existing authority.
    - Progress = fix risk at the affected stage; learning does not seize unrelated work. No useful durable gap → no new artifact. Missing evidence/authority → retain the concrete next action in the existing plan. A checkpoint, ADR or skill is never a substitute for implementation and proof.
    

Comments (0)

Sign in to join the conversation.

No comments yet.

Reviews (0)

No reviews yet.

Related